Файл: 1 разработка сценария внедрения.pdf

64
Если для создания сетевой диаграммы используются про- граммные средства поддержки управления проектом, каждый этап должен заканчиваться контрольной отметкой. Очередной этап может начаться только тогда, когда будет получена кон- трольная отметка (которая может зависеть от нескольких пред- шествующих этапов). Поэтому в третьем столбце таблицы 3.2 приведены контрольные отметки; они будут достигнуты только тогда, когда будет завершен этап, в строке которого помещена соответствующая контрольная отметка.
Любой этап не может начаться, пока не выполнены все эта- пы на всех путях, ведущих от начала проекта к данному этапу.
Например, этап Т9 не может начаться, пока не будут завершены этапы ТЗ и Т6. Отметим, что в данном случае достижение кон- трольной отметки М4 говорит о том, что эти этапы завершены.
Минимальное время выполнения всего проекта можно рас- считать, просуммировав в сетевой диаграмме длительности эта- пов на самом длинном пути (длина пути здесь измеряется не ко- личеством этапов на пути, а суммарной длительностью этих эта- пов) от начала проекта до его окончания (это так называемый критический путь). В нашем случае продолжительность проекта составляет 11 недель или 55 рабочих дней. На рисунке 3.3 крити- ческий путь показан более толстыми линиями, чем остальные пу- ти. Таким образом, общая продолжительность реализации проек- та зависит от этапов работ, находящихся на критическом пути.
Любая задержка в завершении любого этапа на критическом пути приведет к задержке всего проекта.
Задержка в завершении этапов, не входящих в критический путь, не влияет на продолжительность всего проекта до тех пор, пока суммарная длительность этих этапов (с учѐтом задержек) на каком-нибудь пути не превысит продолжительности работ на критическом пути. Например, задержка этапа Т8 на срок, мень- ший 20 дней, никак не влияет на общую продолжительность про- екта. На рисунке 3.4 представлена временная диаграмма, на кото- рой показаны возможные задержки на каждом этапе.

65
Рисунок 3.4 – Временная диаграмма длительности этапов
Сетевая диаграмма позволяет увидеть в зависимости этапов значимость того или иного этапа для реализации всего проекта.
Внимание к этапам критического пути часто позволяет найти способы их изменения с тем, чтобы сократить длительность всего проекта. Менеджеры используют сетевую диаграмму для распре- деления работ.
На рисунке 3.4 показано другое представление графика ра- бот. Это временная диаграмма (иногда называемая по имени ее изобретателя диаграммой Гантта) может быть построена про- граммными средствами поддержки процесса управления. Она по- казывает длительность выполнения каждого этапа и возможные их задержки (показаны затененными прямоугольниками), а также даты начала и окончания каждого этапа. Этапы критического пу- ти не имеют затененных прямоугольников; это означает, что за- держка с завершением данных этапов приведет к увеличению длительности всего проекта.
Подобно распределению времени выполнения этапов, ме- неджер должен рассчитать распределение ресурсов по этапам, в частности назначить исполнителей на каждый этап. В таблице 3.3 приведено распределение разработчиков на каждый этап, пред- ставленный на рисунке 3.4.

66
Таблица 3.3 – Распределение исполнителей по этапам
Этап
Исполнитель
Т1
Джейн
Т2
Анна
Т3
Джейн
Т4
Фред
Т5
Мэри
Т6
Анна
Т7
Джим
Т8
Фред
Т9
Джейн
Т10
Анна
Т11
Фред
Т12
Фред
Приведенная таблица может быть использована программ- ными средствами поддержки процесса управления для построе- ния временной диаграммы занятости сотрудников на определен- ных этапах работ (рисунок 3.5). Персонал не занят в работе над проектом все время его реализации. В течение периода незанято- сти сотрудники могут быть в отпуске, работать над другими про- ектами, проходить обучение и т. д.
Рисунок 3.5 – Временная диаграмма распределения работников по этапам

