В 1994 году , стремясь достичь максимальной отдачи от IT -проектов, Майкрософт выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Майкрософт при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Майкрософт и лучшем из того, что накопила на данный момент IT-индустрия. Все это представлено в виде двух взаимосвязанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF ) и Microsoft Operations Framework (MOF ).
Следует отметить, что 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 решения на базе продуктов и технологий Майкрософт , техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала и процессов; технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL ), составленной Central Computer and Telecommunications Agency - Агентством правительства Великобритании. Информация по MOF доступна в Internet по адресу.
Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Информация по MSF доступна в Internet по адресу.
MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers. Начинать изучение MSF лучше с моделей, а затем перейти к дисциплинам.
MSF содержит:
Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.
Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков пирамидальной, иерархической структуры традиционных проектных групп.
В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться.
Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.
MSF включает в себя ряд основных принципов . Вот те из них, которые имеют отношение к успешной работе команды:
Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением.
В проектную группу входят такие ролевые кластеры :
Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же - построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.
Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за :
Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести - один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив по MSF может состоять всего из трех человек . Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:
Как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и профессиональных навыков. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.
MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами , при котором:
Как следует из вышесказанного, одна из характерных особенностей MSF - отсутствие должности менеджера проекта!
Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.
Использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть много других факторов, определяющих успех или неудачу проекта, но структура проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в ее основе принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.
Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.
Процесс MSF ориентирован на «вехи » (milestones) - ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: «Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?», «В достаточной ли степени готов план действий?», «Соответствует ли продукт утвержденной спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т. д.
Модель процессов MSF учитывает постоянные изменения проектных требований. Она исходит из того, что разработка решения должна состоять из коротких циклов, создающих поступательное движение от простейших версий решения к его окончательному виду.
Модель процессов MSF тесно связана с базовыми принципами MSF, рассмотренными выше. Вообще говоря, тремя особенностями модели процессов MSF являются:
Модель процессов включает такие основные фазы процесса разработки:
Кроме этого существует большое количество промежуточных вех , которые показывают достижение в ходе проекта определенного прогресса и расчленяют большие сегменты работы на меньшие, обозримые участки. Для каждой фазы модели процессов MSF определяет:
В рамках MSF программный код, документация, дизайн, планы и другие рабочие материалы создаются, как правило, итеративными методами. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности. Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. Несмотря на то, что для малых проектов может быть достаточным выпуск одной версии, рекомендуется не упускать возможности создания для одного решения ряда версий. С созданием новых версий эволюционирует функциональность решения.
Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. «Живые» документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.
Решение не представляет бизнес-ценности, пока оно не внедрено. Именно по этой причине модель процессов MSF содержит весь жизненный цикл создания решения, включая его внедрение - вплоть до момента, когда решение начинает давать отдачу.
Управление рисками (risk management) - это одна из ключевых дисциплин Microsoft Solutions Framework® (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF (MSF risk management discipline) отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Девиз MSF - мы не боремся с рисками - мы ими управляем .
Проект (project) - ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги. Управление проектами (project management) - это область знаний, навыков, инструментария и приемов, используемых для достижения целей проектов в рамках согласованных параметров качества, бюджета, сроков и прочих ограничений.
Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют так называемый «треугольник компромиссов ». Нахождение верного баланса между ресурсами, временем разработки и возможностями - ключевой момент в построении решения, должным образом отвечающего нуждам заказчика.
Другое весьма полезное средство для управления проектными компромиссами - матрица компромиссов проекта (project tradeoff matrix). Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях. В определенных случаях из этой приоритезации могут делаться исключения, но в целом следование ей облегчает достижение соглашений по спорным вопросам.
Для иллюстрации использования матрицы компромиссов Майкрософт предлагает использовать следующее предложение (вместо пропущенных слов могут быть вставлены «календарный график», «ресурсы» и «функциональность»): «Зафиксировав ___________, мы согласовываем ___________ и принимаем результирующий ___________».
Как уже говорилось выше, в MSF нет роли «менеджер проекта». Деятельность по управлению проектом распределяется между лидерами групп и ролевым кластером «Управление программой».
Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS . Иерархическая структура работ (Work Breakdown Structure - WBS ) - это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.
Управление подготовкой - это также одна из ключевых дисциплин Microsoft Solutions Framework (MSF). Она посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF описывает фундаментальные принципы MSF и дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Эта дисциплина также рассматривает планирование процесса управления подготовкой. Будучи подкрепленной испытанными практическими методиками, дисциплина управления подготовкой предоставляет проектным группам и отдельным специалистам базу для осуществления этого процесса.
Cледует отметить, что MSF не навязывает использование других продуктов Microsoft . Например, для организации процесса производства ПО можно использовать MSF и при этом применять инструменты Borland , хотя будущая версия MSF 4.0 будет жестко привязана к Microsoft Team System - новому инструментальному средству Майкрософт для поддержки командной работы над проектом.
Первая версия MSF появилась в 1994 году . Текущая версия - MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.
Кроме этого, появилась роль архитектора и поддержка методологии в инструменте - Microsoft Visual Studio Team System .
Андрей Колесов
Обзор подготовлен на базе материалов, представленных в учебном курсе для подготовки к экзамену по программе сертификации Microsoft Certified Solution Developer N 70-300: Analyzing Requirements and Defining Microsoft .NET Solution Architectures. Русский перевод этого курса выпущен в 2004 г. издательством "Русская Редакция" под названием "Анализ требований и создание архитектуры решений на основе Microsoft .NET".
В последние годы мы видим, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (application lifecycle management, ALM). Microsoft (http://www.microsoft.com) пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО, хотя движется именно в этом направлении (об этом свидетельствуют последние новости с конференции TechEd"2004, см. врезку), и основной акцент делает на средствах проектирования и разработки - Visio, Visual Studio и т. д.
Однако для реализации идеологии ALM на практике необходим не только набор инструментов сам по себе, но и общая методологическая база. Microsoft уже более десяти лет занимается развитием собственной ALM-методологии под названием Microsoft Solutions Framework (MSF). Может показаться неожиданным, но MSF в целом - по сути платформно-независимая методология, детально описывающая отдельные процессы на уровне абстракций. Инструменты самой Microsoft присутствуют в ней в минимальной степени, лишь как примеры реализации тех или иных рекомендаций. Вместе с тем, хотя и неявно, концепция эта четко выражает общую нацеленность средств разработки корпорации (круг задач, для решения которых они предназначены), что очень хорошо видно из анализа динамики ее развития. Так, если десять лет назад MSF была ориентирована на создание локальных клиентских приложений, то сегодня - на разработку и внедрение сложных систем масштаба предприятия.
Говоря о моделях процессов жизненного цикла проектов разработки ПО, в первую очередь нужно упомянуть о двух основных схемах: водопадной и спиральной (рис. 1), которые отражают два разных подхода к организации этих работ.
Водопадная модель предусматривает четкий переход от этапа к этапу: работы следующего этапа начинаются только после выполнения всех задач предыдущего. Такой стиль подходит для проектов, в которых проектные требования четко определяются заранее и с большой вероятностью не будут корректироваться потом. Данная схема организации разработки очень удобна с точки зрения управления проектом, так как позволяет четко сформулировать состав и обязанности его участников и контролировать графики выполнения проекта.
Спиральная модель обычно ориентируется на крайний случай, когда требования и параметры проекта непрерывно корректируются, а новые требования формулируются лишь по мере необходимости выполнения конкретных работ. Такая схема часто ассоциируется с понятием "экстремальной разработки"; при этом исполнитель и заказчик работают в постоянном тесном сотрудничестве, клиент привлекается на каждом этапе, формулируя свои соображения по поводу созданных компонентов. Однако при такой организации очень велик риск, что процесс разработки выйдет из-под контроля, поэтому реально данная модель используется лишь в относительно небольших проектах.
Однако проблема заключается в том, что чаще всего все требования на задание действительно практически невозможно определить заранее, к тому же даже сформулированные требования подвергаются коррекции. Но тогда требуется повысить уровень управляемости проектом, без чего создание сложного ПО просто невозможно. Компромисс между этими противоречивыми требованиями и предоставляет модель процессов MSF, в которой сочетаются водопадная и спиральная модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали (рис. 2).
В этом случае планирование на основе промежуточных контрольных точек и предсказуемость водопадной модели дополняются наличием обратной связи с заказчиком и творческим подходом к решению задач, характерными для спиральной модели. Таким образом, модель процессов MSF позволяет создавать и развертывать решения уровня предприятия, обеспечивая прогнозируемость хода проектов и учитывая реальные условия их выполнения.
На этом этапе решаются следующие основные задачи:
На этапе выделяются две промежуточные контрольные точки: "Организован костяк команды" и "Создана общая картина решения".
Организован костяк команды. Здесь не обязательно нужен полный поименный список команды, но в документе структуры проекта должны быть определены роли и обязанности каждого члена команды, а также описана иерархия отчетности и ответственности в группе, каналы взаимодействия с заказчиком и общая структура команды.
Создана общая картина решения. Речь идет о разработке концепции решения, которым должна руководствоваться команда для достижения долгосрочных бизнес-целей проекта. Область действия проекта определяет, что включается в контекст проекта, а что выходит за его рамки. На этой временной точке речь идет о создании первой версии документа, который находится в стадии рецензирования участниками команды и согласования заказчиком.
Этап завершается контрольной точкой "Утверждение документа общей картины и области действия проекта".
На этапе планирования команда решает, что нужно разработать, и формирует планы реализации продукта. Готовится функциональная спецификация, создается проект решения, детализируются планы работы, выполняется оценка стоимости и сроков получения результатов.
На этом этапе проводится анализ требований, которые делятся на бизнес-требования, пользовательские, функциональные и системные требования. После сбора и анализа требований команды разрабатывается проект решения, определяются профили пользователей, после чего формируются сценарии применения решения, выполняемые пользователями одного типа, а затем определяются варианты использования системы.
Этап состоит из трех стадий: концептуальное, логическое и физическое проектирование. На стадии концептуального проектирования задача рассматривается с точки зрения пользовательских и бизнес-требований и заканчивается определением набора сценариев использования системы. При логическом проектировании задача рассматривается с точки зрения проектной команды, решение представляется в виде набора сервисов. И уже на стадии физического проектирования задача рассматривается с точки зрения программистов, уточняются используемые технологии и программные интерфейсы.
В ходе данного этапа решаются такие задачи:
Контрольные точки этапа планирования связаны с достижением следующих результатов:
Результаты данного этапа служат для принятия компромиссных решений в дальнейшем.
На этапе разработки создается решение, в том числе пишется и документируется код. В начале этого этапа команда проверяет выполнение всех задач, характерных для предыдущих этапов, а затем приступает к решению следующих задач:
Результаты этапа предполагают следующие элементы:
Основная контрольная точка этапа - "Окончательное утверждение области действия проекта". В этот момент все функции продукта готовы и прошли тестирование в рамках своего модуля. После этого продукт готов к внешнему тестированию и стабилизации. Кроме того, заказчики, пользователи, сотрудники службы поддержки и сопровождения, а также ключевые участники проекта могут предварительно оценить продукт и указать все недостатки, которые нужно устранить до его поставки.
Данный этап - подготовка к выпуску окончательной версии продукта, доводка его до заданного уровня качества. Здесь выполняется комплекс работ по тестированию (обнаружение и устранение дефектов), а также проверяется сценарий развертывания продукта и проводится пилотная эксплуатация.
Тестирование подразумевает следующие основные виды работ:
Когда решение становится достаточно устойчивым, проводится его пилотная эксплуатация в тестовой среде с привлечением пользователей и применением реальных сценариев работы.
Один из главных показателей этапа стабилизации - число обнаруженных ошибок. Сходимость этой величины в сторону устойчивого уменьшения - признак того, что близится завершение работ над продуктом. Важнейшая промежуточная контрольная точка - появление версии, в которой усилиями самой проектной команды не обнаружено ни одной ошибки. Далее следуют выпуски кандидат-релизов продукта для их исследования в условиях пилотной эксплуатации. Завершающая контрольная точка - подтверждение готовности продукта к выпуску и полноценному развертыванию в промышленной среде.
На этом этапе выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика. Основные контрольные точки данного этапа таковы:
Следует подчеркнуть, что момент завершения данного этапа бывает достаточно сложно формально определить, так как выявление неполадок может продолжаться и в ходе промышленной эксплуатации. Именно поэтому необходимо четко сформулировать критерии для завершающей контрольной точки этапа развертывания и не пытаться отладить абсолютно все.
Добавим к изложенному выше несколько важных замечаний. В целом те же самые идеи лежат в основе всех современных промышленных методологий разработки ПО (IBM/Rational, Borland, Microsoft и т. д.). И здесь нет ничего удивительного: именно этим отличаются выверенные временем технологии от кустарного производства. Но в то же время в каждой методологии есть свой подход к выделению различных этапов разработки и зачастую используется собственная терминология, что усложняет проведение параллелей между ними. Проблема эта усугубляется и отсутствием устоявшейся русской терминологии.
Общепринятый на сегодня список ALM-этапов, которого, в частности, придерживаются Borland и Rational, выглядит следующим образом:
Как легко заметить, модель MSF предлагает несколько иную разбивку на этапы и их наименование. Хотелось бы обратить внимание читателей, что речь здесь не идет просто о разных названиях одних и тех же видов деятельности. Объективная проблема категоризации заключается в том, что выделение самостоятельных этапов в жизненном цикле приложений весьма условно, особенно если речь идет об итерационной циклической модели разработки. Например, широкое использование визуальных методов проектирования с автоматической генерацией кода фактически стирает грань между проектированием и кодированием. А тестирование вообще пронизывает всю жизнь программы.
Имеются и субъективные факторы, которые определяются различиями стратегических бизнес-целей разных поставщиков методологий. Именно этим объясняется то, что Microsoft - основу бизнеса которой составляют не средства разработки, а платформенное ПО, - больше внимания (по сравнению с теми же Rational и Borland) уделяет общим вопросам организации процесса создания приложений, а также их внедрению.
Поэтому, например, этап Envisioning включает определение не только требований к ПО, но и состава команды (здесь содержатся, в частности, очень интересные рекомендации касательно ролевой модели команды разработчиков, а также возможных вариантов совмещения ролей). А этап Stabilizing подразумевает не только собственно тестирование, но и фактически опытную эксплуатацию ПО, на которой могут уточняться исходные требования заказчика. Что уж говорить об особом акценте Microsoft на задачах развертывания решений...
Microsoft для разработчиков - новости с TechEd"2004На проходившей в конце мая в Сан-Диего (шт. Калифорния, США) конференции Microsoft TechEd"2004 был сделан целый ряд важных объявлений относительно развития средств разработки, новых инициатив в области безопасности информационных систем и поддержки жизненного цикла продуктов Microsoft. На конференции были представлены два новых инструмента, предназначенных для интеграции с текущей версией Visual Studio .NET 2003. Первый из них, Web Services Enhancements 2.0 (WSE 2.0), позволяет повысить уровень безопасности создаваемых Web-сервисов за счет использования самых последних спецификаций протоколов WS-Security (на базе утвержденных в 2004 г. стандартов OASIS), в том числе WS-Policy, WS-Security Policy, WS-Trust и WS-SecurityConversation. Версия WSE 2.0 для VS.NET доступна уже сейчас. Кроме того, Microsoft планирует использовать эту технологию для решения задач интеграции данных и приложений: специальный модуль BizTalk Server Adapter for WSE 2.0 представлен пока лишь в виде предварительной технической версии. Второй инструмент - Microsoft Office Information Bridge Framework (IBF), реализованный сейчас в виде бета-версии, - дает возможность использовать Microsoft Office в качестве интеллектуальных клиентских приложений при работе с Web-сервисами, созданными с помощью WSE 2.0. IBF представляет собой набор из нескольких компонентов, предназначенных для разработчиков и пользователей. Один из них устанавливается со стороны Office 2003 Pro и обеспечивает взаимодействие с IBF-приложениями прямо из офисных документов через смарт-теги. Второй компонент IBF - конструктор Information Bridge Metadata Designer, подключаемый к среде VS.NET и обеспечивающий визуальную разработку Web-сервисов с использованием модели безопасности WSE 2.0. В состав IBF входит также Information Bridge Metadata Service - серверный программный модуль, позволяющий передавать на клиентское ПО данные от запущенных на выполнение бизнес-приложений через Web-сервисы. Однако для разработчиков, пожалуй, наиболее интересна информация о намерении существенно расширить в VS.NET возможности управления всем жизненным циклом приложений. Представленная на TechEd"2004 версия Visual Studio 2005 (кодовое имя Whidbey) Enterprise Edition получила название Visual Studio Team System (VSTS). Предполагается, что эта система будет поставляться в трех основных вариантах: Team Architect, Team Developer и Team Test. Предназначенный для архитекторов программных решений инструмент Team Architect включает три конструктора для проектирования распределенных приложений, моделирования логической инфраструктуры и автоматической генерации кода. Последний из них (class designer) выполняет двухстороннюю синхронизацию между визуальной моделью проекта и программным кодом. Примечательно, что в нем используется не классический UML, а собственная нотификация языка моделирования Microsoft. Для поддержки UML в Visual Studio будет по-прежнему использоваться Visio, но встроенные средства самого VS развиваются в несколько ином направлении. Team Developer включает набор инструментов, обеспечивающих выполнение статического анализа и профилирования программного кода, определение степени покрытия кода при тестировании и решение ряда других задач. Эти инструменты можно применять непосредственно в среде разработки приложения, что существенно повышает эффективность процесса отладки. Следует отметить, что Team Architect представляет собой развитие средств, уже имеющихся в текущей версии VS 2003. Функциональность же Team Developer лишь в незначительной степени покрывается текущей версией VS.NET 2003, для эффективного решения подобных задач сегодня требуется подключать соответствующие расширения для VS от третьих фирм. Но в VS 2005 разработчики смогут применять встроенные средства самой Microsoft. Что же касается третьей составляющей VSTS - Team Test, предназначенной для нагрузочного тестирования приложений, то данная функциональность ранее была доступна лишь в автономных продуктах других поставщиков. Теперь же она появилась непосредственно в среде VS 2005, причем в исполнении Microsoft. При этом особое внимание будет уделено задачам тестирования Web-сервисов, в том числе с использованием скриптов, работающих с различными транспортными протоколами, и режимов удаленного мониторинга. Из всей этой информации следует, что Microsoft наращивает возможности своего инструментария в направлении создания комплексных систем масштаба предприятия, включая в него средства автоматизированной поддержки всех этапов жизненного цикла приложений и постепенно вытесняя соответствующие расширения от третьих фирм. Тем не менее многие независимые поставщики одобрительно восприняли сделанные объявления, так как новшества VSTS позволят поднять на качественно новый уровень сотрудничество в рамках "партнерской экосистемы VS", охватывающей несколько десятков компаний-разработчиков. В частности, о своей поддержке будущего продукта на TechEd"2004 уже заявили Borland, Compuware, Telelogic AB и Unisys. |
Один из ключевых элементов реализации проекта - задача управления коллективом его участников. Поэтому наряду с моделью процессов в MSF детально проработана модель команд (MSF Team Model), которая исходит из важности четкого понимания ролей, обязанностей и задач отдельных ее членов, а также их повышенной ответственности за реализацию проекта в целом. Она может применяться в соответствии с потребностями и контекстом проекта, размером коллектива и опытом участников команды. Ниже коротко охарактеризованы роли, используемые в модели команд MSF.
Менеджер продукта (product manager) отвечает за управление связями с клиентом. На этапе проектирования он собирает требования заказчика и ведет контроль за тем, чтобы они соответствовали потребностям его бизнеса. Он также разрабатывает план взаимодействия с клиентом в ходе реализации проекта, в том числе организует встречи с клиентом, демонстрации продукта и другие маркетинговые акции.
Менеджер программы (program manager) управляет собственно разработкой ПО и несет ответственность за его поставку в соответствии с утвержденными спецификациями.
Разработчик (developer) занимается разработкой ПО в соответствии с заданными спецификациями.
Тестировщик (tester) выявляет и устраняет все неполадки в продукте и дает окончательное разрешение на его выпуск. Он также оценивает соответствие набора реализованных в продукте функций общей концепции и области действия проекта.
Менеджер по выпуску (release manager) отвечает за развертывание и поддержку продукта, проверяет корректность ИТ-инфраструктуры заказчика на предмет ее готовности к эксплуатации ПО.
Специалист по удобству использования (user experience specialist) занимается изучением и решением проблем пользователей, оценивает продукт с точки зрения соответствия их потребностям.
Конечно, в небольшом проекте отдельным членам команды приходится совмещать несколько ролей. Тут возможны разные варианты в зависимости от квалификации и опыта сотрудников, а также специфики проекта, но все же нужно придерживаться определенных правил относительно "совместимости" ролей (см. таблицу). Например, обратите внимание, что разработчику не рекомендуется выполнять какие-то еще роли.
| Менеджер продукта | Менеджер программы | Разработчик | Тестиров-щик | Менеджер по выпуску | Специа-лист по удобству исполь-зования | |
| Менеджер продукта | - | - | + | -+ | -+ | |
| Менеджер программы | - | - | -+ | + | -+ | |
| Разработчик | - | - | - | - | - | |
| Тестиров-щик | + | -+ | - | + | + | |
| Менеджер по выпуску | -+ | + | - | + | -+ | |
| Специалист по удобству исполь-зования | + | -+ | - | + | -+ | |
| Примечание: "- " - совмещение не рекомендуется, "-+ " - нежелательно, "+ " - возможно. | ||||||
Кроме собственно исполнителей проекта, в команду могут входить и другие лица:
Одна из основных проблем любого проекта - возможные нарушения графиков или перерасход бюджета. Главная причина этого - нечетко описанная область действия проекта, которая определяет, какие задачи должен решать продукт, а какие не относятся к его компетенции. Поэтому для эффективного управления проектом необходимо следующее:
Управление компромиссами подразумевает достижение баланса всех составных частей проекта, когда в команде осознают, что в выделенное время не удастся решить все поставленные задачи. Проектная группа и заказчик должны постоянно анализировать компромиссы и быть готовыми к нелегкому выбору между разрастанием бюджета (в том числе несоблюдением сроков) проекта и полнотой его функциональности.
Как известно, в любых проектах существует вполне определенная связь между такими его параметрами, как ресурсы, график и набор функций (рис. 3). Любое изменение одного из компонентов требует корректировки других. Поэтому залог успешного создания продукта, отвечающего требованиям заказчика, - определение и обеспечение оптимального баланса между ресурсами, датой поставки и функциональностью.
Для решения этих непростых задач лучше всего использовать матрицу компромиссов, в которой все перечисленные компоненты делятся на обязательные, желательные и факультативные (последние можно исключить или отложить до следующей версии). Продемонстрировать работу матрицы компромиссов можно на примере такого шаблона фразы:
Учитывая, что зафиксировано ____________, мы определим _____________ и в случае необходимости скорректируем ____________________.
Вставляя переменные из определенной заранее матрицы компромиссов, можно получить формулировку, соответствующую целевой задаче проекта, например:
Учитывая, что зафиксированы РЕСУРСЫ, мы определим ГРАФИК и в случае необходимости скорректируем ФУНКЦИОНАЛЬНОСТЬ.
В заключение отметим, что есть и еще одна важная характеристика проекта - качество. Но это как раз тот показатель, который следует жестко зафиксировать. При разработке программных продуктов ни в коем случае не нужно превращать треугольник компромиссов в тетраэдр.
Русская версия Visual Basic .NETВ отличие от продуктов Microsoft массового спроса (Windows, Office), которые переведены на несколько десятков национальных языков, средства разработки Visual Studio .NET представлены сейчас лишь восемью локализованными версиями (французская, немецкая, испанская, итальянская, японская, корейская и два варианта китайских). Освоение русского языка началось лишь в этом году с одного инструмента, но зато самого массового, Visual Basic .NET Standard Edition (поставки его начались в мае 2004 г.). Чтобы представить себе значимость этого проекта, нужно иметь в виду, что полный объем локализации VS.NET 2003 составляет около 20 млн слов (включая всю справочную систему), что существенно превышает аналогичные показатели всего пакета Microsoft Office 2003. VB.NET Standard - это подмножество VS.NET, объем его локализации - 5,6 млн слов. Нужно отметить, что редакция Standard не пользовалась до сих пор большим спросом со стороны профессиональных разработчиков. Тем не менее, по мнению сотрудников московского представительства Microsoft, наличие русской документации непременно повысит интерес разработчиков к VB.NET Standard, тем более что, несмотря на усеченные функции по сравнению с версией VS.NET Pro, с помощью этого инструмента можно создавать весьма широкий круг приложений, компонентов и Web-сервисов промышленного уровня. В отличие от VS.NET Pro, VB.NET Standard не может создавать элементы управления для Windows и Web, мобильные приложения, а также мощные серверные решения. Конечно же, в VB.NET не входят другие языки программирования - VC++, VC# и VJ#. Но подчеркнем, что VS.NET Pro стоит более 1000 долл. (вариант Upgrade - 550 долл.), а VB.NET Standard - всего 100 долл. И все же появление русского VB.NET в основном связано с намерением Microsoft активно продвигать свои инструментальные средства в более широкие круги программистов, в первую очередь - в сферу образования, в частности, подготовки разработчиков. Что касается перспектив расширения линейки русскоязычных средств разработки, сотрудники Microsoft говорят об этом достаточно осторожно. Однако вероятность появления русской версии будущей VS 2005 представляется достаточно большой. |
(Microsoft Solutions Framework)
Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT‑решений. Сочетает в себе свойства двух стандартных производственных моделей: каскадной и спиральной. Она может быть применена при разработке весьма широкого круга программных проектов.
Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Она ориентирована не просто на создание программного продукта, удовлетворяющего определенному набору требований, а на поиск решения проблем, стоящих перед заказчиком. В технологии MSF большое внимание уделяется анализу проблем заказчика и разработке вариантов системы для поиска их приемлемого решения
Являясь гибридом каскадной и спиральной моделей, модель жизненного цикла MSF сочетает простоту управления каскадной модели с гибкостью спиральной (см. рис. 6.10).
Рис. 6.10 . Построение модели жизненного цикла MSF на базе каскадной и спиральной моделей.
Модель жизненного цикла MSF ориентирована на «вехи» (milestones) – ключевые точки проекта, характеризующие достижение какого-либо существенного результата. Этот результат может быть оценен и проанализирован. В модели предусматривается наличие основных вех (завершение главных фаз модели) и промежуточных, отражающих внутренние этапы главных фаз.
Базовыепринципы MSF:
Единое видение проекта - четкое и одинаковое понимание целей и задач проекта членами проектной группы и заказчиком.
Гибкость - непрерывная изменяемость условий проекта при неизменной эффективности управленческой деятельности.
3. Сконцентрированность на бизнес-приоритетах - независимо от того, нацелен ли разрабатываемый продукт на организации или индивидуумов, он должен принести в некоторой форме выгоду или отдачу. В отношении индивидуумов это может означать, например, эмоциональное удовлетворение – как в случае компьютерных игр, в отношении организаций – это бизнес‑отдача (business value).
Открытость информации - свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат, но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности.
Основными фазами модели MSF являются:
1. Создание общей картины приложения (Envisioning ) .На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнес-целей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: «Организован костяк команды» и «Создана общая картина решения».
2. Планирование (Panning). Этап состоит из трех стадий:
Концептуальное проектирование - определение набора сценариев использования системы,
Логическое проектирование - решение представляется в виде набора сервисов
Физическое проектирование - уточняются используемые технологии и интерфейсы.
3. Разработка (Developing). Создается вариант решения проблемы, в виде кода и документации очередного прототипа, включая спецификации и сценарии тестирования. Основная веха этапа – «Окончательное утверждение области действия проекта». Продукт готов к внешнему тестированию и стабилизации.
4. Стабилизация (Stabilizing). Подготовка к выпуску окончательной версии продукта, доводка его до заданного уровня качества. Здесь выполняется комплекс работ по тестированию (обнаружение и устранение дефектов), проверяется сценарий развертывания продукта. Когда решение становится достаточно устойчивым, проводится его пилотная эксплуатация в тестовой среде с привлечением пользователей и применением реальных сценариев работы.
5. Развертывание (Deploying). Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика.
ТЕМА 4: ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ: ИНИЦИАЦИЯ, ПЛАНИРОВАНИЕ, ИСПОЛНЕНИЕ, КОНТРОЛЬ, ЗАВЕРШЕНИЕ.
Процессы инициации
2. Процессы планирования
Процессы исполнения
Введение
Структура MSF
Модель проектной группы
Ролевые кластеры
Модель процессов
Вехи и фазы
Итеративный подход
Фаза выработки концепци (Envisioning)
Фаза планирования (Planning)
Фаза разработки (Development)
Фаза стабилизации (Stabilizing)
Фаза внедрения(Deploying)
Дисциплина управления проектами
Дисциплина управления рисками
Дисциплина управления подготовкой
Новые версии MSF
Литература
Масштабирование проектных групп
Таблица совместимости ролей
Microsoft Solutions Framework, далее MSF, представляет собой подход компании Microsoft к управлению IT-проектами. В данном обзоре будет рассмотрена версия 3.0 данной методологии, опубликованная в июне 2002 года.
Технология MSF состоит из двух моделей:
Модель проектной группы;
Модель процессов.
И трех дисциплин:
Дисциплина управления проектами;
Дисциплина управления рисками;
Дисциплина управления подготовкой.
Все они довольно подробно описаны в 5
whitepapers . Рассмотрим все эти части более детально.Методология MSF отошла от традиционного подхода построения проектных групп в виде пирамидальной, иерархической структуры, разбив ее на ролевые кластеры и четко определив цели и область компетенции каждого кластера.
К основным принципам и ключевым концепциям, определяющих проектную группу MSF относятся:
Команда соратников или равноправие положения ролей в команде. Каждый член команды должен нести ответственность за качество продукта, учитывать интересы заказчика и понимать сущность решаемой бизнес-задачи. Но нет равноправия среди сотрудников, т.е. каждый ролевой кластер имеет свою организационную иерархию для распределения работы и управления ресурсами.
Единое видение проекта. А именно единое четкое понимание целей и задач проекта.
Распределение ответственности при фиксации отчетности .
Нацеленность на необходимый заказчику конечный результат ;
Наличие у сотрудников необходимых полномочий ;
Открытое общение ;
Установка на отсутствие дефектов ;
Стремление к совершенствованию ;
Гибкость и готовность к переменам ;
Заинтересованность и энтузиазм .
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением.
Модель проектной группы MSF определяет шесть ролевых кластеров. Они ответственны за различные области компетенции (
functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.Управление продуктом
Цель : Удовлетворенные заказчики.
Область компетенций :
Маркетинг;
Бизнес-отдача (бизнес-приоритеты);
Представление интересов заказчика;
Планирование продукта.
Управление программой
Цель : Достижение результата в рамках проектных ограничений.
Область компетенций :
Управление проектом;
Выработка архитектуры решения;
Контроль производственного процесса;
Административные службы.
Разработка
Цель : Создание продукта в соответствии со спецификацией.
Область компетенций :
Технологическое консультирование;
Проектирование и осуществление реализации;
Разработка приложений;
Разработка инфраструктуры.
Тестирование
Цель : Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены.
Область компетенций :
Планирование тестов;
Разработка тестов;
Отчетность по тестам.
Удовлетворение потребителя
Цель : Повышение эффективности пользователя, увеличение потребительской ценности продукта.
Область компетенций :
Обеспечение технической поддержки;
Обучение;
Эргономика;
Графический дизайн;
Интернационализация;
Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями);
Управление выпуском
Цель : Беспроблемное внедрение и сопровождение продукта.
Область компетенций :
Инфраструктура;
Сопровождение;
Бизнес-процессы;
Управление выпуском готового продукта.
Принципы MSF формируют такой подход к управлению проектами , при котором:
ответственность за управление проектом распределенная между лидерами ролевых кластеров внутри команды — каждый член проектной группы отвечает за общий успех проекта и качество создаваемого продукта.
профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней — в эффективно работающей команде каждый ее член имеет необходимые полномочия для выполнения своих обязанностей и уверенный, что получит от коллег все необходимое.
Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!
Модель проектной группы
MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия.В одном ролевом кластере может быть много людей;
Один человек может взять на себя несколько ролей;
Большие коллективы:
создаем группы направлений;
создаем функциональные группы;
Малые коллективы:
смотрим таблицу совместимости ролей (из таблицы можно сделать вывод, что минимальный размер команды – 3 человека: удовлетворение потребителя, управление продуктом, Тестирование; Управление программой и выпуском; Разработка);
Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT-решений, а именно описывает последовательность действий, осуществляемых в ходе реализации проекта.
Модель процессов MSF объединяет в себе принципы каскадной и спиральной моделей.
Тремя особенностями модели процессов MSF являются:
Подход, основанный на фазах и вехах.
Итеративный подход.
Занимая центральное место в методологии MSF, вехи используются как опорные точки для планирования и мониторинга хода проекта.
MSF вводит два типа вех: главные (major) и промежуточные (interim). Они имеют следующие особенности:
Главные вехи служат точками перехода от одной фазы к другой. Они также определяют изменения в текущих задачах ролевых кластеров.
Промежуточные вехи показывают достижение в ходе проекта определенного прогресса и расчленяют большие сегменты работы на меньшие, обозримые участки.
Промежуточные вехи могут варьироваться от проекта к проекту. MSF рекомендует использовать определенный набор промежуточных вех, но на практике проектная группа может сама устанавливать их в соответствии с особенностями своей работы.
Итеративный подход к процессу разработки широко используется в MSF. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности. А затем к решению добавляются все новые и новые возможности.
Модель процессов MSF покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Каждая фаза заканчивается главной вехой, результаты которой становятся видимыми за пределами проектной команды.
Для каждой фазы модели процессов
MSF определяет:Что (какие артефакты) является результатом этой фазы;
Над чем работает каждый из ролевых кластеров на этой фазе;
Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка документа общего описания и рамок проекта (vision/scope document).
Веха : Концепция утверждена.
Результаты :
Общее описание и рамки проекта (vision/scope document).
Документ оценки рисков (risk assessment document).
Описание структуры проекта (project structure document).
Ядро проектной группы сформировано
Черновой вариант концепции проекта составлен
На фазе планирования производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.
Веха : Планы проекта утверждены.
Результаты :
Функциональная спецификация;
План управления рисками;
Сводный план и сводный календарный график проекта.
Верификация технологий;
Базовая версия функциональной спецификации создана;
Базовая версия сводного плана проекта создана;
Базовая версия сводного календарного графика проекта создана;
Среды разработки и тестирования развернуты.
На фазе разработки проектная группа фокусируется на создании компонент решения (включая как документацию, так и программный код). Следует обратить внимание, что активность проектной команды на этом этапе не ограничивается написанием разработчиками кода – все ролевые кластеры принимают деятельное участие в создании и тестировании решения.
Веха : Разработка завершена.
Результаты :
Скрипты установки и конфигурирования;
Окончательная функциональная спецификация;
Материалы поддержки решения;
Спецификации и сценарии тестов.
Концепция подтверждена;
Билд 1 завершен;
Билд 2 завершен;
Билд n завершен.
Во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.
Веха : Готовность решения утверждена
Результаты :
Окончательный продукт (golden release);
Документация выпуска (release notes);
Материалы поддержки решения;
Результаты и инструментарий тестирования;
Исходный и исполнимый код приложений;
Проектная документация;
Анализ пройденной фазы (milestone review).
Точка конвергенции (В точке конвергенции (bug convergence) становится заметен существенный прогресс в устранении ошибок, то есть скорость устранения ошибок начинает превосходить скорость их обнаружения. Точка конвергенции дает проектной группе возможность понять, что процесс тестирования близится к концу.
Точка достижения нуля (Точка достижения нуля (zero-bug bounce) – это момент, когда впервые все выявленные ошибки оказываются устраненными. )
Версии-кандидаты
Контрольное тестирование завершено
Тестирование приемлемости для потребителей завершено
Пилотное внедрение завершено
Во время этой фазы проектная группа внедряет технологии и компоненты решения, стабилизирует внедренное решение, передает работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта.
Веха : Внедрение завершено.
Результаты :
Информационные системы эксплуатации и поддержки;
Процедуры и процессы;
Базы знаний, отчеты, журналы протоколов (logbooks);
Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта;
Отчет о завершении проекта (project close-out report);
Окончательные версии всех проектных документов;
Показатели удовлетворенности заказчика и потребителей;
Описание последующих шагов.
Ключевые компоненты развернуты;
Внедрение на местах завершено;
Внедренное решение стабилизировано.
Вскольз упоминается про Управление конфигурацией (протоколирование и контроль состояний элементов проекта ), Управление изменениями и Управление рисками. Говорится что нужно не забывать про них и дается несколько вариантов в поверхностным описанием как это можно делать;
Дается множество определений.
Носителем профессиональных управленческих навыков и организатором работы команды в MSF является ролевой кластер “Управление программой”. Однако типовые управленческие обязанности при этом распределяются среди лидеров всех ролевых кластеров проектной группы.
Данный дисциплина не предоставляет конкретных рецептов управления проектами и не содержит объяснений многочисленных методов работы, применяемых опытными менеджерами. Однако он показывает, как принципы MSF формируют такой подход к управлению проектами, при котором:
Ответственность за управление проектом распределена среди лидеров ролевых кластеров внутри команды.
Профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней.
Распределение ответственности по управлению проектом среди лидеров групп
Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS . Иерархическая структура работ (WBS) — это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.
Дисциплина управления рисками MSF заимствует хорошо известную модель процесса непрерывного управления рисками, разработанную Software Engineering Institute (SEI). При этом интерпретация этой модели дается в контексте опыта Microsoft. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием шестишагового процесса для успешного активного управления рисками. Этот процесс включает в себя:
Выявление рисков (risk identification) – это фаза, позволяющая членам проектной группы вынести на обсуждение всей команды факты наличия рисков.
Анализ рисков (risk analysis) – это фаза преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритизация рисков (risk prioritization) позволяет проектной группе управлять наиболее важными из них, выделяя для этого необходимые ресурсы.
Планирование рисков (risk planning) выполняется исходя из информации, полученной на этапе их анализа, и имеет своей целью выработку стратегий, планов и конкретных шагов.
Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов.
Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения.
Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта в форме, доступной для использования как внутри проектной группы, так и на уровне всего предприятия.
Данная дисциплина посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Этот процесс состоит из четырех шагов:
Определение
Проектные сценарии (scenarios).
Квалификационные требования (competencies).
Профессиональные навыки (proficiencies).
Оценивание
Измерение знаний, умений, способностей (measure knowledge, skills, abilities).
Анализ несоответствий (analyze gaps).
Создание учебных планов (create learning plans).
Корректировка
Обучение (train).
Мониторинг прогресса (track progress).
Осмысление
Анализ результатов (review results).
Управление знаниями (manage knowledge).
Новая версия MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement. MSF for Agile Software Development в определенной степени отражает тенденции последнего времени, связанные с появлением методологий, предлагающих максимально облегченный и гибкий подход к процессу разработки. MSF for CMMI Process Improvement - это строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д. Данная версия выглядит, как облегченный вариант 3.0 и ориентирована на продукты Microsoft, а именно Visual Studio 2005 Team System и MS Project.
Microsoft Solutions Framework (модель разработки приложений Microsoft) - это набор концепций и рекомендуемых моделей, которые позволяют разрабатывать и внедрять информационные системы на основе технологий и инструментальных средств Microsoft. Многие концепции MSF хорошо известны. MSF является одной из интерпретаций спиральной (циклической) модели разработки приложений и базируется на практических результатах организации распределенных вычислений и применения технологий «клиент-сервер» компании Microsoft, ее партнеров и заказчиков.
Главной целью MSF, как и любой методологии проектирования приложений, является создание рабочего приложения вовремя и в рамках установленного бюджета. MSF предлагает хорошо зарекомендовавшие себя практики планирования, разработки и внедрения информационных технологий. В то же время MSF не является простым набором инструкций, которым полагается следовать безоговорочно, - этот процесс достаточно гибок и расширяем. Основной сайт, посвященный методологии MSF: http://www.microsoft.com/msf .
MSF содержит следующие модели:
Team Model (Модель команды) описывает коллектив, в котором работа одного сотрудника зависит от другого;
Proccess Model (Модель процесса) позволяет определить принципы планирования и контроля проектов;
Application Model (Модель приложения) помогает создавать приложения, максимально используя готовые компоненты;
Enterprise Architecture Model (Модель архитектуры корпорации) - обеспечивает принятие решения по технологиям; она очень важна для эффективного использования новых технологий;
Solution Desing Model (Модель проектирования решений) - показывает, каким должно быть приложение с точки зрения пользователя. Эта модель связывает приложение, команду разработчиков и процесс разработки;
Infrastructure Model (Модель управления инфраструктурой) - определяет принципы управления пользователями в больших сетях;
Total Cost of Ownership Model (Модель стоимости владения продуктом) - позволяет оценивать расходы на информационные технологии.
Базовыми компонентами методологии являются:
Solution Development Discipline (SDD) дисциплина разработки решений. Содержание этой дисциплины связано с уникальными моделями: моделью команды и моделью процесса, которые рекомендуется использовать для организации эффективных команд проектов и управления жизненным циклом проекта. SDD включает три фундаментальные модели MSF:
Масштабируемая модель команды разработки - описывает принципы организации группы людей, ответственных за разработку приложения,
Итеративная модель процесса разработки - описывает, как должен быть организован процесс,
Сетевая трехслойная модель приложения - описывает, какой должна быть структура приложения, удовлетворяющего современным требованиям;
Designing Component Solutions (DCS) проектирование компонентного ПО. Эта дисциплина направлена на поддержку процесса проектирования сложных моделей распределенных вычислений;
Enterprise Architecture Planning планирование архитектуры предприятия. С точки зрения Microsoft, это итеративный процесс, сосредоточенный на долгосрочном планировании, но при этом направленный на достижение результатов в максимально сжатые сроки;
Infrastructure Deployment and Management управление технологической инфраструктурой. Эта дисциплина содержит подход к процессу внедрения в масштабах предприятия как новых информационных технологий, так и отдельных программных продуктов и приложений.
Ниже мы рассмотрим ключевые модели, отличающие MSF от других коммерческих реализаций спиральной методологии разработки.
Модель процесса SDD представляет собой один из вариантов спиральной модели: когда один цикл внедрения близок к завершению, уже должен планироваться следующий. Это связано со скоростью изменения бизнес-процессов, а также с быстрым развитием информационных технологий. Сдвиг фаз нового цикла относительно предыдущего может быть разным для различных проектов. Последовательность фаз в витке является логической в смысле зависимости последующих фаз от предыдущих. Это не означает, что фазы выполняются во времени строго одна за другой и следующая фаза может начаться только по окончании предыдущей. Фазы могут выполняться параллельно и быть частично или полностью совмещенными по времени. Кроме того, сами фазы проекта носят итеративный характер. По достижении очередной вехи полученные материалы немедленно подвергаются проверке и оценке, результаты вызывают очередную итерацию уже проделанных работ, что не мешает начинать и продолжать дальнейшую работу в остальной части проекта.
Цикл (виток спирали) разработки включает четыре фазы и завершается выпуском версии продукта. Каждая фаза представляет собой определенную последовательность действий и завершается вехой (milestone).
Первая фаза Анализ (Envisioning). На данном этапе формируется представление о продукте на данном витке спирали. Это гарантирует, что разрабатываемый продукт будет соответствовать как текущим, так и перспективным целям компании, а также поможет скорректировать направление развития компании. Данная стадия требует глубокого осмысления целей проекта. Формирование представления позволяет избежать, например, инвестирования в незначительные или неэффективные проекты. В результате этой стадии составляется представление о продукте, определяются его функциональные возможности и оцениваются результаты. Если новый продукт получает одобрение, то составляется группа разработки проекта, задача которой - выработать концепцию продукта. На этом этапе фиксируются цели и определяется четкое направление разработки. Здесь же устанавливаются возможности конкретной версии продукта или службы и оцениваются тенденции развития продукта в следующих версиях. Вехой данной фазы является утверждение представления.
Вторая фаза Планирование (Planning). С точки зрения Microsoft, планирование - это процесс согласования требований потребителей и группы проекта, касающихся конечного продукта и направления разработки продукта. Это метод прогнозирования рисков, выработки приоритетов и оценки графика работ и необходимых ресурсов. Фаза планирования завершается одобрением плана проекта, который включает функциональную спецификацию - комбинированные планы для каждого члена группы в соответствии с требованиями модели команды и график работ. Функциональная спецификация достаточно детализирована, чтобы позволить группе проекта определить потребности в ресурсах и ее обязательства. Вехой данной фазы является утверждение плана проекта.
Третья фаза Разработка (Developing). Стадия разработки завершается реализацией возможностей продукта и проверкой их на практике. Группа разработки определяет промежуточные этапы выпуска продукта, каждый из которых включает полный цикл тестирования, отладки и внесения исправлений. На этом этапе потребители и группа разработки оценивают функциональные возможности продукта и проверяют оптимальность планов развертывания и поддержки. Разработка в целом завершается, а все нереализованные возможности документируются для включения в следующие версии. Вехой данной фазы является завершение разработки, альфа-версия (передается тестерам, пользователям, начинается устранение ошибок).
Четвертая фаза Стабилизация (Stabilizing). На этой стадии акцент переносится с разработки решения на проверку его работоспособности в реальных условиях и на полномасштабное тестирование. Стадия стабилизации завершается выпуском продукта, который передается группам развертывания и сопровождения. Группе проекта поручают создание следующей версии либо подключают к работе над другими проектам. Вехой данной фазы является релиз продукта.
Контрольными точками процесса являются вехи (milestones). Работа команды ориентирована на достижение вех, что сопровождается появлением и фиксацией того или иного отчуждаемого материала (документа, программы, протокола и т.д.). Веха - это время проведения инспекций (фазовых обзоров), на которых обсуждаются достигнутые результаты и принимаются решения. Перечисленные выше ключевые вехи являются внешними, то есть отчуждаемые материалы вехи согласуются с заказчиком. Очень важно, что каждая веха - это точка синхронизации, в которой происходит взаимное согласование точек зрения исполнителей (команды проекта), заказчиков, пользователей. Следует отметить, что вехи MSF являются точками не «замораживания» проекта (когда одна группа передает результаты своей работы другой группе), а его синхронизации. Все изменения артефактов, полученных в процессе работы над проектом, строго контролируются. Они вносятся не произвольно, а только после согласования на внутренних обзорах. Таким образом обеспечивается возможность принятия решения максимально рано, а «замораживания» проекта - максимально поздно.
Кроме внешних вех, могут быть (и даже рекомендованы) внутренние вехи - события, которые происходят между внешними вехами и свидетельствуют или о достижении какой-либо цели, или о начале и конце какой-либо работы. Внутренние вехи позволяют итеративно создавать итоговые материалы фазы, посредством нескольких обзоров добиваясь нужного качества или содержания.
Управление продуктом;
Управление программой;
Разработка;
Тестирование;
Обучение пользователей;
Сопровождение (логистика).
Исходя из размера проекта определяется, может ли тот или иной член команды совмещать различные роли. В каждую из ролевых групп может входить не более шести человек; при этом один из них назначается руководителем (лидером) группы - он осуществляет руководство и согласование по всем работам, а остальные члены группы являются исполнителями.
Задачи, обязанности (ответственность) и требуемые профессиональные качества каждой роли четко определены, каждому члену группы и группе в целом делегированы достаточные полномочия в сочетании с высокой степенью ответственности.
Каждый исполнитель сам оценивает трудоемкость той части проекта, за которую он отвечает; консолидированная оценка трудоемкости проекта складывается на основе собственных оценок исполнителей, что делает реально достижимыми цели и планы-графики работ.
Работа групп последовательно ориентирована на удовлетворение требований и ожиданий конечных пользователей. Непроизводительные трудозатраты на поддержание формальных и субординационных связей сведены к минимуму.
Модель сравнительно легко масштабируется. Каждый элемент в схеме команды может быть, в свою очередь, циклом.
Таким образом, модель команды MSF очень демократична, поскольку в ней нет явно выделенного центра, строгой иерархической структуры. Модель команды MSF - это команда равных (peer). Схематически ее принято изображать в виде круга, где все роли равноправны и связаны друг с другом.
Модель приложения MSF основана на трех основных понятиях.
Многослойное (Multi-tier) приложение - позволяет адекватным образом описать различные аспекты распределенных приложений. Модель приложения MSF выделяет три основных слоя:
Пользовательский интерфейс;
Бизнес-правила;
Управление данными.
Служба (Service) позволяет описывать логическую структуру приложения в объектно-ориентированном стиле. Служба это набор взаимосвязанных функций, выполняющих некоторые действия или доставляющих информацию в соответствии со спецификой службы. Функциональность службы доступна только через заранее описанный интерфейс, который скрывает все детали реализации. В рассматриваемой трехслойной модели приложения службы делятся на три категории:
Информационные службы;
Бизнес-службы;
Пользовательские службы.
Логически приложение представляет собой некую сеть служб. Затем логическая модель приложения в форме сети служб транслируется в физическую: все логические службы упаковываются в физические объекты - компоненты, которые реализуются затем в виде программных модулей. Получившаяся в результате такой компоновки архитектура называется физической архитектурой, или архитектурой реализации.
Компонент (Component) описывает разбиение программного кода на модули, ориентированные на их многократное использование и предоставляющие описанные в спецификации сервисы через опубликованный интерфейс. Компонент представляет собой многократно используемый «черный ящик» и определяется тем, как он взаимодействует с другими компонентами, а не своей внутренней реализацией. Компонент реализует некоторое множество функций системы и имеет формальные и явно описанные интерфейсы.
Процесс проектирования MSF состоит из трех стадий.
Первая стадия концептуальное проектирование это описание точки зрения пользователя на проект. На этом этапе происходит следующее:
Определение существа проблемы, подлежащей решению, установление цели разработки;
Идентификация основной деятельности: определяются границы области, которую покрывает разрабатываемое решение, причем как перспективные, так и реальные;
Классификация пользователей: группирование пользователей по категориям и описание требований и ожиданий каждой категории;
Составление сценариев «Как есть» и «Как должно быть». Сценарии являются основным выходом стадии концептуального проектирования;
Проверка, оценка и итеративное проектирование. Все стадии проектирования, во-первых, носят итеративный характер, а во-вторых, взаимно перекрываются. Построенный концептуальный проект немедленно подвергается проверке и оценке, результаты которой вызывают очередную итерацию концептуального проектирования, что не мешает начинать и продолжать логическое и физическое проектирование.
Вторая стадия логическое проектирование это точка зрения группы проектировщиков на приложение. Логическое проектирование является ядром процесса разработки. Центральной задачей логического проектирования при использовании рекомендуемой MSF модели приложения является вычленение и спецификация служб. Сюда же относятся создание информационной модели, разбиение слишком большой системы на подсистемы и итеративная верификация логического проекта. Результатом логического проектирования является логическая модель приложения, то есть на этой стадии должны быть спроектированы службы, а также специфицированы реализуемые ими функции и интерфейсы.
Третья стадия физическое проектирование это точка зрения программистов на приложение. Результатом физического проектирования является физическая архитектура приложения, то есть специфицированы все компоненты приложения. Основное содержание этой стадии упаковка служб в физические компоненты приложения.
Цель планирования архитектуры предприятия (Enterprise architecture planning) - показать менеджерам предприятия, занимающимся планированием бизнеса, как связаны между собой бизнес-цели и информационные технологии, направленные на поддержку этого бизнеса, а кроме того, как можно использовать фундаментальные модели для планирования развития бизнеса. Без подобного документа, ориентированного на менеджеров высшего уровня, обосновать и утвердить финансовый план внедрения новых информационных технологий весьма и весьма сложно, так как специалисты в области информационных технологий и бизнес-менеджеры «разговаривают на разных языках». Цель данного компонента методологии - нахождение общего языка. В рамках данного обзора мы не предполагаем давать стилевые рекомендации о том, как создавать такого рода документ или иной артефакт, на основании которого менеджмент будет принимать решение, а лишь укажем набор необходимых аспектов, которые рекомендуется включить в документы.
Enterprise в терминологии MSF - это единица организационной структуры, которая имеет самостоятельную бизнес-задачу (mission). Таким образом, речь может идти как о предприятии в целом, так и о его департаментах, отделениях, отделах и т.д.
Модель архитектуры предприятия предполагает наличие архитектуры бизнеса и архитектуры приложений:
Архитектура бизнеса определяет основную цель бизнеса и бизнес-процессы, необходимые для достижения этой цели. Она описывает, как эти бизнес-процессы выполняются, и определяет возможности для реорганизации, основанной на изменениях рынка, конкурентоспособной позиции и технологических возможностях;
Архитектура приложений (прикладная архитектура) - определяет набор приложений, которые должны поддерживать бизнес-процессы на предприятии, устанавливает приоритеты для автоматизации бизнес-процессов и/или реорганизации уже работающих приложений. Эти приоритеты основываются на целевой бизнес-архитектуре. Прикладная архитектура показывает способ, с помощью которого приложения будут создаваться, чтобы поддерживать бизнес-процессы;
Информационная архитектура - определяет:
Существенные бизнес-объекты (например, заказчики, заказы и т.д.) и отображает их на бизнес-процессы предприятия, то есть определяет их владельцев и пользователей,
Концептуальную модель данных для объектов и их связей,
Текущую информационную топологию (распределение данных по подразделениям или серверам),
Целевую топологию для будущей бизнес-архитектуры;
Технологическая архитектура - определяет текущую технологическую базу предприятия и, основываясь на бизнес-архитектуре и прикладной архитектуре, а также на оценке новых технологий, описывает, какие технологии и как именно будут внедряться на предприятии.
Все эти компоненты зависимы, их следует рассматривать как стратегические цели, на достижение которых должен быть направлен процесс планирования.
