Глава 5 Методологии разработки корпоративных систем

В предыдущих главах были описаны модели жизненного цикла корпоративных систем, основные этапы их существования, начиная от концептуальной идеи, формализации требований, проектирования, реализации, передачи в эксплуатацию или на стадию сопровождения (собственно то, ради чего весь этот жизненный цикл строится) и вывод из эксплуатации. Было описано, каким образом перечисленные этапы отражаются в различных подходах или моделях жизненного цикла. Некоторые модели включают все стадии (объектно-ориентированная модель), другие – (Build-and-fix) не все стадии жизненного цикла. Существуют модели, которые основаны на линейной смене фаз (каскадная или водопадная), другие поддерживают определенную итеративность или цикличность (объектно-ориентированная или спиральная модели). Ряд моделей позволяет рассматривать некоторые этапы жизненного цикла параллельно или во взаимодействии, это прежде всего объектно-ориентированная модель, в которой сочетаются анализ и проектирование. Существуют несамостоятельные модели, такие как модель быстрого прототипирования. Отсюда следует вывод, что ряд моделей можно комбинировать. Комбинировать следует прежде всего некоторые из моделей полного жизненного цикла (спиральная, каскадная) с моделью быстрого прототипирования. Это дает возможность существенно экономить сроки и стоимость внедрения, избежать существенных проектных ошибок, так как позволяет проявить функциональность программного продукта уже на ранних стадиях (анализ и спецификация требований, начальный этап проектирования), а также благодаря быстрому прототипу вместе с заказчиком определить, в том ли направлении мы двигаемся и правильно ли понимаем друг друга.

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

Методология – это параллельное направление (или ортогональное, еще одна ось, вдоль которой можно рассматривать жизненный цикл). Ранее уже упоминалось, что можно рассматривать программные проекты и программные продукты (их жизненный цикл отличается). В этой главе речь пойдет о программных продуктах, и акцент ставится больше на моделях, чем на методологиях. Но методологии полезны как набор практических приемов для достаточно эффективной реализации, в том числе и корпоративных приложений. Методологии, которые будут рассматриваться, могут включать различные модели. Например, методология Rational Unified Process может иметь в основе модель как каскадного жизненного цикла, так и спирального. То же можно сказать о методологии Microsoft Solution Framework (MSF). Методология с точки зрения жизненного цикла и точки зрения детализации этапов разработки информационных систем – это не столь формальный подход, как модели. В ряде случаев в зависимости от характера и масштаба проектов могут быть существенные коррективы. Rational Unified Process может становиться большим или малым (применяется более или менее развернутая схема разработки). В Microsoft Solution Framework также могут рассматриваться варианты более гибкого подхода (Agile) или подхода Formal (более полного). Желательно иметь в виду соотношение методологий и моделей.

Достаточно важно замечание по поводу характера и масштаба методологий. Существуют методологии, которые в полной мере подходят для проектирования корпоративных систем, и их можно назвать корпоративными (или тяжелыми). Они по аналогии с моделями описывают весь жизненный цикл, позволяют подготовить достаточно полную проектную документацию, хотя каждая из них является просто набором хороших приемов и в ряде случаев допускает упрощенный подход к проектированию и реализации информационных систем. И существуют более легкие (гибкие) методологии, которые не идеально подходят для больших корпоративных систем и могут использоваться при определенных условиях: при высоких рисках, высоких степенях неопределенности в проекте. Такие большие (тяжелые) методологии – это аналоги каскадной, спиральной моделей, не в том смысле, что эти модели там используются, а в том, что это достаточно полное представление жизненного цикла. Такими тяжелыми методологиями являются: Rational Unified Process и Microsoft Solution Framework. Rational Unified Process на сегодняшний день является методологией, которая представляется корпорацией IBM, Microsoft Solution Framework – корпорацией Microsoft. Интересно, что методология MSF возникла из модели синхронизации и стабилизации, и здесь имеются аналогии. Но если говорить о MSF как о методологии, речь пойдет скорее не о жизненном цикле программной системы, а о тех приемах и методах, которые нужны для поддержания этого цикла, для разработки, не только о программном продукте, но и о программном проекте (о ролях в проекте, их особенностях, взаимодействии персонала, проектной документации, которая поддерживает выполнение определенных видов деятельности).

