Учебный курс Управление внедрением информационных систем Лекция 3 Методология внедрения MSF (Microsoft Solutions Framework) Лектор к.т.н, доцент, заведующий. - презентация

1 Учебный курс Управление внедрением информационных систем Лекция 3 Методология внедрения MSF (Microsoft Solutions Framework) Лектор к.т.н, доцент, заведующий кафедрой проектирования и внедрения информационных систем факультета "Бизнес-информатика" Государственного университета - Высшая школа экономики Грекул Владимир Иванович

2 MSF- Microsoft Solutions Framework Управление процессом создания и внедрения: традиционного программного обеспечения, решений в области электронной коммерции (e commerce), распределенных сетевых приложений (web- distributed applications) других сложных информационных систем.

3 Дисциплины MSF «Модель процессов MSF» «Модель проектной группы MSF» «Дисциплина управления проектами MSF» «Дисциплина управления рисками MSF» «Дисциплина управления подготовкой MSF»

4 MSF- модель процессов Общая характеристика модели процессов MSF Модель проектной группы MSF Исполнение процессов Дисциплина управления проектами MSF

5 Область применения Модель процессов Модель процессов описывает последовательность действий, осуществляемых в ходе реализации любых проектов: ориентированных на фазы (phase-based), основанных на вехах/контрольных точках (milestone-driven) итеративных (iterative).

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

7 Модель ЖЦ решения MSF Особенности модели MSF Подход, основанный на фазах и вехах. Итеративный подход. Интегрированный подход к созданию и внедрению решений. Разработка концепции Планирование Разработка Стабилизация Внедрение

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

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

10 Вехи как ориентиры производственной ответственности Вехи Ведущие ролевые кластеры Концепция утвержденаУправление продуктом Планы проекта утверждены Управление программой Разработка завершенаРазработка, Удовлетворение потребителя Готовность решения утверждена Тестирование, Управление выпуском Внедрение завершеноУправление выпуском

11 Анализ пройденных вех Цель анализа Цель анализа - осмыслить и извлечь уроки из только что завершившейся фазы. собраний Проводится во время специальных собраний (post milestone reviews): собрания, на которых результаты фазы обсуждаются вместе с заказчиком и другими заинтересованными сторонами (milestone reviews), последующее излечение уроков внутри коллектива (post-milestone reviews). постмортемов Окончательные собрания такого рода проводятся уже после завершения проекта. В некоторых организациях они носят название постмортемов (postmortems).

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

13 Создание живой документации - гибкий способ ведения документации. Живые документы Живые документы (living documents) должны изменяться по мере эволюции проекта. Пересмотр функциональности, сетевых графиков работ, планов, спецификаций, требований и других проектных артефактов не прекращается до конца проекта и производится после каждой итерации. Виды документов: описания высокоуровневых подходов (approaches) базовые (предварительные) версии проектных документов на самых ранних этапах (baseline early) детальные планы Все изменения в уже принятые документы в рамках одной итерации (например, утверждённое ТЗ) вносятся посредством компромиссов проектной группы и согласно технологии управления изменениями.Часто имеет смысл отложить эти изменения до следующей версии, дабы не допускать разрастания рамок проекта и срыва сроков сдачи текущей версии.

14 Преимущества интегрированной модели процессов Сосредоточение на нуждах предприятия Предприятия (и в особенности руководители предприятий) обычно рассматривают разработку и внедрение решения как нечто неразделимое. Даже если разработка решения прошла удачно, заказчики не увидят отдачи до тех пор, пока оно не внедрено на предприятии. Улучшение взаимодействия с командой сопровождения Зачастую команда разработчиков создает решение, не уделяя должного внимания вопросам его эксплуатации. Это приводит к низким показателям производительности (performance), доступности (availability) и управляемости (manageability) решения. Интегрированная модель процессов MSF обеспечивает процесс передачи ответственности от команды разработчиков к команде сопровождения сквозь ряд последовательных вех, а не как одномоментный перенос нагрузки.

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