67
В больших организациях обычно работает много специали- стов, которые задействуются в проекте по мере необходимости.
Конечно, такой подход может создать определенные проблемы для менеджеров проектов. Например, если специалист занят в проекте, который задерживается, это может создать прямые сложности для других проектов, где он также должен участво- вать.
Первоначальный график работ неизбежно содержит какие- нибудь ошибки или недоработки. По мере реализации проекта рассчитанные оценки длительности выполнения этапов работ должны сравниваться с реальными сроками выполнения этих этапов. Результаты сравнения должны использоваться в качестве основы для пересмотра графика работ еще не реализованных эта- пов проекта, в частности для того, чтобы попытаться уменьшить длительность этапов критического пути.
3.2.5 Управление рисками
Важной частью работы менеджера проекта является оценка рисков, которые могут повлиять на график работ или на качество создаваемого программного продукта, и разработка мероприятий по предотвращению рисков. Результаты анализа рисков должны быть отражены в плане проекта. Определение рисков и разработ- ка мероприятий по уменьшению их влияния на ход выполнения проекта называется управлением рисками.
Упрощенно риск можно понимать как вероятность проявле- ния каких-либо неблагоприятных обстоятельств, негативно влияющих на реализацию проекта. Риски могут угрожать проекту в целом, создаваемому программному продукту или организации- разработчику. Можно выделить три типа рисков.
1. Риски для проекта, которые влияют на график работ или ресурсы, необходимые для выполнения проекта.
2. Риски для разрабатываемого продукта, влияющие на ка- чество или производительность разрабатываемого программного продукта.
3. Бизнес-риски, относящиеся к организации-разработчику или поставщикам.

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

69
Продолжение таблицы 3.4
Риск
Типы риска
Описание риска
Задержка в разработке спецификации
Риск для проекта и для разрабатывае- мого продукта
Спецификации основных интерфейсов подсистем не поступили к разработ- чикам в соответствии с графиком работ
Недооценка размера разрабатываемой сис- темы
Риск для проекта и для разрабатывае- мого продукта
Размер системы значи- тельно превысил перво- начальную оценку
Недостаточная эффек- тивность
CASE- средств
Риск для разрабаты- ваемого продукта
CASE-средства, предна- значенные для поддержки проекта, оказались менее эффективными, чем ожи- далось
Изменения в техноло- гии разработки ПО
Бизнес-риск
Основные технологии по- строения программной системы заменяются но- выми
Появление конкури- рующего программно- го продукта
Бизнес-риск
На рынке программных продуктов до окончания проекта появилась конку- рирующая программная система
Схема процесса управления рисками показана на рисун- ке 3.6. Этот процесс состоит из четырех стадий.
1. Определение рисков. Определяются возможные риски для проекта, для разрабатываемого продукта и бизнес-риски.
2. Анализ рисков. Оценивается вероятность и последова- тельность появления рисковых ситуаций.
3. Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект.
4. Мониторинг рисков. Постоянное оценивание вероятно- стей рисков и выполнение мероприятий по смягчению последст- вий проявления рисковых ситуаций.

70
Рисунок 3.6 – Процесс управления рисками
Процесс управления рисками, как и другие процессы плани- рования, является итерационным, выполняемым в течение всего срока реализации проекта. Сначала разрабатываются планы управления рисками, затем постоянно отслеживается ситуация вокруг реализации проекта. При поступлении новой информации о возможных рисках заново проводится анализ рисков и перво- степенное внимание уделяется новым рискам. По мере поступле- ния новой информации также изменяются планы мероприятий по предотвращению и смягчению рисков.
Результаты процесса управления рисками документируются в виде планов управления рисками. Они должны включать опи- сание возможных проектных рисков, их анализ и перечень меро- приятий, необходимых для управления рисками.
Определение рисков – первая стадия процесса управления рисками. На этой стадии описываются риски, которые могут про- явиться при реализации проекта. В принципе на этой стадии не должна оцениваться вероятность и значимость рисков, но на практике маловероятные риски с незначительными последствия- ми обычно отбрасываются сразу.
Определение рисков может выполняться в режиме команд- ной работы с использованием подхода «мозговой штурм» либо основываться на опыте менеджера. При определении рисков мо- жет помочь приведенный ниже список возможных категорий рисков.
1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается сис- тема.
2. Риски, связанные с персоналом. Связаны с членами ко- манды разработчиков.

