Управление разработкой программного обеспечения

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

Основные отличия от других видов управления проектами[править | править вики-текст]

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

История[править | править вики-текст]

Причины возникновения[править | править вики-текст]

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

Дальнейшее развитие[править | править вики-текст]

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

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

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

Основные методы разработки программного обеспечения[править | править вики-текст]

ГОСТы[править | править вики-текст]

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

SW-CMM[править | править вики-текст]

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

RUP[править | править вики-текст]

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

MSF[править | править вики-текст]

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

PSP/TSP[править | править вики-текст]

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

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

Agile[править | править вики-текст]

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

Сопутствующие процессы при управлении проектом[править | править вики-текст]

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

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

Планирование, отслеживание и контроль за проектом[править | править вики-текст]

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

Философия[править | править вики-текст]

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

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

См. также[править | править вики-текст]

Примечания[править | править вики-текст]

  1. IEEE статья Robert N. Charette на английском "Why Software Fails"
  2. [1] ЕСПД на сайте ФГУП Стандартинформ
  3. [2] ГОСТ 34 на rugost.com

Литература[править | править вики-текст]

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

Ссылки[править | править вики-текст]