Предпосылки возникновения понятия ЖЦ

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

В октябре 1968 года в немецком городе Гармиш (Garmish) прошла конференция подкомитета NATO по науке и технике. На этой конференции присутствовало пятьдесят профессиональных разра-ботчиков ПО из одиннадцати стран. Наряду с тем, что большинство обсуждений было сосредоточено на технических аспектах проектирования, производства, реализации, распространения и поддержки программ, также рассматривались отчеты о "трудностях планирования встреч и заданий в больших программных проектах". Это, возможно, было первое общественное признание важности управления программными проектами. Вскоре после этого в Хедсор Парк (Hedsor Park), уединенном местечке вблизи Лондона, собрались двадцать два руководителя из различных стран, которые курировали разработку ПО в академиях, научно-исследовательских лабораториях и на предприятиях. На этой встрече упоминалось оконференции NATO, а также производился анализ будущих направлений развития процесса разработки ПО. Здесь специалисты впервые серьезно заговорили о надвигающемся "кризисе ПО". Он был связан со все более усиливающимся воздействием ПО на жизнь людей, вследствие чего процессы разработки требовали постоянного усовершенствования. В результате была предложена концепция жизненного цикла (ЖЦ) разработки ПО (Software life cycle, SLC).

Эта модель реализует последовательность событий, происходящих при разработке ПО. Определение цикла SLC, равно как и споры относительно смысла его существования,было предметом многих бесед и публикаций, связанных с индустрией ПО. Несмотря на существование различных точек зрения, потребность в документально подтвержденном процессе разработки ПО осталась столь же актуальной. В 1970 году У.У. Ройс (W.W. Royce) произвел идентификацию нескольких стадий в типичном цикле SLC. Именно Ройс и Барри Боэм (Barry Boehm) предположили, что осуществление контроля каждой стадии процесса разработки приведет к улучшению качества ПО, а также к увеличению производительности при разработке программ. Например, работа по проектированию интерфейсов программного модуля может быть отложена до тех пор, пока не будут определены конечные требования. Благодаря этому сокращается количество возможных переделок. В этом случае идет речь о каскадной модели цикла, который схематически представлен на рис. 1.1.

 

 

Рис. 1.1. Каскадная модель жизненного цикла разработки ПО

 

 

Действия по разработке ПО "протекают" на графике последовательно, от блока к блоку. На самом деле, большинство действий в ходе выполнения проектов не происходят по линейному закону. За-частую разработчикам бывает необходимо возвратиться к предыдущей стадии, чтобы выполнить зада-чи, которые не были в свое время разрешены соответствующим образом. Если на стадии разработки обнаруживается отсутствие или неправильное формулирование требований, разработчик не продвига-ется вперед, а возвращается назад - к стадии спецификаций требований. После завершения и коррекции спецификаций требований повторно вводится и начинает выполняться стадия разработки. Повторяющаяся каскадная модель напоминает каскадную модель, в которой возможен возврат к любому предыдущему блоку. Чтобы отобразить повторяющийся характер разработки ПО, в графике были добавлены обратные стрелки, в результате чего получился график стандартного жизненного индустриального цикла (рис. 1.2).

 

Рис. 1.2. Повторяющаяся каскадная модель жизненного цикла разработки ПО

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

На ранних стадиях управления программными проектами на роли менеджеров проектов выдвигались лучшие программисты. Это было связано с тем, что они демонстрировали компетентность в вопросах, касающихся использования инструментов (языки программирования, компиляторы и т.д.) или приложений, выполняющихся в режиме реального времени. Но зачастую они не преуспевали в этой должности, поскольку не были подготовлены к возникновению ситуаций, не относящихся к их предметной области. Сегодня каждому менеджеру программного проекта требуются навыки, далеко выходящие за пределы познаний о принципах программирования. Опыт в деле разработки ПО, конечно, необходим, но хороший менеджер также должен превосходить других специалистов в навыках управления персоналом и проектами. К настоящему времени составлен перечень компетенций, используемых менеджерами наиболее успешных программных проектов, его разбили на три категории: продукт, проект и персонал. Этот перечень основывается на опыте многих практикующих менеджеров программных проектов, которые вносили вклад в программу сертификации менеджмента программных проектов (SWPM) в Техасском университете с 1993 по 2001 годы.

Перечень компетенций содержится в документе Body of Knowledge (SQI BOK), разработанный Институтом качества ПО. Всего этих компетенций - 34, они разделены на три труппы. Рассмотрим коротко эти группы компетенций последовательно.

Методики разработки продукта (11 компетенций).

1. Процессы оценивания - определение критериев для обзора.

2. Знание стандартов процесса - понимание стандартов процесса.

3. Определение продукта - идентификация клиентской среды и требований, выдвигаемых к продукту.

4. Оценка альтернативных процессов - оценка различных подходов.

5. Управление требованиями - мониторинг изменений требований.

6. Управление субподрядчиками - планирование, управление и осуществление контроля.

7. Выполнение начальной оценки - оценка степени трудности, рисков, затрат и создание графика.

8. Отбор методов и инструментов - определение процессов отбора.

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

10. Отслеживание качества продукта - контроль качества в процессе разработки продукта.

11. Понимание действий по разработке продукта - изучение цикла разработки ПО.

Навыки менеджмента проектов (11 компетенций).

1. Создание структуры пооперационного перечня работ — создание структуры WBS для проекта.

2. Документирование планов - идентификация ключевых компонентов.

3. Оценка стоимости - оценка стоимости завершения проекта.

4. Оценка трудозатрат - оценка трудозатрат, необходимых для завершения проекта.

5. Менеджмент рисков - идентификация, определение воздействия и обработка рисков.

6. Отслеживание процесса разработки - контроль процесса разработки ПО.

7. Составление графика - разработка графика и ключевых стадий проекта.

8. Выбор метрических показателей - выбор и использование соответствующих метрических показателей.

9. Отбор инструментов менеджмента проектов - методики, используемые при выборе инструментов менеджмента проектов.

10. Отслеживание процессов - мониторинг совместимости среди членов команды разработчиков.

11. Отслеживание хода разработки проекта - мониторинг хода разработки проекта.

Навыки менеджмента персонала (12 компетенций).

1. Оценка производительности - оценка действий команды, направленных на улучшение ее производительности.

2. Вопросы интеллектуальной собственности - понимание степени влияния критических проблем.

3. Организация эффективных встреч - планирование и проведение эффективных встреч.

4. Взаимодействие и общение - взаимодействие с разработчиками, высшим руководством и другими командами.

5. Лидерство - обучение проектных команд для получения оптимальных результатов.

6. Управление изменениями - обеспечение эффективного управления изменениями.

7. Успешное ведение переговоров - разрешение конфликтов и успешное ведение переговоров.

8. Планирование карьерного роста - структурирование и управление ходом реализации карьеры.

9. Эффективное представление - эффективное использование письменных и устных навыков.

10. Набор персонала - успешная вербовка и собеседование с членами команды.

11. Отбор команды - отбор высококомпетентных специалистов.

12. Создание команды - формирование, руководство и поддержка эффективной команды.