Управле́ние разрабо́ткой програ́ммного обеспе́чения (англ. Software project management) — особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по разработке программного обеспечения является правильный выбор метода разработки.

• Конечный результат проекта по разработке программного обеспечения нематериален
• Недостаточность накопленного в данной области опыта
• Быстрое изменение используемых в проекте технологий
• Опыт управления проектами по разработке программного обеспечения часто не может быть применён к другим проектам

В связи с быстрым увеличением мощностей компьютеров в 60-е и 70-е годы XX века проблемы, которые могли быть решены с их помощью, становились сложнее. Поэтому требовались более масштабные проекты, включавшие в себя координацию труда большего числа людей и написание гораздо большего объёма кода. Однако методы, применявшиеся к управлению такими проектами, были рассчитаны на решение задач в рамках намного меньших проектов. Отсутствие необходимой методологии привело к огромному числу провальных проектов. Попытки изменить положение к лучшему привели к созданию новой модели процесса разработки, концентрировавшей больше внимания на соответствие конечного программного продукта изначальным требованиям заказчика.

Исследования проектов, окончившихся неудачей, показали, что самыми распространёнными причинами провалов были:^[1]

1. Невыполнимые или неясно сформулированные цели проекта
2. Ошибочный подсчет необходимых ресурсов
3. Некорректно определённые системные требования
4. Неосведомлённость управляющего проектом о точном состоянии проекта
5. Неуправляемые риски
6. Слабое взаимодействие между заказчиком, разработчиком и пользователем
7. Использование слишком новых, нестабильных технологий
8. Неспособность справиться со сложностями проекта
9. Слабое управление проектом
10. Финансовые ограничения

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

ГОСТ 19 «Единая система программной документации»^[2] и ГОСТ 34 «Стандарты на разработку автоматизированных систем»^[3] ориентированы на последовательный подход в разработке программного обеспечения. Разработка в соответствии с этими стандартами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ. Строгое следование этим ГОСТам приводит к каскадной модели. На основе этих стандартов разрабатываются программные системы по госзаказам в России.

Данная модель была разработана в середине 80-х годов XX века Институтом программной инженерии, входящим в состав Университета Карнеги-Мелона с целью создать эталонную модель организации разработки программного обеспечения. Основана на проверке соответствия организации определённым требованиям и определении уровня зрелости процесса разработки программного обеспечения.

Унифицированный процесс был разработан компанией Rational Software в качестве дополнения к языку UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на её потребности.

Microsoft Solutions Framework построена на основе итеративной разработки. Особенностью MSF является большое внимание к созданию эффективной и небюрократизированной команды.

Personal Software Process определяет требования к компетенциям разработчика для того, чтобы они смогли получить необходимые навыки для Team Software Process. Team Software Process в комбинации с Personal Software Process делает ставку на самоуправляемые команды численностью 3-20 человек. Команды должны:

• Установить собственные цели
• Составить свой процесс и планы
• Отслеживать работу
• Поддерживать мотивацию и максимальную производительность

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

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

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

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

• Цель отслеживания и контроля за проектом заключается в поддержании соответствия действий команды текущему состоянию проекта. В случае отклонения проекта от плана управляющий проектом может оперативно исправлять выявленные ошибки. Отслеживание состояния проекта включает в себя регулярные встречи с командой для обсуждения текущего состояния проекта.

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

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

Оригинальный текст (англ.)

"Some argue that one can manage software production without the ability to program. This belief seems to arise from the mistaken view that software production is a form of manufacturing. But manufacturing is the repeated construction of identical objects, while software production is the construction of unique objects, i.e., the entire process is a form of design. As such it is closer to the production of a newpaper [sic] — so that a software manager who cannot program is akin to a managing editor who cannot write.

• Инженерия программного обеспечения
• Управление проектами
• Разработка программного обеспечения

• Липаев В. В. Программная инженерия. Методологические основы — Москва: «ТЕИС», 2006 — ISBN 5-7598-0424-3
• Уокер Ройс Управление проектами по созданию программного обеспечения — Москва: «Лори», 1998 — ISBN 5-85582-156-0

• С.Архипенков: Лекции по управлению программными проектами

Нерабочая ссылка