Что касается легких или гибких методологий, будут рассмотрены в разной степени детализации Scrum, Agile, eXtreme Programming. Они являются наборами лучших практик, т. е. наборами рекомендаций о том, каким образом при высоких проектных неопределенностях и рисках вести разработку программных систем для того, чтобы обеспечить определенные качества результирующего программного продукта, если это вообще возможно, или прекратить разработку, если это невозможно, при этом уложившись в определенный бюджет и сроки.

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

Поговорим о методологии Rational Unified Process, которую кратко называют RUP. Она была разработана компанией Rational, затем унаследована корпорацией IBM и сегодня поддерживается достаточно большим количеством инструментальных средств линейки Rational, которые закрывают весь жизненный цикл программного обеспечения. Это и средства проектирования, и средства управления проектами, и целый ряд средств, которые нацелены на фазы разработки, тестирования, внедрения и сопровождения. В линейке более 10 средств, которые взаимодействуют друг с другом, призваны вести проектирование на основе RUP и поддерживают практически весь жизненный цикл программного обеспечения. Самое главное, что нужно отметить о подходе Rational Unified Process, – это то, что есть несколько важных направлений, которых он придерживается. Это прежде всего итеративность (последовательная доработка, примерно, по спиральной или инкрементальной модели). Оценка рисков является важной составляющей RUP (на самом деле всех методологий, особенно гибких). Кроме того, подход имеет в своей основе архитектурную центричность (основан на том, что в центре всего проекта находится архитектура и этап архитектурного проектирования), также применяются сценарии использования. Тут нет ничего удивительного. Сценарии использования применяются широко в языке UML, который поддерживает большинство CASE-средств. Прецеденты – это один из первых видов диаграмм UML, которые встречаются по пути жизненного цикла программных систем. На стадии первичного проектирования возникают прецеденты, и диаграммы прецедентов детализируются в ходе проектирования на сценарии использования. Сценарий использования, по сути, являет собой конкретизацию прецедента. То есть если имеется прецедент, который объединяет такие роли, как пользователь и система, и представляет собой вход в систему (регистрацию), то сценариев использования здесь может быть, как минимум, два – это успешная и неудачная регистрация. То есть сценарий использования детализирует возможные варианты прецедентов.

Кроме того, Rational Unified Process – это достаточно четко определенный и структурированый процесс, последовательные стадии, через которые проходит программное обеспечение по мере своего создания, и важно провести взаимосвязь с дисциплиной программной инженерии. Действительно, RUP вместе с MSF – это та методология, которая предназначена для производства больших, сложных систем, состоящих из ряда взаимодействующих компонентов, возможно включающих базы данных (т. е. корпоративных систем). Rational Unified Process имеет четкую структуру и как методология является достаточно жестким подходом.

Еще одна методология, о которой упоминалось раньше и которая тоже является достаточно жесткой, – это Oracle CDM, но сегодня она применяется нечасто. Она основана на вариации каскадной модели и вполне может быть использована для производства корпоративных приложений. Rational Unified Process – это технология разработки корпоративных информационных систем, которая основана во многом на процессах, она так же, как и жизненный цикл программного продукта, включает четыре стадии.

Очень важно, что RUP, MSF и методологии меньшего калибра основаны на процессах и описывают взаимодействия ролей тех людей, функциональных групп, которые участвуют в этих процессах. При этом процессы разбиваются на активность.

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

Рис. 5.1. RUP: основные вехи

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

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

После того как детальное проектирование осуществлено, начинается третья фаза – фаза построения. Она соответствует реализации и модульному тестированию, интеграции и сборочному тестированию, тестированию. После этого осуществляется приемка и передачи продукта заказчику. Завершает стадию построения ревизия проекта, которая показывает, что продукт отвечает заявленным требованиям и способен пройти все приемочные тесты на реальном программном обеспечение заказчика.

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

