Управление программными проектами

Управление программными проектами — это процесс планирования и руководства программными проектами. Это субдисциплина управления проектами , в которой проекты программного обеспечения планируются, реализуются, контролируются и контролируются.

История

В 1970-х и 1980-х годах индустрия программного обеспечения росла очень быстро, поскольку компьютерные компании быстро осознали относительно низкую стоимость производства программного обеспечения по сравнению с производством аппаратного обеспечения и схем. Для управления новыми усилиями по разработке компании применяли устоявшиеся методы управления проектами, но графики проектов срывались во время тестовых запусков, особенно когда возникала путаница в серой зоне между пользовательскими спецификациями и поставляемым программным обеспечением. Чтобы избежать этих проблем, методы управления программными проектами были сосредоточены на сопоставлении требований пользователей с поставляемыми продуктами с помощью метода, известного теперь как каскадная модель .

По мере развития отрасли анализ ошибок в управлении программными проектами показал, что наиболее распространенными причинами являются следующие:

1. Недостаточное участие конечных пользователей
2. Плохое общение между клиентами, разработчиками, пользователями и менеджерами проектов.
3. Нереалистичные или неясно сформулированные цели проекта.
4. Неточные оценки необходимых ресурсов.
5. Плохо определенные или неполные системные требования и спецификации.
6. Плохая отчетность о статусе проекта
7. Плохо управляемые риски
8. Использование незрелых технологий
9. Неспособность справиться со сложностью проекта.
10. Небрежные методы разработки
11. Политика заинтересованных сторон (например, отсутствие поддержки руководства или политика между клиентом и конечными пользователями)
12. Коммерческое давление

Первые пять пунктов в приведенном выше списке показывают трудности с формулированием потребностей клиента таким образом, чтобы надлежащие ресурсы могли достичь правильных целей проекта. Специальные инструменты управления программными проектами полезны и часто необходимы, но настоящее искусство управления программными проектами заключается в применении правильного метода, а затем в использовании инструментов для его поддержки. Без метода инструменты бесполезны. С 1960-х годов производители программного обеспечения разработали несколько методов управления проектами проприетарного программного обеспечения для собственного использования, а компьютерные консалтинговые фирмы также разработали аналогичные методы для своих клиентов. Сегодня методы управления программными проектами все еще развиваются, но текущая тенденция ведет от водопадной модели к более цикличной модели реализации проекта, имитирующей процесс разработки программного обеспечения.

Процесс разработки программного обеспечения

Процесс разработки программного обеспечения касается в первую очередь производственного аспекта разработки программного обеспечения , а не технического аспекта, такого как программные инструменты . Эти процессы существуют в первую очередь для поддержки управления разработкой программного обеспечения и, как правило, направлены на решение бизнес-задач. Многие процессы разработки программного обеспечения можно выполнять аналогично общим процессам управления проектами. Примеры:

• Межличностное общение , управление и разрешение конфликтов . Активное, частое и честное общение является наиболее важным фактором повышения вероятности успеха проекта и смягчения проблемных проектов. Команда разработчиков должна стремиться к участию конечных пользователей и поощрять их вклад в процесс разработки. Отсутствие участия пользователей может привести к неверному толкованию требований, нечувствительности к меняющимся потребностям клиентов и нереалистичным ожиданиям со стороны клиента. Разработчикам программного обеспечения, пользователям, менеджерам проектов, клиентам и спонсорам проектов необходимо регулярно и часто общаться. Информация, полученная в результате этих обсуждений, позволяет команде проекта анализировать сильные и слабые стороны, возможности и угрозы (SWOT) и действовать на основе этой информации, чтобы извлечь выгоду из возможностей и минимизировать угрозы. Даже плохие новости могут быть хорошими, если они сообщаются относительно рано, поскольку проблемы можно смягчить, если они не обнаружены слишком поздно. Например, непринужденная беседа с пользователями, членами команды и другими заинтересованными сторонами часто может выявить потенциальные проблемы раньше, чем формальные встречи. Все коммуникации должны быть необходима интеллектуально честная и аутентичная, а также регулярная, частая и качественная критика работы по развитию, при условии, что она осуществляется в спокойной, уважительной, конструктивной , без обвинений и гнева манере. Частое случайное общение между разработчиками и конечными пользователями, а также между менеджерами проектов и клиентами необходимо для того, чтобы проект оставался актуальным, полезным и эффективным для конечных пользователей и в рамках того, что может быть завершено. Эффективное межличностное общение, а также управление и разрешение конфликтов являются ключом к управлению программными проектами. Никакая методология или стратегия улучшения процессов не могут решить серьезные проблемы в общении или неправильном управлении межличностными конфликтами. Более того, результаты, связанные с такими методологиями и стратегиями улучшения процессов, улучшаются за счет улучшения коммуникации. Общение должно быть сосредоточено на том, понимает ли команда устав проекта и добивается ли команда прогресса в достижении этой цели. Конечным пользователям, разработчикам программного обеспечения и менеджерам проектов приходится часто задавайте элементарные , простые вопросы, которые помогут выявить проблемы до того, как они перерастут в катастрофу. Хотя участия конечных пользователей, эффективной коммуникации и командной работы недостаточно, они необходимы для обеспечения хорошего результата, а их отсутствие почти наверняка приведет к плохому результату.
• Управление рисками — это процесс измерения или оценки риска , а затем разработка стратегий по управлению риском. В целом используемые стратегии включают передачу риска другой стороне, избегание риска, уменьшение негативного эффекта риска и принятие некоторых или всех последствий конкретного риска. Управление рисками в управлении проектами программного обеспечения начинается с экономического обоснования запуска проекта, которое включает в себя анализ затрат и выгод , а также список запасных вариантов в случае провала проекта, называемый планом действий в чрезвычайных ситуациях .
  • Подвидом управления рисками является «Управление возможностями» , что означает то же самое, за исключением того, что потенциальный результат риска будет иметь положительное, а не отрицательное влияние. Хотя теоретически это рассматривается одинаково, использование термина «возможность», а не несколько негативного термина «риск», помогает сосредоточить внимание команды на возможных положительных результатах любого конкретного реестра рисков в их проектах, таких как побочные проекты, непредвиденные доходы. и бесплатные дополнительные ресурсы.
