970

120	2. Организация бизнеса

2.3.2.Содержательные модели структурной декомпозиции проекта

Структура декомпозиции работ проекта (Work Breakdown Structure, WBS) является ключевым элементом в процессах пре-

одоления сложности программных систем. Сложные проекты выполняются коллективами разработчиков, что вызывает необходимость наличия определенных методик декомпозиции проекта на отдельные работы (задания), выполняемые командой проекта,

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

иконкретного проекта.

Всуществующих стандартах нет четких рекомендаций по способам выделения элементов следующего уровня при декомпозиции. Переход от чисто эмпирического умозрительного подхода деления целого на части к формализованному возможен при использовании формальных моделей декомпозиции. Для дальнейшего изложения материала введем следующие определения [30]:

декомпозиция — процедура формального разбиения проекта на составляющие его элементы (разбиение целого на части);

модель декомпозиции — набор формальных элементов, обеспечивающих однозначное разбиение целого на части.

Для однозначного определения множества элементов декомпозиции предполагается использовать три вида моделей:

1) модель состава, предназначенную для определения формального набора элементов проекта в целом либо его отдельных частей;

2) модель жизненного цикла, обеспечивающую выделение строго упорядоченной совокупности элементов, описывающих

Основы управления программными проектами

121

эволюционное преобразование проекта от момента его инициации до момента завершения;

3) модель структуры, описывающую формальное содержание работы либо задачи проекта.

Формирование состава элементов в перечисленных моделях декомпозиции целесообразно производить, основываясь на отечественных и международных стандартах на разработку программных систем.

Так, основываясь на ГОСТ19.101-77 ЕСПД «Виды программ и программных документов», в качестве содержательной модели состава проекта целесообразно использовать следующие элементы:

·программный продукт — совокупность двух и более программных компонентов, реализующих конкретный бизнес-про- цесс;

·программный компонент — совокупность программных кодов, реализующих элементарную функцию бизнес-процесса и применяемых самостоятельно или в составе ПП.

Компонентами могут быть как прикладные подсистемы, так

иинфраструктурные (например, подсистема безопасности, библиотека визуальных компонентов и т. д.).

Содержательные модели жизненного цикларазработки программного проекта могут быть представлены в нескольких вариантах.

Например, ГОСТ 19.102-77 предусматривает следующие стадии разработки: техническое задание, эскизный проект, технический проект, рабочий проект, внедрение.

ГОСТ 19.201-78 ЕСПД «Техническое задание. Требования к содержанию и оформлению» предусматривает проведение предпроектного обследования, разработку функциональных требований, требований к базовому ПО, оборудованию и системному ПО, определение сроков и ресурсов на реализацию проекта, согласование и утверждение ТЗ.

Согласно ГОСТ Р ИСО/МЭК12207-99 «Процессы жизненного цикла программных средств» модель жизненного цикла —

122	2. Организация бизнеса

это структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования.

В этом стандарте все работы, которые могут выполняться в жизненном цикле программных средств, распределены следующим образом:

·по пяти основным процессам (1 — заказ; 2 — разработка; 3 — поставка; 4 — эксплуатация; 5 — сопровождение);

·восьми вспомогательным процессам (1 — документирование; 2 — управление конфигурацией; 3 — обеспечение качества; 4 — верификация; 5 — аттестация; 6 — совместный анализ; 7 — аудит; 8 — решение проблем);

· четырем организационным процессам (1 — управление, 2 — создание инфраструктуры; 3 — усовершенствование; 4 — обучение).

Каждый процесс жизненного цикла разделен на набор -ра бот; каждая работа разделена на набор задач. Процесс, работа или задача по мере необходимости инициируются и выполняются другим процессом, причем нет заранее определенных последовательностей. Так, например использование жизненного цикла каскадной модели при создании программного продукта подразумевает ступенчатое выполнение стадий разработки, когда следующая стадия наступает после полного завершения предыду-

щей (рис. 2.10) [31].

Данная модель предполагает строгое последовательное(во времени) и однократное выполнение всех стадий проекта с жестким (детальным) предварительным планированием определенных требований к программной системе.

Содержательная модель структуры работы или задачи про-

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

Практическое использование данной модели, например при планировании работы «Подготовка объекта к внедрению», позволяет менеджеру включать в проект следующие задачи:

Основы управления программными проектами

123

1)поставку и монтаж оборудования(разработку спецификации на оборудование; закупку и поставку оборудования; монтаж оборудования; установку и настройку оборудования);

2)поставку и установку общесистемного ПО(разработку спецификаций на общесистемное ПО; закупку общесистемного ПО; развертывание и настройку общесистемного ПО);

3)обучение пользователей (подготовку учебных курсов; обучение непосредственных пользователей; обучение руководства; обучение администраторов системы).

Планирование

План	Формирование требований