16 Заказчики MSF различает термины: заказчики" заказчики" (customer) - организации или лица, желающие получить от решения бизнес-отдачу потребители потребители (пользователь, user) - люди, сталкивающиеся с работой этого решения в ходе своей профессиональной деятельности. Участие заказчика Участие заказчика является условием успешности IT проектов. MSF предоставляет заказчику широкий спектр возможностей для уточнения и модификации проектных требований и установки контрольных точек (вех) для мониторинга работы над проектом. В свою очередь, это требует затрат времени со стороны заказчика и взятия им на себя определенных обязательств.

17 Заинтересованные стороны Заинтересованные стороны Заинтересованные стороны (stakeholders) – это лица или группы лиц, чьи интересы затрагиваются результатами проекта: Начальники отделов, чей персонал и режим работы будут изменены в результате внедрения разрабатываемого решения. Персонал сопровождения решения, на который будет возложена ответственность за его функционирование, а также персонал сопровождения других приложений, затрагиваемых внедрением решения. Функциональные руководители (functional managers), обеспечивающие проектную группу необходимыми ресурсами.

18 Ролевые кластеры MSF За успех проекта ответственна вся команда, но каждый из ее ролевых кластеров ассоциирован с одной из шести целей и работает над ее достижением: Управление продуктом (product management), Управление программой (program management), Разработка (development), Тестирование (test), Удовлетворение потребителя (user experience) Управление выпуском (release management). Использование ролевых кластеров не подразумевает никакой специальной структуры организации или обязательных должностей.

19 Управление продуктом Ролевой кластер ЦельОбласть компетенции Функции Управление продуктом Удовлетворенные заказчики Маркетинг Бизнес-отдача (бизнес-приоритеты) Представление интересов заказчика Планирование продукта Выступает в роли представителя заказчика Формирует общее видение/рамки проекта Организует работу с требованиями заказчика Развивает сферы применения в бизнесе Формирует ожидания заказчика Определяет компромиссы между параметрами возможности продукта / время / ресурсы Организует маркетинг, PR и евангелизацию Разрабатывает, поддерживает и исполняет план коммуникаций

20 Управление программой Достижение результата в рамках проектных ограничений Управление проектом Выработка архитектуры решения Контроль производственного процесса Административные службы Управляет процессом разработки с целью получения готового продукта в отведенные сроки Формулирует спецификацию продукта и разрабатывает его архитектуру Регулирует взаимоотношения и коммуникацию внутри проектной группы Следит за временным графиком проекта и готовит отчетность о его состоянии Проводит в жизнь важные компромиссные решения Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта Организует управление рисками

21 Разработка Создание продукта в соответствии со спецификацией Технологическое консультирование Проектирование и осуществление реализации Разработка приложений Разработка инфраструктуры Определяет детали физического дизайна Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна Разрабатывает или контролирует разработку элементов Подготавливает продукт к внедрению Консультирует команду по технологическим вопросам

22 Тестирование Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены Планирование тестов Разработка тестов Отчетность по тестам Обеспечивает обнаружение всех дефектов Разрабатывает стратегию и планы тестирования Осуществляет тестирование

23 Удовлетворение потребителя Повышение эффективности пользователя, увеличение потребительской ценности продукта Обеспечение технической поддержки Обучение Эргономика Графический дизайн Интернационализация Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями) Представляет интересы потребителя в команде Организует работу с требованиями пользователя Проектирует и разрабатывает системы поддержки производительности Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта Определяет требования к системе помощи и её содержание Разрабатывает учебные материалы и осуществляет обучение пользователей

24 Управление выпуском Беспроблемное внедрение и сопровождение продукта Инфраструктура Сопровождение Бизнес-процессы Управление выпуском готового продукта Представляет интересы отделов поставки и обслуживания продукта Организует снабжение проектной группы Организует внедрение продукта Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта Организует сопровождение и инфраструктуру поставки Организует логистическое обеспечение проектной группы

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

