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

Область планирования и руководства программными проектами

Управление программными проектами — это процесс планирования и руководства программными проектами. ^[1] Это подраздел управления проектами , в котором программные проекты планируются, реализуются, контролируются и отслеживаются.

История

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

По мере развития отрасли анализ неудач в управлении программными проектами показал, что наиболее распространенными причинами являются следующие: ^{[2] [3] [4]}

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

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

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

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

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

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

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

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

Проблема

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

Например, OpenOffice.org называл свою модифицированную версию Bugzilla IssueZilla. С сентября 2010 года ^[update]они называют свою систему Issue Tracker. ^{[ требуется обновление ]}

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

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

Высокий

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

Середина

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

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

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

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

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

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

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

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

Философия

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

Ссылки

1. Stellman, Andrew; Greene, Jennifer (2005). Управление прикладными программными проектами. O'Reilly Media. ISBN 978-0-596-00948-9. Архивировано из оригинала 2015-02-09.
2. «Почему программное обеспечение терпит неудачу», в IEEE Spectrum
3. Производство программного обеспечения с открытым исходным кодом: как запустить успешный проект свободного программного обеспечения (электронная книга, доступна для бесплатной загрузки), Карл Фогель
4. Роберт Фрезе и Вики Сотер , «Повышение шансов на успех программного проекта», IEEE Engineering Management Review , том 42, № 4, четвертый квартал, декабрь 2014 г.
5. Филип Гринспан , в книге Джессики Ливингстон « Основатели на работе » (2007), ISBN 1-59059-714-1 
6. Дейн, Бертрам (2009). "Социальная природа отслеживания проблем в программной инженерии" (PDF) . Архивировано из оригинала (PDF) 2016-11-08 . Получено 2023-10-07 .
7. Джон К. Рейнольдс, Некоторые мысли о преподавании программирования и языков программирования , SIGPLAN Notices, том 43, выпуск 11, ноябрь 2008 г., стр. 108: «Некоторые утверждают, что можно управлять производством программного обеспечения, не умея программировать. Это убеждение, по-видимому, возникает из ошибочного представления о том, что производство программного обеспечения является формой производства. Но производство — это повторяющееся создание идентичных объектов, в то время как производство программного обеспечения — это создание уникальных объектов, т. е. весь процесс является формой проектирования. Как таковой он ближе к производству газеты [sic] — так что менеджер по программному обеспечению, который не умеет программировать, сродни главному редактору, который не умеет писать».

Общий

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

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

• Медиа, связанные с управлением программными проектами на Wikimedia Commons

• Роберт Фрезе (16.12.2003). «УСПЕХ И НЕУДАЧА ПРОЕКТА: ЧТО ТАКОЕ УСПЕХ, ЧТО ТАКОЕ НЕУДАЧА И КАК ВЫ МОЖЕТЕ УВЕЛИЧИТЬ СВОИ ШАНСЫ НА УСПЕХ?». Университет Миссури-Сент-Луис . Получено 13.05.2015 .