Спецификация	Анализ и проектирование
Дизайн			Конструирование
	Код
			Интеграция и тестирование
	Продукт			Поддержка и эксплуатация

Рис. 2.10. Каскадная модель жизненного цикла

При составлении плана реализации проекта не следует стремиться к его максимальной детализации. Если проект содержит слишком много уровней, менеджеры проекта сталкиваются с проблемой размерности. Например, при декомпозиции проекта по каскадной модели жизненного цикла можно выделить только три элемента — планирование, разработку и эксплуатацию, а

можно — и все шесть перечисленных в каскадной модели элементов. С одной стороны, использование второй модели существенно увеличивает детализацию проекта, а соответственно и точность планирования, с другой стороны, увеличивается размер-

124	2. Организация бизнеса

ность проекта, что порождает проблемы управления им. В этом случае понятие полноты работ и задач проекта вступает в про-

тиворечие с понятием их элементарности. С одной стороны,

проект должен быть рассмотрен максимально всесторонне и полно, а с другой — полученные результаты должны быть доступны для понимания и анализа. Декомпозиция целого на части должна производиться до получения задачи, которая понятна исполнителю и может быть достаточно адекватно оценена по срокам исполнения и требуемым ресурсам [30].

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

на следующих уровнях — элементы жизненного цикла каскадной модели. В этом случае содержание получаемой структурной модели проекта, ее размерность и в конечном итоге качество зависят от последовательности, в которой менеджер проекта использует выбранные модели декомпозиции, и с учетом выделенных принципов — от глубины декомпозиции.

2.3.3. Управление рисками проекта

В методологии по управлению IT-проектами Microsoft Solutions Framework (MSF) компании Microsoft под риском проекта

понимается событие или условие, которое может оказать как негативное, так и позитивное влияние на итоги проекта, и отмечается, что риски не есть проблемы. Проблемы — это нечто, имеющее место в настоящее время, в то время как риски относятся к будущему и носят вероятностный характер (могут и не состояться). Однако риски могут стать проблемами, если ими эффективно не управлять [29].

Цель управления рисками— максимизировать их положительное влияние (открывающиеся возможности), но при этом минимизировать связанные с ними негативные факторы(убытки). К минимизации рисков стремятся все потенциальные участники

Основы управления программными проектами

125

проекта: разработчики (поставщики) ПП, заказчики (потребители), а также предполагаемые инвесторы. Управление рисками — это определенная деятельность, которая выполняется в проекте от его начала и до завершения. О положении дел в проекте нужно судить не по количеству рисков, связанных с его выполнением, а по степени проработанности процедуры их выявления, анализа и управления ими.

Процесс управления рисками включает логически взаимосвя-

занные этапы: идентификацию рисков, анализ рисков, планирование рисков, мониторинг и управление рисками[26]. Необходимо отметить, что описанные этапы являются логическими шагами и не обязательно должны следовать друг за другом в строгом хронологическом порядке. Проектные группы могут циклически повторять шаги «выявление», «анализ» и «планирование» по мере обнаружения дополнительных факторов, влияющих на проект.

Идентификация рисков — этап, позволяющий определить и вынести на обсуждение команды факты наличия рисков, способных повлиять на проект, и документально оформить их характеристики. Выявление рисков является начальной стадией процесса управления ими. Это интерактивный процесс, который периодически повторяется на всем протяжении проекта, поскольку в рамках его жизненного цикла могут обнаруживаться и новые риски.

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

Каждый проект задумывается и разрабатывается на основании ряда гипотез, сценариев и допущений. Неопределенность в допущениях проекта следует также обязательно рассматривать в качестве потенциального источника возникновения рисков проекта.

Результатом идентификации рисков должен стать список рисков с описанием их основных характеристик. Рекомендуется

126 2. Организация бизнеса

каждый риск формулировать на естественном языке причинноследственной связи между реально существующим фактором проекта и потенциально возможным, еще не случившимся событием или ситуацией [26]. Первая часть формулировки риска— условие — содержит описание существующего фактора или особенности проекта, которые, по мнению членов проектной группы, могут сделать результат проекта убыточным либо сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется последствием. Она описывает нежелательную ситуацию, которой следует избегать.

Пример формулировки выявленных рисков представлен в табл. 2.2.

	Описание рисков проекта			Таблица 2.2
Причина	Условия	Последствия		Ущерб
Требования	Отсутствие опи-	Задержка начала		Задержки в сроках
не ясны	сания сценариев	разработки ППО.		сдачи готового про-
	использования	Большой объем		дукта и дополнитель-
	системы	переработок		ные трудозатраты
Недостаток	Архитектура	Большое число		Задержки в сроках
квалифици-	и код низкого	ошибок. Большие		сдачи готового про-
рованных	качества	затраты на их		дукта и дополнитель-
кадров		исправление		ные трудозатраты
Текучесть	Частая смена	Низкая произво-		Задержки в сроках
кадров	участников	дительность при		сдачи готового про-
	команды	вводе новых уча-		дукта и дополнитель-
		стников в проект		ные трудозатраты

