Файл: Московский финансовопромышленный университет Синергия Бенин Д. М. Интернеткурс.pdf

92
•
Дисциплина управления рисками MSF.
•
Дисциплина управления подготовкой MSF.
MSF предлагает несколько оригинальных идей, перечислим их:
•
Единое видение проекта.
•
Треугольник и матрица компромиссов.
•
«Проектная группа – команда равных».
•
Управление рисками.
В 1993 году, стремясь достичь максимальной отдачи от IT- проектов, компания Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базировались на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft и лучшем из того, что накопила на тот момент IT индустрия.
MSF предлагает стремиться к созданию культуры, которая бы помогала разработчикам успешно выполнять проекты. При этом под образом мыслей понимается набор ценностей, которые определяют, как мы интерпретируем ситуации и реагируем на них.
Образ мыслей помогает членам команды принимать решения, приоритезировать работу, представлять свои роли в команде и взаимодействовать с другими участниками проекта.
Методология MSF содержит весьма много элементов, в частности:
•
рекомендованные процессы создания IT-проектов;
•
структуру итераций;
•
роли членов команды;
•
шаблоны документов (Excel, Word);
•
шаблоны Microsoft Project;
•
отчеты;
•
портал проекта (шаблон сайта SharePoint).
MSF for
Agile
Software
Development ориентирован на использование итеративной и эволюционной модели процесса разработки и основан на сценариях использования.
Основные принципы построения команды.
Методология MSF считает, что успешная работа команды над проектом существенным образом зависит от ее структуры и распределения зон ответственности ролевых групп внутри команды.
Построение команды в MSF соответствует ряду ключевых концепций
(key concepts), часть которых кажутся самоочевидными, другие чем-то сродни «ноу-хау».

93
К самоочевидным можно отнести:
1. Концентрация на нуждах заказчика (customer-focused mindset) – главный приоритет любой хорошо работающей проектной группы.
Означает обязательное понимание бизнес-задач заказчика и стремление к их решению со стороны команды. Не менее важным является активное участие заказчика в проектировании решения и получение его отзывов в ходе процесса разработки.
2. Нацеленность на конечный результат (product mindset) – каждый участник проектной группы должен рассматривать собственную работу в качестве самостоятельного проекта или же вклада в какой-либо больший проект. Установка на конечный продукт означает, что получению конечного результата проекта уделяется больше внимания, чем процессу его достижения. Из этого не следует, что сам процесс может быть плох или непродуман – просто он существует для получения конечной цели, а не ради себя самого.
3. Установка на отсутствие дефектов (zero-defect mindset) – это стремление к высочайшему уровню качества. Она означает, что цель команды – выполнение своей работы с максимально возможным качеством, в идеале таким образом, что если от команды потребуют поставить результат завтра, она будет способна поставить что-то работающее. В успешной команде каждый сотрудник чувствует ответственность за качество продукта. Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой. Концепции, которые в определенном смысле можно отнести к
«ноу-хау» методологии MSF:
•
«Проектная группа – команда равных» (teem of peers).
Концепция означает равноправное положение каждой из ролей в команде. Чтобы достичь успеха в рамках команды равных, каждый из ее членов, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес- задачи. В то же время, принятие решения методом консенсуса между ролями не тождественно принятию решения методом консенсуса между сотрудниками. Каждая ролевая группа требует определенной организационной иерархии для распределения работы и управления ее ресурсами.
•
Стремление к самосовершенствованию (willingness to learn) – это приверженность идее неустанного саморазвития посредством накопления опыта и обмена знаниями. Оно позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. По окончанию основных фаз проекта и по завершению проекта в целом предполагается проведение открытых обсуждений его состояния и доброжелательный, но объективный анализ.

