Сергей Зыков - Основы проектирования корпоративных систем

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

Чем хороша спиральная модель? Прежде всего, если ПО производится на основе этой модели, то за счет прототипирования, если оно применяется, за счет анализа и оценки рисков возможно повторное использование продукта. То есть сам подход к жизненному циклу обеспечивает плавное движение продукта по этому жизненному циклу, плавный переход к его сдаче заказчику. Таким образом обеспечивается возможность повторного использования продукта, даже в условиях изначально высоких проектных рисков. Поскольку анализ рисков происходит изначально, можно ограничиться в ряде случаев упрощенной схемой тестирования. С другой стороны, можно достаточно корректно обосновать, в каких случаях и в какой мере это тестирование проводить, когда завершится тестирование и продукт перейдет к заказчику – исходя из применяемой технологии анализа рисков. На основе анализа рисков получается еще целый ряд метрик, которые дают возможность оценить продукт с точки зрения его качества, надежности, полноты документации, чтобы его можно было передать заказчику. Кроме того, можно относительно гладко перейти к сопровождению продукта за счет того, что продукт последовательно приближается к «боевому» решению в ходе достаточно большого количества витков спирали, каждый из которых подтверждается и уточняется очередной итерацией оценки рисков. То есть имеет место цикличность. В этой связи, несмотря на большие затраты из-за оценки рисков, обеспечивается относительно недорогое сопровождение, а оно является наиболее затратной частью жизненного цикла, принимая на себя около 2/ 3всех затрат. Таким образом, на полном жизненном цикле – с учетом сопровождения – может быть получена экономия. По сути, все недостатки, присущие этой модели, вытекают из того, что требуются большие затраты на оценку риска. Во-первых, она применима преимущественно для внутренних проектов – таких, которые ведутся в пределах одного подразделения, разными структурами одной корпорации или структурами, которые имеют давнюю историю партнерских отношений и тесные взаимосвязи. Это происходит потому, что требуется предварительная оценка рисков и представителям разработчика часто необходима полная информация о производственных процессах заказчика, которые могут эти риски повлечь. Эта информация часто относится к категории коммерческой тайны и далеко не всегда может быть в достаточной мере передана разработчику. Поэтому если проект внутренний, эта проблема снимается. Конечно, спиральная модель может быть принципиально применима и для относительно небольших проектов, но, учитывая существенную затратность оценки рисков, она в первую очередь используется для больших корпоративных проектов. Что еще очень важно: она требует опыта оценки рисков. То есть либо в команде разработчика должны быть опытные специалисты по оценке рисков (с умением приоретизировать сложную структуру рисков по целому ряду критериев, особенно в корпоративных системах), либо этих специалистов следует привлекать извне.

Еще одна модель – наиболее интересная и динамичная – это объектно-ориентированная модель. Речь пойдет о той ее разновидности, которую называют фонтанной. Это название будет понятно, если посмотреть на схему взаимодействия фаз этой модели.

В чем ее особенности? Если все предыдущие модели содержат изолированные, четко отделенные стадии жизненного цикла (анализ требований, спецификация требований, предварительное и первичное проектирование, детальное и окончательное проектирование, реализация и тестирование, сборка и интеграционное тестирование, тестирование продукта, приемочное тестирование и передача заказчику, сопровождение, вывод из эксплуатации), особенно четко это представлено в водопадной модели (пока нет подписи на документе, что предыдущая стадия завершена в соответствии с принятыми стандартами качества, следующая стадия не может быть начата), то в объектно-ориентированной модели принято достаточно интенсивное взаимодействие между различными фазами жизненного цикла. Более того, имеет место перекрытие фаз: перекрываются объектно-ориентированный анализ и спецификация требований, иногда – объектно-ориентированный анализ и проектирование (вместе это называется «object-oriented analysis and design», что, вообще говоря, в других моделях является разными фазами). В отличие от других моделей она не разделяет данные и действия: внутри класса атрибуты и методы равноправно взаимодействуют внутри класса. Во многом именно поэтому взаимодействие фаз и является важной особенностью объектно-ориентированного подхода.

Еще важной особенностью выступает итеративная смена фаз. Изготовление продукта – процесс циклический, который может требовать и в ряде случаев требует возврата на предыдущие фазы. То есть фазы объектно-ориентированного проектирования часто включают в себя фазы объектно-ориентированного анализа. Скажем, анализ сценариев использования связан с объектным моделированием и производится на основе диаграмм прецедентов, которые являются продуктом проектирования.

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