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