26 Функциональные группы это подкоманды, существующие внутри ролевых кластеров. Они формируются, когда стоящие перед ролевым кластером задачи столь масштабны, что требуют выделения специальных ресурсов. Основание – разделение стоящих перед ролевым кластером задач, а не потребность ролевого кластера в более чем одном сотруднике!!! Лидеры групп (team leads) - интегрируют свои коллективы в общую проектную деятельность. Они несут ответственность за управление проектом на уровне своих подкоманд.

27 Группы направлений (feature teams) Это компактные мини-команды, образующие матричную организационную структуру. В них входят по одному или несколько членов из разных ролевых кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от проектирования и составления календарного графика.

28 Объединение ролей

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

30 3. Исполнение процессов

31 Фаза выработки концепции Цель Цель – создание и сплочение проектной группы на основе выработки единого видения проекта. Рекомендуемые промежуточные вехи Ядро проектной группы сформировано Черновой вариант концепции проекта составлен Главная веха Главная веха Концепция утвержденаРезультаты Общее описание и рамки проекта (vision/scope document). Документ оценки рисков (risk assessment document). Описание структуры проекта (project structure document).

32 Основные задачи проектной группы на фазе выработки концепции Ролевой кластерФокус Управление продуктомОбщие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта. Управление программойЦели дизайна; концепция решения; структура проекта. РазработкаПрототипирование; анализ технологических возможностей; анализ осуществимости. Удовлетворение потребителяНеобходимые эксплуатационные характеристики решения и их влияние на его разработку. ТестированиеСтратегии тестирования; критерии приемлемости, их влияние на разработку решения. Управление выпускомТребования внедрения и их влияние на разработку решения; требования сопровождения. - создание ядра проектной группы, подготовка документа общего описания и рамок проекта (vision/scope document), оценка рисков. Видение (vision) –ничем не ограничиваемое представление о том, каким должно быть решение. Рамки (scope) - дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.

33 Фаза планирования Главная веха Главная веха Планы проекта утверждены Результат Результат – базовая версия проекта (project baseline): Функциональная спецификация. План управления рисками. Сводный план и сводный календарный график проекта. Рекомендуемые промежуточные вехи Верификация технологий Базовая версия функциональной спецификации создана Базовая версия сводного плана проекта создана Базовая версия сводного календарного графика проекта создана Среды разработки и тестирования развернуты Цель Цель – разработка планов проекта

34 Основные задачи проектной группы на фазе планирования Ролевой кластерФокус Управление продуктомКонцептуальный дизайн; анализ бизнес-требований; коммуникационный план. Управление программойКонцептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет. РазработкаОценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates). Удовлетворение потребителяСценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение. ТестированиеОценка дизайна; требования тестирования; план и календарный график тестирования. Управление выпускомОценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения.

35 Фаза разработки Цель Цель - создание компонент решения (включая как документацию, так и программный код). Рекомендуемые промежуточные вехи Концепция подтверждена Билд n завершен, билд n+1 завершен Главная веха Главная веха Разработка завершенаРезультаты Исходный и исполнимый код приложений. Скрипты установки и конфигурирования. Окончательная функциональная спецификация. Материалы поддержки решения. Спецификации и сценарии тестов.

36 Основные задачи проектной группы на фазе разработки Ролевой кластерФокус Управление продуктомОжидания заказчика. Управление программойУправление функциональной спецификацией; мониторинг проекта; доработка планов. РазработкаРазработка программного кода и инфраструктуры; документирование конфигураций. Удовлетворение потребителя Обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн. ТестированиеФункциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования. Управление выпускомЧеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists).

37 Фаза стабилизации Цель Цель - тестирование и отладка разработанного решения в реалистичной модели производственной среды. Рекомендуемые промежуточные вехи Точка конвергенции Точка достижения нуля Версии-кандидаты Контрольное тестирование завершено Тестирование приемлемости для потребителей завершено Пилотное внедрение завершено

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

