Технология Microsoft Solutions Framework (MSF)

Microsoft Solutions Framework – это методология разработки программного обеспечения от Microsoft. MSF опирается на практический опыт корпорации Microsoft и описывает управление людьмии рабочими процессами в процессе разработки решения.

MSF представляет собой согласованный набор концепций, моделей и правил.

В 1994 г., стремясь достичь максимальной отдачи от IT-проектов, корпорация Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождениюрешений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном корпорацией при работе над большими проектами по разработке и сопровождению программногообеспечения, опыте консультантов Microsoft и лучшем из того, что«накопила» на данный момент IT-индустрия. Все это представленов виде двух взаимосвязанных и хорошо дополняющих друг другаобластейзнаний: MicrosoftOperationsFramework (MOF) иMicrosoftSolutions Framework (MSF).

MOF призван обеспечить организации, создающие критическиважные (mission-critical) IT-решения на базе продуктов и технологийMicrosoft, техническим руководством по достижению их надежности(reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала и процессов; технологиямии менеджментом в условиях сложных (complex), распределенных (distributed) иразнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library(ITIL), составленной Агентством правительства Великобритании (CentralComputerandTelecommunicationsAgency). Информация по MOFдоступна в Интернете по адресу http://www.microsoft.com/mof.

Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSFпредлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своейгибкости, масштабируемости и отсутствию жестких инструкций MSFспособен удовлетворить нужды организации или проектной группылюбого размера. Методология MSF состоит из принципов, моделейи дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Информация по MSFдоступна в Интернете по адресу http://www.microsoft.com/msf.

MSF состоит из двух моделей и трех дисциплин.

Модели MSF: 1) модель проектной группы; 2) модель процессов

Дисциплины MSF: 1) дисциплина «управление проектами»; 2) дисциплина «управление рисками»; 3)дисциплина «управление подготовкой.

Структура процессов MSF. Модель процессов MSF является компромиссной – она сочетает водопадную и спиральную модели жизненного цикла. Проект реализуется поэтапно с использованием необходимых контрольных точек. Сама же последовательность этапов можетповторяться по спирали. Схема этой модели представлена на рис. 19.3.

В этой схеме планирование на основе промежуточных контрольных точек и предсказуемость водопадной модели дополняются наличием обратной связи с заказчиком и творческим подходом к решению задач, свойственным спиральной модели.

Рис. 19.3. Этапы и контрольные точки модели процессов MSF

Таким образом, модель процессов MSF позволяет создавать и развертывать решенияуровня предприятия, обеспечивая прогнозируемость хода проектови учитывая реальные условия их выполнения.

Создание общей картины приложения. На этом этапе решаютсяследующие основные задачи:

- определение состава команды;

- определение структуры проекта;

- определение бизнес-целей;

- оценка существующей ситуации;

- создание документа общей картины и области действия проекта;

- определение требований и профилей пользователей;

- разработка концепции решения;

- оценка риска;

- закрытие этапа.

На этом этапе выделяются две промежуточные контрольные точки: «Организован костяк команды» и «Создана общая картина решения».

Организован костяк команды – здесь не обязательно нужен полный поименный список команды, но в документе структуры проектадолжны быть определены роли и обязанности каждого члена команды, а также описана иерархия отчетности и ответственности в группе, каналы взаимодействия с заказчиком и общая структура команды.

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

Данный этап завершается контрольной точкой «Утверждение документа общей картины и области действия проекта».

Планирование. На этапе планирования команда решает, что нужно разработать, и формирует планы реализации продукта. Готовитсяфункциональная спецификация, создается проект решения, детализируются планы работы, выполняется оценка стоимости и сроковполучения результатов.

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

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

В ходе данного этапа решаются следующие задачи:

- разработка проекта и архитектуры решения;

- создание функциональной спецификации;

- разработка планов проекта;

- разработка календарного графика;

- создание среды разработки, тестирования и пилотной эксплуатации;

- закрытие этапа.

Контрольные точки этапа планирования связаны с достижениемследующих результатов:

- функциональная спецификация;

- план управления рисками;

- определение среды разработки и тестирования;

- генеральный план и календарный график проекта.

Результаты данного этапа служат для принятия компромиссныхрешений в дальнейшем.

Разработка. На этапе разработки создается решение, в том числепишется и документируется код. В начале этого этапа команда проверяет выполнение всех задач, характерных для предыдущих этапов, а затем приступает к решению следующих задач:

- создание прототипа приложения;

- разработка программных компонентов приложения;