94
К концепции команды равных в MSF тесно примыкает идея о том, что каждая ролевая группа имеет зону ответственности и защищает интересы заинтересованных лиц из этой зоны (более подробно об этом далее).
Модель проектной группы в MSF может масштабироваться в зависимости от числа участников.
MSF for Agile Software Development выделяет 7 ролевых групп
(рис. 6):
•
Управление программой (program management).
•
Архитектура продукта (architecture).
•
Разработка (development).
•
Тестирование (test).
•
Управление выпуском (release operations).
•
Удовлетворение потребителя (user experience).
•
Управление продуктом (product management).
Рис. 6. Модель команды в MSF – ролевые группы
и 6 ролей:
•
менеджер проекта (project manager) – ролевая группа
Управление программой;
•
архитектор (archrect) – ролевая группа Архитектура;
•
разработчик (developer) – ролевая группа Разработка;
•
тестер (tester) – ролевая группа Тестирование;

95
•
релиз-менеджер (release manager) – ролевая группа Управление выпуском;
•
бизнес-аналитик (business analyst) – ролевые группы
Управление продуктом.
Удовлетворение потребителя
Рис. 7. Модель команды в MSF – роли
Каждая ролевая группа в команде имеет зону ответственности
(advocacy), в которой роль из этой группы имеет решающий голос.
•
Управление программой – отвечает за управление проектом, за то, что ожидания заинтересованных сторон будут верно поняты и проведены через проект.
•
Архитектура продукта – отвечает за систему в целом, вырабатывает архитектуру решения, включая сервисы, технологии и стандарты, которые будут использованы в ходе работы над решением.
•
Разработка – отвечает за проектирование и осуществление реализации.
•
Тестирование – отвечает за качество решения с точки зрения заказчика и будущих пользователей.
•
Управление выпуском – отвечает за гладкое внедрение решения в инфраструктуру заказчика.
•
Удовлетворение потребителя – отвечает за понимание потребностей пользователей и их надлежащую реализацию в решении.

96
•
Управление продуктом – отвечает за понимание того как, и успешное получение бизнес-отдачи от внедрения разрабатываемого решения, которое в результате сможет получить заказчик.
Управление программой.
Ролевая группа выполняет следующие задачи:
•
управляет процессом разработки с целью получения готового продукта в отведенные сроки;
•
регулирует взаимоотношения и коммуникацию внутри проектной группы;
•
следит за временным графиком проекта и готовит отчетность о его состоянии;
•
разрабатывает, поддерживает и исполняет сводный план и календарный график проекта;
•
организует управление рисками.
Архитектура продукта.
Ролевая группа выполняет следующие задачи:
•
формулирует спецификацию решения и разрабатывает его архитектуру;
•
определяет структуру развертывания (внедрения) решения.
Разработка.
Ролевая группа выполняет следующие задачи:
•
определяет детали физического дизайна;
•
оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна;
•
разрабатывает или контролирует разработку элементов;
•
подготавливает продукт к внедрению;
•
консультирует команду по технологическим вопросам.
Тестирование.
Ролевая группа выполняет следующие задачи:
•
обеспечивает обнаружение всех дефектов;
•
разрабатывает стратегию и планы тестирования;
•
осуществляет тестирование.
Управление выпуском.
Ролевая группа выполняет следующие задачи:
•
представляет интересы отделов поставки и обслуживания продукта;
•
организует снабжение проектной группы;
•
организует внедрение продукта;

97
•
вырабатывает компромиссы в управляемости и удобстве сопровождения продукта;
•
организует сопровождение и инфраструктуру поставки.
Удовлетворение потребителя.
Ролевая группа выполняет следующие задачи:
•
представляет интересы потребителя в команде;
•
организует работу с требованиями пользователя;
•
определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта;
•
определяет требования к системе помощи и её содержание;
•
разрабатывает учебные материалы и осуществляет обучение пользователей.
Управление продуктом.
Ролевая группа выполняет следующие задачи:
•
выступает в роли представителя заказчика;
•
организует работу с требованиями заказчика;
•
формирует ожидания заказчика;
•
формирует общее видение и рамки проекта;
•
определяет компромиссы между параметрами «возможности продукта / время /ресурсы»;
•
организует маркетинг;
•
разрабатывает, поддерживает и исполняет план коммуникаций.
Вопрос 4. Методология MOF.
Методологическая модель Microsoft Operations Framework (MOF) состоит из набора взаимосвязанных «рекомендованных практик», основополагающих принципов и процедур, которые вместе предоставляют полные руководства по достижению надежности ИТ- решений и услуг. В составе MOF вы найдете инструкции в форме вопросов, помогающие определить, что необходимо вашему ИТ- подразделению сегодня, а также мероприятия, которые позволят ему эффективно и результативно работать в будущем.
Инструкции в Microsoft Operations Framework охватывают все действия и процессы управления ИТ-услугами: планирование, разработка, использование, обслуживание и, в конечном счете, вывод из эксплуатации. В модели MOF эти действия и процессы упорядочены в виде функций управления ИТ-услугами (SMF-функций), которые группируются по этапам, отражающим жизненный цикл ИТ-услуги.
Каждая SMF-функция относится к определенному этапу жизненного цикла и обладает уникальным набором целей и результатов, отвечающих предназначению этого этапа. Готовность ИТ-услуги к

