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

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

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

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

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

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

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

Рассмотрим преимущества, которые связаны с моделью Microsoft. Это, во-первых, частое и раннее тестирование. Чем это полезно? Уже говорилось о том, что ошибки в продукте нужно выявлять как можно раньше. Чем позже выявляется ошибка, тем большую работу по ее устранению придется провести, поскольку может случиться так, что ошибка, даже будучи локализованной в одном из модулей, все же влияет на работу соседних модулей, на определенные компоненты проекта, на продукт в целом. Кроме того, она влияет на документацию проекта: придется дорабатывать не только код, но и документацию, причем документацию не только на этот код, но и к проекту, которая описывает модуль, его работу, взаимодействие с другими модулями – диаграммы классов, возможно, диаграммы взаимодействия. Ведь ошибку в логике работы модуля верхнего уровня, который отвечает за общую бизнес-логику работы системы, можно локализовать, но после этого ее устранение потребует достаточно радикальной перестройки значительной части структуры программного обеспечения, большого количества классов и документации к ним. Поэтому, конечно, частое и максимально раннее тестирование – весьма позитивный подход и потенциальное преимущество модели Microsoft.