- создание решения (последовательность ежедневных или более частых сборок приложения;

- закрытие разработки (реализация всех функций, поставка кода идокументации.

Результаты этапа предполагают следующие элементы:

- исходный текст кода и исполняемые файлы;

- сценарии установки и конфигурации для развертывания;

- окончательная функциональная спецификация;

- элементы поддержки решения;

- спецификации и сценарии тестирования.

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

Стабилизация. Данный этап – подготовка к выпуску окончательной версии продукта, доводка его до заданного уровня качества.

На этапе стабилизации выполняется комплекс работ по тестированию(обнаружение и устранение дефектов), а также проверяется сценарийразвертывания продукта и проводится пилотная эксплуатация.

Тестирование подразумевает следующие основные виды работ:

- тестирование компонентов;

- тестирование баз данных;

- тестирование инфраструктуры;

- тестирование защиты;

- тестирование интеграции;

- анализ удобства работы с продуктом;

- нагрузочное тестирование (включая анализ ресурсоемкости и производительности

- регрессивное тестирование;

- ведение отчетности по тестированию.

Когда решение становится достаточно устойчивым, проводитсяего пилотная эксплуатация в тестовой среде с привлечением пользователей и применением реальных сценариев работы.

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

Завершающаяконтрольная точка – «Подтверждение готовности продукта к выпускуи полноценному развертыванию в промышленной среде».

Развертывание. На этом этапе выполняется установка решенияи необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и осуществляется передача проектав руки группы сопровождения. Кроме того, анализируется проектв целом на предмет уровня удовлетворенности заказчика.

Основные контрольные точки данного этапа:

- развернуты основные компоненты;

- развернуто решение в целом;

- развернутое решение стабилизировано;

- решение развернуто и передано в эксплуатацию заказчику.

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

Комментарии по поводу этапов работ. В целом те же самые идеилежат в основе всех современных промышленных методологий разработки ПО (IBM/Rational, Borland, Microsoft и т. д.) – именно этимотличаются выверенные временем технологии от кустарного производства. Но в то же время в каждой методологии есть свой подходк выделению различных этапов разработки и зачастую используетсясобственная терминология, что усложняет проведение параллелеймежду ними. Эта проблема усугубляется отсутствием устоявшейсярусской терминологии.

Далее приведен общепринятый в настоящее время перечень ALMэтапов, которого, в частности, придерживаются Borland и Rational:

- Defining (определение требований);

- Designing (анализ и проектирование);

- Developing (разработка);

- Testing (тестирование);

- Deploying (развертывание).

Модель MSF предлагает немного другое подразделение на этапыи их наименования. Здесь речь идет не просто о разных названиях одних и тех же видов деятельности. Объективная проблема категоризациизаключается в том, что выделение самостоятельных этапов в жизненномцикле приложений условно, особенно если речь идет об итерационнойциклической модели разработки. Например, широкое использованиевизуальных методов проектирования с автоматической генерацией кодафактически стирает грань между проектированием и кодированием, а тестирование вообще пронизывает всю «жизнь» программы.

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

Формирование проектных команд. Один из ключевых элементовреализации проекта – задача управления коллективом его участников.

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

Она может применяться в соответствии с потребностями и контекстомпроекта, размером коллектива и опытом участников команды. Далеекратко охарактеризованы роли, используемые в модели команд MSF.

Менеджер продукта (product manager) отвечает за управление связями с клиентом. На этапе проектирования он собирает требования заказчика и осуществляет контроль за тем, чтобы они соответствовали потребностям его бизнеса. Он также разрабатывает план взаимодействияс клиентом в ходе реализации проекта, в том числе организует встречис клиентом, демонстрации продукта и другие маркетинговые акции.

Менеджер программы (program manager) управляет собственноразработкой ПО и несет ответственность за его поставку в соответствии с утвержденными спецификациями.

Разработчик (developer) занимается разработкой ПО в соответствии с заданными спецификациями.

Тестировщик (tester) выявляет и устраняет все неполадки в продукте и дает окончательное разрешение на его выпуск. Он такжеоценивает соответствие набора реализованных в продукте функцийобщей концепции и области действия проекта.

Менеджер по выпуску (release manager) отвечает за развертываниеи поддержку продукта, проверяет корректность ИТ-инфраструктурызаказчика на предмет ее готовности к эксплуатации ПО.

Специалист по удобству использования (user experience specialist) занимается изучением и решением проблем пользователей, оцениваетпродукт с точки зрения соответствия их потребностям.

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