39 Точка достижения нуля – это момент, когда впервые все выявленные ошибки оказываются устраненными. Вслед за ней пики количества активных ошибок должны становиться все меньше, вплоть до полного угасания в момент, когда решение уже достаточно стабильно для выпуска первой версии кандидата. Точка достижения нуля показывает, что проектная группа приближается к созданию стабильной версии кандидата (release candidate).

40 Версии-кандидаты Каждая версия-кандидат имеет полный набор составляющих, необходимых для внедрения решения в производство. Создание версии-кандидата служит тестом готовности решения к выпуску, то есть проверяет готовность всех его составляющих. Период тестирования, следующий за созданием каждой версии-кандидата, определяет, пригодна ли созданная версия к внедрению, или же проектная группа должна подготовить новую версию-кандидат, исправляющую недостатки предыдущей. Тестирование версий-кандидатов, проходящее внутри проектной группы, требует высокой степени концентрации и интенсивности работы и фокусируется на выявлении критических накладок (showstopper bugs). Тестирование сопряжено с процессом приоритезации всех нововыявленных ошибок, необходимым для организации их устранения. Маловероятно, что первая версия-кандидат окажется заключительной. Как правило, при интенсивном тестировании версий-кандидатов будут выявлены накладки. Свойства:

41 Контрольное тестирование завершено Проектная группа должна: Оценить результаты тестирования в соответствии с имеющимися критериями успешности. Подготовить среду внедрения. Создать необходимые для внедрения процедуры, скрипты и массивы данных (load sets). Иметь готовые учебные материалы. Обеспечить условия для сопровождения решения. Создать и протестировать план отката (rollback plan). Результаты полной уверенности в готовности и отлаженности всего, что необходимо для внедрения решения.

42 Тестирование приемлемости для потребителей завершено Тестирование приемлемости для потребителей (user acceptance testing) и исследование эргономичности (usability studies) выполняются начиная с фазы разработки и продолжаются на протяжении фазы стабилизации. цель – убедиться в том, что новая система отвечает требованиям потребителей и бизнеса. Цель – убедиться в том, что новая система отвечает требованиям потребителей и бизнеса.

43 Пилотное внедрение завершено Пилотный релиз (pilot release) – это внедрение решения в часть производственной среды или для части пользователей. Проектная группа тестирует решение целиком в среде, максимально приближенной к производственным условиям. Перед выпуском пилотной версии ее испытатели и проектная группа должны определить критерии успеха пилотного внедрения. Они должны соответствовать общим критериям успеха разработки. Все выявленные проблемы должны быть улажены либо доработкой кода, либо документированием обходных путей (work-arounds) для персонала внедрения и сопровождения, либо же включением соответствующего материала в сопроводительные руководства и учебные курсы. К моменту начала работы пилотной версии должна быть создана инфраструктура сопровождения. Это может потребовать обучения персонала сопровождения. Процедуры разрешения проблем пилотной версии могут сильно отличаться от тех, что будут использоваться во время окончательного внедрения и полноценной эксплуатации решения. Чтобы проверить работоспособность процесса внедрения, необходимо провести пробное испытание для каждого из его элементов. Это поможет заблаговременно выявить трудности внедрения.

44 Действия после завершения пилотного внедрения Шаг вперед: пилотное внедрение нового релиза. Откат назад: выполняется план отката, и пилотная группа возвращается к конфигурациям, существовавшим до пилотного внедрения. Позднее попытка пилотного внедрения будет повторена вновь с более стабильной версией решения. Приостановка: пилотная версия замораживается. Исправление и продолжение: пилотная группа получает заплату (patch) к существующему коду. Переход к фазе внедрения.