Выше уже упоминалось, что при подходе Rational Unified Process можно пользоваться как моделью, связанной с итерациями, так и каскадной моделью. Последнюю можно использовать в подходе, похожем на инкрементальную модель. Предположим, что имеется программный продукт на определенной стадии развития (корпоративная информационная система), которая предполагает стабильный путь апгрейда и позволяет плавно наращивать функциональность. При доработке и развитии системы можно пользоваться подходом, напоминающим каскадную модель. Существует первоначальная стадия концептуального проектирования, которая связана с прототипированием. Затем стадия, связанная с детальным проектированием, приводит к стабилизации архитектурного проекта и основных требований, связанных с функциональностью продукта, детализированных требований. На стадии построения создается фактически новый продукт, который соответствует уже расширенной функциональности. И в результате здесь может потребоваться несколько взаимосвязанных шагов. Есть возможность осуществить передачу заказчику. Здесь объединяется основной подход, связанный с каскадным жизненным циклом, с тем подходом, который предполагает итеративную разработку. Ограничения в данном случае – предсказуемый путь развития программного обеспечения, достаточно четкая определенность функциональных требований, которые нужно реализовать для нового релиза информационной системы, и хорошее владение особенностями предметной области, технологиями проектирования и программирования той проектной командой, которая осуществляет производство программного продукта.

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

Если говорить об эволюционном жизненном цикле программного продукта, то возможны коррективы на случай предметной области, которая является для команды в большей мере неопределенной, чем в предыдущих случаях. И здесь видно, что достаточно быстро происходит стадия разработки, но стадия детального проектирования предполагает несколько итераций. Возможно экономить на последующих стадиях реализации, внедрения и сопровождения за счет того, что последовательно уточняется функциональность в ходе архитектурного проектирования на второй стадии Rational Unified Process. Все, что здесь говорится о методологиях, следует рассматривать критически, поскольку речь идет о наборе практик, которые предназначены для достаточно эффективного проектирования и разработки информационных систем.

Rational Unified Process может быть адаптирована для целого ряда моделей жизненного цикла (каскадной, инкрементальной, спиральной, эволюционной). Общее между этими моделями, если абстрагироваться от конкретной модели и пытаться рассказать об RUP, – это итеративность и некоторый перечень того, что называется лучшими практиками. Часто бывает так, что необдуманный выбор определенного подмножества этих лучших практик приводит к тому, что не удается осуществить корректную разработку, даже если разработчики тешат себя иллюзиями, что они работают в рамках этой методологии. Лучше использовать эти практики в совокупности. О лучших практиках RUP можно сказать то, что это итеративная разработка. Не стоит стремиться к тому, чтобы сразу (за один проход) разработать весь проект полностью. Уточнение архитектурного плана проекта и реализация, разработка, тестирование, сборка, подготовка к передаче заказчику происходят последовательными приближениями. Продукт последовательно уточняется. В этой связи актуально второе замечание, связанное с управлением требованиями. Изменение требований происходит последовательно, на каждой итерации они просматриваются и корректируются. Очень важны требования, связанные с архитектурой, которые заключаются в том, что следует использовать архитектуру на основе компонентов. Это достаточно важное замечание для корпоративных информационных систем, так как они представляют совокупность взаимодействующих модулей, каждый из которых призван решать относительно замкнутую задачу, связанную с анализом, планированием, управлением определенной отраслью деятельности корпорации (кадры, финансы, специфические ресурсы, основные средства, другие аспекты). В этой связи компонентный подход достаточно важен, потому что дает возможность вести разработку систем таким образом, чтобы можно было посредством минимального взаимодействия компонентов обеспечить высокую взаимозаменяемость и хорошую сопровождаемость. В этом случае можно было бы вносить коррективы в отдельный компонент, и при этом в целом корпоративная система будет оставаться функциональной и достаточно эффективной.

Еще одно важное замечание, которое нужно реализовать при внедрении методологии Rational Unified Process: необходимо использовать программно-инструментальные средства, предназначенные для визуального моделирования и проектирования. Визуального, потому что Rational Unified Process существенно связана с UML, и, конечно, поэтому сложные продукты и их документация содержат огромное количество UML-диаграмм и графических примитивов (классы, прецеденты, состоянии и т. д.), чтобы управлять проектом и проектировать продукт (если мы работаем итеративно, то у нас существует кроме большого количества диаграмм еще большое количество итераций). Грамотно отслеживать, говорить на одном и том же языке важно для упрощения рабочих навыков общения с кейс-средствами, которые поддерживают проектирование на языке UML и обеспечивают сопряжение со средствами тестирования, кодогенерации, создания баз данных и т. д. Кроме того, важными требованиями являются постоянный мониторинг качества программного продукта и управление изменениями (управление потоками работ, которые происходят при реализации программных продуктов по этой методологии).

