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

Рис. 3.8. Спиральная модель жизненного цикла ПО

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

Нужно заметить, что поскольку анализ рисков включает ряд существенных неопределенностей, которые заказчик для исполнителя обычно раскрывает далеко не в полной мере, спиральная модель достаточно хороша для внутренних проектов, когда разработчик и заказчик либо являются одним юридическим лицом, либо работают в рамках одной корпоративной структуры. Очень часто в больших корпорациях выделяется отдельная компания, занимающаяся ведением ИТ-проектов, например компания «Сибинтек» в составе ЮКОСа, компания «Итеранет» в группе компаний «Итера». Спиральная модель при такой организации взаимодействия, когда разработчик и заказчик находятся в рамках одной структуры корпоративного типа, – достаточно хорошее решение. В этом случае может осуществляться достаточно полная передача всей необходимой информации для оценки рисков, они могут оцениваться достаточно достоверно и поэтому грамотно и с минимальными затратами разрешаться.

Следующая модель, о которой хочется более подробно сказать, получила название «синхронизация и стабилизация», или модель синхростабилизации. Это связано с особенностью организации фаз жизненного цикла программного продукта. Другое название – модель Microsoft. Сегодня по информации из ряда источников она постепенно заменяется на Microsoft Solution Framework (MSF). По сути, эта модель была во многом похожа на MSF, но сегодня ею вытесняется. MSF – достаточно сложная и достаточно открытая модель. Она имеет интересные преимущества, которые основаны на определенном равноправии членов проектной команды. С другой стороны, эта модель достаточно сложна. Крайне ограниченно количество экспертов, владеющих тонкостями этой модели настолько, чтобы донести ее до широкой аудитории руководителей проектов, менеджеров продуктов, системных архитекторов. Поэтому, к сожалению, несмотря на свою привлекательность, модель не получила широкого распространения вне компании Microsoft. Сторонние компании, даже если они работают с инструментарием Microsoft и имеют хорошие знания о технологиях и стандартах Microsoft, редко пользуются ею из-за сложности ее реализации.

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

Достаточно интересным является понятие видения (концепции) продукта, с этого вообще и начинается разговор о нем. Сначала должна появиться некоторая неформальная идея того, чем этот продукт будет принципиально отличаться от существующих, какие преимущества он принесет при реализации. При этом в ходе работы по этой модели, как и всегда, производится последовательная детализация программного продукта, и, естественно, видение является наиболее абстрактным представлением о нем. До того как начать разрабатывать продукт на основе этого представления, пусть даже неформализованного, готовится более точный документ, который описывает проектные спецификации. После этого происходит формирование проектной команды, готовится график работ: какие виды деятельности какой из ролей будут реализованы, на какой стадии, сколько это займет времени, какие будут вехи, результаты на каждом этапе изготовления продукта. Нужно заметить, что очень часто при разработке продуктов Microsoft проектная команда набирается именно под данный проект. И люди, которые участвуют в проекте на различных ролях – разработчиков, проектировщиков, документаторов, тестировщиков, встречаются только в тот период, когда изготавливают продукт. После этого часто бывает, что далее продукт существует независимо от них. Поэтому еще раз хочется подчеркнуть важность программной документации для обеспечения преемственности продуктов внутри линейки продуктов. У Microsoft, например, это линейки ОС Windows, приложений MS Office и др.

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