Материал: 970

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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