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

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

На рис. 5.7 представлена матрица совместимости групп ролей, которая во многом отражает возможности масштабирования подхода Microsoft Solution Framework по программным продуктам с учетом их размера. Ряд ролей можно совмещать. Управление продуктом и управление проектом возможно совмещать, но не рекомендуется. Таким образом, в группе, которая ведет проект по подходу MSF, может быть небольшое количество людей, при этом ряд ролей может совмещаться. С другой стороны, если это крупный проект, то роли разделяются. Так же, как и RUP, подход MSF имеет в своей основе процессы, и их фазы достаточно близки. Если в RUP говорилось о стадии создания концепции, то здесь – о создании видения, абстрактного представления о том, каким должен быть продукт, какого рода задачу он должен решать, при этом процессная модель основана на итеративном уточнении функционала проекта с построением нескольких релизов, которые являются полномасштабными с точки зрения функционала продукта, артефактов (на каждом этапе, релизе мы продуцируем практически готовый продукт с точки зрения всех его артефактов, функциональность не является завершенной).

Рис. 5.7.Матрица совместимости ролей в подходе MSF

Итак, видение завершается определением границ, т. е. концептуальных проектных ограничений, которые описывают базовую функциональность программного продукта: какие задачи он должен решать и на какие он не должен распространяться, какие будут решены тактически в ходе дальнейших релизов, какие стоит стратегически оставить за рамками данного проекта в целом. После этого происходит планирование проекта и разработка. Между стадиями осуществляется контроль достижения целей по истечении каждой вехи и сопоставление документально полученных результатов с целями и требованиями. Как только завершено планирование, начинается разработка. И затем существует специфическая стадия для каждого релиза, которая отсутствует в RUP, – это стабилизация (рис. 5.8), так как Microsoft Solution Framework основана на модели синхронизации и стабилизации, т. е. существенной составляющей является стабилизация каждого релиза, и для достижения его устойчивой и надежной работы необходимо обеспечивать качество релиза согласно проектным метрикам.

Рис. 5.8.Процессная модель MSF

Только после стабилизации возможны передача заказчику и стадия развертывания. Стадия стабилизации при неудовлетворительной дисциплине проекта или неполном владении инструментарием может приводить к большим потерям времени и людских ресурсов. За счет наличия этой стадии подход Microsoft Solution Framework достаточно сложен, и вне Microsoft редко удается реализовать удовлетворительные решения для больших информационных систем. Тем не менее общая схема во многом близка к RUP и основана на процессах, производстве последовательных релизов, и основные стадии во многом совпадают.

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

Ранее были рассмотрены основные понятия корпорации и корпоративной системы, затем – основные подходы к разработке этих систем с точки зрения их жизненного цикла на уровне моделей (более формальный, общий подход), после этого – основные методологии проектирования. Напомним, это тоже не вполне строгий подход с математической точки зрения, по сути, это набор правил хорошего тона, полезных советов, рекомендаций для реализации и сопровождения информационных систем. Поэтому имеет смысл ограничиться констатацией тех подходов, которые приемлемы для корпоративных приложений. Это MSF, RUP и те, которые приемлемы лишь отчасти, – Scrum, Agile. Знать ЖЦ нужно, чтобы иметь представление о создании и функционировании систем. Направление методологий и моделей жизненного цикла – это во многом ортогональные направления. Например, в RUP можно использовать спиральную или каскадную модель, а в MSF – эволюционные или инкрементальные подходы.