Эволюция методологий разработки по

Начало истории развития дисциплины управления проектами и проектного менеджмента относят к 30-м годам 20го века и связывают с появлением новых методов подготовки, анализа и исполнения крупных проектов в США – в фирмах «US Air Corporation» (авиационные проекты) и «Exon» (нефтегазовые). В это же время в СССР начинает появляться теория и практика потоковой организации работ на строительных проектах большого масштаба [1] .

В конце 60х – начале 70х годов появляются первые предпосылки внедрения принципов управления проектами в процессы разработки ПО [2] :

• 1.    Первый кризис программного обеспечения

• 2.    Изменение взглядов на разработку софта

Первый кризис программного обеспечения.

На Конференции НАТО «Инженерия программного обеспечения» в 1968 Фридрих Л. Бауэр констатировал [6] факт увеличения темпов роста вычислительных мощностей компьютеров и значительного увеличения сложности проблем разработки и проектирования ПО. Таким образом:

• 1.    Стоимость разработки программ приблизилась к стоимости аппаратного обеспечения (серверов).

• 2.    Стоимость проектов все чаще превышала бюджет.

• 3.    Программное обеспечение имело чрезвычайно низкое качество.

• 4.    Разработанные программы не советовали заявленным требованиям.

• 5.    Возникали трудности с поддержкой кода.

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

Изменение взглядов на разработку софта.

Изменения так же происходили и внутри самой отрасли – процесс разработки ПО начинает восприниматься как полноценная сфера деятельности со своими стадиями работ, жизненным циклом и регламентами проектирования, разработки и эксплуатации программ [2] . Таким образом начинается развитие инструментария и рабочих методологий для инженеров, занятых на всех этапах разработки программных продуктов.

Методологии в программной инженерии

В 1968 году на конференции НАТО, повещённой вопросам максимальной производительности компьютеров в качестве темы конференции был использован термин “Программная инженерий” [6] . Впоследствии термин стал обозначать так же название научной дисциплины исследующей вопросы экономичности и надежности разработки ПО, его качества и эксплуатации.

Выделение промышленного программирования и программной инженерии как научных областей знания послужило началом многочисленных исследований способов повышения качества и скорости разработки, отказоустойчивости кода, эффективности процессов тестирования и прочих технологических показателей. Таким образом появляются стандарты и регламенты, методы и «лучшие практики», которые входят в программную инженерию как область знания. Совокупности таких практик, применяемых на различных стадиях жизненного цикла программного обеспечения и объединенных общим философским подходом принято называть «Методологиями разработки программного обеспечения» [3]. Так, методологии разработки ПО стали одной из самых динамично развивающихся областей знаний, т.к. несут в себе практическую составляющую.

Классификация методологий управления проектом

Согласно SWEBOK [4] , методологии управления разработкой ПО делятся на:

• 1.    Традиционные (waterfall, каскадная модель)

• 2.    Spiral (модель спирали)

• 3.    Итерационная разработка  (Agile,

Scrum, XP)

Традиционные модели

Основным примером традиционных моделей служит “Каскадная модель”, впервые описанная в статье Уинстона Ройса (1970) [7] и предполагает последовательное выполнение всех фаз проекта. Итоговый продукт будет получен после завершения всех фаз проекта. Водопадная модель долгое время рассматривалась как основной способ регулярной разработки ПО. В 70x — 80x годах XX вв. была принята министерства обороны США как стандарт.

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

• 1.    Сильный рост стоимости незапланированных изменений требований к продукту в на каждом следующем этапе работ.

• 2.    Рост количества проблем в процессе проектирования с ростом проекта.

Тем не менее традиционная модель внесла существенный вклад в понимание процессов разработки ПО по следующим утверждениям:

• 1.    Старт реализации проекта должен быть отложен до выяснения всех целей и

• задач проекта и сбора полных требований к нему.

• 2.    Разработка продукта должна быть хорошо скоординированной, подчиняться разумному планированию и управлению.

Спиральная модель

В спиральной модели работы над проектом представляются как цикл (спираль), каждый виток который является водопадной моделью. Цикл начинается с этапа сбора требований к предполагаемым изменениям, вносимым на данном витке и завершается реализации прототипа. Таким образом решается основная проблема традиционных моделей о невозможности изменения требований к продукту. Модель была впервые описана Барри Боемом в статье «A Spiral Model of Software Development and Enhancement», опубликовавший в 1988гг [8] . Несмотря на то, что в SWEBOK модель выделена отдельно, в статье автор относит модель к семейству итеративных.

Итеративная модель

Модель предполагает разработку проекта как последовательность итераций, каждая из которых сама по себе является небольшим проектом в рамках общей задачи и предполагает измеримый прирост ценности продукта по завершении итерации. В отличие от спиральной модели в итерационных (гибких) методологиях фокус смещается с обеспечения полноты требований к продукту на формирование процессов слаженной работы команды [5] .

Зачатки модели итеративной разработки появляются еще в 30-х годах в статьях специалиста по проблемам качества продукции Уолтера Шеварта из Bell Labs. Показательным примером эффективности гибких методологий стал реализованный в 50-е годы проект сверхзвукового самолета Х-15. Согласно мнению участников проекта, итерационный подход стал одним из ключевых факторов успешной реализации проекта.

Заключение

Методологии разработки ПО как область знаний в программной инженерии развивались эволюционно наряду с развитием самой отрасли промышленного программирования. Замена традиционных подхо- дов итерационными была неизбежна ввиду быстрорастущей сложности технологий и роста количества практических проблем в процессах разработки продуктов. Так, в 1995 году появляется методология Scrum, экстремальное программирование (XP) – в 1996. Разработанный в 2001м году Agile-манифест [9] провозгласил эру итерационной разработки и задал направление развития гибких методологий в будущем.