98 переходу на следующий этап определяет управленческий анализ, который призван убедиться, что цели были достигнуты надлежащим образом, а цели ИТ соответствуют целям организации.
Цель MOF заключается в предоставлении ИТ-подразделениям руководств, помогающих создавать, эксплуатировать и поддерживать
ИТ-услуги, обеспечивая получение ожидаемых коммерческих преимуществ от конкретных инвестиций в ИТ с приемлемым уровнем риска.
Модель MOF предназначена для создания среды, в которой компания и ИТ-подразделение смогут совместно работать над совершенствованием деятельности и использовать при этом проактивную модель, определяющую процессы и стандартные процедуры, направленные на повышение эффективности и продуктивности ИТ-услуг. MOF предлагает логический подход к принятию решений и обмену информацией при планировании, развертывании и поддержке ИТ-услуг.
Данное описание модели MOF состоит из серии обзоров этапов
(фаз жизненного цикла) и руководств по функциям сервисного управления (SMF), в которых описаны действия по успешному управлению ИТ-услугами, начиная с оценки, предваряющей запуск новой или усовершенствованной услуги, через оптимизацию существующей услуги, вплоть до вывода устаревшей услуги из эксплуатации.
Руководства написаны для разных целевых аудиторий: директоров по ИТ, руководителей ИТ-подразделений и ИТ-специалистов:
•
обзорные руководства предназначены для директоров по ИТ, которым необходимо получить «общую картину» модели;
•
функциональные руководства, содержащие обзорную информацию и описание рабочих процессов, помогут руководителям
ИТ-подразделений изучить стратегии предоставления ИТ-услуг;
•
функциональные руководства, с подробным перечнем действий, рассчитаны на ИТ-специалистов, занимающихся применением модели
MOF на практике.
Вопрос 5. Методология RUP.
Rational Unified Process (RUP)- это процесс разработки программного обеспечения. Его цель состоит в том, чтобы гарантировать высокое качество программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого графика и бюджета выполнения. RUP обеспечивает строгий подход к решению задач проектирования и ответственности разработчиков.
Rational Unified Process – это итеративныйпроцесс (так называемая спиральная модель жизненного цикла разработки). Каждая итерация может приводить к созданию фрагмента разрабатываемой