71 3. Организационные риски. Проистекают из организацион- ного окружения, в котором выполняется проект.
4. Инструментальные риски. Связаны с используемыми
CASE-средствами и другими средствами поддержки процесса создания ПО.
5. Риски, связанные с системными требованиями. Прояв- ляются при изменении требований, предъявляемых к разрабаты- ваемой системе.
6. Риски оценивания. Связаны с оцениванием характери- стик программной системы и ресурсов, необходимых для реали- зации проекта.
В таблице 3.5 представлены некоторые примеры, относя- щиеся к каждой из описанных категорий рисков. Результатом этапа определения рисков будет длинный список возможных рисков, которые могут повлиять на разрабатываемый программ- ный продукт, проект или организацию-разработчика.
Таблица 3.5 – Категории рисков
Категория рисков
Примеры рисков
Технологические риски
База данных, которая используется в программ- ной системе, не обеспечивает обработку ожидае- мого объема транзакций.
Программные компоненты, которые используют- ся повторно, имеют дефекты, ограничивающие их функциональные возможности
Риски, связанные с персоналом
Невозможно подобрать работников с требуемым профессиональным уровнем.
Ведущий разработчик заболел в самое критиче- ское время.
Невозможно организовать необходимое обучение персонала

72
Продолжение таблицы 3.5
Категория рисков
Примеры рисков
Организационные риски
В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего из- менились приоритеты в управлении проектом.
Финансовые затруднения в организации привели к уменьшению бюджета проекта
Инструментальные риски
Программный код, генерируемый
CASE- средствами, не эффективен.
CASE-средства невозможно интегрировать с дру- гими средствами поддержки проекта
Риски, связанные с системными требова- ниями
Изменения требований приводят к значительным повторным темным требованиям к работам по проектированию системы.
Первоначальная нечеткая формулировка пользо- вательских требований привела к значительным изменениям системных требований, проявивших- ся на поздних стадиях разработки проекта
Риски оценивания
Недооценки времени выполнения проекта.
Скорость выявления дефектов в системе ниже ранее запланированной.
Размер системы значительно превышает перво- начально рассчитанный
При анализе для каждого определенного риска подсчитыва- ется вероятность его проявления и ущерб, который он может на- нести. Не существует простых методов выполнения анализа рис- ков – в значительной мере он основан на мнении и опыте менед- жера. Можно привести следующую шкалу вероятностей рисков и их последствий.
1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до
25%; средней при значениях от 25 до 50%; высокой, если значе- ние колеблется от 50 до 75%; очень высокой при значениях более
75%.
2. Возможный ущерб от рисковых ситуаций можно подраз- делить на катастрофический, серьезный, терпимый и незначи- тельный.
Результаты анализа рисков должны быть представлены в виде таблицы рисков, упорядоченных по степени возможного

73 ущерба. В таблице 3.6 приведен упорядоченный список рисков, описанных в таблице 3.5, там же указаны вероятности этих рис- ков. Здесь вероятности рисков и степень ущерба от них указаны произвольно. На практике для их определения необходима под- робная информация о проекте, технологии создания ПО, команде разработчиков и о самой организации.
Таблица 3.6 – Список рисков после проведения их анализа
Риск
Вероятность
Степень ущерба
Финансовые затруднения в органи- зации привели к уменьшению бюд- жета проекта
Низкая
Катастрофиче- ская
Невозможно подобрать работников с требующимся профессиональным уровнем
Высокая
Катастрофиче- ская
Ведущий разработчик заболел в са- мое критическое время
Средняя
Серьезная
Программные компоненты, исполь- зуемые повторно, имеют дефекты, ограничивающие их функциональ- ные возможности
Средняя
Серьезная
Изменения требований приводят к значительным повторным работам по проектированию системы
Средняя
Серьезная
В организации, выполняющей раз- работку ПО, произошла реорганиза- ция, в результате чего изменились приоритеты в управлении проектом
Высокая
Серьезная