Учебный курс «Технологии программирования. Курс на базе Microsoft Solutions Framework (msf)» для подготовки по направлению «Информационные технологии»
Скачать 167.96 Kb.
|
| Федеральное агентство по образованию РФ ГОУ ВПО Нижегородский государственный университет им. Н.И. Лобачевского Факультет Вычислительной математики и кибернетики Кафедра Математического обеспечения ЭВМ УЧЕБНЫЙ КУРС «Технологии программирования. Курс на базе Microsoft Solutions Framework (MSF)» для подготовки по направлению «Информационные технологии» Нижний Новгород 2006 СодержаниеЛЕКЦИЯ 6. Методология Microsoft Solutions Framework. Управление рисками. Модель процессов 1 1. Вспоминая предыдущую лекцию 3 2. Управление рисками в MSF for Agile Software Development 3 3. Модель процессов MSF for Agile Software Development 8 4. Что дальше? 13 5. Литература 14 ^ Наша предыдущая лекция была посвящена введению в методологию Microsoft Solutions Framework. Мы обсудили, что такое методология вообще. Поговорили о том, чем является и чем не является MSF. В чем она схожа с другими методологиями и чем отличается от них. Перечислили и кратко охарактеризовали концепции MSF: модель процессов, управление проектом, модель проектной группы, управление рисками. Далее мы дали краткую историческую справку по MSF и указали нововведения последней версии MSF 4.0. Наконец, мы подробно остановились на модели проектной группы MSF и рассмотрели принципы формирования команды, роли и ролевые группы, которые выделяет MSF, их задачи и зоны ответственности. ^ Дисциплина управления рисками MSF возводит процесс управления рисками в ранг стратегической задачи, затрагивающей все фазы проекта. В рамках MSF управление рисками – это процесс выявления, анализа и превентивной работы над рисками в целях избежания их превращения в проблемы, приносящие ущерб или иной вред. В ходе всего проекта команда должна уделять внимание дисциплине управления рисками. Основные ее характеристики:
Прежде всего, определим, что такое “риск”. Заглянем в “Толковый словарь русского языка” С.И. Ожегова. “Риск – 1. Возможность опасности, неудачи. 2. Действие наудачу в надежде на счастливый исход” [12]. Отметим, что понятие “риск” включает в себя два по сути противоположных толкования: одно со знаком минус, второе со знаком плюс. Риск проекта (project risk) понимается в MSF именно в таком полном виде – как всякое событие или условие, которое может оказать как негативное, так и позитивное влияние на итоги проекта. Такое же расширенное понимание спекулятивного риска (speculative risk) присутствует, например, в финансовой индустрии, где решения в условиях неопределенности могут привести к получению прибыли точно так же, как и к убыткам. Указанное понимание противоположно понятию чистого риска (pure risk) в индустрии страхования, где неопределенности связываются только лишь с потенциальными убытками в будущем. Важно отметить, что риски не есть проблемы. Проблемы – это нечто, имеющие место в настоящее время, в то время как риски относятся к будущему и носят вероятностный характер (могут и не состояться). Однако риски могут стать проблемами, если ими эффективно не управлять. Цель управления рисками – максимизировать их положительное влияние (открывающиеся возможности), но при этом минимизировать связанные с ними негативные факторы (убытки). Дисциплина управления рисками в MSF основана на убеждении, что такое управление должно выполняться превентивно; это часть формального и систематического процесса, трактующего усилия, затрачиваемые на управление рисками, с позитивной точки зрения. Говоря о рисках, MSF выделяет несколько ключевых концепций:
Во время проектных фаз выработки концепции и планирования (изучению этих фаз будет посвящена лекция 7) проектная группа должна разработать формальный документ, описывающий управление рисками в проекте. В этом документе должны быть даны ответы на целый ряд вопросов, из которых здесь мы рассмотрим основные.
Часть вопросов, которые также должны быть учтены, мы сознательно опустили – интересующихся отсылаем к соответствующей белой книге [2]. Поскольку риски являются неотъемлемой частью всех фаз всех проектов от начала и до конца, должны быть изначально выделены и должным образом распределены ресурсы, необходимые для эффективного управления рисками. Планирование управления рисками осуществляется проектной группой во время фаз выработки концепции и планирования, и результирующий план управления рисками должен определять конкретные действия, ответственность за которые возложена на определенных членов проектной группы. Эти задачи должны быть интегрированы в сводный план проекта (master project plan) и в сводный календарный график проекта (master project schedule). ^ Дисциплина управления рисками MSF отстаивает превентивное управление рисками, непрерывную оценку имеющихся рисков и интеграцию этих процессов в общую деятельность по принятию решений на протяжении всего жизненного цикла проекта или бизнес-процесса. Процесс управления рисками MSF определяет шесть логических шагов, посредством которых проектная группа управляет текущими рисками, разрабатывает и исполняет стратегии управления рисками и извлекает уроки из своего опыта для использования на уровне всего предприятия.  Рис. 6.1. Процесс управления рисками MSF. Источник: белая книга [2] Выявление рисков (risk identification) – этап, позволяющий членам проектной группы вынести на обсуждение всей команды факты наличия рисков. Выявление рисков является начальной стадией процесса управления ими. Оно должно быть осуществлено как можно раньше, и к нему необходимо постоянно возвращаться на протяжении всего жизненного цикла проекта. Анализ рисков (risk analysis) – этап преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритезация рисков (risk prioritization) позволяет проектной группе управлять наиболее важными из них, выделяя для этого необходимые ресурсы. Планирование рисков (risk planning) выполняется исходя из информации, полученной на этапе их анализа, и имеет целью выработку стратегий, планов и конкретных шагов. Календарное планирование рисков (risk scheduling) интегрирует эти планы в повседневный процесс управления проектом, обеспечивая непрерывность управления рисками. Эта стадия напрямую увязывает планирование рисков с планированием проекта в целом. Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов. Мониторингу должны быть подвергнуты сделанные оценки вероятности (probability) риска, его угрозы (impact), ожидаемая величина риска (exposure) и прочие факторы, способные повлиять на приоритет рисков. Наблюдению подвергаются также составленные планы, имеющиеся ресурсы и принятый календарный график. Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения. Этот процесс также включает в себя инициирование изменений всего проекта (project change control requests), если изменения в состоянии рисков либо в соответствующих планах влияют на прогнозируемый объем работы, требуемые ресурсы или сроки. Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта. Необходимо отметить, что описанные этапы являются логическими шагами и не обязательно должны следовать друг за другом в строгом хронологическом порядке. Проектные группы могут циклически повторять шаги выявления-анализа-планирования по мере обнаружения дополнительных факторов, влияющих на проект. ^ Процесс управления рисками в MSF тесно интегрирован с общим жизненным циклом проекта. Оценка рисков может быть начата даже на этапе выработки концепций, поскольку в этот момент проектная группа и заинтересованные стороны начинают формировать видение проекта, его границ и рамок. По результатам анализа и планирования рисков необходимые планы по предотвращению и смягчению последствий должны быть сразу включены в календарный график проекта и его сводный план. В ходе выполнения проекта команда постоянно проводит мониторинг рисков, осуществляет необходимые корректирующие действия в соответствии с расписанием и планом проекта, и при наступлении связанных с триггерами рисков событий. Действия по выявлению и анализу новых рисков могут проводиться по достижении вех (milestones) проекта (подробнее о вехах далее в этой лекции). Также в этот момент можно резюмировать извлеченные уроки. По ходу проекта тип рисков, которым уделяется внимание, также должен изменяться. На ранних этапах доминируют риски связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. С течением времени начинают играть важную роль технологические риски, связанные с реализацией проекта. Затем внимание переходит к рискам поддержки и сопровождения. Для организации деятельности по выявлению рисков в моменты основных фазовых переходов полезно использовать контрольные перечни (checklists) и классификации рисков. ^ Вернемся к учебному примеру “Система бронирования билетов для авиакомпании”. Выделим некоторые возможные риски.
Мы выделили не так уж и много рисков, однако можно заметить, что они происходят из самых разных областей и связаны с людьми (риск №3), с процессами (риски №1, №8, №10), с технологиями (риск №2), с внешними условиями (риски №5, №6), с заказчиком (риски №4, №7, №9). Помимо представленных риски могут иметь и другие источники. Далее MSF рекомендует для каждого риска представить формулировку – выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта и потенциально возможным, еще не случившимся событием или ситуацией. Первая часть формулировки риска называется условием (condition) и содержит описание существующего фактора или особенности проекта, которые, по мнению проектной группы, могут сделать результат проекта убыточным либо же сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется (по)следствием (consequence). Она описывает ту нежелательную ситуацию, которой следует избежать. В качестве примера представим формулировки некоторых выявленных выше рисков.
^ Модель процессов MSF представляет общую методологию разработки и внедрения IT- решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral).    Рис. 6.2. Модели процесса (слева направо): каскадная, спиральная, MSF. Источник: белая книга [1] Процесс MSF ориентирован на “вехи” (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Модель процессов MSF учитывает постоянные изменения проектных требований. Она исходит из того, что разработка решения должна состоять из коротких циклов, создающих поступательное движение от простейших версий решения к его окончательному виду. ^ 3.1.1.Взаимодействуйте с “заказчиками”MSF настаивает на непрерывном взаимодействии с заказчиком в ходе всей работы над проектом. Удовлетворенный заказчик – главный приоритет проектной группы. Понимание бизнес-отдач заказчика от проекта, потребностей его будущих пользователей требует максимальной полной вовлеченности заказчика в процесс создания решения. ^ Модель процессов MSF считает очень важным открытый обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат, но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности. Естественно речь здесь не идет об информации финансовой или имеющей статус коммерческой или иной тайны. ^ Успех коллективной работы над проектом немыслим без наличия у членов проектной группы и заказчика единого видения (shared vision), т.е. четкого, и, самое главное, одинакового, понимания целей и задач проекта. Изначально понимание того, что должно быть достигнуто в ходе работы над проектом, у заказчика может (и нередко) не совпадать с пониманием проектной группы. Лишь наличие единого видения способно внести ясность и обеспечить движение всех заинтересованных в проекте сторон к общей цели. Формирование единого видения и последующее следование ему являются столь важными, что модель процессов MSF выделяет для этой цели специальную фазу (фаза “Выработка концепции”), которая заканчивается соответствующей вехой. ^ MSF настаивает на том, что каждый участник проектной группы должен ощущать ответственность за качество разрабатываемого решения. Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой. Несмотря на наличие в команде ролевых групп “Удовлетворение потребителя” и “Тестирование”, прямая задача которых – следить за качеством решения и повышать его, все остальные ролевые группы также постоянно должны иметь в виду нужды конечного пользователя. ^ MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности. Проектная группа должна быть готова к переменам, и методология MSF предоставляет эффективный инструментарий для адекватной и своевременной реакции на изменения в проектной среде. ^ Каждая итерация, каждая фаза процесса создания решения должна заканчиваться некоторым зримым результатом, некоторой вехой (milestone). Наличие вех позволяет проектной группе и заказчику видеть движение проекта вперед. ^ Работа проектной группы в идеале должна быть построена так, чтобы при возникновении такой потребности у заказчика текущее состояние разрабатываемого решения могло быть немедленно внедрено (естественно с той функциональностью, которая в данный момент реализована). Это означает, что итерации работы над проектом должны быть максимально короткими, и в каждый момент времени должна существовать текущая работоспособная версия решения. Такой подход дает возможность раннего обнаружения рисков, ошибок, пропущенных или недопонятых требований, дает возможность своевременно получать обратную реакцию от заказчика, а, значит, сокращает затраты. ^ В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения (trade-offs). ^ Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник компромиссов (tradeoff triangle).  Рис. 6.3. Треугольник компромиссов. Источник: белая книга [1] После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне. Нахождение верного баланса между ресурсами, временем разработки и возможностями – ключевой момент в построении решения, должным образом отвечающего нуждам заказчика. ^ Другое полезное средство управления проектными компромиссами – матрица компромиссов проекта (project tradeoff matrix). Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях. Возможный вариант такой матрицы представлен на рисунке.  ^ Матрица компромиссов помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка “Фиксируется”), фактор, являющийся в проекте приоритетным (колонка “Согласовывается”), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка “Принимается”). ^ Модели процессов описывают последовательность действий, осуществляемых в ходе реализации проекта. Можно сказать, что они задают тем самым жизненный цикл проекта. Спектр моделей, применяемых в настоящее время различными организациями, весьма широк. Среди них есть и модель процессов MSF, возникшая на основе используемого в компании Microsoft подхода к разработке программных приложений. В результате своего развития она объединила ряд наиболее эффективных принципов других известных моделей процессов, сформировав при этом единую базу для работы над проектами любых типов: ориентированных на фазы (phase-based), основанных на вехах/контрольных точках (milestone-driven) и итеративных (iterative). ^ MSF for Agile Software Development поддерживает быструю итеративную разработку. Проектирование, разработка, тестирование выполняются в перекрывающих друг друга итерациях, каждая из которых фокусируется на реализации отдельных аспектов решения.  Рис. 6.5. Итерации процесса разработки. Источник: MSF for Agile Software Development Process Guidance [11] Короткие итерации позволяют свести к минимуму влияние ошибок в понимании и формулировании требований, дают быструю обратную реакцию о точности проектных планов. Каждая итерация должна завершаться получением результата в виде стабильной части целого продукта. ^ На каждом уровне процесса создания решения MSF предполагает цикличность. Создание версии продукта – цикл из итераций. Итерация – цикл из ежедневно собираемых билдов. Билд – цикл изменений, вносимых в систему контроля версий.  Рис. 6.6. Циклы процесса разработки. Источник: MSF for Agile Software Development Process Guidance [11] ^ Модель MSF покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Весь процесс создания решения разбит на пять фаз. Каждая из них заканчивается главной вехой, результаты которой становятся видимыми за пределами проектной команды.  Рис. 6.7. Фазы и вехи модели процессов MSF. Источник: белая книга [1] Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых групп. В рамках фазы обычно присутствуют промежуточные вехи, обозначающие достигнутые промежуточные результаты. MSF дает определенные рекомендации (будут рассмотрены при изучении соответствующих фаз) относительно промежуточных вех на каждой фазе, однако проектная команда может сформировать свои специфические для проекта и фазы промежуточные вех. ^
1 Раздел подготовлен на основе материалов белой книги [2]. 2 Раздел подготовлен на основе материалов белой книги [1] и руководства [11]. |
Добавить документ в свой блог или на сайт
Похожие:
 | Лекция методология Microsoft Solutions Framework. Выработка концепции. Планирование | | Лекция методология Microsoft Solutions Framework. Разработка. Стабилизация. Внедрение |
| Лекция методология Microsoft Solutions Framework. Введение. Версии. Модель проектной группы | | Лекции 3 Визуальное моделирование при анализе и проектировании. Основы Unified Modeling Language (uml) |
| ... | | Спецкурс «Информационные технологии в сфере экономики и бизнеса» ориентирован на классы с экономическим профилем обучения. Данный... |
| Зачем нужно распределенное исполнение, какова его славная история и зачем вообще нужна wcf. Мы рассмотрим предшествующие и существующие... | | Зачем нужно распределенное исполнение, какова его славная история и зачем вообще нужна wcf. Мы рассмотрим предшествующие и существующие... |
| Специализированный краткосрочный учебный курс «Информационные технологии в сфере местного самоуправления» | | Специализированный краткосрочный учебный курс «Информационные технологии в сфере местного самоуправления» |