Модели традиционного представления о жизненном цикле

Классическая итерационная модель

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

Таковы мотивы классической итерационной модели жизненного цикла (см. рис. 7.2).

увеличить изображение
Рис. 7.2. Классическая итерационная модель жизненного цикла программного обеспечения

Стрелки, идущие вверх, обозначают возвраты к предыдущим этапам, квалифицируемые как требование повторить этап для исправления обнаруженной ошибки. В связи c этим может показаться странным переход от этапа "Эксплуатация и сопровождение" к этапу "Тестирование и отладка". Дело в том, что рекламации, предъявляемые в ходе эксплуатации системы, часто даются в такой форме, что нуждаются в перепроверке. Чтобы понять, о каких ошибках идет речь в рекламации, разработчикам полезно предварительно воспроизвести пользовательскую ситуацию у себя, т.е. выполнить действия, которые обычно относят к тестированию.

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

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

Безусловно, представленная идея становится реальностью лишь при условии, что у разработчиков программного обеспечения есть поддержка сохранения старого полезного кода, причем без потери эффективности. Такая поддержка сегодня почти повсеместно связывается с объектно-ориентированными методами программирования и проектирования. Более того, многие считают это чуть ли не единственным способом реализации итеративного наращивания [ 8 ] . Отдавая должное методике объектной ориентированности, а также разработке методологий поддержки ведения проектов в рамках этого подхода, стоит обратить внимание на то, что он вовсе не всеобъемлющ, как утверждают его апологеты. Так, разработчики программных проектов, пользуясь им, вынуждены связывать себя множеством соглашений, без которых итеративное наращивание было бы просто непознаваемым. Помощь, которую оказывают объектно-ориентированные CASE-системы (например, [ 30 ] ), достаточно очевидна, чтобы оспаривать ее. Однако приходится констатировать, что эти системы либо заставляют разработчика оставаться в жестких рамках, которые появляются в результате проектных ограничений конкретных и не всегда хорошо сбалансированных частных решений, либо предусматривают привнесение средств, концептуально противоречащих идеологии подхода. Да и сами объектно-ориентированные языки можно упрекнуть в той же эклектике и противоречивости (подробнее об этом см. в [ 16 ] ).

Итеративное наращивание имеет целью повышение гибкости системы, обеспечение возможности ее адаптации к меняющимся требованиям к программе и условиям развития проекта. Можно сказать, что разбиение на итерации есть средство повышения адаптивности проекта, а потому проблема не в том, используются или нет для реализации итеративности объектно-ориентированные языки или CASE-системы, а в том, насколько сам проект приспособлен к изменениям. Это в корне противоречит и традиционным методологиям, и объектным, если при использовании как тех, так и других не закладывать в процесс разработки и в архитектуру системы адаптационные механизмы. В объектном подходе такие механизмы более развиты, но и они имеют границы применимости.

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

Адаптивность проекта — это альтернатива точке зрения на программный проект, согласно которой его развитие считается предсказуемым. В материальной сфере предсказуемость проекта означает, что его развитие/производство полностью подчинено заранее разработанным планам. Именно в этом отношении программные проекты отличаются от материальных: необходимость учета изменчивости требований, о чем в данном курсе речь впереди, влечет за собой их явную зависимость от внешних факторов.

В частности, по этим причинам появляются подходы к ведению проектов, которые пытаются учитывать потребность адаптивности. Это уже обсуждавшиеся методологии быстрого развития (см. лекцию 5). Чаще всего новые методологии в целом остаются объектно-ориентированными, но отходят от наиболее жестких установок этого подхода. Так, в методиках экстремального программирования жесткости и неизменности первичной декомпозиции проекта (дизайн системы) противопоставляется предписание переделки дизайна по мере продвижения разработки к удовлетворению уточняющихся потребностей пользователей [ 3 ] . Это нарушение канона компенсируется рядом организационных мер, позволяющих сгладить противоречия. По существу, предлагается специальный вариант менеджмента программных проектов. И, как это часто бывает сегодня, об ограничениях нового подхода упоминается лишь вскользь. В свое время мы еще будем иметь возможность обсудить ситуацию.