Структура методологии RUP включает роли, это важно, так как используются прецеденты и задачи, связанные со сценариями использования, и артефакты – проектные документы, которые производятся на каждой стадии (рис. 5.2). При этом используется целый ряд руководств, шаблонов и инструкций, которые указывают, каким образом следует вести проектирование и реализацию корпоративных приложений в рамках подхода Rational Unified Process. Для всех продуктов Rational существуют инструкции, руководства по проектированию, где описаны шаблоны, на основе которых нужно разрабатывать сценарии использования, анализировать и проектировать.

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

По сути, идеология связана с лучшими практиками, которые были перечислены ранее. Основные из них сводятся к удовлетворению принципов итеративного подхода: архитектурная центричность, компонентное проектирование, управление изменениями и качеством. Rational Unified Process можно адаптировать для различных моделей жизненного цикла, т. е. применять как каскадный подход, так и как подход, связанный с итерациями (может быть эволюционная модель жизненного цикла или инкрементальные, спиральные модели), и, кроме того, RUP может включать более или менее широкий набор артефактов, активностей и ролей и быть более или менее формализованной (рис. 5.4). Поэтому можно говорить о том, что Rational Unified Process может быть легкой или тяжелой, большой, формализованной, более применимой к корпоративным приложениям. Тем не менее говорить о том, что RUP имеет смысл применять для небольших проектов или изготовления небольших продуктов, не совсем правильно, потому как это достаточно серьезная методология, которая предусматривает существенные трудозатраты и весомый инструментарий. И, конечно, пользоваться ею для создания небольших продуктов экономически нецелесообразно: слишком много дополнительных расходов, связанных с проектной документацией, обучением сотрудников, привлечением специалистов по рискам. Для небольших проектов это неоправданно, а вот для корпоративных проектов важно, что Rational Unified Process является достаточно формальным подходом, его артефакты достаточно четко определены, процессы формальны описаны, существует большое количество руководств, хороший опыт, накопленный в разных коллективах, по производству серьезных программных продуктов. Это свидетельствует о том, что этим подходом можно пользоваться для производства и сопровождения больших корпоративных приложений. При этом можно применять достаточно широкий спектр моделей жизненного цикла.

Рис. 5.2. Структура RUP: роли, задачи, артефакты

Рис. 5.3. Структура RUP: руководства, шаблоны, инструкции

Рис. 5.4. RUP: настройка процесса

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

Конечно, Microsoft Solution Framework возникла внутри Microsoft и основана на большом опыте этой компании по созданию серьезных корпоративных систем, корпоративных в смысле масштаба, распределенности, количества заказчиков. Это прежде всего операционные системы Windows, офисные приложения, которые являются корпоративными. Существуют специальные классы, которые позволяют строить офисные расширения, настраивать продукты офиса, создавать новые возможности, управление проектами посредством Microsoft Project Server, Microsoft Visual Studio, порталов. И это нашло отражение в данной методологии. То есть MSF предназначена для производства больших корпоративных приложений, но является достаточно гибким подходом и может быть адаптирована для небольших систем.

В описании модели стабилизации и синхронизации было упомянуто, что эта модель до сегодняшнего дня не нашла широкого применения вне Microsoft. На самом деле есть достаточно много серьезных организационных сложностей, связанных с использованием специфических средств тестирования (тестирование является важным атрибутом). Далее будут показаны некоторые примеры, которые получены на основе Microsoft Solution Framework не в Microsoft, но они не так уж многочисленны.

Еще одна особенность MSF сводится к тому, что это достаточно адаптивная методология. И как Rational Unified Process, она может быть как большой, так и маленькой, претендует на использование не только для корпоративных, но и для относительно маленьких проектов. Для небольших проектов она называется Agile. Это версия MSF и может быть более формальной, пригодной для больших корпоративных систем. Надо отметить, что принципы, которые заложены в MSF, могут быть использованы не только при проектировании программного обеспечения, а просто при проектировании.

