Модели разработки

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

Итак. Что такое процесс разработки программного обеспечения. Если говорить абстрактно, то это процесс алгоритмизации идей. То есть процесс перевода одного идеального объекта в другой такой же идеальный (в философском понятии). Однако, если мы говорим о процессе, то возникает вопрос о методе решения задачи.

Чаще всего история стартапа начинается со стиля кодирования «Улыбаемся и Машем», то есть «Кодируем и Правим». Слушаем заказчика, придумываем как это делать, кодируем и отдаем. Вариант Студенческий. После одного-двух проектов приходит понимание, что, во -первых, требования надо фиксировать, что было можно показать соответствие продукта им, во-вторых, нужно тестирование не на словах, а на деле. Таким образом, мы приходим к классической и вечно живущей модели «водопада»:

Выработка системных требований → Выработка требований к ПО → Анализ → Проектирование → Кодирование → Тестирование → Развертывание → Эксплуатация.

В реальности, эта модель принимает вид итеративности:

Выработка системных требований ↔ Выработка требований к ПО ↔ Анализ ↔ Проектирование ↔ Кодирование ↔ Тестирование ↔ Развертывание ↔ Эксплуатация.

Я рискну заявить, что такая модель достаточно хороша, ибо лучше иметь плохой метод, чем никакого.

Однако, я не зря писал, что программирование, перевод одно идеального продукта в другой. Ничто так не непостоянно как идеи, и, как сказал, 13ый апостол, «ну, знаете, идею проще изменить». Кроме того, часто заказчик в курсе, что программу изменить, не деталь новую выточить, и поэтому, требования плывут как ладожский лед по Неве. На смену водопадному пришла ( а пришла ли ;-) ?) итеративная модель:

Анализ требований → Проектирование → Кодирование → Тестирование → {Анализ требований → ...→ Тестирование → Развертывание}^{ N} → Эксплуатация

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

Развитием идей итеративной модели стала т.н. спиральная модель (БэрриБоэм)разработки. Эта модель предлагает на каждой итерации проводить одну и ту же схему работы - планирование, определение задач, оценка рисков, выполнение основных работ, оценка результатов, при этом схематично, разработка продукта может выглядеть так:

Концепция → План жизненного цикла и работа с требованиями → Анализ рисков → Прототип → Разработка и проверка требований → План разработки → Анализ рисков → Прототип → Проектирование → Проверка проекта → План интеграции и тестирования → Анализ рисков → Рабочий прототип → Наборы тестов → Проектирование модулей → Кодирование → Тестирование модулей → Интеграция и тестирование системы → Приемочное тестирование → Развертывание.

Нельзя сказать, что процесс управления разработкой программного обеспечения прошел мимо внимания комитета по стандартизации. Здесь стоит упомянуть ГОСТ P-1999 , ISO/IEC 12207,ISO/IEC 15288, ISO/IEC 15504, IEEE 1074-1997, IEEE/EIA 12207-1997 и др, а также стандарты CMM разработанные SEI. К сожалению, излишняя бюрократизация не способствует улучшению процессов управления. К примеру, одна из широко использующихся методологий - RUP противопоставляется «живым методологиям» Agile не в последнюю очередь из -за излишней формализованности. Хотя, и я постараюсь показать дальше, RUP может быть таким же «живым».

Последнее время говоря о «живых» методологиях неявно упоминают адаптивную модель разработки ПО (см., например, Джим Хайсмит). У такого процесса можно обозначить шесть базовых характеристик: Целенаправленность, Компонентный подход, Итеративность, Жесткие временные рамки, Оценка с точки зрения рисков и Допустимость изменений.

«Адаптивный жизненный цикл проекта строится исходя из результатов, а не задач, причем в качестве результатов выступают компоненты системы. В этом контексте под словом компонент понимается некий набор свойств программы (или некоторых элементов, входящих в поставку системы), который должен быть разработан в течение итерации. Конечно, документы (например, модель данных) тоже можно считать поставляемым компонентом, однако по отношению к свойству программы документация всегда второстепенна, так как только работающий программный код дает заказчику возможность ощутить реальные результаты работы.[...] Как и в спиральной модели Бэрри Боэма (Barry Boehm), планирование в адаптивном жизненном цикле ведется исходя из осознания и анализа критических рисков . Кроме того, адаптивный способ разработки ПО приемлет и приветствует все возникающие изменения . С адаптивной точки зрения, возможность внесения изменений - это конкурентное преимущество, а не просто еще одна "проблема". » Джим Хайсмит

Если изобразить схематично, то адаптивная модель состоит из следующих блоков:
Обдумывание ^<-→ Взаимодействие → ^<- Обучение

Обдумывание состоит из следующих шагов:

1. Провести начальную фазу проекта.
2. Определить временные рамки проекта.
3. Определить оптимальное количество циклов и временные рамки каждого из них.
4. Расписать основные задачи по всем циклам.
5. Связать разрабатываемые компоненты системы с соответствующими циклами.
6. Связать с циклами технологические компоненты и компоненты поддержки.
7. Разработать список задач по проекту.

Взаимодействие - процесс согласованного написания компонентов системы.

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

Более подробно модель выглядит так:

(Начало проекта → /^<-Адаптивный цикл планирования)→(Разработка компонентов)→(Оценка качества ^<- / → Приемочное тестирование и развертывание)

Адаптивная методология как методология, а не модель, более подробно описана здесь http://www.adaptivesd.com/