Дефрагментация мозга. Софтостроение изнутри

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

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

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

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

Таким образом, из научной плоскости мы переходим в область экспертных оценок. Поэтому слово «методология» справедливо вызывает у многих негативное отношение. Правильнее было бы говорить о технологии ведения со-фтостроительных проектов, но исторически появившийся термин так просто из обращения не выкинуть. Да и надо ли?

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

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

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

Рис. 16. «Гибкая» методология соответствует классической схеме «снизу-вверх»