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

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

Энциклопедичный YouTube

  • 1 / 5

    Следует отметить, что Microsoft разработала на базе общих методов MSF методики для прикладного и специализированного применения. Причём, Microsoft сертифицирует экспертов именно по прикладным знаниям в применении MSF (например, сертификация MCTS 74-131 по экспертизе в методике управления проектами). Перед тем, как изучать методы MSF, следует сначала определить, какой прикладной вариант MSF имеется в виду.

    Наиболее популярные прикладные варианты MSF, разработанные Microsoft:

    • методика внедрения решений в области Управления проектами;
    • методика управления IT-проектами на базе методологий MSF и Agile.

    Важность прикладных вариантов MSF подчёркивает тот факт, что в «чистом варианте» саму методику MSF в своих IT-проектах компания Microsoft не использует. В проектах Microsoft Consulting Services используется гибридная методология MSF и Agile. Несмотря на внешние существенные различия прикладных вариантов MSF, разработанных экспертами Microsoft, общая база методов MSF для них остается общая и отражает общие методологические подходы к итеративному ведению проектов.

    MOF призван обеспечить организации, создающие критически важные (англ. mission-critical ) IT решения на базе продуктов и технологий Microsoft, техническим руководством по достижению их надёжности (англ. reliability ), доступности (англ. availability ), удобства сопровождения (англ. supportability ) и управляемости (англ. manageability ). MOF затрагивает вопросы, связанные с организацией персонала и процессов, технологиями и менеджментом в условиях сложных (англ. complex ), распределённых (англ. distributed ) и разнородных (англ. heterogeneous ) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленных Central Computer and Telecommunications Agency - Агентством правительства Великобритании.

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

    MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers. Начинать изучение MSF лучше с моделей, а затем перейти к дисциплинам.

    MSF содержит:

    • модели :
      • модель проектной группы
      • модель процессов
    • дисциплины :
      • дисциплина управление проектами
      • дисциплина управление рисками
      • дисциплина управление подготовкой

    Модель проектной группы MSF

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

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

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

    Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.

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

    1. Распределение ответственности при фиксации отчетности
    2. Наделяйте членов команды полномочиями
    3. Концентрируйтесь на бизнес-приоритетах
    4. Единое видение проекта
    5. Проявляйте гибкость - будьте готовы к переменам
    6. Поощряйте свободное общение

    Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):

    1. Команда соратников
    2. Сфокусированность на нуждах заказчика
    3. Нацеленность на конечный результат
    4. Установка на отсутствие дефектов
    5. Стремление к самосовершенствованию
    6. Заинтересованные команды работают эффективно

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

    В проектную группу входят такие ролевые кластеры :

    • управление программой
    • управление продуктом
    • разработка
    • тестирование
    • управление релизом
    • удовлетворение потребителя

    Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же - построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.

    Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за :

    • управление программой (program manager) - разработку архитектуры решения, административные службы;
    • разработку (developer) - разработку приложений и инфраструктуры, технологические консультации;
    • тестирование (QAE) - планирование, разработку тестов и отчетность по тестам;
    • управление выпуском (release manager) - инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;
    • удовлетворение заказчика (user experience) - обучение, эргономику, графический дизайн, техническую поддержку;
    • управление продуктом (product manager) - бизнес-приоритеты, маркетинг, представительство интересов заказчика.

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

    В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:

    1. Роль команды разработчиков не может быть объединена ни с какой другой ролью.
    2. Избежание сочетания ролей, имеющих предопределенные конфликты интересов.

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

    MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами , при котором:

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

    Как следует из вышесказанного, одна из характерных особенностей MSF - отсутствие должности менеджера проекта!

    Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.

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

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

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

    Модель процессов MSF

    Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена ещё одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать своё внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.

    Процесс MSF ориентирован на «вехи » (milestones) - ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: «Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?», «В достаточной ли степени готов план действий?», «Соответствует ли продукт утверждённой спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т. д.

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

    Модель процессов MSF тесно связана с базовыми принципами MSF, рассмотренными выше. Вообще говоря, тремя особенностями модели процессов MSF являются:

    • Подход, основанный на фазах и вехах.
    • Итеративный подход.
    • Интегрированный подход к созданию и внедрению решений.

    Модель процессов включает такие основные фазы процесса разработки:

    • Выработка концепции (Envisioning)
    • Планирование (Planning)
    • Разработка (Developing)
    • Стабилизация (Stabilizing)
    • Внедрение (Deploying)

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

    • что (какие артефакты) является результатом этой фазы
    • над чем работает каждый из ролевых кластеров на этой фазе

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

    Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. «Живые» документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.

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

    Управление рисками

    Управление рисками (risk management) - это одна из ключевых дисциплин Microsoft Solutions Framework® (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF (MSF risk management discipline) отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Девиз MSF - мы не боремся с рисками - мы ими управляем .

    Как уже говорилось выше, в MSF нет роли «менеджер проекта». Деятельность по управлению проектом распределяется между лидерами групп и ролевым кластером «Управление программой».

    Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS . Иерархическая структура работ (Work Breakdown Structure - WBS) - это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.

    Управление подготовкой

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

    .

    Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов.

    Процесс MSF ориентирован на «вехи» (milestones) - ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: «Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?», «В достаточной ли степени готов план действий?», «Соответствует ли продукт утвержденной спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т. д.

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

    Тремя особенностями модели процессов MSF являются:

      Подход, основанный на фазах и вехах.

      Итеративный подход.

      Интегрированный подход к созданию и внедрению решений.

    Модель процессов включает такие основные фазы процесса разработки:

      Выработка концепции (Envisioning)

      Планирование (Planning)

      Разработка (Developing)

      Стабилизация (Stabilizing)

      Внедрение (Deploying)

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

      что (какие артефакты) является результатом этой фазы

      над чем работает каждый из ролевых кластеров на этой фазе

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

    Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. «Живые» документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.

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

    Олег Большаков

    Методология разработки программного обеспечения Microsoft Solution Framework появилась в 1994 году. В основу методологии MSF заложен накопленный опыт компании Майкрософт в области управления человеческими ресурсами и рабочими процессами в ходе разработки программных решений. Данные знания базируются на опыте работы компании Майкрософт над крупными проектами по разработке и сопровождению программного обеспечения, а также прочего опыта IT-индустрии.

    Основу методологии составляют модели и дисциплины.

    • модель проектной группы;
    • модель процессов.

    Дисциплины:

    • дисциплина управления проектами;
    • дисциплина управления рисками;
    • дисциплина управления подготовкой.

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

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

    В проектную группу входят следующие ролевые кластеры (рис.1):

    • Управление продуктом (Product Management) . Ключевая цель данного ролевого кластера - довольные заказчики. Проект не может считаться успешным, если он не привел к удовлетворению потребностей заказчика. Возможна ситуация, когда проектная группа уложилась в бюджет и сроки, но успех не был достигнут, так как не были удовлетворены бизнес-нужды заказчика.
    • Управление программой (Program Management). Основная задача этого ролевого кластера - обеспечить реализацию решения в рамках ограничений проекта. Для этого контролируются календарный график проекта, объем работы и отведенный на проект бюджет. Рассматриваемый кластер обеспечивает своевременное достижение требуемых результатов и удовлетворение ожиданий спонсора на протяжении проекта.
      В версии MSF 4 из данного ролевого кластера был выведен кластер "Управление архитектурой", который подразумевает организацию и выполнение высокоуровневого проектирования решения, создание функциональной спецификации ПО и управление этой спецификацией в процессе разработки, определение рамок проекта и ключевых компромиссных решений.
    • Разработка (Development) . Первостепенной задачей ролевого кластера "Разработка" является построение решения в соответствии со спецификацией. Ее выполнение означает создание решения, соответствующего ожиданиям заказчика и условиям, сформулированным в функциональной спецификации. Также данный ролевой кластер строго следует выработанной архитектуре и дизайну решения, которые совместно с функциональной спецификацией составляют сводное описание конечного продукта.
    • Тестирование (Test) . Задача данного ролевого кластера - одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Но нужно обнаружить и уладить все из них до того, как продукт выпущен. Улаживание дефекта может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта. Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом.
    • Удовлетворение потребителя (User Experience) . Цель этого ролевого кластера - повышение эффективности использования продукта.
    • Управление выпуском (Release Management) . Цель этого ролевого кластера - беспрепятственное внедрение и сопровождение продукта. Эта роль служит связующим звеном между проектной группой и группами процессов сопровождения.

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

    Д - допустимо, Н - недопустимо, Н/Ж - не желательно

    Анализируя данную матрицу можно сделать следующие выводы:

    • Недопустимо совмещать ролевые кластеры управления продуктом и управления программой.
    • Ролевой кластер "Разработка" нельзя совмещать ни с одним другим ролевым кластером.
    • Совмещения других кластеров допустимы, но части из них - нежелательны.

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

    Таким образом, минимальный коллектив, применяющий методологию MSF, может состоять всего лишь из трех человек, которые будут совмещать ролевые кластеры следующим образом (рис.2):

    • Удовлетворение потребителя, Управление продуктом, Тестирование.
    • Управление программой, Управление выпуском.
    • Разработка.

    Отметим, что такое распределение ролей по матрице допустимо без ограничений, причем соблюдены два основных ограничения: роль разработчика не совмещена ни с одной другой ролью; и нет совмещения ролей, имеющих предопределенные конфликты интересов. Также следует отметить рекомендацию Майкрософт касаемо совмещения ролей: когда проектная команда состоит из шести или меньшего количества участников, выполняющих все проектные роли - деятельность по управлению проектом осуществляется ролевым кластером "Управление программой".

    В случае если необходимо увеличение количества участников проекта (от 10 и более), Майкрософт предлагает разбиение больших команд на малые группы направлений (feature teams) . Такие группы работают параллельно, с постоянной синхронизацией результатов работы. Таким образом, происходит гибкое масштабирование модели проектной группы. Пример варианта масштабирования приведен на рис.3.

    В качестве заключительного вывода к статье можно привести слова Стива Макконнелла (Steve C McConnell): "Даже при наличии квалифицированных, мотивированных и трудолюбивых людей неверная структура команды способна свести на нет их усилия, вместо того чтобы привести их к успеху. Слабая структура команды может послужить причиной увеличения времени разработки, снижения качества, понижения морального духа, повышения текучести кадров и, в конечном итоге, привести к провалу проекта".

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

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

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

      • модель команды

        модель процессов

      • дисциплины:

      • дисциплина управление проектами

        дисциплина управление рисками

        дисциплина управление подготовкой

    Модель команды msf

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

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

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

      Распределение ответственности при фиксации отчетности

      Наделение членов команды полномочиями

      Концентрация на бизнес-приоритетах

      Единое видение проекта

      Гибкость и готовность к переменам

      Поощрение свободного общения

    Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций:

      Команда соратников

      Сфокусированность на нуждах заказчика

      Нацеленность на конечный результат

      Установка на отсутствие дефектов

      Стремление к самосовершенствованию

      Заинтересованные команды работают эффективно

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

      управление программой (program manager) - разработка архитектуры решения, административные службы;

      разработка (developer) - разработка приложений и инфраструктуры, технологические консультации;

      тестирование (QAE) - планирование, разработка тестов и отчетность по тестам;

      управление выпуском/логистикой (release manager) - инфраструктура, сопровождение, бизнес-процессы, выпуск готового продукта;

      удовлетворение заказчика (user experience) - обучение, эргономика, графический дизайн, техническая поддержка;

      управление продуктом (product manager) - бизнес-приоритеты, маркетинг, представительство интересов заказчика.

    Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же - построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.

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

    В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:

      Роль команды разработчиков не может быть объединена ни с какой другой ролью.

      Избежание сочетания ролей, имеющих предопределенные конфликты интересов.

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

    MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:

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

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

    Как следует из вышесказанного, одна из характерных особенностей MSF - отсутствие должности менеджера проекта.

    Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.

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

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

    Ключевые термины Microsoft Solution Framework (MSF) Модель проектной группы Модель процесса проектирования Модель приложения Модель разработки решений Службы пользователя Службы бизнеса Службы данных Концептуальный проект Логический проект Физический проект Необходимые знания и приемы Распознавание ролей в модели проектной группы Распознавание фаз и вех в модели процесса проектирования Распознавание типов служб в модели приложения Распознавание точек зрения в модели разработки решений

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

    • Модель проектной группы (team model). Одна из основных моделей MSF. Описывает методы организации людей в высокоэффективные группы.
    • Модель процесса (process model). Еще одна основная модель MSF. Содержит рекомендации по организации процесса разработки, способствующие принятию лучших проектных решений.
    • Модель приложения (application model). Предлагает общую структуру модульного приложения, помогающую масштабируемости, производительности и расширяемости продукта.
    • Модель разработки решений (solutions design model). Показывает, как, придерживаясь точки зрения заказчика и его бизнеса, создавать решения, наиболее полно отвечающие его ожиданиям.
    • Модель архитектуры масштаба предприятия (enterprise architecture model). Помогает в принятии ключевых решений, касающихся информации, приложений и технологий, необходимых для поддержки развивающегося и растущего бизнеса.
    • Модель общей стоимости владения (total cost of ownership model). Предлагает направленный на минимизацию стоимости владения подход к использованию, развитию и управлению информационными технологиями.

    Подробному описанию этих моделей и будет посвящена эта глава.
    Одно из ключевых свойств MSF - возможность коллективного обсуждения в терминах вышеозначенных моделей различных высокоуровневых аспектов проекта, включая концепцию, архитектуру и распределение обязанностей. Другой ключевой аспект - связанность проектной группы и проекта: проект заканчивают те же люди, что и начинают (в противовес другому подходу, при котором над проектом работают несколько групп, каждая из которых, выполнив свой узкоспециализированный кусочек работы, передает проект другой группе, и так вплоть до его завершения). Таким образом, группа, работающая над проектом, обладает всеми навыками, необходимыми для принятия решений, ведущих к его завершению. Развитие же самого проекта рассматривается как последовательное прохождение вех (milestones), позволяющих проектной группе измерять степень соответствия и прогресса актуального проекта относительно первоначального замысла.
    Microsoft все время оценивает свои собственные методологии по ведению проектов, а также отзывы использующих MSF. Анализ этой информации приводит к расширению существующих моделей MSF и включению новых, что делает MSF динамической, постоянно развивающейся и улучшающейся системой.

    Модель проектной группы

    Своим успехом любой проект обязан прежде всего людям, его выполнившим, поэтому модель проектной группы является краеугольным камнем MSF. Эта модель построена на шести четко определенных ролях, выполняемых членами проектной группы (не исключая распределения ролей типа "одна роль - несколько человек" и "один человек - несколько ролей"): Менеджер программы (Program Management), Менеджер продукта (Product Management), Разработчик (Development), Тестер (Testing), Инструктор (User Education) и Логистик (Logistics Management). За каждой из этих ролей закреплен свой набор вех, за который она ответственна.
    Важная особенность этой модели заключается в том, что она не устанавливает отношений подчинения или подотчетности между ролями. В реальности проектная группа может быть составлена из людей, принадлежащих к различным организациям и потому подчиняющихся различным руководителям. Рисунок 3.1 иллюстрирует это.
    Проектная группа - группа равных, формируемая из людей, обладающих качествами, требуемыми для принятия решений, необходимых для успешной разработки и выпуска продукта. Группа разделяющих одну роль сосредоточивается на конкретной задаче, определяемой ролью, в то время как лидеры каждой из групп отвечают за межгрупповое взаимодействие и управление. При этом главной задачей каждого является выпуск успешного продукта в запланированные сроки. Работая сообща, члены проектной группы определяют образ продукта, сам продукт, процесс разработки и планируют проектные вехи, после чего сами отслеживают продвижение и состояние проекта.


    Рис. 3.1. Модель проектной группы MSF

    Данная модель проектной группы позволяет реализовать следующие свойства:

    • Полномочность (empowerment). Члены проектной группы полномочны принимать решения в областях своей компетентности. Например, разработчики могут контролировать, как и какие технологии применять в процессе разработки.
    • Ответственность (accountability). Каждый член группы чувствует себя ответственным за все аспекты проекта, как то: анализ, планирование, разработку, стабилизацию и выпуск.
    • Вовлеченность (identity). Членам группы присущ высокий уровень вовлеченности и ответственности друг перед другом. Член такой группы считает конечной целью своей работы выпуск продукта к 12 июля, а не просто создание форм для ввода заказов.
    • Согласность (consensus). Группе свойственна атмосфера открытости, поскольку ее члены идентифицируют себя скорее с конечным продуктом, чем с собственной деятельностью в группе, и поскольку они разделяют взаимную ответственность за продукт.
    • Сбалансированность (checks and balances). Проектная группа представляет собой сбалансированное сочетание навыков, обязанностей и точек зрения.

    Характеристики модели проектной группы в MSF

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

    Роли в модели проектной группы MSF

    В проектной группе MSF определены ровно шесть ролей: Менеджер продукта (Product Management), Менеджер программы (Program Management), Разработчик (Development), Тестер (Testing), Инструктор (User Education) и Логистик (Logistics Management).

    Менеджер продукта

    Главная функция менеджера продукта - Его работа не связана напрямую с продажей, он устанавливает и поддерживает коммуникационный канал между заказчиком и проектной группой. Основная задача этой роли - удовлетворение заказчика .
    В частности, в обязанности Менеджера продукта входит:

    • управление согласованным с заказчиком образом и границами проекта;
    • управление определением запросов заказчика;
    • разработка и поддержка бизнес-контекста продукта;
    • управление удовлетворением ожиданий заказчика;
    • управление балансом между функциональностью продукта и графиком проекта;

    Менеджер программы

    Эта роль отвечает за функциональные спецификации приложения и за координацию усилий внутри проектной группы, ведя проект к успешному завершению и являясь, по сути дела, лидером и координатором проекта (но не боссом). Менеджер программы поддерживает связь между разработчиком и менеджером продукта. Основная задача этой роли - создание продукта вовремя и в рамках выделенного бюджета .
    В частности, в обязанности Менеджера программы входит:

    • управление процессом разработки;
    • управление спецификацией продукта;
    • облегчение взаимодействия и общения внутри группы;
    • ведение графика проекта и составление отчетов по состоянию проекта;

    Разработчик

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

    • создание физического проекта;
    • создание плана разработки;
    • создание продукта;

    Тестер

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

    • отслеживание всех ошибок и проблем взаимодействия;

    Инструктор

    Инструктор выступает в роли представителя проектной группы для конечного пользователя продукта. Основная его задача - максимальная эффективность работы пользователя .
    В частности, в обязанности Инструктора входит:

    • взаимодействие с конечным пользователем;
    • управление определением запросов пользователя;
    • разработка и реализация мер по поддержке производительности пользователя: системы помощи, документации пользователя, курсов и т. п.;

    Логистик

    Логистик призван обеспечить гладкое внедрение и развитие продукта. Он отвечает за готовность заказчика к внедрению, своевременное выполнение всех подготовительных работ и существование необходимой инфраструктуры. Основная задача этой роли - гладкое внедрение продукта .
    В частности, в обязанности Логистика входит:

    • взаимодействие со службами операций, поддержки и доставки;
    • управление обеспечением;
    • управление внедрением продукта;
    • управление решениями по развертыванию и сопровождению продукта;

    Совмещение ролей

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

    Модель процесса

    Модель процесса также является одной из основных моделей MSF. Ее назначение, равно как и любой другой модели процесса разработки, - предоставить общую структуру, упорядочивающую деятельность проектной группы на всем ее пути к завершению проекта. Известно и опробовано множество моделей процесса проектирования, к одной из которых - традиционной каскадной модели - мы еще вернемся в этой главе.
    Модель MSF базируется на успешно применяемой внутри подразделений Microsoft модели жизненного цикла продукта. Внутри этой модели различаются четыре фазы, с каждой из которых связана определенная веха, ее завершающая, и набор отчуждаемых материалов (deliverables), производимых группой по достижении вехи. Рис. 3.2 графически иллюстрирует суть модели процесса MSF (фазы отображены в виде стрелок, вехи - эллипсов). Что не показано на рисунке, так это то, что процесс принципиально цикличен и развивается по спирали (на рисунке изображен лишь один ее виток). Таким образом, мы имеем итеративный, а не линейный процесс, базирующийся на последовательности улучшений и тем самым позволяющий проектной группе гибко реагировать на изменение приоритетов в процессе развития проекта.
    Четыре фазы, составляющие модель процесса MSF, называются, соответственно, анализ (envisioning), планирование (planning), разработка (developing) и стабилизация (stabilizing).
    С каждой фазой связана собственная внешняя веха, означающая успешное завершение всех активностей фазы. Кроме внешней, могут быть и внутренние (промежуточные) вехи, отмечающие степень продвижения к основной вехе.
    Вехи -точки саморегуляции процесса. Это точки пересмотра и синхронизации, а не точки замораживания проектных решений, после которых они становятся окончательными. В это время синхронизируются отчуждаемые материалы, уточняются ожидания заказчика и, быть может, пересматриваются границы проекта, дабы подстроиться под изменившиеся требования заказчика, а также дать ход изменениям, накопившимся за время развития проекта.


    Рис. 3.2. Модель процесса MSF

    Характеристики модели процесса проектирования MSF

    У данной модели есть четыре характерные особенности:

    • Ориентация на вехи (milestone-based approach). Проектные вехи (как внешние, так и внутренние) служат в качестве контрольных точек для синхронизации отчуждаемых материалов проекта.
    • Четкое разграничение зон ответственности (clear ownership and accountability).Ответственность за каждую из вех четко определена и привязана к проектной роли.
    • Планирование с учетом рисков (risk-driven scheduling). Части проекта, связанные с наибольшими рисками, выявляются и разрабатываются как можно скорее.
    • Выпуск версий (versioned releases). Подход, основанный на разделении больших проектов на несколько версий, сменяющих друг друга на протяжении жизни продукта, делает более обозримым текущий фронт работ проектной группы. Кроме того, он позволяет группе выбирать, какая новая функциональность будет добавлена в разрабатываемую версию, увеличивая вероятность завершения работ в установленные сроки.

    Фазы модели процесса проектирования MSF

    Модель процесса MSF суть ориентированная на процесс модель (process-oriented model), состоящая из четырех фаз. О них и пойдет речь ниже.

    Фаза анализа

    На этой фазе достигается договоренность с заказчиком относительно общего облика и направления развития проекта, в частности, оговаривается, что войдет в продукт, а что - нет, и определяются образ (vision) и границы (scope) проекта. Под образом понимается описание наиболее желательных с точки зрения бизнеса и конечного пользователя качеств будущего продукта без оглядки на технические аспекты реализации.
    Закончив создание образа, можно двигаться дальше, к определению границ проекта - отображению его образа на возможности реализации задуманного. Здесь принимаются во внимание такие факторы, как доступные технологии, стоимости, графики и ресурсы, и выясняется, каковы возможности реализации образа с учетом существующих ограничений.
    Фаза анализа заканчивается вехой "Общее описание проекта" (vision/scope approved), означающей наличие внутригруппового согласия по следующим вопросам:

    • общее видение продукта;
    • потребности заказчика, которые должны быть удовлетворены в первую очередь;
    • оценка сроков;
    • риски и предположения, связанные с проектом;
    • бизнес-ограничения, способные повлиять на проект.

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

    Таблица 3.1. Вехи и отчуждаемые материалы фазы анализа
    Фаза Вехи Отчуждаемые материалы
    Анализ Закончено формирование группы(team formation complete) Документ "Образ и границы проекта" (vision/scope document)
    Предварительная версия документа "Образ и границы проекта" (draft vision/scope) План управления рисками (risk management plan)
    Окончательная версия документа "Образ и границы проекта" (final vision/scope) Документ "Структура проекта" (project structure document)
    Общее описание проекта (vision/scope approved) Оценка затрат, связанных со следующей фазой, и база данных ошибок (issues and bug database)

    Фаза планирования

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

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

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

    Таблица 3.2. Вехи и отчуждаемые материалы фазы планирования
    Фаза Вехи Отчуждаемые материалы
    Планирование Завершен концептуальный проект (conceptual design complete) Документ "Концептуальный проект" (conceptual design document)
    Завершена проектная спецификация (design specification complete) Проектная спецификация (design specification)
    Завершен план проекта (master project plan complete) План по безопасности (security plan)
    Функциональная спецификация (project plan approved) План-график тестера (test plan)
    План-график инструктора (user education plan)
    План-график логистика (logistics plan)
    График проекта (master project schedule)
    План проекта (master project plan)
    СОВЕТ Объединенное содержимое документа по концептуальному проекту и плана проекта охватывает информацию, содержащуюся в функциональной спецификации.

    Фаза разработки

    Это фаза действия, фаза следования планам - здесь разрабатывается готовое к использованию решение, то есть по окончании фазы вся требуемая функциональность реализована и продукт готов к внешнему тестированию и стабилизации. Достижение этой точки дает возможность всем участникам проекта оценить продукт и, если остались какие-нибудь нерешенные вопросы, решить их до выпуска продукта.
    Веха, завершающая фазу разработки, так и называется - "Завершение разработки" (scope complete/first use). Ее достижение означает, что проектная группа считает решение готовым к внедрению. А также означает готовность к внедрению и любых других дополнительных средств, например средств поддержки или обучения пользователей.
    Названия всех четырех вех фазы и ее отчуждаемые материалы приведены в табл. 3.3.

    Таблица 3.3. Вехи и отчуждаемые материалы фазы разработки
    Фаза Вехи Отчуждаемые материалы
    Разработка Завершено лабораторное тестирование (lab testing complete) План пилотного проекта (pilot plan)
    Концепция одобрена (proof of concept complete) План обучения пользователей (training plan)
    Пилотный проект завершен (pilot complete) План развертывания (rollout plan)
    Завершение разработки (scope complete/first use) Обновленный план управления рисками (updated risk management plan)
    Документация к продукту (documentation)
    Функциональная спецификация на текущую версию (versioned functional specification)
    Обновленный график проекта (updated schedule)

    Фаза стабилизации

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

    Таблица 3.4. Вехи и отчуждаемые материалы фазы стабилизации
    Фаза Вехи Отчуждаемые материалы
    Стабилизация Начато развертывание (rollout begins) Бинарные файлы проекта (project binaries)
    Завершено обучение (training complete) Пояснения к текущей версии (release notes)
    Развертывание завершено (rollout complete) Исходные тексты текущей версии (versioned source)
    Завершена стабилизация (stabilization complete) Руководства по обучению (training manuals)
    Выпуск (release) Документация (documentation)
    Обновленный план управления рисками (updated risk management plan)

    Традиционные модели процесса

    Традиционные модели процесса, как правило, основаны на так называемой каскадной модели. Каскадная модель является ориентированной на задачу (task-oriented model) и чаще всего содержит следующие фазы:

    • подготовка;
    • анализ;
    • проектирование;
    • конструирование;
    • тестирование;
    • переход и миграция;
    • эксплуатация.

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

    СОВЕТ Хотя модель процесса проектирования MSF тоже делится на фазы, она, в отличие от ориентированной на задачу каскадной модели, является ориентированной на процесс моделью с понятием вех.

    Модель приложения

    Модель приложения описывает понятие приложения в концептуальных терминах и предоставляет определения, правила и отношения, задающие его структуру. Модель приложения не навязывает детали реализации, она лишь предоставляет отправную точку для их обсуждения. С ее помощью можно обмениваться идеями как о возможной логической структуре приложения, так и о способах реализации структуры физической. Таким образом, модель позволяет определиться с тем, как будет создаваться приложение, поэтому ее понимание является ключевым для эффективной разработки успешных приложений.
    Согласно определению Microsoft, приложение строится из логической сети потребителей (services consumers) служб и их поставщиков (services suppliers). Для поддержки потребностей многих приложений такие службы могут быть распределенными относительно физических или функциональных границ. Служба, она же сервис (service) - это элемент логики приложения, реализующий операции, функции или преобразования, применяемые к объектам. Служба может соответствовать бизнес-правилу, выполнять определенные вычисления, манипулировать данными или предоставлять возможности для ввода, получения, просмотра и изменения информации.
    В модели приложения MSF службы делятся на три категории: службы пользователя (user services), службы бизнеса (business services) и службы данных (data services). Подобное разделение находится в соответствии с многоярусной моделью распределенных приложений, поэтому модель приложения MSF рекомендуется в качестве подхода для создания подобных приложений.
    Использование модели, основанной на четко определенных категориях служб, напрямую поддерживает концепцию модульности, имеющую множество преимуществ по сравнению с концепцией монолитных приложений, создававшихся в прошлом. Кроме того, есть и технология, позволяющая создавать модульные приложения, основанные на этой модели: Component Object Model (COM).

    СОВЕТ С развитием Интернет-технологий модель приложения MSF становится все более популярной, поскольку она позволяет одному и тому же набору служб бизнеса и служб данных быть доступным как через компонент службы пользователя в клиентском приложении, так и через Web-страницу.

    Службы пользователя

    Службы пользователя - это элементы логики приложения, предоставляющие интерфейс с пользователем. Пользователем приложения может быть человек или другое приложение. Таким образом, служба пользователя может быть графическим интерфейсом пользователя (graphical user interface, GUI), а может - программируемым интерфейсом (application programming interface, API).
    К примеру, все продукты семейства Microsoft Office отличает развитый графический интерфейс пользователя. В дополнение к этому интерфейсу каждый из продуктов также содержит набор программируемых интерфейсов, предоставляющих доступ к той же функциональности, что и графический интерфейс, но через программирование.
    Службы пользователя отвечают за управление всеми аспектами взаимодействия между пользователем и приложением. При проектировании этих служб необходимо понимать пользователя, знать его запросы, привычки и сложившиеся подходы к решению типичных для него задач.

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

    Службы бизнеса

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

    • Гибкость во внедрении компонентов служб бизнеса. Например, службы бизнеса могут быть реализованы на отдельном сервере приложений в виде процедур, хранимых в СУБД, или в виде процедур на клиентской системе.
    • Возможность скрывать стандартный набор служб бизнеса за различными интерфейсами пользователя. Например, набор служб, реализованный в виде отдельного компонента, выполняющегося на сервере приложений, может использоваться самыми различными клиентами: макросом Microsoft Office, заказным приложением, написанным на Visual Basic, или Microsoft Explorer для отображения Web-страницы.
    • Дополнительная гибкость в поддержке бизнес-логики приложения как результат изоляции изменений от служб пользователя и служб данных.

    Службы данных

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

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

    Модель разработки решений

    Модель разработки решений предоставляет пошаговую стратегию для проектирования решений, руководствуясь конкретными бизнес-потребностями. Целью этой стратегии является решение, напрямую отвечающее потребностям бизнеса. Проектирование происходит поэтапно:

    • концептуальное проектирование;
    • логическое проектирование;
    • физическое проектирование.

    Процесс проектирования программного продукта часто объясняется посредством аналогии с процессом проектирования здания. Проект здания начинается с эскизов архитектора, дающих заказчику представление об облике строения. Кроме того, среди эскизов могут быть и планы этажей, и диаграммы, показывающие, как новое здание вписывается в существующее окружение. В проекте программного продукта эскизам архитектора соответствует концептуальный проект (conceptual design): проектирование продукта начинается с понимания потребностей пользователя, с создания и обсуждения с заказчиком одной или нескольких моделей, отражающих это понимание.
    За эскизами архитектора следуют архитектурные планы - взгляд на здание с точки зрения архитектора. На этой фазе видение здания заказчиком объединяется с видением и знаниями архитектора, и эскизы архитектора уступают место детальным чертежам, имея которые, уже можно общаться с подрядчиками и другими строительными организациями. В проектировании программного продукта данной фазе соответствует логический проект (logical design), в котором описываются логические элементы проекта и взаимосвязи между ними.
    И наконец, для строителей создаются конструкторские планы. На этом этапе к архитекторным планам добавляются детали, учитывающие особенности местности и доступность различных строительных материалов. Полученные планы содержат все детали, необходимые для работы субподрядчиков, и служат руководством к действию для строителей. Аналогичным образом, физический проект (physical design) программного продукта проецирует технологические и прочие ограничения реального мира на логический проект, позволяя разработчикам приступить к созданию продукта.

    Концептуальный проект

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

    Логический проект

    Логический проект (logical design) - это взгляд на решение с точки зрения проектной группы, описывающий его в виде набора объектов, служб (разделенных на службы пользователя, бизнеса и данных) и взаимосвязей между ними.
    Цель логического проектирования - описать структуру решения и взаимосвязи между ее элементами. Результат - набор объектов и служб, высокоуровневый проект интерфейса пользователя и логический проект базы данных.

    Физический проект

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

    Вопросы для подготовки к экзамену

     Question 1 Which of the following isn"t a role defined by the MSF team model?
    • A. Development
    • B. Testing
    • C. Marketing
    • D. User education
    Вопрос 1 Что из перечисленного ниже не является ролью в модели проектной группы MSF?
    • A. Разработчик
    • B. Тестер
    • C. Маркетолог
    • D. Инструктор

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

    Question 2 Which of the following characteristics describe the MSF process model? (Check all correct answers)
  • A. Based on the waterfall design model.
  • B. Uses the concept of versioned releases.
  • C. Based on four distinct project phases including envisioning, planning, development, and release.
  • D. Uses project milestones to synchronize and gate project processes. Вопрос 2 Какие из следующих характеристик верны для модели процесса проектирования MSF? (Отметьте все правильные ответы)
    • A. Основана на каскадной модели.
    • B. Использует концепцию выпуска версий.
    • C. Основана на четырех фазах проекта: анализ, планирование, разработка и выпуск.
    • D. Использует понятие вех проекта как точек синхронизации и регулирования проектных процессов.

    Правильные ответы - B и D . Каскадная модель ориентирована на задачу и основана на идеях, отличных от лежащих в основе модели MSF. Ответ C неправильный, потому что четвертая фаза проекта - стабилизация, а не выпуск, являющийся внешней вехой, завершающей фазу стабилизации.

    Question 3 Which of the following statements best describes the MSF application model?
    • A. Provides a set of guidelines for developing C++ component objects.
    • B. Conceptually partitions applications into user, business, and data services.
    • C. Requires a one-to-one mapping between logical and physical components.
    • D. Uses the concept of versioned software releases.
    Вопрос 3 Какое из приведенных ниже высказываний наилучшим образом описывает модель приложения MSF?
    • A. Предоставляет рекомендации по разработке компонентов на C++.
    • B. Концептуально делит приложения на службы пользователя, бизнеса и данных.
    • C. Требует однозначного соответствия между логическими и физическими компонентами.
    • D. Использует концепцию выпуска версий.

    Правильный ответ - B . Ответ А неправильный, поскольку модель приложения не привязана к какому-либо языку. Ответ C неправильный, поскольку модель приложения не накладывает никаких ограничений на логический или физический проекты. Ответ D неправильный, поскольку использование концепции выпуска версий - характеристика модели процесса проектирования, а не модели приложения (хотя приложение, скорее всего, будет реализовано как одна из версий продукта).

    Question 4 Which of the following statements best describes the MSF solutions design model?
    • A. Encompasses concepts from other MSF models.
    • B. Provides an architecture that aligns the solution with the business.
    • C. Uses conceptual, logical, and physical designs to describe a software system.
    • D. All of the above.
    Вопрос 4 Какое из приведенных ниже высказываний наилучшим образом описывает модель разработки решений MSF?
    • A. Объединяет в себе концепции из других моделей MSF.
    • B. Предлагает архитектуру, обеспечивающую соответствие решения бизнесу.
    • C. Использует концептуальный, логический и физический проекты как средство описания программной системы.
    • D. Все вышеперечисленное.

    Правильный ответ - D .

    Question 5 The MSF Team Model defines six major roles. These are:
    • Product management
    • Program management
    • Developing
    • Testing
    • User education
    • Logistics management
    Identify the appropriate role for each of the following project responsibilities.
    • Builds the features.
    • Designs and develops performance support systems (documentation, online help files, training).
    • Manages operations, support, and delivery channel relationships.
    • Manages customer expectations.
    • Drives the development process.
    • Acts as end-user advocate on the team.
    • Drives shared project vision/scope.
    • Manages product deployment.
    • Manages the product specification.
    • Drives feature versus schedule trade-off decisions.
    • Facilitates communication and negotiation within the team.
    • Maintains the project schedule and reports project status.
    • Manages the definition of customer requirements.
    • Specifies the features of the physical design.
    • Manages marketing, evangelizing, and public relations.
    • Estimates the time and effort needed to complete each feature.
    • Acts as advocate for operations, support, and delivery channels.
    • Develops testing strategy and plans.
    • Manages the user requirement definition.
    • Develops and maintains the business case.
    • Drives the trade-off decisions relating to usability and user performance enhancement.
    • Ensures that all issues are known.
    • Manages procurement.
    • Drives overall critical trade-off.
    • Prepares the product for distribution.
    • Drives the trade-off decisions associated with manageability and supportability.
    Вопрос 5 В модели проектной группы MSF определены шесть следующих ролей:
    • Менеджер продукта
    • Менеджер программы
    • Разработчик
    • Тестер
    • Инструктор
    • Логистик
    Для каждой из перечисленных ниже обязанностей укажите роль, за нее отвечающую.
    • Создание продукта.
    • Разработка и реализация систем поддержки производительности пользователя (системы помощи, документации пользователя, курсов и т. п.).
    • Управление взаимодействием между службами операций, поддержки и доставки.
    • Создание физического проекта.
    • Управление маркетингом и связями с общественностью.
    • Создание плана разработки.
    • Разработка стратегий и планов тестирования.
    • Разработка и поддержка бизнес-контекста продукта.
    • Управление решениями, связанными с потребительскими качествами продукта и эффективностью работы пользователя.
    • Управление обеспечением.
    • Управление критическими вопросами проекта.
    • Подготовка продукта к распространению.

    Правильные ответы:

    • Менеджер продукта
      • Управление согласованным с заказчиком образом и границами проекта.
      • Управление определением запросов заказчика.
      • Разработка и поддержка бизнес-контекста продукта.
      • Управление удовлетворением ожиданий заказчика.
      • Управление балансом между функциональностью продукта и графиком проекта.
      • Управление маркетингом и связями с общественностью.
    • Менеджер программы
      • Управление процессом разработки.
      • Управление спецификацией продукта.
      • Облегчение взаимодействия и общения внутри группы.
      • Ведение графика проекта и составление отчетов по состоянию проекта.
      • Управление критическими вопросами проекта.
    • Разработчик
      • Создание физического проекта.
      • Создание плана разработки.
      • Создание продукта.
      • Подготовка продукта к распространению.
    • Тестер
      • Отслеживание всех ошибок и проблем взаимодействия.
      • Разработка стратегий и планов тестирования.
    • Инструктор
      • Взаимодействие с конечным пользователем.
      • Управление определением запросов пользователя.
      • Разработка и реализация мер по поддержке производительности пользователя: системы помощи, документации пользователя, курсов и т. п.
      • Управление решениями, связанными с потребительскими качествами продукта и эффективностью работы пользователя.
    • Логистик
      • Взаимодействие со службами операций, поддержки и доставки.
      • Управление обеспечением.
      • Управление внедрением продукта.
      • Управление решениями относительно внедрения и сопровождения продукта.
      • Управление взаимодействием между службами операций, поддержки и доставки.
    Question 6 The MSF application model defines three application services. These are:
    • User services
    • Business services
    • Data services
    Identify the appropriate service for providing each of the following functions:
    • Retrieving an invoice record.
    • Creating a monthly customer statement.
    • Providing a graphical user interface.
    • Deleting a particular customer data record.
    • Providing an automation interface.
    • Ensuring that each order item had a corresponding valid order number.
    • Creating a new order for three items.
    Вопрос 6 В модели приложения MSF определены три типа служб:
    • Службы пользователя
    • Службы бизнеса
    • Службы данных
    Для каждой из следующих функций укажите тип службы, ее предоставляющий:
    • Создание ежемесячного отчета.

    Правильные ответы:

    • Службы пользователя
      • Предоставление графического интерфейса пользователя.
      • Предоставление программируемого интерфейса.
    • Службы бизнеса
      • Создание нового счета для трех наименований.
      • Создание ежемесячного отчета.
    • Службы данных
      • Получение записи из базы данных накладных.
      • Удаление записи из базы данных клиентов.
      • Обеспечение соответствия между счетами и соответствующими им номерами.
    Question 7 The MSF process model defines four project phases. These are:
    • Envisioning
    • Planning
    • Development
    • Stabilization
    Identify the appropriate project phase where each of the following project activities would occur:
    • Selected end users begin evaluating the product.
    • Appropriate members are selected for the project team.
    • The project team examines the requirements and agrees on a high-level vision for the product.
    • Developers write the code.
    • Detailed project plans and specifications are written.
    • The product is documented.
    • The product is prepared to move into production.
    • A master project schedule is prepared.
    • The product is tested.
    • Release notes are prepared.
    Вопрос 7 В модели процесса проектирования MSF определены четыре фазы:
    • Анализ
    • Планирование
    • Разработка
    • Стабилизация
    Для каждой из перечисленных ниже активностей укажите, к какой из фаз, согласно модели процесса проектирования MSF, она принадлежит:
    • Разработчики пишут код.
    • Продукт готов к эксплуатации.
    • Продукт оттестирован.

    Правильные ответы:

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

    Дополнительная информация
    • Smith, Will. "Managing Infrastructure Deployment Projects". Статья TechEd 97. В этой статье, доступной в Microsoft Developer Network Library, описываются различные аспекты моделей MSF и их применение к проекту. Содержит детальное описание обязанностей многих ролей проектной группы на различных фазах проекта и отчуждаемых материалов этих фаз.
    • The Microsoft Developer Network Library

      • Содержит множество статей о Microsoft Solution Framework, технологии COM и разработке программного обеспечения в целом. В качестве ключевых слов для поиска можно использовать слова типа "Architecture", "MSF", "Team Model", "Process Model", "Application Model".
    • www.microsoft.com/enterprise
      •
      Предоставляет информацию по разработке решений масштаба предприятия. Содержит информацию, дополняющую материал этой главы, а также ссылки на другие узлы со сходной тематикой.
    • www.microsoft.com/enterprise/support/support/consult/c_msfOverview.htm
      •
      Содержит полноценный обзор MSF.