MSF дополняется методологией Microsoft Operation Framework, которая нацелена на работу с существующими программными решениями. Сегодня достаточно актуальной является версия 4.0 Microsoft Solution Framework, но уже больше 10 лет существует MSF и накоплен большой опыт программных проектов (негативный и позитивный). Также, как в Rational Unified Process, существует целый ряд инструментов: визуальных, проектирования, реализации, тестирования и сопровождения, у Microsoft существует средства, которые ориентированы на MSF и поддерживают жизненный цикл программного обеспечения. Это прежде всего Visual Studio, поддерживающий репозиторий проектов на разных языках, визуальное проектирование, описание метаданных проекта, компонентное проектирование (поддержание механизма сборок), безопасное проектирование (каждая сборка идентифицируется цифровой подписью автора), производство программного обеспечения, средства, основанные на веб-сервисах. Эти средства поддерживают командную работу. Уже было сказано о программировании в малом, т. е. об искусстве программирования, и также о программировании в большом, о программной инженерии, технологии производства большого программного обеспечения. Также речь шла о программировании в массе, о командной разработке, где каждый разработчик обладает какой-то ролью, все они должны координироваться в проекте, и необходимо отслеживать соответствие версий. Весь этот сложный функционал берет на себя CASE-средство, в нашем случае Visual Studio.

Нужно сказать, что в основе проектирования как в MSF, так и RUP лежат процессы. И существуют две готовые модели, которые называются Agile и Formal. Они призваны поддерживать построение как небольших программных продуктов, так и больших.

Рассмотрим основные элементы, которые включает MSF. Прежде всего существуют базовые принципы и лучшие практики, которые во многом похожи, но имеют свои особенности. Внутри формируются модели, поддерживающие разработку в команде. Технологии разработки корпоративных информационных систем неосуществимы без грамотной координации и постановки процессов. Microsoft обладает огромным опытом сопровождения программных проектов (существуют средства онлайного сопровождения, большое количество центров и т. д.). У Microsoft также самая большая база знаний по взаимодействию с пользователями. Естественно, существует целый ряд документов, которые описывают дисциплины управления проектами, поскольку в рамках MSF существуют ключевые понятия проекта, менеджера проекта, менеджера продуктов, процедуры управления рисками, разрешения рисков (для этого используется матрица противоречий). Кроме того, существуют наборы практических рекомендаций для той или иной модели, которая применяется для решения задач, связанных с проектированием информационных систем. Если говорить о моделях Agile или Formal, здесь своя специфика, но каждая из них ориентирована на командную разработку, четкое разделение ролей и тесное взаимодействие. Очень важно, что в отличие от RUP и целого ряда других методологий MSF предполагает относительное равенство прав для ролей в проекте. Голос рядового разработчика может быть услышан наряду с голосом менеджера проекта. Учет мнения каждого участника проекта принимается во внимание. Организация потоков работ и активностей, которые составляют эти потоки, похожа на ту, что обсуждалась при разговоре о RUP. Своя специфика связана с отчетами о выполнении рабочих заданий, которые составляют активности. Эти задания включают целый ряд состояний и достаточно обширные отчеты, которые объединяют большое количество различных полей, чтобы сформировать представление о том, в какой степени задание завершено. Более формальная реализация Microsoft Solution Framework Formal включает большее число артефактов, расширенный набор документации и ролей. Эта модель в большой степени подходит для разработки корпоративных приложений.

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

Рис. 5.5. Связь между элементами MSF

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

Как видно из рис. 5.6, в модели команды Microsoft Solution Framework можно выделить несколько областей знаний. Это управление программой, управление продуктом, область, связанная с пользовательским опытом, разработка или реализация, тестирование (тестирование должно происходить в сжатые сроки, достаточно часто и обеспечивать качество каждого релиза, поэтому предполагается использование программных средств и высококвалифицированных специалистов в этой области), опыт, который связан с изготовлением релизов и эксплуатацией, архитектурное проектирование.

Рис. 5.6. Модель команды MSF

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

Центральным понятием в схеме 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 этот подход применяется достаточно редко.