45 Главная веха Главная веха Готовность решения утверждена Результаты Окончательный продукт (golden release). Документация выпуска (release notes). Материалы поддержки решения. Результаты и инструментарий тестирования. Исходный и исполнимый код приложений. Проектная документация. Анализ пройденной фазы (milestone review).

46 Основные задачи проектной группы на фазе стабилизации Ролевой кластерФокус Управление продуктомИсполнение коммуникационного плана; планирование премьеры продукта. Управление программойМониторинг проекта; приоритезация ошибок. РазработкаУстранение ошибок; оптимизация программного кода. Удовлетворение потребителя Доработка эксплуатационных руководств; учебные материалы. ТестированиеТестирование; сообщение об ошибках и их статусе; тестирование конфигурации. Управление выпускомРазвертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения.

47 Фаза внедрения Цель Цель – передача системы персоналу поддержки и сопровождения, получение окончательного одобрения результатов проекта со стороны заказчика. Рекомендуемые промежуточные вехи Ключевые компоненты развернуты Внедрение на местах завершено Внедренное решение стабилизировано

48 Главная веха Главная веха Внедрение завершеноРезультаты Информационные системы эксплуатации и поддержки. Процедуры и процессы. Базы знаний, отчеты, журналы протоколов (logbooks). Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта. Отчет о завершении проекта (project close-out report). Окончательные версии всех проектных документов. Показатели удовлетворенности заказчика и потребителей. Описание последующих шагов.

49 Основные задачи проектной группы на фазе внедрения Ролевой кластерФокус Управление продуктомПолучение отзывов и оценок заказчика; акт о приеме выполненной работы. Управление программойСопоставление рамок проекта с поставленным решением; управление стабилизацией. РазработкаРазрешение проблем; поддержка эскалации. Удовлетворение потребителя Обучение; управление календарным графиком обучения. ТестированиеТестирование производительности. Управление выпускомУправление внедрением; одобрение изменений.

50 4. Дисциплина управления проектами MSF

51 Отличительные особенности управления проектами MSF Одной из основных характеристик MSF является отсутствие должности менеджера проекта. Носителем профессиональных управленческих навыков и организатором работы команды в MSF является ролевой кластер Управление программой. Типовые управленческие обязанности распределяются среди лидеров всех ролевых кластеров проектной группы. Ответственность за управление проектом распределена среди лидеров ролевых кластеров внутри команды. Профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней.

52 Характеристики управления проектами MSF Большая часть ответственности по менеджменту проекта возлагается на ролевой кластер Управление программой. (области компетенции: Управление проектом, Выработка архитектуры решения, Контроль производственного процесса и Административные службы) В больших проектах, использующих масштабированную модель проектной команды, деятельность по управлению проектами осуществляется на многих уровнях. Для некоторых больших и сложных проектов требуется наличие специалиста или группы по управлению проектами. По мере роста объема и сложности проекта в ролевом кластере Управление программойкластере выделяются две ветви специализации: работа над архитектурой/спецификациями и управление проектом.

53 Масштабирование функций управления проектом

54 Распределение обязанностей по управлению проектом

55 Определение рамок (scope definition) на этапе планирования Во время фазы планирования общий объем работы над проектом должен быть разбит на меньшие, более простые и легко исполнимые части. Этот процесс выявляет некоторые области, выходящие за рамки проекта. С ними обычно связаны риски неоднозначного толкования. Управление изменениями рамок (scope change control) начинается с момента выработки их базовой версии. Изменения рамок проекта или решения могут быть приняты только лишь после их рассмотрения и одобрения как проектной группой, так и заказчиком. Полноценное управление рамками включает в себя принятие компромиссных решений. Используемые в MSF треугольник компромиссов (trade-off triangle) и матрица компромиссов (trade-off matrix) облегчают управление изменениями.

56 Матрица компромиссов (trade-off matrix) отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях. Она помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка Фиксируется), фактор, являющийся в проекте приоритетным (колонка Согласовывается), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка Принимается).

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

58 Неопределенность и точность оценок