• Управление требованиями — это процесс идентификации, выявления , документирования, анализа, отслеживания , определения приоритетов и согласования требований, а затем контроля изменений и связи с соответствующими заинтересованными сторонами. Новая или измененная компьютерная система Управление требованиями, включающее анализ требований , является важной частью процесса разработки программного обеспечения ; посредством чего бизнес-аналитики или разработчики программного обеспечения определяют потребности или требования клиента; определив эти требования, они могут разработать решение.
• Управление изменениями — это процесс выявления, документирования, анализа, определения приоритетов и согласования изменений объема (управление проектом) , а затем контроля изменений и общения с соответствующими заинтересованными сторонами. Анализ влияния изменений новой или измененной области действия, включающий анализ требований на уровне изменений, является важной частью процесса разработки программного обеспечения ; посредством чего бизнес-аналитики или разработчики программного обеспечения выявляют изменившиеся потребности или требования клиента; определив эти требования, они могут перепроектировать или модифицировать решение. Теоретически каждое изменение может повлиять на сроки и бюджет программного проекта, и поэтому по определению перед утверждением необходимо включать анализ рисков и выгод .
• Управление конфигурацией программного обеспечения — это процесс определения и документирования самого объема разработки программного продукта, включая все подпродукты и изменения, а также обеспечение возможности передачи информации об этом соответствующим заинтересованным сторонам. В общем, используемые процессы включают контроль версий , соглашение об именах (программирование) и соглашения об архивировании программного обеспечения.
• Управление выпусками — это процесс идентификации, документирования, определения приоритетов и согласования выпусков программного обеспечения, а затем контроля графика выпуска и общения с соответствующими заинтересованными сторонами. Большинство программных проектов имеют доступ к трем программным средам, для которых может быть выпущено программное обеспечение; Разработка, тестирование и производство. часто существует больше сред для тестирования, называемого модульным тестированием , системным тестированием или интеграционным тестированием В очень крупных проектах, где распределенным командам необходимо интегрировать свою работу перед выпуском для пользователей, перед выпуском для пользовательского приемочного тестирования (UAT) .
  • Подмножеством управления выпусками, которое привлекает внимание, является управление данными , поскольку очевидно, что пользователи могут тестировать только на основе известных им данных, а «реальные» данные находятся только в программной среде, называемой «производство». Поэтому для проверки своей работы программистам часто приходится создавать «фиктивные данные» или «заглушки данных». Традиционно для этой цели когда-то использовались старые версии производственной системы, но поскольку компании все больше и больше полагаются на внешних участников при разработке программного обеспечения, данные компании могут не передаваться группам разработчиков. В сложных средах могут создаваться наборы данных, которые затем переносятся между тестовыми средами в соответствии с графиком выпуска тестов, во многом похожим на общий график выпуска программного обеспечения.
• Сопровождение и обновление — это процесс, в котором всегда учитываются требования и потребности клиентов. Они, несомненно, найдут ошибки, могут запросить новые функции, другие функции и дополнительные обновления. Таким образом, все эти запросы необходимо проверять и удовлетворять требованиям и удовлетворению клиентов.

