Проектные методологии
А посуда вперёд и вперёд
По полям, по болотам идёт.
И чайник шепнул утюгу: "
Я дальше идти не могу".
Наверное, каждому из нас родители в детстве читали стихи Корнея Чуковского «Федорино Горе». В них посуда предпринимает попытку уйти от нерадивой хозяйки Федоры, но терпит поражение и возвращается назад, обосновав это желанием дать Федоре шанс исправиться. Очевидно же, что проект «уход от Федоры» потерпел неудачу из-за того, что заказчик выполнял его своими силами, не руководствуясь никакой проектной методологией. События развивались бы совсем иначе, если бы были приглашены профессиональные консультанты. Давайте рассмотрим на примере данного проекта популярные методологии разработки программного обеспечения.
Каскадная модель (Водопад)
Автором каскадной модели считают У.У.Ройса, который описал ее в 1970 году в работе Managing the Development of Large Software Systems. Суть каскадной модели заключается в том, что все работы выполняются по очереди: анализ, проектирование, разработка, тестирование, внедрение. Переход от одной фазы к следующей осуществляется только после полного завершения предыдущей (Рисунок 1).
Следуя в нашем проекта каскадной модели, сначала аналитики проведут анализ местности, выявят ее ландшафт: определят поля, реки, болота, леса, холмы и овраги; замеряют расстояния, глубины и перепады высот. Далее аналитики подробно обследуют заказчика – посуду - ее состав и характеристики, мебель - размеры, вес, состояние качества и другие. Консультанты опишут задачу и цели проекта и сформулируют требования к механизмам и инструментам, которые нужны для осуществления ухода, и полностью опишут процесс преодоления препятствий на местности с их помощью. Все это аналитики изложат в документе, который назовут « Техническое задание». Техническое задание согласуется с каждым из представителей заказчика – столовые приборы, посуда, кастрюли, бытовые приборы, мебель, - все внесут свои предложения, которые учтут и отразят в документе до полного удовлетворения всех сторон.

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

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

На последней фазе проекта – внедрение (опытно-промышленная эксплуатация), - в соответствии с проектной документацией посуда и мебель будут погружены в средства передвижения и отправлены в долгий путь, по заранее выбранному маршруту. По мере появления препятствий средства передвижения будут меняться и использоваться предусмотренные проектом приспособления для преодоления особенностей местности – овраги, леса, реки болота и т.д, в результате чего, посуда достигнет своего конечного пункта назначения.

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

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

Спиральная модель была описана Барри Боэмом в 1986 году , спустя 16 лет после появления каскадной модели (Richard W. Selby. Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research) и была нацелена на решение 10 основных, отмеченных Боэмом рисков:
1
Дефицит специалистов.
2
Нереалистичные сроки и бюджет
3
Реализация несоответствующей функциональности
4
Разработка неправильного пользовательского интерфейса
5
«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей
6
Непрекращающийся поток изменений
7
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию
8
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами
9
Недостаточная производительность получаемой системы
10
Разрыв между квалификацией специалистов и требованиями проекта
Спиральная модель заложила основу для создания следующего поколения методологий, которое на сегодняшний момент, является основным в разработке и внедрении программного обеспечения – итеративная разработка.
Итеративная разработка
Методология итеративной разработки предусматривает параллельное выполнение проектных работ – анализ и проработка требований выполняются одновременно с ведением процесса разработки функционала. Пожалуй, наиболее известной реализацией итеративного подхода является методология Rational Unified Process (RUP), предложенная и описанная компанией RationalSoftware.
В соответствии с этой методологией, проект разбивается на 4 основных стадии
1
Начальная стадия
2
Уточнение
3
Конструирование
4
Внедрение
Каждая стадия может быть разбита на несколько итераций. Важно, что на каждой итерации идут все процессы проекта - от анализа до тестирования, смещая, однако, интенсивность и акцент от анализа на начальной стадии к реализации на стадии конструирования и к развертыванию на стадии внедрения.

Если в предыдущих методологиях проектная команда работала по очереди – сначала аналитики, потом проектировщики, далее разработчики и тестировщики, то руководствуясь итерационным подходом, проектная команда будет занята на протяжении всего проекта вся, постоянно. В то время, пока разработчики реализуют очередную модель транспорта и инструментов, аналитики возят посуду и мебель по пересеченной местности на транспорте предыдущего поколения, фиксируя проблемы, неудобства и планируя предстоящие модификации к основной стадии проекта – конструирование. Анализ и разработка не прекращается и на финальной стадии «внедрение». Когда вся посуда и мебель собрана, погружена в транспорт и отправлена в путь, на ходу продолжаются конструктивные доработки: доворачивание гаек, утолщение колес, удлинение весел и т.п.

Если мы оглянемся на наши проекты, то обнаружим, что успешно используем итерационную модель разработки. А критикуемые (в прошлом) нашими архитекторам недостатки, такие как:
1
Разработка начинается на основе рамок проекта
2
Техническое задание готово полностью только ближе к концу проекта
3
Технический проект к моменту завершения разработки окончательно устаревает
4
И другие…
являются просто особинностями применяемой нами модели :) .

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

- В чем состоят проблемы заказчика, которые мы хотим решить?

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