Читать онлайн «Основы проектирования корпоративных систем». Страница 15

Каждая фаза ЖЦ ПО включает три важных составляющих – процессы, методы и средства. Под процессами понимают задачи, которые необходимо реализовать, они отличаются и, по сути, не зависят друг от друга. Методы – это относительно формальное описание каждой задачи процесса. Средства – автоматический инструментарий типа CASE-средств для поддержки процессов и методов.

Ниже перечислены основные виды моделей ЖЦ, которые будут подробнее рассмотрены в следующих главах: это прежде всего модель Build-and-fix – «кодируй и фиксируй», по сути, она близка к модели проб и ошибок; затем – водопадная модель, которая дает возможность за один проход ЖЦ построить полномасштабное программное обеспечение; модель быстрого прототипирования, которая, как правило, объединяется с другими моделями; инкрементальная модель с последовательным наращиванием функциональности; модель синхронизации и стабилизации, или модель Microsoft; спиральная модель, в которой очень важна оценка рисков и которая тоже подразумевает циклическую обработку продукта по мере его движения к пользователю; объектно-ориентированная модель с перекрытием ряда фаз и во многом циклическим или итерационным развитием.

Какие общие черты можно выделить в перечисленных моделях ЖЦ? Как правило, они включают все его стадии, за исключением модели Build-and-fix. Кроме того, предполагается несколько итераций по разработке продукта, за исключением каскадной модели. Как правило, стадии ЖЦ четко различимы, кроме объектно-ориентированной модели, где они могут объединяться. Некоторые отдельные модели, связанные с некоторыми методологиями проектирования, такие как модель синхронизации и стабилизации, связаны с методологией MSF. RUP поддерживает каскадные и спиральные сценарии жизненного цикла и т. д.

Грамотное применение модели ЖЦ требует высокой организационной зрелости команды и серьезной дисциплины проекта с точки зрения стандартов документирования, кодирования, использования специализированных CASE-средств и т. д. Если такие знания недостаточны, то объектно-ориентированная модель может выродиться в такую модель, как Build-and-fix, т. е. можно потерять все преимущества модели и увеличить затраты.

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

Что определяют модели ЖЦ программных продуктов? Во-первых, характер и масштаб проекта. В этой связи, как только при анализе и спецификации требований и ограничений определены основные границы проекта и продукта, в идеале следует определиться с совокупностью моделей, которые будут выбраны. Здесь критичны объем продукта, сроки и проектные риски. Скажем, спиральная модель существенно связана с использованием рисков, поэтому ее имеет смысл применять в случаях, когда необходим анализ рисков. Модели определяют экономику проекта, в том числе и скорость возврата инвестиций. В случае если нет острой необходимости применять модель полного ЖЦ, можно сэкономить на отдельных стадиях, например если не нужно разрабатывать документацию в полном объеме. Модель определяет степень сопровождаемости: в ряде моделей мы можем получить продукт, который будет более сопровождаемым. Модели ЖЦ определяют также перспективы развития – насколько можно будет удовлетворить будущие запросы клиента. Также модели ЖЦ определяют общую структуру проекта с точки зрения его эволюционного или революционного совершенствования: потребуются ли радикальные изменения или можно ограничиться архитектурой, в которой проект будет стабильно эволюционировать. Модели определяют скорость поиска и устранения ошибок, например, модель синхронизации и стабилизации нацелена на частое раннее тестирование. Некоторые модели, как уже отмечалось, способствуют хорошему управлению рисками проекта. Кроме того, отдельные модели подразумевают изготовление прототипов (модель быстрого прототипирования, инкрементальная модель), другие требуют изготовления готового продукта сразу же.

Какие особенности ЖЦ можно выделить уже в первом приближении для конкретных моделей? Модель Build-and-fix – это модель неполного ЖЦ, которая пригодна для малых проектов (≈1000 строк) и абсолютно непригодна для больших и сложных проектов с большим потенциалом развития. Водопадная, или каскадная, модель обеспечивает хорошую обратную связь с ранними стадиями ЖЦ, поскольку завершается подготовкой документов, которые позволяют перейти к следующей стадии. Без этих документов, без корректного закрытия предыдущей стадии невозможно начало следующей. Быстрое прототипирование – несамостоятельная модель, не приводящая к созданию надежного кода. Инкрементальная модель всегда дает возможность получить на каждом этапе готовый продукт, пусть и неполнофункциональный. Модель синхронизации и стабилизации, или модель Microsoft, нацелена на раннее выявление ошибок. Спиральная модель подразумевает несколько итераций и нацелена на анализ рисков. Объектно-ориентированная модель – это итеративное проектирование с перекрытием фаз и наложением их друг на друга.

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

Кратко остановимся на преимуществах и недостатках различных моделей ЖЦ.

Модель Build-and-fix хороша для небольших проектов, которые не требуют сопровождения, но абсолютно непригодна для корпоративных или вообще нетривиальных проектов объемом более 1000 строк.

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

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

Инкрементальная модель способствует хорошей сопровождаемости за счет того, что получается достаточно плавный путь перехода от одной версии к другой. Эта модель способствует раннему возврату инвестиций, но требует открытой архитектуры, которая поддерживает такое эволюционное совершенствование программного продукта, и может выродиться в модель Build-and-fix.