Планирование, выполнение, мониторинг и контроль проекта

Целью планирования проекта является определение объема проекта, оценка необходимых работ и составление графика проекта . Планирование проекта начинается с требований , определяющих разрабатываемое программное обеспечение. , план проекта Затем разрабатывается в котором описываются задачи , которые приведут к завершению. — Выполнение проекта это процесс выполнения задач, определенных в плане проекта.

Цель мониторинга и контроля проекта — держать команду и руководство в курсе хода проекта. Если проект отклоняется от плана, руководитель проекта может принять меры по устранению проблемы. Мониторинг и контроль проекта включают в себя статусные встречи для сбора информации о статусе команды. Когда необходимо внести изменения, используется контроль изменений , чтобы поддерживать продукты в актуальном состоянии.

Проблема

В вычислительной технике термин «проблема» означает единицу работы по улучшению системы. Проблема может заключаться в ошибке , запрошенной функции , задаче, отсутствующей документации и т. д.

Например, OpenOffice.org раньше называл свою модифицированную версию Bugzilla IssueZilla. По состоянию на сентябрь 2010 г. они называют свою систему Issue Tracker.

Уровни серьезности

Проблемы часто классифицируются по уровням серьезности . Разные компании имеют разные определения серьезности, но некоторые из наиболее распространенных из них:

Высокий

Ошибка или проблема затрагивает важную часть системы и должна быть исправлена, чтобы она возобновила нормальную работу.

Середина

Ошибка или проблема затрагивает незначительную часть системы, но оказывает некоторое влияние на ее работу. Этот уровень серьезности назначается, когда затрагивается нецентральное требование системы.

Низкий / фиксированный

Ошибка или проблема затрагивает незначительную часть системы и очень незначительно влияет на ее работу. Этот уровень серьезности назначается, когда затрагивается нецентральное требование системы (и с более низкой важностью).

Тривиальный (косметический, эстетический)

Система работает корректно, но внешний вид не соответствует ожидаемому. Например: неправильные цвета, слишком большой или слишком маленький интервал между содержимым, неправильные размеры шрифта, опечатки и т. д. Это проблема самой низкой степени серьезности.

Управление проблемами

В некоторых реализациях процессов разработки программного обеспечения проблемы исследуются аналитиками по обеспечению качества, система проверяется на корректность, а затем передается обратно члену команды разработчиков для решения выявленной проблемы. Они также могут быть идентифицированы пользователями системы на этапе пользовательского приемочного тестирования (UAT) .

Проблемы можно фиксировать и сообщать о них с помощью систем отслеживания проблем или дефектов . В отсутствие официальной системы отслеживания проблем или дефектов обычным явлением является простое использование любой формы письменного общения, например электронной почты или мгновенных сообщений, для сообщения о существовании обнаруженной проблемы.

Философия

В качестве субдисциплины управления проектами некоторые считают управление разработкой программного обеспечения сродни управлению производством , которое может выполнять человек, обладающий навыками управления, но не имеющими навыков программирования. Джон К. Рейнольдс опровергает эту точку зрения и утверждает, что разработка программного обеспечения — это полностью дизайнерская работа, и сравнивает менеджера , который не умеет программировать , с главным редактором газеты , который не умеет писать .

Ссылки

Общий

• 16326:2019(E) - Международный стандарт ISO/IEC/IEEE. Системная и программная инженерия. Процессы жизненного цикла. Управление проектами . 2019. doi : 10.1109/IEESTD.2019.8932690 . ISBN  978-1-5044-6299-0 .
• 1058-1998 — Стандарт IEEE для планов управления программными проектами . 1998. doi : 10.1109/IEESTD.1998.88822 . ISBN  978-0-7381-1448-4 .
• Джалоте, Панкадж (2002). Управление программными проектами на практике . Аддисон-Уэсли. ISBN  0-201-73721-3 .
• Мурали Чемутури, Томас М. Кэгли младший и (2010). Управление программными проектами: лучшие практики, инструменты и методы . Издательство Дж. Росс. ISBN  978-1-60427-034-1 .

Внешние ссылки

• СМИ, связанные с управлением проектами программного обеспечения, на Викискладе?

Провал проекта

• Роберт Фрезе (16 декабря 2003 г.). «УСПЕХ И НЕУДАЧА ПРОЕКТА: ЧТО ТАКОЕ УСПЕХ, ЧТО ТАКОЕ НЕУДАЧА И КАК ВЫ МОЖЕТЕ УЛУЧШИТЬ СВОИ ШАНСЫ НА УСПЕХ?» . Университет Миссури-Сент. Луи . Проверено 13 мая 2015 г.