Выявление рисков — ответственный и важный этап проекта. Знание о существовании рисков — необходимое условие эффективной работы по предотвращению рисков.

Анализ рисков — этап обработки данных, накопленных при идентификации рисков, в формы, позволяющие осуществить качественную и количественную оценки рисков: вероятности на-

Основы управления программными проектами

127

ступления риска, его угрозы, ранжирование рисков по степени возможных угроз, ожидаемую величину потерь и т. д.

Качественный анализ рисков проекта включает определение вероятности наступления рисков, тяжести последствий от рисков, степени опасности (ранга) риска, близости наступления риска [26]. Для измерения параметров рисков применяются, как правило, порядковые шкалы либо шкалы интервалов.

Определение тяжести последствий от рисков предлагается оценивать в шкале интервалов (табл. 2.3).

Таблица 2.3 Относительная шкала оценки воздействия рисков

	Количественное	< 0,4	0,4–0,7	> 0,7
	значение оценки
	Качественное	Умеренные	Критичные	Катастрофи-
	значение оценки			ческие
	Потери от	Потери менее…	Потери от … до…	Потери
	наступления риска			более…

Риск может воздействовать и на сроки проекта, и на качество получаемого продукта, но все эти отклонения могут быть оценены в денежном эквиваленте. Например, последствия задержки по срокам выполнения проекта могут быть выражены в сумме денежных санкций в контракте.

Похожая шкала может быть применена для оценки вероятности наступления риска (табл. 2.4).

Таблица 2.4 Относительная шкала измерения вероятности наступления риска

	Количественное	< 0,4	0,4–0,7	> 0,7
	значение вероятности
	Качественное значение	Мало-	Возможно	Очень вероятно
	вероятности	вероятно
	Возможность	Наступление	Шансы	Шансы
	наступления риска	события весьма	равны	наступления
		сомнительно		весьма велики

128	2. Организация бизнеса

Ранжирование рисков позволяет проектной группе управлять наиболее важными из них, выделяя для этого необходимые ресурсы. Для определения ранга риска используется информация матриц вероятностей и воздействий(табл. 2.5). Ранг риска определяет его порядковый номер в полной совокупности рисков проекта. Чем выше ранг, тем более опасен риск.

Таблица 2.5 Матрица рангов выявленных рисков проекта

	Причина	Вероятность	Воздействие	Ранг
	Требования не ясны	Очень вероятно	Катастрофические	9
	Недостаток квалифи-	Очень вероятно	Критичные	6
	цированных кадров
	Текучесть кадров	Возможно	Критичные	4

Одной из важных характеристик риска является близость его наступления. Естественно, что при прочих равных условиях рискам, которые могут осуществиться уже завтра, следует сегодня уделять больше внимания, чем тем, которые могут произойти не ранее чем через полгода. Возможная шкала оценки близости риска представлена в табл. 2.6.

Таблица 2.6 Относительная шкала измерения близости наступления риска

Количественное значение	Больше чем через …	От … до	Меньше
близости наступления			чем через …
Качественное значение	Очень нескоро	е оченьН	Очень скоро
близости наступления		скоро

Итоговые результаты анализа рисков подробно оформляются в виде документа, представленного в табл. 2.7.

Оценка рисков должна проводиться постоянно. Обстоятель-

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

Основы управления программными проектами

129

	Таблица 2.7
Пример карточки с описанием риска
Номер: R-101	Категория: технологический
Причина: недостаток ква-	Симптомы: разработчики будут исполь-
лифицированных кадров	зовать новую платформу J2EE
Последствия: низкая произ-	Воздействие: увеличение сроков и тру-
водительность разработки	доемкости разработки
Вероятность: очень вероятно	Степень воздействия: критическая
Близость: очень скоро	Ранг: 6
Исходные данные: «Содержание проекта», «План обеспечения ресур-
сами», протоколы совещаний № 21 от …, № 27 от …….

Результаты качественного анализа используются в ходе последующей количественной оценки рисков и планирования мероприятий по реагированию на риски.

Количественная оценка рисков позволяет определять:

·вероятность достижения конечной цели проекта;

·степень воздействия риска на проект и объемы непредвиденных затрат и материалов, которые могут понадобиться;

·риски, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на проект;

·фактические затраты и предполагаемые сроки окончания работ на проекте.

Количественная и качественная оценки рисков могут применяться в отдельности или вместе в зависимости от времени и бюджета.

Планирование рисков — это процесс определения конкретных действий (мероприятий) по управлению рисками проекта. Тщательное и подробное планирование рисков проекта позволяет:

·определить возможные потери от наступления рисков;

·выделить достаточное количество времени и ресурсов для выполнения операций по управлению рисками;

·повысить вероятность успешного достижения результатов проекта.