99 системы или новой версии и включает этапы выработки требований, анализа, проектирования, реализации и тестирования. Поскольку тестирование проводится на каждой итерации, риск снижается уже на начальных этапах жизненного цикла разработки.
Итеративный подход позволяет увеличивать понимание проблемы через последовательные усовершенствования и повышать эффективность проектных решений. Этот подход обеспечивает лучшую гибкость в учете новых требований или тактических изменений в деловых целях, и позволяет проектировщику заранееидентифицировать и разрешать риски.
RUP – это управляемыйпроцесс. Итеративный подход предполагает управление требованиями и управление изменениями, чтобы своевременно и по всем пунктам обеспечивать общее понимание ожидаемых функциональных возможностей, ожидаемый уровень качества, и гарантировать наилучшее управление связанными затратами и графиками выполнения.
RUP заключается в создании и обслуживании моделей. RUP
фокусирует внимание не на создании большого количества бумажных документов, а на развитии и эксплуатации моделей - семантически богатых представлений программной системы при ее разработке.
RUP концентрирует внимание на первоначальной разработке и компоновке устойчивой архитектуры программы, которая облегчает параллельную разработку, минимизирует переделки, увеличивает возможность многократного использования и надежность эксплуатации.
Эта архитектура используется для планирования использования и управления развитием программных компонентов.
Действия при выполнении RUP управляются прецедентами.
Определение прецедентов и сценария управляет технологическим маршрутом от делового моделирования и требований до испытаний, и обеспечивают связанные и доступные для анализа маршруты разработки и поставки системы.
RUP
поддерживает объектно-ориентированную технологию.
Объектно-ориентированные модели базируются на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), используют унифицированный язык моделирования (UML) как общую систему обозначений.
RUP поддерживает компонентно-ориентированное программирование. Компоненты - это нетривиальные модули или подсистемы, которые выполняют конкретную функцию и могут быть смонтированы в строго очерченной архитектуре, специальной или некоторой общедоступной инфраструктуре компонентов, типа Internet,
CORBA, COM/DCOM, для которых появляется индустрия многократно используемых компонентов.

100
RUP – это процесс с перестраиваемой конфигурацией. RUP удовлетворяет и маленькие группы разработчиков, и большие организации. RUP основан на простой и корректной архитектуре, которая обеспечивает общность для семейства процессов, и все же может быть адаптирована к конкретным ситуациям. RUP содержит рекомендации о том, как сконфигурировать процесс, чтобы удовлетворить потребности данной организации (рис. 8).
RUP поощряет объективно осуществляемое управление
качеством. Оценка качества всех действий и их участников, формируемая в процессе, использует объективные измерения и критерии.
RUP поддерживается инструментальными средствами, которые автоматизируют большинство действий процесса. Инструментальные средства используются для создания и обслуживания различных артефактов - моделей в частности - процесса разработки программного обеспечения: визуального моделирования, программирования, испытаний и так далее. Инструментальные средства осуществляют информационную поддержку управления изменениями, которыми сопровождается каждая итерация.
Рассмотрим, как понимается в RUP процесс разработки программы. Процесс - частично упорядоченный набор шагов, которые нужно проделать для достижения цели; при разработке программного обеспечения цель состоит в формировании или расширении существующего программного изделия; при разработке процессов цель состоит в том, чтобы разработать или расширить процесс. Таким образом, процесс программирования - деловой процесс. RUP представляет собой универсальный деловой процесс объектно- ориентированной разработки программного обеспечения. Он описывает семейство связанных процессов разработки программного обеспечения, совместно использующих общую структуру и имеющих общую архитектуру.
Когда программная система разрабатывается заново, ее разработка
– это процесс создания системы из требований. Но как только система приняла какую-то форму (или в наших терминах, когда система прошла начальный цикл развития), то любая дополнительная разработка – это процесс приспособления системы к новым или изменившимся требованиям, это и есть жизненный цикл системы.
Рис. 8. Процесс разработки программы

101
Рис. 9. Процесс разработки ПО
Процесс разработки программного обеспечения - процесс разработки системы из требований, новых (начальный цикл развития) или измененных (цикл эволюции) (рис. 9).
Чтобы понять Rational Unified Process, рассмотрим два следующих измерения:
•
По основным потокам работ (какова по характеру логика действий групп разработчиков).
•
По времени (аспекты жизненного цикла процесса, как он разворачивается).
Процесс организован во времени (стадии) и по содержанию
(основные потоки работ). Первое измерение представляет статический аспект процесса: оно описано в терминах основных потоков работ
(действия, потоки работ и так далее). Второе измерение представляет динамический аспект процесса, поскольку оно выражено в терминах циклов, стадий, итераций и этапов.
Описание процесса часто выполняется с двух различных точек зрения:
•
Техническая точка зрения, фокусирующаяся на артефактах и представлениях, связанных с разрабатываемым изделием.
•
Организационная точка зрения, фокусирующаяся на времени, бюджете, людях, процессах и других экономических соображениях.
Если целью объектного моделирования является формирование новых прикладных программ, то деловое моделирование есть часть процесса разработки программного обеспечения. Но объектное