Microsoft solutions framework что это
Однако для реализации идеологии ALM на практике необходим не только набор инструментов сам по себе, но и общая методологическая база. Microsoft уже более десяти лет занимается развитием собственной ALM-методологии под названием Microsoft Solutions Framework (MSF). Может показаться неожиданным, но MSF в целом - по сути платформно-независимая методология, детально описывающая отдельные процессы на уровне абстракций. Инструменты самой Microsoft присутствуют в ней в минимальной степени, лишь как примеры реализации тех или иных рекомендаций. Вместе с тем, хотя и неявно, концепция эта четко выражает общую нацеленность средств разработки корпорации (круг задач, для решения которых они предназначены), что очень хорошо видно из анализа динамики ее развития. Так, если десять лет назад MSF была ориентирована на создание локальных клиентских приложений, то сегодня - на разработку и внедрение сложных систем масштаба предприятия.
Структура процессов MSF
Говоря о моделях процессов жизненного цикла проектов разработки ПО, в первую очередь нужно упомянуть о двух основных схемах: водопадной и спиральной (рис. 1), которые отражают два разных подхода к организации этих работ.
Рис. 1. Водопадная и спиральная модели разработки.
Водопадная модель предусматривает четкий переход от этапа к этапу: работы следующего этапа начинаются только после выполнения всех задач предыдущего. Такой стиль подходит для проектов, в которых проектные требования четко определяются заранее и с большой вероятностью не будут корректироваться потом. Данная схема организации разработки очень удобна с точки зрения управления проектом, так как позволяет четко сформулировать состав и обязанности его участников и контролировать графики выполнения проекта.
Спиральная модель обычно ориентируется на крайний случай, когда требования и параметры проекта непрерывно корректируются, а новые требования формулируются лишь по мере необходимости выполнения конкретных работ. Такая схема часто ассоциируется с понятием "экстремальной разработки"; при этом исполнитель и заказчик работают в постоянном тесном сотрудничестве, клиент привлекается на каждом этапе, формулируя свои соображения по поводу созданных компонентов. Однако при такой организации очень велик риск, что процесс разработки выйдет из-под контроля, поэтому реально данная модель используется лишь в относительно небольших проектах.
Однако проблема заключается в том, что чаще всего все требования на задание действительно практически невозможно определить заранее, к тому же даже сформулированные требования подвергаются коррекции. Но тогда требуется повысить уровень управляемости проектом, без чего создание сложного ПО просто невозможно. Компромисс между этими противоречивыми требованиями и предоставляет модель процессов MSF, в которой сочетаются водопадная и спиральная модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали (рис. 2).
Рис. 2. Этапы и контрольные точки модели MSF.
В этом случае планирование на основе промежуточных контрольных точек и предсказуемость водопадной модели дополняются наличием обратной связи с заказчиком и творческим подходом к решению задач, характерными для спиральной модели. Таким образом, модель процессов MSF позволяет создавать и развертывать решения уровня предприятия, обеспечивая прогнозируемость хода проектов и учитывая реальные условия их выполнения.
Создание общей картины приложения
На этом этапе решаются следующие основные задачи:
- определение состава команды;
- определение структуры проекта;
- определение бизнес-целей;
- оценка существующей ситуации;
- создание документа общей картины и области действия проекта;
- определение требований и профилей пользователей;
- разработка концепции решения;
- оценка риска;
- закрытие этапа.
На этапе выделяются две промежуточные контрольные точки: "Организован костяк команды" и "Создана общая картина решения".
Организован костяк команды. Здесь не обязательно нужен полный поименный список команды, но в документе структуры проекта должны быть определены роли и обязанности каждого члена команды, а также описана иерархия отчетности и ответственности в группе, каналы взаимодействия с заказчиком и общая структура команды.
Создана общая картина решения. Речь идет о разработке концепции решения, которым должна руководствоваться команда для достижения долгосрочных бизнес-целей проекта. Область действия проекта определяет, что включается в контекст проекта, а что выходит за его рамки. На этой временной точке речь идет о создании первой версии документа, который находится в стадии рецензирования участниками команды и согласования заказчиком.
Этап завершается контрольной точкой "Утверждение документа общей картины и области действия проекта".
Планирование
На этапе планирования команда решает, что нужно разработать, и формирует планы реализации продукта. Готовится функциональная спецификация, создается проект решения, детализируются планы работы, выполняется оценка стоимости и сроков получения результатов.
На этом этапе проводится анализ требований, которые делятся на бизнес-требования, пользовательские, функциональные и системные требования. После сбора и анализа требований команды разрабатывается проект решения, определяются профили пользователей, после чего формируются сценарии применения решения, выполняемые пользователями одного типа, а затем определяются варианты использования системы.
Этап состоит из трех стадий: концептуальное, логическое и физическое проектирование. На стадии концептуального проектирования задача рассматривается с точки зрения пользовательских и бизнес-требований и заканчивается определением набора сценариев использования системы. При логическом проектировании задача рассматривается с точки зрения проектной команды, решение представляется в виде набора сервисов. И уже на стадии физического проектирования задача рассматривается с точки зрения программистов, уточняются используемые технологии и программные интерфейсы.
В ходе данного этапа решаются такие задачи:
- разработка проекта и архитектуры решения;
- создание функциональной спецификации;
- разработка планов проекта;
- разработка календарного графика;
- создание среды разработки, тестирования и пилотной эксплуатации;
- закрытие этапа.
Контрольные точки этапа планирования связаны с достижением следующих результатов:
- функциональная спецификация;
- план управления рисками;
- определение среды разработки и тестирования;
- генеральный план и календарный график проекта.
- Результаты данного этапа служат для принятия компромиссных решений в дальнейшем.
Разработка
На этапе разработки создается решение, в том числе пишется и документируется код. В начале этого этапа команда проверяет выполнение всех задач, характерных для предыдущих этапов, а затем приступает к решению следующих задач:
- создание прототипа приложения;
- разработка программных компонентов приложения;
- создание решения (последовательность ежедневных или более частых сборок приложения);
- закрытие разработки (реализация всех функций, поставка кода и документации).
Результаты этапа предполагают следующие элементы:
- исходный текст кода и исполняемые файлы;
- сценарии установки и конфигурации для развертывания;
- окончательная функциональная спецификация;
- элементы поддержки решения;
- спецификации и сценарии тестирования.
Основная контрольная точка этапа - "Окончательное утверждение области действия проекта". В этот момент все функции продукта готовы и прошли тестирование в рамках своего модуля. После этого продукт готов к внешнему тестированию и стабилизации. Кроме того, заказчики, пользователи, сотрудники службы поддержки и сопровождения, а также ключевые участники проекта могут предварительно оценить продукт и указать все недостатки, которые нужно устранить до его поставки.
Стабилизация
Данный этап - подготовка к выпуску окончательной версии продукта, доводка его до заданного уровня качества. Здесь выполняется комплекс работ по тестированию (обнаружение и устранение дефектов), а также проверяется сценарий развертывания продукта и проводится пилотная эксплуатация.
Тестирование подразумевает следующие основные виды работ:
- тестирование компонентов;
- тестирование баз данных;
- тестирование инфраструктуры;
- тестирование защиты;
- тестирование интеграции;
- анализ удобства работы с продуктом;
- нагрузочное тестирование (включая анализ ресурсоемкости и производительности);
- регрессивное тестирование;
- ведение отчетности по тестированию.
Когда решение становится достаточно устойчивым, проводится его пилотная эксплуатация в тестовой среде с привлечением пользователей и применением реальных сценариев работы.
Один из главных показателей этапа стабилизации - число обнаруженных ошибок. Сходимость этой величины в сторону устойчивого уменьшения - признак того, что близится завершение работ над продуктом. Важнейшая промежуточная контрольная точка - появление версии, в которой усилиями самой проектной команды не обнаружено ни одной ошибки. Далее следуют выпуски кандидат-релизов продукта для их исследования в условиях пилотной эксплуатации. Завершающая контрольная точка - подтверждение готовности продукта к выпуску и полноценному развертыванию в промышленной среде.
Развертывание
На этом этапе выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика. Основные контрольные точки данного этапа таковы:
- развернуты основные компоненты;
- развернуто решение в целом;
- развернутое решение стабилизировано;
- решение развернуто и передано в эксплуатацию заказчику.
Следует подчеркнуть, что момент завершения данного этапа бывает достаточно сложно формально определить, так как выявление неполадок может продолжаться и в ходе промышленной эксплуатации. Именно поэтому необходимо четко сформулировать критерии для завершающей контрольной точки этапа развертывания и не пытаться отладить абсолютно все.
Комментарии по поводу этапов работ
Добавим к изложенному выше несколько важных замечаний. В целом те же самые идеи лежат в основе всех современных промышленных методологий разработки ПО (IBM/Rational, Borland, Microsoft и т. д.). И здесь нет ничего удивительного: именно этим отличаются выверенные временем технологии от кустарного производства. Но в то же время в каждой методологии есть свой подход к выделению различных этапов разработки и зачастую используется собственная терминология, что усложняет проведение параллелей между ними. Проблема эта усугубляется и отсутствием устоявшейся русской терминологии.
Общепринятый на сегодня список ALM-этапов, которого, в частности, придерживаются Borland и Rational, выглядит следующим образом:
- Defining (определение требований);
- Designing (анализ и проектирование);
- Developing (разработка);
- Testing (тестирование);
- Deploying (развертывание).
Как легко заметить, модель MSF предлагает несколько иную разбивку на этапы и их наименование. Хотелось бы обратить внимание читателей, что речь здесь не идет просто о разных названиях одних и тех же видов деятельности. Объективная проблема категоризации заключается в том, что выделение самостоятельных этапов в жизненном цикле приложений весьма условно, особенно если речь идет об итерационной циклической модели разработки. Например, широкое использование визуальных методов проектирования с автоматической генерацией кода фактически стирает грань между проектированием и кодированием. А тестирование вообще пронизывает всю жизнь программы.
Имеются и субъективные факторы, которые определяются различиями стратегических бизнес-целей разных поставщиков методологий. Именно этим объясняется то, что Microsoft - основу бизнеса которой составляют не средства разработки, а платформенное ПО, - больше внимания (по сравнению с теми же Rational и Borland) уделяет общим вопросам организации процесса создания приложений, а также их внедрению.
Поэтому, например, этап Envisioning включает определение не только требований к ПО, но и состава команды (здесь содержатся, в частности, очень интересные рекомендации касательно ролевой модели команды разработчиков, а также возможных вариантов совмещения ролей). А этап Stabilizing подразумевает не только собственно тестирование, но и фактически опытную эксплуатацию ПО, на которой могут уточняться исходные требования заказчика. Что уж говорить об особом акценте Microsoft на задачах развертывания решений.
Формирование проектных команд
Один из ключевых элементов реализации проекта - задача управления коллективом его участников. Поэтому наряду с моделью процессов в MSF детально проработана модель команд (MSF Team Model), которая исходит из важности четкого понимания ролей, обязанностей и задач отдельных ее членов, а также их повышенной ответственности за реализацию проекта в целом. Она может применяться в соответствии с потребностями и контекстом проекта, размером коллектива и опытом участников команды. Ниже коротко охарактеризованы роли, используемые в модели команд MSF.
Менеджер продукта (product manager) отвечает за управление связями с клиентом. На этапе проектирования он собирает требования заказчика и ведет контроль за тем, чтобы они соответствовали потребностям его бизнеса. Он также разрабатывает план взаимодействия с клиентом в ходе реализации проекта, в том числе организует встречи с клиентом, демонстрации продукта и другие маркетинговые акции.
Менеджер программы (program manager) управляет собственно разработкой ПО и несет ответственность за его поставку в соответствии с утвержденными спецификациями.
Разработчик (developer) занимается разработкой ПО в соответствии с заданными спецификациями.
Тестировщик (tester) выявляет и устраняет все неполадки в продукте и дает окончательное разрешение на его выпуск. Он также оценивает соответствие набора реализованных в продукте функций общей концепции и области действия проекта.
Менеджер по выпуску (release manager) отвечает за развертывание и поддержку продукта, проверяет корректность ИТ-инфраструктуры заказчика на предмет ее готовности к эксплуатации ПО.
Специалист по удобству использования (user experience specialist) занимается изучением и решением проблем пользователей, оценивает продукт с точки зрения соответствия их потребностям.
Конечно, в небольшом проекте отдельным членам команды приходится совмещать несколько ролей. Тут возможны разные варианты в зависимости от квалификации и опыта сотрудников, а также специфики проекта, но все же нужно придерживаться определенных правил относительно "совместимости" ролей (см. таблицу). Например, обратите внимание, что разработчику не рекомендуется выполнять какие-то еще роли.
Возможное совмещение ролей в проектной команде
Менеджер продукта | Менеджер программы | Разработчик | Тестиров-щик | Менеджер по выпуску | Специа-лист по удобству исполь-зования | |
Менеджер продукта | - | - | + | -+ | -+ | |
Менеджер программы | - | - | -+ | + | -+ | |
Разработчик | - | - | - | - | - | |
Тестиров-щик | + | -+ | - | + | + | |
Менеджер по выпуску | -+ | + | - | + | -+ | |
Специалист по удобству исполь-зования | + | -+ | - | + | -+ | |
Примечание: " - " - совмещение не рекомендуется, " -+ " - нежелательно, " + " - возможно. |
Кроме собственно исполнителей проекта, в команду могут входить и другие лица:
- инициатор, или спонсор проекта, который обычно также принимает решение об одобрении проекта;
- заказчик (бизнес-спонсор) - тот, кто получает деловую выгоду от проекта;
- пользователи - группа лиц, непосредственно работающих с решением;
- группа поддержки решения, отвечающая за его сопровождение после развертывания.
Управление компромиссами
Одна из основных проблем любого проекта - возможные нарушения графиков или перерасход бюджета. Главная причина этого - нечетко описанная область действия проекта, которая определяет, какие задачи должен решать продукт, а какие не относятся к его компетенции. Поэтому для эффективного управления проектом необходимо следующее:
- определить ограничения, накладываемые на проект;
- организовать управление компромиссами;
- организовать управление изменениями;
- обеспечить мониторинг проекта.
Управление компромиссами подразумевает достижение баланса всех составных частей проекта, когда в команде осознают, что в выделенное время не удастся решить все поставленные задачи. Проектная группа и заказчик должны постоянно анализировать компромиссы и быть готовыми к нелегкому выбору между разрастанием бюджета (в том числе несоблюдением сроков) проекта и полнотой его функциональности.
Как известно, в любых проектах существует вполне определенная связь между такими его параметрами, как ресурсы, график и набор функций (рис. 3). Любое изменение одного из компонентов требует корректировки других. Поэтому залог успешного создания продукта, отвечающего требованиям заказчика, - определение и обеспечение оптимального баланса между ресурсами, датой поставки и функциональностью.
Рис. 3. Треугольник компромиссов.
Для решения этих непростых задач лучше всего использовать матрицу компромиссов, в которой все перечисленные компоненты делятся на обязательные, желательные и факультативные (последние можно исключить или отложить до следующей версии). Продемонстрировать работу матрицы компромиссов можно на примере такого шаблона фразы:
Учитывая, что зафиксировано ____________, мы определим _____________
и в случае необходимости скорректируем ____________________.
Вставляя переменные из определенной заранее матрицы компромиссов, можно получить формулировку, соответствующую целевой задаче проекта, например:
Учитывая, что зафиксированы РЕСУРСЫ, мы определим ГРАФИК
и в случае необходимости скорректируем ФУНКЦИОНАЛЬНОСТЬ.
В заключение отметим, что есть и еще одна важная характеристика проекта - качество. Но это как раз тот показатель, который следует жестко зафиксировать. При разработке программных продуктов ни в коем случае не нужно превращать треугольник компромиссов в тетраэдр.
Шаблон:Нет сносок Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.
MSF представляет собой согласованный набор концепций, моделей и правил.
Содержание
Введение [ ]
Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.
Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков пирамидальной, иерархической структуры традиционных проектных групп.
В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться.
Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.
MSF включает в себя ряд основных принципов. Вот те из них, которые имеют отношение к успешной работе команды:
- Распределение ответственности при фиксации отчетности
- Наделяйте членов команды полномочиями
- Концентрируйтесь на бизнес-приоритетах
- Единое видение проекта
- Проявляйте гибкость — будьте готовы к переменам
- Поощряйте свободное общение
Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):
- Команда соратников
- Сфокусированность на нуждах заказчика
- Нацеленность на конечный результат
- Установка на отсутствие дефектов
- Стремление к самосовершенствованию
- Заинтересованные команды работают эффективно
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из её ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над её достижением.
В проектную группу входят такие ролевые кластеры:
- управление программой
- управление продуктом
- разработка
- тестирование
- управление релизом
- удовлетворение потребителя
Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.
Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за:
- управление программой (program manager) — разработку архитектуры решения, административные службы;
- разработку (developer) — разработку приложений и инфраструктуры, технологические консультации;
- тестирование (QAE) — планирование, разработку тестов и отчетность по тестам;
- управление выпуском (release manager) — инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;
- удовлетворение заказчика (user experience) — обучение, эргономику, графический дизайн, техническую поддержку;
- управление продуктом (product manager) — бизнес-приоритеты, маркетинг, представительство интересов заказчика.
Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести — один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:
- Роль команды разработчиков не может быть объединена ни с какой другой ролью.
- Избежание сочетания ролей, имеющих предопределенные конфликты интересов.
Как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и профессиональных навыков. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.
MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:
- ответственность за управление проектом распределенная между лидерами ролевых кластеров внутри команды — каждый член проектной группы отвечает за общий успех проекта и качество создаваемого продукта.
- профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней — в эффективно работающей команде каждый её член имеет необходимые полномочия для выполнения своих обязанностей и уверен, что получит от коллег все необходимое.
Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!
Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.
Использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть много других факторов, определяющих успех или неудачу проекта, но структура проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в её основе принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.
Модель процессов MSF [ ]
Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена ещё одним инновационным аспектом: она покрывает весь Управление рисками [ ]
MSF risk management discipline) отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Девиз MSF — мы не боремся с рисками — мы ими управляем.
Как уже говорилось выше, в MSF нет роли «менеджер проекта». Деятельность по управлению проектом распределяется между лидерами групп и ролевым кластером «Управление программой».
Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS. Иерархическая структура работ ( Управление подготовкой [ ]
Управление подготовкой — это также одна из ключевых дисциплин Microsoft Solutions Framework (MSF). Она посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF описывает фундаментальные принципы MSF и дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Эта дисциплина также рассматривает планирование процесса управления подготовкой. Будучи подкрепленной испытанными практическими методиками, дисциплина управления подготовкой предоставляет проектным группам и отдельным специалистам базу для осуществления этого процесса.
Следует отметить, что Microsoft. Например, для организации процесса производства ПО можно использовать MSF и при этом применять инструменты Версии [ ]
Первая версия MSF появилась в 1994 году . Текущая версия — MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.
Кроме этого, появилась роль архитектора и поддержка методологии в инструменте — Ссылки [ ]
Microsoft Solutions Framework — Pour les articles homonymes, voir MSF. Microsoft Solutions Framework (MSF) est un regroupement de principes, de modèles, de concepts et de lignes directrices dans la conception d applications édicté par Microsoft … Wikipédia en Français
Microsoft Solutions Framework — (MSF) is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology solutions from Microsoft. MSF is not limited to developing applications only, it is also applicable to other IT projects like… … Wikipedia
Microsoft Solutions Framework — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Microsoft Operations Framework — (MOF) 4.0 is a series of guides aimed at helping information technology (IT) professionals establish and implement reliable, cost effective services. Contents 1 Overview 2 Structure of MOF 4.0 3 See also 4 … Wikipedia
MSF — may refer to: * National Physical Laboratory (MSF) time signal* Mail Summary File(.msf), file extension used by Earthlink, Mozilla Thunderbird, and Netscape mail clients. * Major Street basketball Foundation (MSF Basketball) * Manufacturing… … Wikipedia
Msf — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. >> Sigles d une seule lettre Sigles de deux lettres > Sigles de trois lettres … Wikipédia en Français
MSF — ist: das Rufzeichen des britischen Zeitzeichendienstes, siehe MSF (Zeitzeichensender) MSF ist eine Abkürzung für: Magna Steyr Fahrzeugtechnik AG Co. KG, ein österreichischer Automobilhersteller Mail Summary File, .msf, Datenformat für die lokal… … Deutsch Wikipedia
MSF — Microsoft Solutions Framework (Computing » General) * Médicos Sin Fronteras (International » Guatemalan) * Motorcycle Safety Foundation (Governmental » Transportation) * Manufacturing Science And Finance (Business » Accounting) * Multiple… … Abbreviations dictionary
MSF — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français
MSF — Médecins Sans Frontières Международная медицинская гуманитарная организация «Врачи без границ» Microsoft Solutions Framework методология разработки программного обеспечения от Microsoft. Multiservice Switching Forum (Форум Коммутации… … Википедия
Опубликован: 12.03.2009 | Доступ: свободный | Студентов: 5180 / 1507 | Оценка: 4.44 / 4.12 | Длительность: 11:27:00
Аннотация: IT решение. Основные принципы MSF. Модель команды: основные принципы, ролевые кластеры. Масштабирование команды MSF. Модель процесса. Управление компромиссами.
История и текущий статус
В 90-х годах компания Microsoft, стремясь достичь максимальной отдачи от реализации заказных IT-решений и в целях улучшения работы с субподрядчиками обобщила свой опыт по разработке, внедрению, сопровождению и консалтингу ПО , создав методологию MSF . В 2002 году вышла версия MSF 3.1, состоявшая из пяти документов-руководств:
- модель процессов ( process model ),
- модель команды ( team model ),
- модель управления проектами ( project management ),
- дисциплина управления рисками ( risk management ),
- управление подготовкой ( readiness management ).
IT решение – понимается как скоординированная поставка набора элементов (таких как программные средства , документация, обучение и сопровождение), необходимых для удовлетворения бизнес-потребности конкретного заказчика. Причем под его разработкой понималась создание ПО, обучение пользователей и полная передача продукта команде сопровождения. Задача наладки полноценного сопровождения IT-решения - важная составляющая успешности проекта.
Основными новшествами MSF является следующее.
- Акцент на внедрении IT-решения.
- Модель процесса , объединяющая спиральную и водопадную модели.
- Особая организация команды – не иерархическая, а как группа равных, но выполняющих разные функции (роли) работников.
- Техника управления компромиссами .
Ниже мы рассмотрим эти положения более детально.
В 2005 году MSF претерпело значительные изменения. Верcия MSF 4.0. стала составной часть продукта Visual Studio Team System (VSTS) и разделилась на две ветки – MSF for Agile и MSF for CMMI . При этом, если версии до 3.х были именно методологиями (там были изложены принципы, MSF свободно распространялась в виде Word-документов, которые были также переведены на русский язык), то теперь MSF превратилась в шаблоны процесса для VSTS. Эти шаблоны имеют описание в виде html -документов (Word-документов уже нет) и определяют типы ролей, их ответственности, действия в рамках этих ответственностей, а также все входные и выходные артефакты этих деятельностей и другие формализованные атрибуты процесса разработки. Кроме этого "человеческого" описания MSF for Agile и MSF for CMMI имеют XML -настройки, которые позволяют в точности следовать предложенным выше описаниям, используя VSTS. При этом на процесс накладываются достаточно жесткие ограничения, деятельность разработчиков сопровождается набором автоматических действий – все это задано в шаблонах. Данные шаблоны можно частично использовать (например, без некоторых ролей), а также изменять (VSTS предоставляет обширные средства настройки шаблонов). Версия MSF 4.2 продолжила направление версии MSF 4.0.
Можно считать, что фактически, версии MSF 4.x являются продуктами другого класса, чем MSF 3.x. MSF 3.х были нацелены на разработку заказных IT-решений, MSF 4.0 – на разработку произвольного ПО . Формально, документация этих версий не сильно пересекается и содержит для 3.х в большей степени общие принципы, а для 4.х – формальные атрибуты в терминах VSTS. В некотором смысле можно сказать, что MSF 4.х является реализацией MSF 3.х для продукта VSTS. В этой лекции мы рассмотрим основные принципы MSF . то есть, фактически, MSF 3.1, а в лекциях, посвященных VSTS будут рассмотрены MSF for Agile и MSF for CMMI .
Основные принципы
Перечислим основные принципы MSF .
- Единое видение проекта. Успех коллективной работы над проектом немыслим без наличия у членов проектной группы и заказчика единого видения ( shared vision ), т.е. четкого, и, самое главное, одинакового, понимания целей и задач проекта . Как проектная группа, так и заказчик изначально имеют собственные предположения о том, что должно быть достигнуто в ходе работы над проектом. Лишь наличие единого видения способно внести ясность и обеспечить движение всех заинтересованных в проекте сторон к общей цели. Формирование единого видения и последующее следование ему являются столь важными, что модель процессов MSF выделяет для этой цели специальную фазу – "Выработка концепции", которая заканчивается соответствующей вехой.
- Гибкость – готовность к переменам. Традиционная дисциплина управления проектами и каскадная модель исходят из того, что все требования могут быть четко сформулированы в начале работы над проектом, и далее они не будут существенно изменяться. В противоположность этому MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности.
- Концентрация на бизнес-приоритетах. Независимо от того, нацелен ли разрабатываемый продукт на организации или индивидуумов, он должен удовлетворить определенные нужды потребителей и принести в некоторой форме выгоду или отдачу. В отношении индивидуумов это может означать, например, эмоциональное удовлетворение – как в случае компьютерных игр. Что же касается организаций, то неизменным целевым фактором продукта является бизнес-отдача ( business value). Обычно продукт не может приносить отдачу до того, как он полностью внедрен. Поэтому модель процессов MSF включает в свой жизненный цикл не только разработку продукта, но и его внедрение.
- Поощрение свободного общения. Исторически многие организации строили свою деятельность на основе сведения информированности сотрудников к минимуму, необходимому для исполнения работы (need-to-know). Зачастую такой подход приводит к недоразумениям и снижает шансы команды на достижение успеха. Модель процессов MSF предполагает открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат , но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности. По этой причине модель процессов MSF предлагает проведение анализа хода работы над проектом в определенных временных точках. Документирование результатов делает ясным прогресс, достигнутый в работе над проектом - как для проектной команды, так и для заказчика и других заинтересованных в проекте сторон.
Модель команды
Основные принципы. Главная особенность модели команды в MSF является то, что она "плоская", то есть не имеет официального лидера. Все отвечают за проект в равной степени, уровень заинтересованности каждого в результате очень высок, а коммуникации внутри группы четкие, ясные, дружественные и ответственные. Конечно, далеко не каждая команда способна так работать – собственно, начальники для того и нужны, чтобы нести основной груз ответственности за проект и, во многом, освободить от него других. Демократия в команде возможна при высоком уровне осознанности и заинтересованности каждого, а также в ситуации равности в профессиональном уровне (пусть и в разных областях – см. различные ролевые кластеры в команде, о которых речь пойдет ниже). С другой стороны, в реальном проекте, в рамках данной модели команды, можно варьировать степень ответственности, в том числе вплоть до выделения, при необходимости, лидера.
Одной из особенностей отношений внутри команды является высокая культура дисциплины обязательств:
- готовность работников принимать на себя обязательства перед другими;
- четкое определение тех обязательств, которые они на себя берут;
- стремление прилагать должные усилия к выполнению своих обязательств;
- готовность честно и незамедлительно информировать об угрозах выполнению своих обязательств.
Ролевые кластеры. MSF основан на постулате о семи качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы и образуют ролевые кластеры (или просто роли ) в проекте. В каждом ролевом кластере может присутствовать по одному или несколько специалистов, некоторые роли можно соединять одному участнику проекта. Каждый ролевой кластер представляет уникальную точку зрения на проект, и в то же время никто из членов проектной группы в одиночку не в состоянии успешно представлять все возможные взгляды, отражающие качественно различные цели. Для разрешения этой дилеммы команда соратников ( команда равных, team of peers ), работающая над проектом, должна иметь четкую форму отчетности перед заинтересованными сторонами ( stakeholders ) при распределенной ответственности за достижение общего успеха. В MSF следующие ролевые кластеры (часто их называют ролями) – см. рис. 9.1.
- Управление продуктом ( product management ). Основная задача этого ролевого кластера – обеспечить, чтобы заказчик остался довольным в результате выполнения проекта. Этот ролевой кластер действует по отношению к проектной группе как представитель заказчика и зачастую формируется из сотрудников организации-заказчика. Он представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика. В него же входит контроль за полным пониманием интересов бизнеса при принятии ключевых проектных решений.
- Управление программой ( program management ) обеспечивает управленческие функции – отслеживание планов и их выполнение, ответственность за бюджет, ресурсы проекта , разрешение проблем и трудностей процесса, создание условий, при которых команда может работать эффективно, испытывая минимум бюрократических преград.
- Разработка ( development ). Этот ролевой кластер занимается, собственно, программированием ПО.
- Тестирование ( test ) – отвечает за тестирование ПО.
- Удовлетворение потребителя ( user experience ). Дизайн удобного пользовательского интерфейса и обеспечение удобства эксплуатации ПО (эргономики), обучение пользователей работе с ПО, создание пользовательской документации.
- Управление выпуском ( release management ). Непосредственно ответственен за беспрепятственное внедрение проекта и его функционирование, берет на себя связь между разработкой решения, его внедрением и последующим сопровождением, обеспечивая информированность членов проектной группы о последствиях их решений.
- Архитектура (Architecture) 1 Этот ролевой кластер появился в версиях MSF 4.х. До этого данная ответственность входила в ролевой кластер "Управление программой". . Организация и выполнение высокоуровневого проектирования решения, создание функциональной спецификации ПО и управление этой спецификацией в процессе разработки, определение рамок проекта и ключевых компромиссных решений.
Масштабирование команды MSF. Наличие 7 ролевых кластеров не означает, что команда должна состоять строго из 7 человек. Один сотрудник может объединять несколько ролей. При этом некоторые роли нельзя объединять. В таблице ниже представлены рекомендации MSF относительно совмещения ролей в рамках одним членом команды. "+" означает, что совмещение возможно, "+-" - что совмещение возможно, но нежелательно, "-" означает, что совмещение не рекомендуется.
В частности, нельзя совмещать разработку и тестирование, поскольку, как обсуждалось выше, необходимо, чтобы у тестеровщиков был сформирован свой, независимый взгляд на систему, базирующийся на изучении требований.
Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений ( feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия, каждая из которых устроена на основе модели кластеров. Это компактные мини-команды, образующие матричную организационную структуру. В них входят по одному или несколько членов из разных ролевых кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от проектирования и составления календарного графика . Например, может быть сформирована специальная группа проектирования и разработки сервисов печати.
Кроме того, когда ролевому кластеру требуется много ресурсов, формируются так называемые функциональные группы ( functional teams), которые затем объединяются в ролевые кластеры . Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. Например, в Майкрософт группа управления продуктом обычно включает специалистов по планированию продукта и специалистов по маркетингу. Как первая, так и вторая сферы деятельности относятся к управлению продуктом: одна из них сосредотачивается на выявлении качеств продукта, действительно интересующих заказчика, а вторая – на информировании потенциальных потребителей о преимуществах продукта.
Аналогично, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, бизнес-логика или объекты данных. Часто программистов разделяют на разработчиков библиотек и разработчиков решения. Программисты библиотек обычно используют низкоуровневый язык C и создают повторно используемые компоненты, которые могут пригодиться всему предприятию. Создатели же решения обычно соединяют эти компоненты и работают с языками более высокого уровня, такими как, например Microsoft Visual Basic .
Часто функциональные группы имеют внутреннюю иерархическую структуру. Например, менеджеры программы могут быть подотчетны ведущим менеджерам программы, которые в свою очередь отчитываются перед главным менеджером программы. Подобные структуры могут также появляться внутри областей компетенций. Но важно помнить, что эти иерархии не должны затенять модель команды MSF на уровне проекта в целом.
Microsoft Solutions Framework (MSF) - это методология ведения проектов и разработки решений, базирующаяся на принципах работы над продуктами самой фирмы Microsoft и предназначенная для использования в организациях, нуждающихся в концептуальной схеме для построения современных решений [35].
Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.
Microsoft Solutions Framework представляет собой хорошо сбалансированный набор методик организации процесса разработки, который может быть адаптирован под потребности практически любого коллектива разработчиков. MSF содержит не только рекомендации общего характера, но и предлагает адаптируемую модель коллектива разработчиков, определяющую взаимоотношения внутри коллектива, гибкую модель проектного планирования, основанного на управлении проектными группами, а также набор методик для оценки рисков.
В момент подготовки данного учебного курса последней версией MSF была 3.1, при этом существовали документы, относящиеся к версии 4.0 beta.
MSF состоит из двух моделей:
- модель проектной группы ;
- модель процессов,
и трех дисциплин:
- управление проектами;
- управление рисками;
- управление подготовкой.
В MSF нет роли "менеджер проекта" и иерархии руководства, управление разработкой распределено между руководителями отдельных проектных групп внутри коллектива, выполняющих следующие задачи:
- Управление программой
- Разработка
- Тестирование
- Управление выпуском
- Удовлетворение потребителя
- Управление продуктом
Жизненный цикл процессов в MSF сочетает водопадную и спиральную модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали (Рис. 1.4).
При таком подходе от водопадной модели берется простота планирования, от классической спиральной - легкость модификаций. Благодаря промежуточным контрольным точкам и обратной спирали верификации облегчается взаимодействие с заказчиком.
При управлении проектом четко ставится цель, которую необходимо достичь в результате, и учитываются ограничения, накладываемые на проект. Все виды ограничений могут быть отнесены к одному из трех видов: ограничения ресурсов, ограничения времени и ограничения возможностей. Эти три вида ограничений и приоритетность задач по их преодолению образуют треугольник приоритетов в MSF (Рис. 1.5).
Треугольник приоритетов является основой для матрицы компромиссов - заранее утвержденных представлений о том, какие аспекты процесса разработки будут четко заданы, а какие будут согласовываться или приниматься как есть.
Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF - Microsoft Visual Studio 2005 Team Edition. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы.
В состав Visual Studio Team Edition входит специальная редакция для тестировщиков - Team Edition for Software Testers (Рис. 1.6). Материалы семинарских занятий по данному курсу ориентированы на эту среду разработки, в то время как лекционные материалы ориентированы на изложение общих принципов и методик тестирования.
1.4.2. Rational Unified Process
Rational Unified Process - это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.
Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.
RUP обеспечивает строгий подход к распределению задач и ответственности внутри организации-разработчика. Его предназначение заключается в том, чтобы гарантировать создание точно в срок и в рамках установленного бюджета качественного ПО, отвечающего нуждам конечных пользователей.
RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом - RUP гарантирует, что все члены группы используют общий язык моделирования и процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.
Особенностью RUP является то, что в результате работы над проектом создаются и совершенствуются модели. Вместо создания громадного количества бумажных документов, RUP опирается на разработку и развитие семантически обогащенных моделей, всесторонне представляющих разрабатываемую систему. RUP - это руководство по тому, как эффективно использовать UML. Стандартный язык моделирования, используемый всеми членами группы, делает понятными для всех описания требований, проектирование и архитектуру системы.
RUP поддерживается инструментальными средствами, которые автоматизируют многие элементы процесса разработки. Они используются для создания и совершенствования различных промежуточных продуктов на различных этапах процесса создания ПО, например, при визуальном моделировании, программировании, тестировании и т.д.
RUP - это конфигурируемый процесс, поскольку вполне понятно, что невозможно создать единого руководства на все случаи разработки ПО. RUP пригоден как для маленьких групп разработчиков, так и для больших организаций, занимающихся созданием ПО. В основе RUP лежит простая и понятная архитектура процесса, которая обеспечивает общность для целого семейства процессов. Более того, RUP может конфигурироваться для учета различных ситуаций. В его состав входит Development Kit, который обеспечивает поддержку процесса конфигурирования под нужды конкретных организаций.
RUP описывает, как эффективно применять коммерчески обоснованные и практически опробованные подходы к разработке ПО для коллективов разработчиков, где каждый из членов получает преимущества от использования передового опыта в:
- итерационной разработке ПО;
- управлении требованиями;
- использовании компонентной архитектуры ;
- визуальном моделировании;
- тестировании качества ПО;
- контроле за изменениями в ПО.
RUP организует работу над проектом в терминах последовательности действий ( workflows ), продуктов деятельности, исполнителей и других статических аспектов процесса, с одной стороны, и в терминах циклов, фаз, итераций и временных отметок завершения определенных этапов в создании ПО ( milestones ), т.е. в терминах динамических аспектов процесса - с другой. [29]
1.4.3. eXtreme Programming
Экстремальное программирование [36] - сравнительно молодая методология разработки программных систем, основанная на постепенном улучшении системы и разработки ее очень короткими итерациями. По своей сути экстремальное программирование (XP) - это одна из, так называемых, "гибких" методологий разработки ПО, которая представляет собой небольшой набор конкретных правил, позволяющих максимально эффективно выполнять требования современной теории управления программными проектами.
XP ориентирована на:
- командную работу с тесными связями внутри команды и с заказчиком;
- разработку наиболее простых работающих решений;
- гибкое адаптивное планирование;
- оперативную обратную связь (путем модульного и функционального тестирования ).
Основными принципами XP является разработка небольшими итерациями на основании порции требований заказчика (т.н. пользовательских историй), написание функциональных тестов до написания программного кода, постоянное общение и постоянный рефакторинг кода.
Основными практиками XP являются:
- Планирование процесса
- Частые релизы
- Метафора системы
- Простая архитектура
- Тестирование
- Рефакторинг
- Парное программирование
- Коллективное владение кодом
- Частая интеграция
- 40-часовая рабочая неделя
- Стандарты кодирования
- Тесное взаимодействие с заказчиком
1.4.4. Сравнение технологий MSF, RUP и XP
Основные особенности MSF, RUP и XP сведены в таблицу 1.2 [1]. По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.
Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP - сопровождаемость. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации.
Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.
Читайте также: