Улучшение плана программного проекта на основе анализа характеристик его формальной модели Текст научной статьи по специальности «Компьютерные и информационные науки»

Улучшение плана программного проекта на основе анализа характеристик его формальной модели

Матвеева Т.О., Старовойтов И.В. (starov@iacp.dvo.ru) Институт автоматики и процессов управления ДВО РАН

Введение

При выполнении проектов, связанных с разработкой программных средств (ПС), одной из задач, решаемых менеджерами, является детальное планирование этих проектов. Такая деятельность включает в себя определение процессов, которые будут выполняться в ходе проекта, разбиение этих процессов на задачи и подзадачи, соответствующие шагам проекта, определение связей между задачами по передаваемым рабочим продуктам, установление графика выполнения шагов проекта, а также назначение ресурсов для выполнения этих шагов - людей, средств и методов реализации. Созданные планы могут подвергнуться модификации, если их характеристики не удовлетворяют выбранным критериям (таким как уровень занятости ресурсов или оцениваемая общая продолжительность проекта). Существуют специализированные программные средства (например, Microsoft Project, Adaptable Process Model [19]), которые поддерживают осуществление такой деятельности, а также специализированные методы (например, PERT, CPM [16]), позволяющие получать статистическую оценку наиболее вероятной продолжительности запланированного проекта. Более глубокий анализ характеристик планируемого проекта могут обеспечивать средства, основанные на методах формального моделирования процессов производства (таких как конечные автоматы (Statemate), сети Петри (MELMAC, SPADE [4]), продукционные системы (MARVEL)) [7,8] и обеспечивающие прогнозирование динамических характеристик проекта. Тем самым, использование такого подхода потенциально позволяет при минимальных затратах получить оценки эффекта от изменения плана проекта, поскольку при наличии соответствующего формального аппарата можно осуществить "анимацию" модели проекта, количественно оценить ее динамические характеристики, а также выявить фрагменты плана, которые при выполнении проекта могут привести к неэффективному использованию ресурсов.

В общем случае применение такого подхода предполагает:

(а) построение формальной модели, наиболее полно отражающей свойства реального процесса,

(б) выбор критериев улучшения, выраженных набором мер,

(в) измерение построенной модели процесса в терминах выбранных мер,

(г) его целенаправленное изменение с целью минимизации/максимизации значений выбранных мер,

(д) оценку достигнутого эффекта от изменения процесса.

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

Большинство применяемых в настоящее время методов формального моделирования процессов на уровне отдельного программного проекта предложены не позднее начала 90-х гг. и оставляют без внимания то, что в организации, имеющей хотя бы 2-й уровень зрелости (согласно шкале SEI СММ [15]), все программные проекты имеют общие черты. Современные же модели процесса производства (представленные в ISO/IEC 12207 [12] и в таких моделях, как СММ [15]) предполагают, что модель плана конкретного программного проекта должна конструироваться путем адаптации моделей процесса более высокого уровня, компоненты которых в значительной степени стандартизованы.

Недостатком большинства традиционно применяемых в данной области формализмов (таких как, например, сети Петри [7, 8]) является то, что динамика построенных с их помощью моделей плохо отражает реальное выполнение программных проектов, основные роли в которых играют люди, а не механизмы.

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

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

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

(2) правил, обеспечивающих имитацию процесса выполнения проекта;

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

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

1. Основные компоненты модели процесса производства программного обеспечения

Целью этого раздела является неформальное определение основных компонентов процесса производства программного обеспечения (ПО) при его рассмотрении на разных уровнях абстракции.

Предлагаемый в данной работе способ моделирования рассматривает процесс производства ПО на следующих трех уровнях:

(1) Онтологический уровень. На этом уровне принято рассматривать следующие компоненты процесса производства ПО [7, 8, 18].

Процесс жизненного цикла (ЖЦ) ПО (life-cycle software process) -взаимосвязанное множество видов деятельности, преобразующих входы в выходы [12]. Входами и выходами процесса являются продукты (work products)

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

- видов деятельности (activities), любой из них может получать на вход часть продуктов из множества входных продуктов всего процесса и создает другие продукты, часть которых поступает на выход всего процесса. В свою очередь, каждый вид деятельности состоит из задач (tasks), на вход которых поступает часть входных продуктов вида деятельности и результатом выполнения которых являются один или несколько других продуктов или компонентов продуктов [13]. Задачи выполняются с использованием ресурсов (resources). Основными типами ресурсов при разработке ПО являются люди, средства и методы. Реальное разделение труда внутри программного проекта достаточно точно отражается разделением процессов и подпроцессов на технические, организационные и процессы менеджмента. Такое разделение процессов на категории рекомендуется международным стандартом ISO/IEC 12207. Отсюда, существует следующая иерархическая структура процессов жизненного цикла ПО [12]:

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

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

управляющие связи между выполняемыми видами деятельности. Каждая из моделей ЖЦ может быть детализирована в терминах стандарта ISO/IEC 12207. Все процессы, виды деятельности и задачи, которые выполняются в организации при разработке ПО, образуют общий процесс организации (см. ниже уровень (2)). Конкретной реализацией такого процесса является проект по разработке некоторого программного средства (см. ниже уровень (3)).

Существуют также онтологические соглашения относительно некоторых атрибутов объектов этого уровня моделирования (к ним относятся, например, продолжительность выполнения вида деятельности, производительность ресурса, размер программного продукта [6]).

(2) Уровень конкретной организации. В соответствии с рекомендациями широко признанных методологий (таких как СММ [15] и ISO/IEC 15504 [13]) каждая организация должна стремиться специфицировать и "установить" стабильный общий процесс производства, согласованный с уровнем (1) и такой, что каждый программный проект наследует черты этого общего процесса.

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

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

Используя общую модель процесса производства и параметры ее адаптации к условиям конкретного проекта (такие как оцениваемый размер нового проекта, тип его приложения, оцениваемая стабильность требований и т.п. [16]), менеджер проекта выбирает общую структуру проекта - так называемую сеть задач (task network). Следующим шагом является назначение ресурсов для выполнения задач, после чего может быть оценена продолжительность выполнения каждой задачи. Последним шагом является установление временного графика (timeline chart), предполагающего определение очередности выполнения задач (c учетом возможности параллельного выполнения некоторых из них) и оценку даты начала и завершения каждой задачи.

Формальная модель процесса производства ПО, охватывающая все вышесказанное, представлена в разделе 3.

2. Общая схема моделирования и улучшения плана программного проекта

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

Общая трехуровневая схема процесса моделирования и улучшения плана программного проекта представлена на рисунке.

На верхнем уровне из создаваемых различными авторитетными организациями (такими как ISO, SEI и т.п.) стандартов и руководств, связанных с определением процессов ЖЦ ПО, извлекаются онтология этой предметной области и знания. Затем знания формализуются.

Онтология и знания предметной области используются средством поддержки инженерии процесса на втором уровне схемы. При помощи этого средства менеджер процессов организации-разработчика ПО выбирает элементы модели процессов, связывает их в шаблоны и формирует модель процесса производства организации (см. раздел 3). При этом в своих действиях он руководствуется политикой организации, которая определяет набор используемых стандартов и моделей процессов ЖЦ ПО. На этом же уровне находится база данных (БД) с информацией о предыдущих программных проектах, выполненных в данной организации. На основе схемы этой БД и онтологии, полученной на верхнем уровне схемы, формируется метод специфицирования планов новых программных проектов, который встраивается в средства нижнего уровня схемы, представленной на рисунке.

Модель процесса организации и информация из БД о предыдущих проектах поступают на вход графическому редактору модели плана проекта (на третьем (нижнем) уровне схемы). При помощи этого редактора менеджер конкретного программного проекта адаптирует модель процесса организации к планируемому проекту и устанавливает значения параметров модели на основе исторической информации из БД. Полученная модель плана проекта автоматически преобразуется во внутренний формат. После того как менеджер определит значения параметров поведения модели (см. раздел 4.5) при помощи специального средства поддержки, сформированная реляционная модель может интерпретироваться средством исполнения модели плана проекта, в результате чего будет сгенерирована реляционная динамическая модель процесса исполнения плана проекта (см. раздел 4). Менеджер может увидеть эту модель в удобной для него форме с помощью специализированного средства визуализации (см. раздел 6). При этом он может получать ответы на запросы о состоянии как динамической модели в целом, так и ее отдельных фрагментов в разные моменты времени.

Характеристики динамической модели проекта измеряются средством измерения, которое использует для этого формализованные знания о мерах и дефектах планов программных проектов (см. раздел 7). Значения мер и данные о дефектах плана проекта анализируются и оцениваются на основе критериев оценивания, заданных менеджером проекта (см. раздел 8). Он получает доступ

Организации (КО и т. п.)

Формализованные знания

Средство Средство

визуализации визуализации

результатов моделей с

измерения и помощью

оценивания графов

Средство анализа и оценивания

Значения мер и данные о дефектах планов проекта

Динамическая модель плана проекта

г

Средство измерения

к к Формализация

Литература о мерах и дефектах, опыт менеджеров

Общая схема моделирования и улучшения плана программного проекта

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

3. Реляционная модель процесса производства программного обеспечения

Целью этого раздела является формальное специфицирование "полной" статической модели процесса производства ПО. Эта модель обеспечивает базис для определения процесса исполнения модели плана программного проекта (см. раздел 4), а также набора графовых моделей (см. разделы 5 и 6), облегчающих специфицирование плана и визуальный анализ его характеристик.

3.1. Элементы модели

При определении модели процесса производства программного обеспечения будут использоваться следующие элементарные понятия:

Process-names - множество названий процессов (например, процесс разработки, процесс документирования [12]),

Process-types - множество названий категорий процессов (например, основные процессы, поддерживающие процессы и процессы управления [12]),

LC-model-names - множество названий моделей жизненного цикла (например, линейная модель, спиральная модель, прототипирование [16]),

Activity-names - множество названий видов деятельности (например, детальное проектирование, тестирование приемлемости [12]),

Activity-types - множество названий типов деятельности (например, генерация отчетов, объектно-ориентированный анализ),

Task-names - множество названий задач (например, разработка набора тестовых ситуаций),

Product-names - множество названий продуктов, создаваемых в процессе выполнения задач (например, план испытаний, спецификация системы [13]),

Product-types - множество типов рабочих продуктов (например, отчет, план [10]),

Project-names - множество названий программных проектов (например, Logiscope, РЕПРО2),

Role-names - множество названий ролей исполнителей при выполнении задач (например, кодировщик, инспектор, менеджер по тестированию),

Method-names - множество названий применяемых в организации методов выполнения программных проектов (например, SA/SD method, Jackson diagrams [16]),

Tool-names - множество уникальных идентификаторов доступных в организации средств выполнения проектов (например, Rational Rose, Pure Coverage, SQL Navigator, Comp#15),

Tool-types - множество названий типов средств (например, программные средства отладки, компьютер, тестовые драйверы),

Agent-names - множество идентификаторов исполнителей, способных выполнять задачи программных проектов (например, Mary Stewart, Андрей Лучников),

Steps - множество идентификаторов шагов проекта (обычно натуральные числа), соответствующих выполняемым (возможно, неоднократно) задачам,

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

Duration - продолжительность процесса или его части (например, число недель, месяцев),

Productivity - производительность исполнителя при выполнении конкретной работы (например, 300 строк кода на C++ при кодировании, 2 найденных дефекта в час при инспекции),

Time-moments - дискретное множество моментов условного времени программного проекта, начиная от 0 и с постоянным приращением At (например, менеджеры часто практикуют планирование и прослеживание проекта с приращением в одну неделю [16]),

Date - функция перевода условного времени программного проекта (представленного множеством Time-moments) в календарное время. Сигнатура функции:

Date (date0, Adate, time-moment) e {<месяц-число-год>}, где date0 -календарная дата, сопоставленная началу проекта (т.е. условному нулю множества Time-moments), Adate - календарный интервал, сопоставленный приращению At, time-moment - условный момент времени, переводимый в календарную дату.

3.2. Отношения, представляющие компоненты модели

Компоненты модели процесса производства ПО ниже рассматриваются как объекты, каждый из которых представлен списком своих атрибутов. Связи между объектами тоже рассматриваются как их атрибуты. Компоненты модели рассматриваются на трех уровнях абстракции в соответствии со схемой, представленной на рисунке.

3.2.1. Знания общего характера о процессах производства ПО (верхний уровень)

На этом уровне модель процесса производства ПО содержит компоненты, представленные значениями следующих отношений:

(* перечень процессов производства ПО *)

Processes

(process-name, (*название процесса, где все process-name е Process-names*)

process-type, (* категория процесса, где все process-type е Process-types *)

List-of<activity-name>, (*ссылки на виды деятельности, в совокупности реализующие процесс с именем process-name, где все activity-name е Activity-names *)

List-of<LC-model-name> (* ссылки на возможные модели ЖЦ для реализации процесса с именем process-name, где все LC-model-name е LC-model-names *))

(* перечень видов деятельности, реализующих процессы производства*) Activities

(activity-name, (* название вида деятельности, где все activity-name е Activity-names *)

List-of<task-name>), (* ссылки на задачи, в совокупности реализующие вид деятельности с именем activity-name, где все task-name е Task-names *))

(* перечень задач, реализующих виды деятельности *) Tasks

(task-name, (* название задачи, где все task-name е Task-names *)

List-of <product-name-IN>, (* ссылки на продукты, являющиеся входами для задачи с именем task-name, где все product-name-IN е Product-names *)

List-of<product-name-OUT>, (* ссылки на продукты, являющиеся выходами для задачи с именем task-name, где все product-name-OUT е Product-names *))

(* модели ЖЦ ПС *) Life-cycles

(LC-model-name, (* название модели ЖЦ, где все LC-model-nameе LC-model-names *)

Expression (* выражение, описывающее задаваемые моделью с именем LC-model-name управляющие связи между видами деятельности и некоторыми задачами*))

Примечание. В данной работе формальное определение выражения не приводится. Оно основано на следующей гипотезе.

Гипотеза. Любую модель ЖЦ можно однозначно представить в виде выражения, где операнды - виды деятельности, отдельные задачи или блоки, а операции - последовательное выполнение, выборочное выполнение и возврат на <операнд>.

(* перечень рабочих продуктов, создаваемых в процессе производства *) Work-products

(product-name, (* название продукта, где все product-name e Product-names *)

product-type, (* тип продукта, где все product-type e Product-types *)

List-of <task-name-IN>, (* ссылки на задачи, для которых продукт с именем product-name является входным, где все task-name-IN e Task-names *)

List-of<task-name-OUT>, (*ссылки на задачи, для которых продукт с именем product-name является выходным, где все task-name-OUT e Task-names *)

<состав продукта> (*перечень названий разделов, описывающих содержимое продукта с именем product-name (см., например, ISO/IEC 15504. Ч. 5 [13]) *) )

Эти отношения позволяют формально представить модели процессов в соответствии с современными международными стандартами, такими как, например, ISO/IEC 12207 [12], ISO/IEC 15504 [13]. При этом формализованные знания конкретных стандартов представляются множеством кортежей описанных отношений, которые могут храниться в реляционной базе данных и доступ к которым обеспечивается с помощью обычных средств языка запросов.

3.2.2. Процесс производства конкретной организации

В соответствии со схемой (см. рисунок) спецификации общей модели процесса строятся из отношений, описанных выше и представляющих знания общего характера, а также из отношений, представляющих данные о компонентах процесса производства конкретной организации. Знания общего характера должны быть адаптированы к рассматриваемому контексту, а именно, должны быть выбраны те компоненты процессов (модели ЖЦ, рабочие продукты, виды деятельности и задачи), которые охватываются процессом производства данной организации. "Поведенческий" аспект модели процесса производства организации (в дополнение к рассмотренному выше структурному), как правило, представлен историческими данными о выполненных в данной организации программных проектах.

(1) Структура общей модели процесса производства описывается в терминах отношений Processes, Life-cycles, Tasks, Work-products, а также отношений:

(* набор шаблонов декомпозиции видов деятельности на задачи *) Activities

(activity-name, (*где все activity-name е Activity-names *) activity-type, (*где все activity-type е Activity-types *) List-of-<expression> (*набор выражений, описывающих различные шаблоны декомпозиции вида деятельности с именем activity-name на задачи *)),

(* перечень ролей исполнителей *) Roles

(role-name, (* название роли, где все role-name е Role-names *) List-of<task-name> (* ссылки на задачи, в которых агенты используются в роли с именем role-name, где все task-name е Task-names *) ),

(* перечень используемых методов производства *) Methods

(method-name, (* название метода, где все method-name е Method-names *) activity-type, (* ссылка на тип деятельности, для выполнения которой предназначен метод с именем method-name, где все activity-type е Activity-types *)

List-of<task-name> (* ссылки на задачи, выполнение которых поддерживается методом с именем method-name, где все task-name е Task-names *) ),

(* перечень доступных средств производства *) Tools

(tool-name, (* уникальный идентификатор средства, где все tool-name е Tool-names *)

tool-type, (* тип средства, где все tool-type е Tool-types *) List-of<task-name> (* ссылки на задачи, выполнение которых поддерживается средством с именем tool-name, где все task-name е Task-names *) ),

(2) Исторические данные о выполненных в организации проектах могут быть представлены, например, в терминах следующих отношений (необходимо отметить, что состав и формат представления таких данных в разных организациях может существенно различаться. В данной работе использован набор атрибутов проекта, рекомендованный SEI SCE [5]). Поскольку шкалы значений для большинства атрибутов ПО не стандартизованы, ниже приводится их неформальное определение, снабженное примерами.

(* данные о выполненных программных проектах *) Projects

(project-name, (* название проекта, где все project-name е Project-names *) type-of-work, (* тип выполняемой работы, например, полная разработка, разработка кода, разработка системы без кодирования и т.п. *)

customer, (* тип заказчика, например, оборонные предприятия,

федеральные организации *) quality, (* информация о качестве - требуемый уровень качества и

фактическое качество создаваемого ПС [11]) size, (* размер выхода проекта - оцениваемый и фактический *) reuse, (* доля повторного использования - оцениваемая и фактическая *) application-type, (* тип приложения, например, информационная система,

система управления) schedule, (* основные даты проекта - календарное время начала,

окончания, текущее состояние - выполняемый этап проекта *) duration, (* продолжительность проекта - оцениваемая и фактическая *) team-size, (* размер бригады разработчиков проекта *)

development-team-approach, (* тип организации бригады проекта, например, multi-functional, interdisciplinary, standard functional, integrated product teams, [5] *) languages, (* язык реализации *)

process-metrics-data, (* характеристики процесса, выраженные значениями метрик, например, уровень занятости ресурсов, данные о производительности и т.п.)

applicable-standards, (* стандарты, которые были "навязаны" в данном проекте извне *)

major-subcontractors, (* признак привлечения внешних субподрядчиков *) successfulness (* признак успешности/неуспешности проекта *))

(* данные о созданных рабочих продуктах *) Developed-products

(product-ref, (* уникальный идентификатор продукта *)

product-name, (* стандартное название продукта, где все product-name e Product-names *)

project-name, (* название проекта, в рамках которого продукт был создан *) language, (* язык реализации продукта*)

size, (* размер продукта в терминах языка реализации language*) reuse, (* доля повторного использования (от общего размера size) *)

complexity, (* сложность продукта *)

List-of<agent-name>, (* ссылки на создателей продукта, где все agent-name

e Agent-names *) re-work, (* число возвратов продукта на доработку *) relationships (* связь с другими продуктами *) )

(* данные об имеющемся персонале *) Staff

(agent-name, (* идентификатор исполнителя *)

age, (* возраст *) sex, (* пол *)

education, (* образование исполнителя *) (* опыт выполнения программных проектов *)

List-of <project-name, (* ссылка на проекты, в которых участвовал исполнитель *)

task-name, (* название выполняемой задачи *)

role-name, (* роль, которую играл исполнитель в проекте с именем project-name *)

List-of <product-ref>, (* продукты, которые были созданы исполнителем *)

manager, (* ссылка на менеджера, под управлением которого работал исполнитель *)

List-of <tool-types>, (* ссылки на типы средств, с которыми работал исполнитель *)

List-of<method-names>, (* ссылки на методы, которые использовал исполнитель *)

productivity (* производительность, с которой работал исполнитель *)>)

3.2.3. План программного проекта (нижний уровень)

План конкретного программного проекта строится на основе общей модели процесса производства организации аналогично тому, как на предыдущем уровне знания общего характера адаптируются к контексту конкретной организации. При планировании используются и уточняются отношения Processes, Life-cycles, Activities, Tasks, Work-products, Roles, Methods и Tools, представляющие компоненты общего процесса, в терминах которых выражается модель плана, а также строятся следующие отношения. (* описание планируемого проекта *) Projects

(project-name, (* название планируемого проекта *)

<атрибуты> (*атрибуты отношения Projects (см. раздел 3.2.2.), кроме фактических данных*) )

(* перечень планируемых рабочих продуктов *) Products

(product-ref, (* уникальный идентификатор продукта *) <атрибуты>,(*атрибуты отношения Developed-products (см. раздел 3.2.2.)*) List-of-<stepFROM>, (* ссылки на шаги проекта, на которых создается

данный продукт, где все stepFROM е Steps *) List-of-<stepTO> (* ссылки на шаги проекта, использующие продукт, где все stepTO е Steps *))

(* описание шагов планируемого проекта *) Project-steps

(step, (*уникальный идентификатор шага проекта, step e Steps*)

task-name, (* ссылка на задачу, выполняемую на данном шаге *)

List-of<(*IN*) product-ref>, (* ссылки на используемые на данном шаге продукты *)

List-of<(*OUT*) product-ref>, (* ссылки на генерируемые на данном шаге продукты *)

List-of<role-name, agent-name>, (* ссылки на исполнителей ролей на данном шаге *)

List-of<method-name>, (* ссылки на используемые на данном шаге методы *)

List-of<tool-name>, (* ссылки на используемые на данном шаге средства *)

starting-date, (* планируемая дата начала шага, где все starting-date e Time-moments *)

efforts, (* оцениваемый в контексте объем работы на данном шаге *) duration (* оцениваемая продолжительность выполнения данного шага *))

(* описание ограничений на выполнение шагов планируемого проекта *) Constraints

(step, (* идентификатор шага, на который наложено ограничение *) List-of <agent-name>, (* список критичных для данного шага исполнителей *)

List-of<tool-name>, (* список критичных для данного шага средств *) sign, (* признак снятия ограничения извне, где все sign e {hold, release} *) constrained-date (* дата, ранее которой шаг не может начать выполняться, где все constrained-date e Date *) ) Примечание. Отношение (предикат) Constraints определяет, доступны ли к началу выполнения шага step критичные ресурсы и наступила ли "сдерживающая" дата начала шага (связанная, например, с условиями контракта или датами планируемого поступления денег для выполнения этапов проекта). В данной работе предполагается, что при планировании проекта для некоторых его шагов могут быть заданы ограничения такого рода, при этом оценка фактической доступности конкретных ресурсов (представленная значением признака sign) может быть отсрочена до момента фактического начала выполнения шага.

(* описание назначений исполнителей на роли, связанные с выполнением шагов проекта*)

Assignments

(effort-unit, (* уникальный идентификатор назначения *)

agent-name, (* ссылка на назначенного исполнителя *) role-name, (* ссылка на роль, на которую назначен исполнитель *) step, (* ссылка на шаг проекта, с которым связано назначение*) norm-productivity (* оцениваемая производительность исполнителя при выполнении данного назначения *) ) Примечание. В данной модели допускается как назначение разных исполнителей на одну и ту же роль для выполнения одной и той же задачи на разных шагах, так и назначение одного исполнителя на разные роли, связанные с одним и тем же шагом.

(* перечень средств, планируемых для использования при выполнении шагов проекта *) Used-tools

(tool-name, (* ссылка на идентификатор средства *)

step, (* ссылка на шаг проекта, на котором планируется использовать средство *)

norm-productivity (* оцениваемая производительность средства на данном шаге *) )

(* описание методов, планируемых для использования при выполнении шагов проекта *)

Used-methods

(method-name, (* ссылка на идентификатор метода *)

step (* ссылка на шаг проекта, на котором планируется использовать данный метод *) )

(* начальный шаг запланированного проекта *) Starting-step

(step (* ссылка на шаг, являющийся первым шагом выполнения проекта *))

(*запланированная очередность запуска шагов проекта *)

Previous (step1, step2) (* выполнение шага step2 предшествует выполнению шага step1 *).

Примечание 1. Это отношение, по сути, соответствует отношению строгого порядка на запланированных датах начала выполнения шагов проекта. Его значение определяется следующим образом:

V step1, step2

(Previous (step1, step2) —

Project-steps (step1, _, _, _, _, _, starting-date1, _, _) &

Project-steps (step2, _, _, _, _, _, starting-date2, _, _) &

starting-date1 < starting-date2 ) )

Примечание 2. Здесь и далее символ "_" в отношении означает вхождение анонимной свободной переменной.

3.2.4. Принятые соглашения и ограничения модели

1. В плане всегда есть начальная задача (шаг), и она единственна.

2. Для начального шага всегда доступны все входные продукты и нет дополнительных ограничений, определяемых отношением Constraints.

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

4. Идентификаторы ресурсов уникальны в пределах объединения множеств названий методов, средств и идентификаторов исполнителей.

5. Перед исполнением все атрибуты элементов модели, определенной в разделе 3, должны быть определены или оценены. Помимо этого должны быть определены параметры процесса исполнения модели плана (т.е. выбран вариант правил выполнения и заданы значения для Tmax и At (см. раздел 4)).

6. В случае выбора правил выполнения с параметрами в процессе исполнения модели плана менеджер должен доопределить значение отношения Constraints и определить значение функции Effort-ratio, устанавливающей размер долевого участия конкретного исполнителя в параллельно выполняемых им работах.

7. Методы являются ресурсом, доступным без каких-либо ограничений.

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

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

Описанная модель позволяет формально представить план программного проекта, охватив при этом такие виды деятельности, как адаптация стандартизованных знаний о процессе производства ПО к условиям конкретной организации и адаптация общей модели процесса производства организации к условиям конкретного программного проекта, а также основные этапы процесса планирования, а именно: (1) определение состава создаваемых продуктов, (2) построение так называемой сети задач, (3) назначение задачам ресурсов, (4) оценку основных параметров шагов проекта, (5) установление временного графика для выполнения запланированных шагов.

4. Модель процесса исполнения плана программного проекта

Целью раздела является формальное специфицирование реляционной динамической модели плана программного проекта. Эта модель описывает процесс исполнения статической модели плана проекта (см. раздел 3) при заданных значениях параметров.

Модель процесса исполнения плана программного проекта ниже описана в форме проблемно-ориентированного исчисления, которое включает в себя четыре составляющие [3]:

1) структуру множества состояний рабочей среды,

2) проблемно-ориентированные правила,

3) универсальный рецепт (правила вывода, которые описывают регламент применения проблемно-ориентированных правил),

4) правила остановки.

4.1. Структура состояния рабочей среды

Каждое состояние рабочей среды Wi есть множество кортежей отношений трех типов:

1) отношений, описывающих сам исполняемый план, а именно: Project-steps, Products, Constraints, Assignments, Previous, Used-tools, Used-methods, Starting-step, представленных в разделе 3.2.3; значения этих отношений не меняются в процессе исполнения плана, и в каждом состоянии Wi они одинаковы;

2) отношения, представляющего условные часы и указывающего текущий момент времени ("такт") процесса исполнения плана (значения параметров Tmax и delta задаются извне):

Current-time (time-moment, delta), time-moment e [0, Tmax], delta < Tmax;

3) отношений, описывающих текущее состояние процесса исполнения модели плана проекта, а именно:

Started (time-moment, step) - представляет момент начала выполнения шага step;

Current-ratio (time-moment, step, efforts-ratio) - представляет долю работы efforts-ratio, выполненную на шаге step к моменту time-moment;

Assumptions (time-moment, agent-name, List-of<effort-unit (*из отношения Assignments*)>) - представляет активные на момент time-moment назначения исполнителя agent-name,

Performs (time-moment1, time-moment2, agent-name, effort-unit, ratio) -представляет ту работу effort-unit, которой фактически был занят исполнитель agent-name на временном промежутке [time-moment1, time-moment2] с долей ratio занятости его рабочего времени;

Allocations (time-moment, tool-name, List-of<step>) - представляет шаги, для выполнения которых в момент времени time-moment используется средство tool-name;

Примечание. Распределенное использование средства на каждом промежутке времени в данной модели допускается (если это не ограничено отношением Constraint), однако явно не моделируется. Считается, что

средство, предоставленное для использования N шагам, в равной доле используется ими на всем протяжении их выполнения.

Finished (time-moment, step) - представляет момент time-moment завершения шага step;

Produced (time-moment, product-ref) - представляет момент time-moment завершения создания продукта с идентификатором product-ref.

Начальное состояние - состояние рабочей среды Wi, содержащее кортежи отношений первого типа (см. выше), кортеж для начального момента времени Current-time (0, delta), а также по два кортежа третьего типа для каждого используемого в проекте ресурса (кроме методов):

(Vagent-name (Assignments (_, agent-name, _, _, ) ^ Assumptions (0, agent-name, []) )

(* [] обозначает пустой список *)

(Vtool-name (Used-tools (tool-name, _, _) ^ Allocations (0, tool-name, []) ).

Примечание. В соответствии с гипотезой о замкнутости мира [17] (см. универсальный рецепт, описанный в разделе 4.3) все, что не содержится в текущем состоянии рабочей среды, считается ложным. Так, в начальном состоянии все предикаты Started, Produced, Finished, Performs имеют значение false для всех значений аргументов соответствующих отношений.

Конечное состояние. Конечным состоянием рабочей среды Wi является состояние, полученное в результате применения правила остановки (см. раздел 4.4).

4.2. Проблемно-ориентированные правила

Проблемно-ориентированные правила (применение которых регламентируется универсальным рецептом (см. раздел 4.3)) определяют операции добавления множества новых кортежей к текущему состоянию рабочей среды Wi. Синтаксис правил основан на работах [1, 2]. При этом здесь и далее в работе все переменные, для которых явно не задана область их действия, считаются находящимися под квантором существования, начиная с момента их указания и в пределах области, ограниченной скобками соответствующего уровня вложенности.

Правило 1. Инициализация шагов проекта.

Вариант 1. Инициализация шага в соответствии с наступлением календарной даты его запланированного начала (без учета запланированной очередности выполнения шагов).

Current-time (time-moment, _) & 3 step

(Project-steps(step, _, List-of<in-product-ref>, _, _, _, List-of<tool-name>, starting-date, _,) &

NOT (Started (_, step) ) &

(&(Vproduct e List-of<in-product-ref>) Produced (_, product) ) &

starting-date < Date (date0, calendar-unit, time-moment) ) &

(NOT (Constraints (step, _, _, _, _) ) v

Constraints (step, _,_, "release", date) & date > Date(date0, calendar-unit, time-moment) )

^ Started (time-moment, step) & Current-ratio (time-moment, step, 0) )

Вариант 2. Инициализация шагов в соответствии с запланированной очередностью их выполнения.

Current-time (time-moment, _) &

3 step

(Project-steps(step, _, List-of<in-product-ref>, _, _, _, _, starting-date, _, _) & NOT (Started (_, step) ) &

(&(Vproduct e List-of<in-product-ref>) Produced product) ) & (&(Vstep1 (Previous (step1, step)) Started (_, step1) ) &

(NOT (Constraints (step, _, _, _, _) ) v

Constraints (step, _,_, "release", date) & date > Date(date0, calendar-unit, time-moment) )

^ Started (time-moment, step) & Current-ratio (time-moment, step, 0) )

Правило 2. Назначение ресурсам работ по выполнению инициализированных шагов.

Правило 2.1. Для ресурсов-исполнителей. Current-time (time-moment, _) &

3 agent-name (Assumptions (time-moment, agent-name, List-of<effort-unit>) &

Relevant-units — ^effort-unit(&(V effort-unit (Assignments (effort-unit, agent-name, _, step, _))

Started (time-moment, step) ) ^ Assumptions (time-moment, agent-name, List-of<effort-unit> !! List (Relevant-units) ) ) (* List - функция построения списка из заданного множества элементов *)

Правило 2.2. Для ресурсов-средств. Current-time (time-moment, _) &

3 tool-name (Allocations (time-moment, tool-name, List-of<step>) &

Relevant-units = Ustep (&(Vstep (Used-tools (tool-name, step, _))

Started (time-moment, step) ) ^ Allocations (time-moment, tool-name, List-of<step> !! List(Relevant-units)))

Правило 3. Выполнение части работы на шаге проекта.

Вариант 1. Исполнители в равных долях занимаются всеми назначенными им видами работ.

Current-time (time-moment, delta) &

3 step (Project-steps (step, _, _, _, _, _, _, _, efforts, _) &

Current-ratio (time-moment, step, effort-ratio) & effort-ratio < 100 &

(&(V agent-name (Assignments (effort-unit, agent-name, _, step, _) & Assumptions (time-moment, agent-name, List-of<effort-unit>))

Current-efforts = Z(delta/Length (List-of<effort-unit>) * 100 / efforts) ^ Performs (time-moment, time-moment + delta, agent-name,

effort-unit, 100/Length (List-of<effort-unit>) ) ) ^ Current-ratio (time-moment + delta, step, effort-ratio + Current-efforts) )

Вариант 2. Каждый исполнитель выполняет назначенные ему виды работ последовательно. Current-time (time-moment, delta) & 3 step (Project-steps (step, _, _, _, _, _, _, _, efforts, _) &

Current-ratio (time-moment, step, effort-ratio) & effort-ratio < 100 &

(&(V agent-name (Assignments (effort-unit, agent-name, _, step, _) & Assumptions (time-moment, agentname, List-of<effort-unit>)) Relevant-agents = U(agent-name)

^ Performs (time-moment, time-moment + delta, agent-name, First (List-of<effort-unit>), 100) ) ^ Current-ratio (time-moment + delta, step,

effort-ratio + delta * |Relevant-agents| * 100 / efforts)) Примечание. Функция First обеспечивает получение первого элемента заданного списка.

Вариант 3. Каждый исполнитель выполняет назначенные ему виды работ в соответствии с дополнительным назначением весовой доли для каждой работы из текущего списка выполняемых им работ. Current-time (time-moment, delta) & 3 step (Project-steps (step, _, _, _, _, _, _, _, efforts, _) &

Current-ratio (time-moment, step, effort-ratio) & effort-ratio < 100 &

(V agent-name (Assignments (effort-unit, agent-name, _, step, _) & Assumptions (time-moment, agentname, List-of<effort-unit>)) & (V effort-unite List-of<effort-unit> Ri = Effort-ratio (effort-unit, List-of<effort-unit>) ) )

Current-efforts = E( delta * Ri / efforts)

(* Effort-ratio - функция со значениями [0,100%], определяющая весовой коэффициент - долевой вклад исполнителя в конкретный вид работы из текущего списка назначенных ему работ*)

^ Performs (time-moment, time-moment + delta, agent-name, effort-unit, Ri) )

^ Current-ratio (time-moment +delta, step, effort-ratio + Current-efforts) )

Правило 4. Завершение шага проекта.

Current-time (time-moment, _) & time-moment Ф 0 & 3 step (Project-steps (step, _, _, _, _, _, _, _, _, _ ) &

Current-ratio (time-moment, step, effort-ratio) & effort-ratio > 100 ^ Finished (time-moment, step) )

Правило 5. Устранение назначений ресурсам работ по выполнению завершенных шагов.

Правило 5.1. Для ресурсов-исполнителей. Current-time (time-moment, _) &

3 agent-name (Assumptions (time-moment, agent-name, List-of<effort-unit>) &

Relevant-units — ^effort-unit (&(Veffort-unit (Assignments(effort-unit, agent-name,_, step,_))

Finished (time-moment, step) )

^ Assumptions (time-moment, agent-name, List-of<effort-unit> \ List

(Relevant-units) ) )

Правило 5.2. Для ресурсов-средств. Current-time (time-moment, _) &

3 tool-name (Allocations (time-moment, tool-name, List-of<step>) )

Relevant-units — Ustep (&(Vstep (Used-tools (tool-name, step, _) )

Finished (time-moment, step) ) ^ Allocations (time-moment, tool-name, List-of<step> \ List (Relevant-units)))

Правило 6. Генерация продукта.

Current-time (time-moment, _) & time-moment Ф 0 &

3 product (Products (product-ref, _, _, _, _, _, _, _, _, _, List-of-<stepFROM>, _) &

(&(Vstep (Project-steps (step, ...) & step e List-of-<stepFROM> )

Finished (_, step) ) & NOT (Produced(_, product-ref))

^ Produced (time-moment, product-ref) )

Примечание. Здесь и далее символ "..." в отношении означает вхождение множества анонимных свободных переменных.

Правило 7. Передача назначений работ ресурсам на следующий временной интервал.

Правило 7.1. Для ресурсов-исполнителей.

Current-time (time-moment, delta) & time-moment ф 0 &

3 agent-name (Assumptions (time-moment - delta, agent-name, List-of<effort-unit>)

^ Assumptions(time-moment, agent-name, List-of<effort-unit>) )

Правило 7.2. Для ресурсов-средств. Current-time (time-moment, delta) & time-moment ф 0 &

3 tool-name (Allocations (time-moment - delta, tool-name, List-of<step>) ^ Allocations (time-moment, tool-name, List-of<step>) )

4.3. Универсальный рецепт

В качестве универсального правила вывода в данном исчислении используется правило modus ponens и гипотеза о замкнутости мира [17], в соответствии с которой отрицание интерпретируется как неудача (т.е. как отсутствие в текущем состоянии рабочей среды Wi соответствующего кортежа). Следует отметить, что описанное проблемно-ориентированное исчисление обладает свойством монотонности относительно значений всех предикатов, использованных под отрицанием. Дополнительным правилом вывода является правило смены текущего момента времени, суть которого состоит в замене в рабочей среде кортежа отношения Current-time: Current-time (time-moment, delta) & Wi = Wi-1

^ Wi+1 = Wi \ Current-time (time-moment, delta) U Current-time (timemoment + delta, delta).

Комментарий. Если текущее состояние среды Wi не меняется при значении текущего момента времени time-moment, то значение текущего момента времени увеличивается на delta.

4.4. Правило остановки

Процесс вывода останавливается, если достигнуто конечное состояние рабочей среды Wi (см. раздел 4.1.) или превышено установленное на шкале времени максимальное значение, т.е. истинен предикат:

(&(Vproduct-ref (Products (product-ref, _,...) ) Produced pr°duct-ref) ) V

Current-time (time-moment, _) & time-moment > Tmax

4.5. Специфицирование параметров динамической реляционной модели плана проекта

Перед началом модельного исполнения плана проекта необходимо задать длину единичного временного интервала (delta), используемого во "внутренних часах" процесса выполнения проекта, а также выбрать варианты правил (см. раздел 4.2), которые будут использоваться при моделировании. Последнее относится к правилу инициализации шага проекта (для которого возможна альтернатива: (1) инициализация шага в соответствии с наступлением календарной даты его запланированного начала и (2) инициализация шага в соответствии с запланированной очередностью выполнения шагов) и к правилу выполнения части работы на шаге проекта (для которого возможны три варианта: (1) выполнение работ в равных долях, (2) выполнение работ последовательно и (3) выполнение работ с учетом указанных весовых долей).

В процессе модельного выполнения, в случае выбора вариантов правил с параметрами, необходимо оценивать значения этих параметров в конкретном контексте. К таким параметрам относится (1) признак снятия ограничений на инициализацию шага (см. раздел 4.2, Правило 1), обусловленных фактической доступностью критичных ресурсов или другими причинами (для этой цели используется атрибут sign в отношении Constraints), а также (2) весовая доля распределения рабочего времени исполнителя в зависимости от текущего списка его назначений (см. раздел 4.2, Правило 3, Вариант 3). Задание значений этих параметров производится менеджером в процессе применения правил с параметрами по запросу средства исполнения модели плана проекта (см. рисунок). При этом менеджер должен учитывать особенности планируемого проекта и исходить из собственного опыта.

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

5. Статический граф плана программного проекта

Целью этого раздела является формальное определение понятия статический граф плана программного проекта. Статический граф плана проекта предназначен для визуализации фрагментов этого плана, поддержки процесса его специфицирования и моделирования процесса его исполнения (см. раздел 4).

Предлагаемая графовая модель отражает видение плана программного проекта как сети задач; такое видение является широко распространенным (task network [16], network of tasks [14]). Вершины-задачи связаны дугами, отражающими передачу между задачами производимых ими продуктов. Кроме этого, модель отражает назначение ресурсов (людей, средств и методов) для выполнения шагов проекта. Вершины-ресурсы связаны дугами с теми вершинами-задачами, для выполнения которых они назначены, при этом указаны шаги, на которых выполняются задачи (поскольку одна и та же задача может выполняться многократно). Разметка множества вершин-задач графа задает частичный порядок выполнения шагов проекта, определяемый запланированным временным графиком.

В качестве структурной модели плана проекта будем использовать связный размеченный ориентированный граф G = <Task , Res, (R1, R2)>. В работе [14] аналогичный граф с двумя типами вершин называется многослойным (layered).

Приведенное ниже определение графа G представляет собой набор правил, устанавливающих взаимно-однозначное соответствие между элементами графа G и атрибутами реляционной модели (см. раздел 3). Такое определение позволяет, с одной стороны, использовать граф G для специфицирования полной модели плана программного проекта, а с другой -однозначно определять любые фрагменты модели плана при их визуализации.

5.1. Вершины статического графа, представляющие задачи

Task - множество вершин графа, представляющих множество задач плана программного проекта, Task = {task-name1, ..., task-namek}, Vi = 1,k (task-namei e Task-names), и при этом

3 task-name e Task -о- 3 task-name (Tasks (task-name, _,_) )

Примечание. Здесь и далее символ "_" в отношении означает вхождение анонимной свободной переменной.

Комментарий. Вершина графа task-name существует тогда и только тогда (т. и тт.), когда в реляционной модели плана проекта определена задача с именем task-name.

5.2. Разметка вершин статического графа

S - разметка множества вершин Task, определяющая шаги программного проекта и частичный порядок их выполнения. Каждой вершине соответствует непустое множество меток, где меткой является либо 0, либо пара натуральных чисел (ij). Первое число из этой пары задает частичный порядок выполнения шагов, второе число определяет уникальный номер шага проекта, на котором выполняется эта задача.

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

S1 s? S

V task-name1 , task-name2 eTask

(task-name1 ф task-name2 ^ S1cS & S2cS & S1nS2 = 0 )

Везде ниже шаг K, на котором выполняется задача task-name и очередность выполнения которого задана числом t, обозначается task-name(t,K).

Правило 1. Разметка вершины, соответствующей начальному шагу проекта.

3! task-name{0} e Tasks ^

3 step (Project-steps (step, task-name, ...) & Starting-step (step) )

Примечание. Здесь и далее символ "..." в отношении означает вхождение множества анонимных свободных переменных.

Комментарий. Вершина графа task-name помечена множеством меток {0} и является начальной вершиной т. и тт., когда в реляционной модели плана проекта определен шаг, на котором выполняется задача с именем task-name, и этот шаг является первым.

Правило 2. Разметка вершин, соответствующих остальным шагам проекта.

3 task-name2(iK2) e Tasks ^ 3 task-name1(i-1K1) e Tasks

(Project-steps (K2, task-name2, ...) & Project-steps (K1, task-name1, ...) & Previous (K1, K2) & V task-name3(tK3) e Tasks (Project-steps (K3, task-name3, ...) & Previous (K3, K2) ^ i-1 > t ) ) .

Комментарий. Вершина графа task-name2 помечена меткой (i,K2) т. и тт., когда существует вершина графа task-name1 (возможно, совпадающая с task-name2), помеченная меткой (i-1,K1), и в реляционной модели плана проекта определены шаги с номерами K1 и K2, на которых выполняются задачи task-name1 и task-name2 соответственно, причем установлено, что шаг с номером K1 должен выполняться перед шагом с номером K2 и для каждой вершины графа task-name3, помеченной меткой (t,K3), определен шаг с номером K3, на котором выполняется задача task-name3 и который должен выполняться перед шагом с номером K2; при этом первый индекс метки (i-1,K1) не меньше первого индекса метки (t,K3). Тем самым при построении разметки из всех меток вершин-задач предшествующих шагов выбирается метка с наибольшим первым индексом, указывающим на наиболее позднее выполнение задачи.

5.3. Дуги статического графа, представляющие передачу продуктов между задачами

R1 - множество дуг графа, представляющих передачи продуктов между задачами плана проекта, R1 = {(task-namei, task-namej)}, 1 < i < k, 1 < j < k, k = |Task|, и при этом

3 (task-name1(t1' K1), task-name2(t2 K2)) product-name e R1 —

3 product-name (Products (product-name, _, _, _, List-of<stepFROM>, List-

of<stepTO>, _) &

3 K1 (Project-steps (K1, task-name1, ...) &

3 K2 (Project-steps (K2, task-name2, ...) &

K1 e List-of<stepFROM> & K2 e List-of<stepTO>) ) )

Комментарий. Дуга (task-name 1, task-name2) существует и помечена именем рабочего продукта product-name т. и тт., когда в реляционной модели определен продукт, являющийся выходным для шага с номером K1, на котором выполняется задача task-name1, и входным для шага с номером K2, на котором выполняется задача task-name2.

Примечание. Здесь и далее значение первого индекса разметки t в идентификаторе шага task-name1(t,K) однозначно определяется значениями переменных task-name и K (согласно Правилу 2, описанному в разделе 5.2.).

5.4. Вершины статического графа, представляющие ресурсы

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

Res={resource-name1, ..., resource-namen}, Vi (i=1,n) resource-nameie Resource-names, где

Resource-names=Agent-names u Tool-names u Method-names, и при этом 3 resource-name e Res —

3 resource-name e Resource-names

(Assignments ( _, resource-name,.) v Used-tools (resource-name, ...) v Used-methods (resource-name, _) )

Комментарий. Вершина с именем resource-name, представляющая ресурс, существует в графе т. и тт., когда в реляционной модели определен ресурс resource-name (исполнитель, инструмент или метод), предназначенный для использования в данном проекте.

5.5. Дуги статического графа, представляющие назначение ресурсов для выполнения шагов проекта

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

R2 = {(resource-namei, task-namej(tK))role-name}, 1 < i < n, 1 < j < p,

где n = |Res|, p = |Task| и

3 (resource-name, task-name(t,K))role-name e R2 ^

3 resource-name e Resource-names

(3 K (Project-steps (K, task-name, .) &

(Assignments ( _, resource-name, role-name, K, _) V

Used-tools (resource-name, K, _) V

Used-methods (resource-name, K) ) ) )

Комментарий. В графе существует дуга между вершиной resource-name, представляющей ресурс, и вершиной task-name, представляющей задачу, т. и т.т., когда в реляционной модели плана проекта определен ресурс resource-name и шаг, на котором выполняется задача task-name и для выполнения которого назначен ресурс resource-name. Если при этом ресурс resource-name -исполнитель, то дуга помечена ролью role-name, на которую он назначен.

6. Динамические графовые модели плана программного проекта

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

Динамический граф строится на основе определенного в разделе 5

s

статического графа G = <Task , Res, (R1, R2)>, представляющего структуру плана программного проекта, и описанной в разделе 4 реляционной динамической модели, представляющей процесс исполнения специфицированного плана при заданных параметрах. Предполагается, что к моменту построения динамического графа процесс модельного исполнения завершен и существует полная реляционная динамическая модель.

Определим Gd (time-moment) = <(Tasks)D, Res1^, (R1ps,R2Rs)> -динамический граф, описывающий состояния вершин и дуг статического графа G в заданный момент процесса исполнения time-moment (time-moment e [0, T], где дискретное множество [0, T] содержит "такты" условного времени модельного исполнения проекта, заданные значением параметра delta (см. раздел 4), T - полученная "тактовая" продолжительность процесса модельного исполнения). В таблице представлено описание возможных состояний элементов графа Gd, представленных множествами D, RQ Ps и Rs. В разделах 6.1-6.4 приведены правила определения этих состояний при заданном

статическом графе О плана проекта и динамической реляционной модели процесса его выполнения.

Описание возможных состояний элементов динамического графа в заданный

момент времени time-moment

Элемент графа Состояние элемента в процессе исполнения Описание значений элементов кортежа состояния

Вершина task e Task, соответствующая задаче Пятерка вида (step, stepstatus, step-progress, startingmoment, finishing-moment) e D step e N - номер шага

step-status e {not-started, started-not-finished, finished} - состояние шага в момент времени time-moment (еще не начал выполняться, выполняется, завершен)

Продолжение таблицы

Элемент графа Состояние элемента в процессе исполнения Описание значений элементов кортежа состояния

step-progress e [0,100] - процентная доля выполненной работы для шага проекта (если шаг еще не начал выполняться, то step-progress = 0, если шаг завершен, то step-progress = 100)

starting-moment e {not-defined} u [0, Tmax] - момент начала выполнения шага (если шаг еще не начал выполняться и момент начала выполнения не определен, то starting-moment = not-defined)

finishing-moment е {not-defined} u ]0, Tmax] - момент завершения шага (если шаг еще не завершен, то finishing-moment = not-defined)

Вершина res e Res, соответствующая ресурсу Метка resource-status е ЯС resource-status е {occupied, free} - состояние ресурса в момент времени time-moment (занят, свободен).

Дуга r1 e R1, соответствующая передаче продукта product-name между задачами Пара вида (product-status, production-moment) е PS product-status е {not-produced, produced} - состояние продукта в момент времени time-moment (создан, не создан)

Production-moment е {not-defined} u ]0, Tmax] - момент создания продукта (если продукт еще не создан, production-moment = not-defined)

Дуга r2 e R2, соответствующая назначению ресурса на роль для выполнения шага Тройка вида (status, initiating-moment, releasemoment) е RS status е {not-performs, performs, performed} - состояние назначения ресурса в момент времени timemoment (ресурс не начал работать на шаге, работает на шаге, закончил работать на шаге)

Окончание таблицы

Элемент графа Состояние элемента в процессе исполнения Описание значений элементов кортежа состояния

initiating-moment e {not-defined} u[0, Tmax] - момент начала работы ресурса на шаге (если в момент времени time-moment назначение ресурса r2 еще не активизировано, то moment = not-defined)

release-moment e {not-defined} u ]0, Tmax] - момент освобождения ресурса от выполнения шага (если ресурс еще не освобожден, то release-moment = not-defined)

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

Примечание 2. Для каждого продукта может быть определено еще одно состояние, когда работы по созданию продукта уже ведутся, но продукт еще не создан. При необходимости это состояние можно получить из текущего состояния вершины task, из которой исходит соответствующая продукту дуга (т.е. из состояния шага, на котором создается рассматриваемый продукт: если этот шаг еще выполняется, значит, идет работа по созданию продукта).

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

6.1. Состояния вершин динамического графа, соответствующих задачам

Правило 1. Шаг еще не начал выполняться.

task-name(iK) e TaskS &

Started (starting-moment, K) & time-moment < starting-moment

_ (task-nameS1)(K'not-started'°' not-defmed> ^^e (TaskS)D

Комментарий. Состояние вершины task-name описывается пятеркой (K, not-started, 0, not-defined, not-defined), если шаг с номером K, на котором выполняется задача task-name, начал выполняться позже момента времени timemoment (см. выше Примечание 3).

Правило 2. Шаг выполняется.

task-name(i,K) e TaskS &

Started (starting-moment, K) & Finished (finishing-moment, K) & time-moment > starting-moment & time-moment < finishing-moment & Current-ratio (time-moment, K, P)

_^ (task nameS1)(K' started-not-finished, P, starting-moment, not-defined) e (TaskS)D

Комментарий. Состояние вершины task-name описывается пятеркой (K,started-not-finished, P, starting-moment, not-defined), если шаг с номером K, на котором выполняется задача task-name, начал выполняться в момент времени starting-moment, предшествующий моменту времени time-moment; был завершен позже момента времени time-moment; в момент времени time-moment был выполнен на P процентов.

Правило 3. Выполнение шага завершено.

task-name(i,K) e Tasks &

Started(starting-moment, K) & Finished (finishing-moment, K) & time-moment > finishing-moment

у (task-names1)(K'flnished' 100, starting-moment, finishing-moment) e (Tasks)D

Комментарий. Состояние вершины task-name описывается пятеркой (K,finished,100,starting-moment,finishing-moment), если шаг с номером K, на котором выполняется задача task-name, был завершен в момент времени finishing-moment, предшествующий моменту времени time-moment.

6.2. Состояния вершин динамического графа, соответствующих ресурсам

Правило 1. Ресурс свободен. resource-name e Res &

resource-name e Agent-names u Tool-names & V initiating-moment, release-moment

( (Performs*(initiating-moment, release-moment, resource-name, _) v Allocations*(initiating-moment, release-moment, resource-name, _)) & ((time-moment < initiating-moment) v (time-moment > release-moment) ) )

free -г-» RС

^ resource-name e Res Комментарий. Состояние вершины resource-name описывается меткой free, если в момент времени time-moment ресурс, представленный этой вершиной, не выполнял никакой работы по проекту.

Правило 2. Ресурс занят. resource-name e Res &

resource-name e Agent-names u Tool-names & 3 initiating-moment, release-moment ((Performs*(initiating-moment, release-moment, resource-name, _) v Allocations*(initiating-moment, release-moment, resource-name, _)) & ((initiating-moment < time-moment) & (time-moment < release-moment) ) ^ resource-nameoccupied e Res1^ Комментарий. Состояние вершины resource-name описывается меткой occupied, если в момент времени time-moment ресурс, представленный этой вершиной, выполнял работу по проекту.

6.3. Состояния дуг динамического графа, соответствующих передаче продуктов

Правило 1. Продукт не произведен. (task-name1(t1K1), task-name2(t2K2)) product-name e R1 &

Produced (production-moment, product-name) & time-moment < production-moment

^ ((task-name1(t1' K1), task-name2(t2' K2)) product-name) (not-Produced, not-defined) e RiPs

Комментарий. Состояние дуги (task-name 1, task-name2), помеченной рабочим продуктом product-name, описывается парой (not-produced, not-defined), если продукт product-name создан позже момента времени timemoment.

Правило 2. Продукт произведен.

(task-name1(t1K1), task-name2(t2K2)) product-name е R1 & Produced (production-moment, product-name) & time-moment > production-moment

^ ((task-name1(t1K1), task-name2(t2K2)) product-name) (produced> р^ш™^ e R1ps

Комментарий. Состояние дуги (task-name 1, task-name2), помеченной рабочим продуктом product-name, описывается парой (produced, production-moment), если продукт product-name создан в момент времени production-moment, предшествующий моменту времени time-moment.

6.4. Состояния дуг динамического графа, соответствующих текущим назначениям ресурсов

6.4.1. Назначения для ресурсов-исполнителей

Определим на основе отношения Performs (time-moment1, time-moment2, agent-name, effort-unit, ratio) (см. раздел 4.1) вспомогательное отношение Performs* (time-moment 1, time-moment2, agent-name, effort-unit), представляющее непрерывный промежуток времени, в течение которого исполнитель agent-name выполнял конкретное назначение effort-unit. В соответствии с определенными в разделе 4.2 правилами модельного исполнения плана проекта для каждой пары (agent-name, effort-unit) существует набор кортежей отношения Performs, в совокупности определяющих непрерывный временной интервал, в течение которого исполнитель фактически выполнял данное назначение. Соответственно, отношение Performs*, определяющее единственный кортеж для каждой пары (agent-name, effort-unit), может быть задано следующим правилом.

3 agent-name е Agent-names

(Performs (time-moment1, time-moment2, agent-name, effort-unit, _) & Current-time(_, delta) &

NOT (Performs (time-moment1 - delta, time-moment1, agent-name, effort-unit, _) ) &

Performs(time-moment3, time-moment4, agent-name, effort-unit, _) & NOT (Performs (time-moment4, time-moment4 + delta, agent-name,

effort-unit, _) )

^ Performs*(time-momentl, time-moment4, agent-name, effort-unit) ) Комментарий. Отношение Performs задает временные интервалы длиной delta, на которых исполнитель занимался некоторой работой. Записанное выше правило фактически объединяет несколько последовательных интервалов, заданных отношением Performs, в течение которых исполнитель выполнял одну и ту же работу, в один интервал, заданный отношением Performs*.

Правило 1. Исполнитель еще не начал работать на шаге. (agent-name, task-name(tK))role-name е R2 &

Assignments (effort-unit, agent-name, role-name, K, _) & Performs*(initiating-moment, _, agent-name, effort-unit) & time-moment < initiating-moment ^ ((agent-name, task-name(t'K))role-name)(not-performs' not-defmed> not-defined) е R2rs Комментарий. Состояние помеченной ролью role-name дуги графа между вершиной agent-name, представляющей исполнителя, и вершиной task-name(t,K), представляющей шаг с номером K, на котором выполняется задача task-name, описывается тройкой (not-performs, not-defined, not-defined), если на шаге с номером K исполнитель agent-name в роли role-name выполнял часть работы effort-unit, начиная с момента времени initiating-moment, и момент времени time-moment предшествует моменту времени initiating-moment.

Правило 2. Исполнитель работает на шаге. (agent-name, task-name(tK))role-name е R2 &

Assignments (effort-unit, agent-name, role-name, K, _) & Performs*(initiating-moment, release-moment, agent-name, effort-unit) & time-moment > initiating-moment & time-moment < release-moment ^ ((agent-name, task-name(t'K))role-name)(perfo^s' mitiating-moment> n°t-defined) е r2rs Комментарий. Состояние помеченной ролью role-name дуги графа между вершиной agent-name, представляющей исполнителя, и вершиной task-name(t,K), представляющей шаг с номером K, на котором выполняется задача task-name, описывается тройкой (performs, initiating-moment, not-defined), если на шаге с номером K исполнитель agent-name в роли role-name выполнял часть работы effort-unit, начиная с момента времени initiating-moment и до момента времени release-moment, и момент времени time-moment находится между моментами времени initiating-moment и release-moment.

Правило 3. Исполнитель закончил работать на шаге, (agent-name, task-name(tK))role-name е R2 &

Assignments (effort-unit, agent-name, role-name, K, _) & Performs*(initiating-moment, release-moment, agent-name, effort-unit) &

time-moment > release-moment

^ ((agent-name, task-name(t'K))role-name)(perfoimed' mitiating-moment> ^«тшц е r2rs

Комментарий. Состояние помеченной ролью role-name дуги графа между вершиной agent-name, представляющей исполнителя, и вершиной task-name(t,K), представляющей шаг с номером K, на котором выполняется задача task-name, описывается тройкой (performed, initiating-moment, release-moment), если на шаге с номером K исполнитель agent-name в роли role-name выполнял часть работы effort-unit, начиная с момента времени initiating-moment и до момента времени release-moment, и момент времени release-moment предшествует моменту времени time-moment.

6.4.2. Назначения для ресурсов-средств производства

Определим аналогичное отношению Performs* отношение Allocations*(time-moment1, time-moment2, tool-name, step) по следующему правилу.

3 tool-name, step

(Used-tools (tool-name, step, _) &

Started (time-moment1, step) &

Finished (time-moment2, step)

^ Allocations* (time-moment1, time-moment2, tool-name, step) )

Комментарий. Отношение Used-tools определяет назначение средств, используемых при выполнении шагов проекта. Отношение Allocations* определяет непрерывный промежуток времени, на котором средство tool-name использовалось при выполнении шага step.

Правило 1. Средство еще не начали использовать на шаге.

(tool-name, task-name(t,K)) е R2 &

Allocations* (initiating-moment, _, tool-name, K) & time-moment < initiating-moment ^ (tool-name, task-name(tK)) (not-performs> not-fed, nct-d^d) е r2rs

Комментарий. Состояние дуги графа между вершиной tool-name, представляющей средство, и вершиной task-name(t,K), представляющей шаг с номером K, на котором выполняется задача task-name, описывается тройкой (not-performs, not-defined, not-defined), если средство tool-name используется при выполнении шага с номером K, начиная с момента времени initiating-moment, и момент времени time-moment предшествует моменту времени initiating-moment.

Правило 2. Средство используют на шаге.

(tool-name, task-name(t,K)) е R2 &

Allocations* (initiating-moment, release-moment, tool-name, K) &

time-moment > initiating-moment & time-moment < release-moment ^ (tool-name, task-name(tK)) (performs=initiating-moment, not-defined) e R2RS Комментарий. Состояние дуги графа между вершиной tool-name, представляющей средство, и вершиной task-name(tK), представляющей шаг с номером K, на котором выполняется задача task-name, описывается тройкой (performs, initiating-moment, not-defined), если средство tool-name используется при выполнении шага с номером K, начиная с момента времени initiating-moment и до момента времени release-moment, и момент времени time-moment находится между моментами времени initiating-moment и release-moment.

Правило 3. Средство закончили использовать на шаге.

(tool-name, task-name(t,K)) &

Allocations* (initiating-moment, release-moment, tool-name, K) & time-moment > release-moment ^ (tool-name, task-name(tK)) (performed,initiating-moment,reiease-moment) e R2rs

Комментарий. Состояние дуги графа между вершиной tool-name, представляющей средство, и вершиной task-name(t,K), представляющей шаг с номером K, на котором выполняется задача task-name, описывается тройкой (performed, initiating-moment, release-moment), если средство tool-name используется при выполнении шага с номером K, начиная с момента времени initiating-moment и до момента времени release-moment, и момент времени release-moment предшествует моменту времени time-moment.

6.5. Приращение динамического графа

В дополнение к динамическому графу Gd(time-moment), представляющему состояния элементов модели плана проекта в заданный момент времени процесса исполнения, определим приращение динамического графа AGd(time-moment1, time-moment2) = Gd(time-moment2) - Gd(time-momentl) как подграф динамического графа Gd(time-moment2), который представляет прогресс выполнения плана проекта на заданном промежутке времени.

Пусть Gd(time-moment 1) = <(TaskS)D1, ResRa, (R1PS1,R2RS1)> -динамический граф в момент времени time-moment1,

Gd(time-moment2) = <(TaskS)D2, Res^2, (R1PS2,R2RS2)> - динамический граф в момент времени time-moment2,

тогда AGd(time-moment1, time-moment2) = <(ATaskS)AD, ARes^^ (AR1, AR2ARS)> - приращение динамического графа на промежутке времени [timemoment!, time-moment2], которое содержит только те элементы графа Gd(time-moment2), состояния которых изменились по сравнению с элементами графа Gd(time-moment1).

Состояния вершин приращения динамического графа определяются в виде правил, аналогичных правилам определения состояний вершин динамического графа (разделы 6.1. - 6.4.).

7. Меры и дефекты плана программного проекта

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

Для формального определения мер и дефектов используются статическая (см. раздел 3) и динамическая (см. раздел 4) реляционные модели плана проекта [Мат02а], ее статический граф G = <Task , Res, (R1, R2)> (см. раздел 5), динамический граф Gd(time-moment) = <(TaskS)D, Res^, (R1PS, R2RS)> и приращение динамического графа на промежутке времени AGd(time-moment1, time-moment2) = <(ATaskS)AD, ARes^, (AR1, AR2ARS)> (см. раздел 6).

7.1. Меры плана программного проекта

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

Мера 1. Продолжительность проекта.

Неформальное определение: фактическая продолжительность программного проекта (сетевое время (net process time [14], длина критического пути (critical path [16])).

Формальное определение:

Current-time (time-moment, _) ^ net-process-time = time-moment

Примечание. Здесь и далее символ "_" в отношении означает вхождение анонимной свободной переменной.

Комментарий. В соответствии с описанным в разделе 4.3 универсальным рецептом, в каждом состоянии рабочей среды Wi процесса исполнения модели плана проекта существует только один кортеж отношения Current-time, который представляет текущее время проекта. Тем самым, по окончании процесса исполнения значение переменной time-moment представляет фактическую продолжительность модельного исполнения проекта.

Мера 2. Занятость исполнителя в проекте.

Неформальное определение: процентная доля времени занятости исполнителя в проекте по отношению к общей продолжительности проекта.

Формальное определение:

3 agent-name е Agent-names

(time-intervals = {time-moment | (Performs (time-moment,_,agent-name,_,_) & V time-moment1, time-moment2 е time-intervals (time-moment1 Ф time-moment2) ) } ^ agent-usage-time-ratio (agent-name) =

|time-intervals| / net-process-time * 100 )

Примечание 1. Здесь и далее единицей измерения времени является длина единичного интервала delta, определяемая отношением Current-time.

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

Комментарий. Каждый кортеж отношения Performs определен на промежутке времени длиной delta. В соответствии с правилами моделирования выполнения шага проекта (см. три варианта Правила 3 в разделе 4.2), на каждом таком промежутке исполнитель может либо находиться в состоянии "свободен" (если его список назначений пуст), либо быть полностью занятым выполнением работы из текущего списка назначений. Тем самым, время, затраченное исполнителем на работу в проекте, определяется суммарным размером промежутков "занятости" исполнителя. Процентная доля времени, затраченного исполнителем на работу в проекте, по отношению к общей продолжительности проекта (см. Мера 1) определяет значение рассматриваемой меры.

Мера 3. Средний уровень занятости исполнителей в проекте (при установленных назначениях).

Неформальное определение: средняя (медианная) доля занятости исполнителей в проекте (относительно общей продолжительности проекта).

Формальное определение:

V agent-name е Agent-names

(all-agent-usage-time-ratios = { agent-usage-time-ratio (agent-name) } ^ resource-capacity-usage-ratio = median (all-agent-usage-time-ratios) )

Примечание. Функция median находит среднее медианное значение для заданного набора значений.

Комментарий. Для каждого исполнителя вычисляется процентная доля времени его занятости в проекте (см. определение Меры 2). Для полученного набора значений при помощи функции median вычисляется средняя процентная доля занятости исполнителей в проекте.

Мера 4. Продолжительность выполнения вида деятельности.

Неформальное определение: фактическая продолжительность выполнения вида деятельности в проекте.

Формальное определение:

3 activity-name

(Activities (activity-name, List-of<task-name>) & 3 first-task e List-of<task-name>

(3 first-step (Project-steps (first-step, first-task, ...) & Started (earliest-moment, first-step) &

V task-name1 e List-of<task-name>\{first-task}

(V step1 (Project-steps (step1, task-name1, ...) & Started (time-moment1, step1) & earliest-moment < time-moment1 ) ) v List-of<task-name> = {first-task} & 3 last-task e List-of<task-name>

(3 last-step (Project-steps (last-step, last-task, .) & Finished (latest-moment, last-step) &

V task-name2 e List-of<task-name>\{last-task}

(V step2 (Project-steps (step2, task-name2, .) & Finished (time-moment2, step2) & latest-moment > time-moment2 ) ) v List-of<task-name> = {last-task} ^ activity-process-time (activity-name) = latest-moment - earliest-moment

) ) ) ) )

Примечание. Здесь и далее символ "..." в отношении означает вхождение множества анонимных свободных переменных.

Комментарий. В составе вида деятельности activity-name существуют задача first-task, выполнение которой началось раньше (не позже) выполнения всех остальных задач этого вида деятельности, и задача last-task, выполнение которой завершилось позже (не раньше) выполнения всех остальных задач этого вида деятельности. Фактическое время выполнения вида деятельности определяется промежутком времени от момента начала выполнения задачи first-task до завершения выполнения задачи last-task. В самом тривиальном случае вид деятельности содержит только одну задачу, продолжительность выполнения которой и определяет продолжительность выполнения этого вида деятельности.

7.2. Дефекты плана программного проекта

Спецификация каждого дефекта описана ниже в форме правила логического вывода с параметрами. Значения параметров задаются до начала этапа анализа плана и оказывают существенное влияние на результаты

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

- название дефекта;

- значения заданных параметров правила выявления дефекта;

- фактические значения атрибутов компонентов плана, которые удовлетворяют условию наличия дефекта;

- ссылка на компонент плана, к которому относится выявленный дефект, путем локализации соответствующего фрагмента статического графа. При этом используется функция Visualize (graph-fragment), где graph-fragment е Task u Res и R2 - фрагмент статического графа. Эта функция реализует операцию визуализации заданного фрагмента.

7.2.1. Дефекты плана программного проекта, определяемые по его статической модели

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

Дефект 1.1.

Неформальное определение: назначение на роль исполнителя с недостаточным опытом.

Параметр: число проектов, участие в которых в такой же роли, как и в рассматриваемом проекте, дает исполнителю достаточный опыт.

Формальное определение:

3 agent-name, role-name, step

(Assignments (_, agent-name, role-name, step, _) & Staff (agent-name, _, _, _, experience-records) & Parameter-sufficient-experience (role-name, #previous-projects) & relevant-records = { <_,_, role-name,.. .> е experience-records } & |relevant-records| < #previous-projects ^ unexperienced-agent (agent-name, #previous-project, |relevant-records|) & Visualize ((agent-name, task-name(t' step))role-name е R2) )

Примечание 1. Здесь и далее значение переменной t в следствии правила однозначно определяется значениями переменных task-name и step (согласно определению статического графа, приведенному в разделе 5).

Примечание 2. Операция { }, введенная при определении Меры 2, в данном случае обеспечивает построение множества записей (которые могут повторяться), каждая из которых удовлетворяет следующему условию: запись принадлежит множеству experience-records и описывает работу исполнителя в предыдущих проектах в роли role-name.

Комментарий. На шаге step на роль role-name назначен исполнитель agent-name, причем число проектов, в которых он выполнял эту роль ранее, меньше числа проектов, участие в которых (в соответствии с заданным значением параметра) дает исполнителю достаточный опыт для выполнения данной роли. Если это условие наличия дефекта выполнено, в графе G будет локализована дуга, соответствующая "дефектному" назначению, в сопровождении информации об имени исполнителя, заданном значении параметра и числе проектов, в которых исполнитель участвовал в данной роли.

Дефект 1.2.

Неформальное определение: недостаточное назначение исполнителей для выполнения шага.

Формальное определение:

3 step (Project-steps (step, task-name, _, _, List-of<role-name, _>, ... ) & 3 role-name (<role-name, _> e List-of<role-name, _> & NOT (Assignments (_, _, role-name, step, _))

^ vacant-role (role-name) & Visualize(task-name(tstep) e TaskS) ) )

Комментарий. На шаге step существует роль role-name, для выполнения которой не назначен ни один исполнитель. Если это условие наличия дефекта выполнено, в графе G будет локализована вершина, соответствующая шагу step, в сопровождении названия роли, на которую не назначен исполнитель.

7.2.2. Дефекты плана программного проекта, проявляющиеся в процессе

его выполнения

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

Дефект 2.1.

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

Вариант 1 (для нескольких "задерживающих" продуктов).

Параметры:

1) промежуток времени, задержка в течение которого считается допустимой (задается числом единичных интервалов длиной delta),

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

Формальное определение:

3 step (Project-steps (step, task-name, List-of<(*IN*) product-ref>, ...) & 3 product-ref1, product-ref2 е List-of<(*IN*) product-ref> (Produced (time-moment1, product-ref1) & Produced (time-moment2, product-ref2) & Parameters-step-delay (time-period, product-ratio) & time-moment2 - time-moment1 > time-period &

V product-ref3 е List-of<(*IN*) product-ref> (Produced (time-moment3, product-ref3) &

(time-moment3 < time-moment1 v time-moment3 > time-moment2) ) & product-set = { product-ref4 е List-of<(*IN*) product-ref > (Produced (time-moment4, product-ref4) & time-moment4 > time-moment2) } & |product-set| < |List-of<(*IN*) product-ref>|* product-ratio/100 ^ step-delay (time-period, product-ratio, product-set) & Visualize(task-name(t step) е TaskS) ) )

Комментарий. При выполнении проекта имеет место следующая ситуация: существуют две группы входных продуктов шага step, причем продукты второй группы были созданы значительно позже (более чем через заданное время time-period), по сравнению с продуктами первой группы, и при этом число продуктов второй группы (созданных позже) составляет незначительную долю (не более чем заданная доля product-ratio) от общего числа входных продуктов шага step. Если это условие наличия дефекта выполнено, в графе G будет локализована вершина, соответствующая шагу step, в сопровождении информации о параметрах и множестве продуктов, из-за неготовности которых произошла задержка начала выполнения шага.

Вариант 2 (для одного "задерживающего" продукта).

Параметр: промежуток времени, задержка в течение которого считается допустимой (задается числом единичных интервалов длиной delta).

Формальное определение:

3 step (Project-steps(step, task-name, List-of<(*IN*) product-ref>, ...) )& 3 product-ref е List-of<(*IN*) product-ref> (Produced (time-moment1, product-ref) &

V product-ref2 е List-of<(*IN*) product-ref>\{product-ref}

(Produced (time-moment2, product-ref2) & time-moment1 > time-moment2 ) & 3 product-ref3 e List-of<(*IN*) product-ref>\{product-ref} (Produced (time-moment3, product-ref3) &

V product-ref4 e List-of<(*IN*) product-ref>\{product-ref, product-ref3} (Produced (time-moment4, product-ref4) & time-moment3 > time-moment4 ) v List-of<(*IN*) product-ref>\ {product-ref, product-ref3} = 0 & Parameter-step-delay-by-one-product (time-period) & time-moment1 - time-moment3 > time-period ) ^ step-delay-by-one-product (time-period, product-ref) & Visualize(task-name(t step) e TaskS) ) )

Комментарий. Существует входной продукт product-ref шага step, созданный позже всех остальных входных продуктов этого шага, причем ни один из других входных продуктов шага step не был создан в течение промежутка времени заданной длины time-period до момента создания продукта product-ref, где длина промежутка time-period определяет допустимое время задержки начала выполнения шага. Если это условие наличия дефекта выполнено, в графе G будет локализована вершина, соответствующая шагу step, в сопровождении информации о заданной длине промежутка времени и идентификаторе продукта, из-за неготовности которого произошла задержка начала выполнения шага.

Дефект 2.2.

Неформальное определение: существует исполнитель, который простаивает в течение длительного промежутка времени.

Параметр: максимальный промежуток времени, в течение которого простаивание исполнителя считается допустимым (задается числом единичных интервалов длиной delta).

Формальное определение:

3 time-moment1, time-moment2 e [0, Tmax] (time-moment1 < time-moment2 & 3 agent-name (V time-moment3 (Assumptions (time-moment3, agent-name, List-of<effort-unit>) & time-moment1 < time-moment3 & time-moment3 < time-moment2 & |List-of<effort-unit>| = 0 & Parameter-max-staying-time (time-period) & time-moment2 - time-moment1 > time-period ^ nonoperating-agent (time-period, time-moment1, time-moment2) & Visualize(agent-name e Res) ) ) )

Комментарий. Существует промежуток времени [time-moment 1, time-moment2], в течение которого исполнитель agent-name не выполнял работы по данному проекту, и длина этого промежутка превышает заданный допустимый период простаивания исполнителей time-period. Если это условие наличия дефекта выполнено, в графе G будет локализована вершина, соответствующая исполнителю agent-name, в сопровождении информации о заданном значении параметра и промежутке времени, с которым связано наличие рассматриваемого дефекта.

Дефект 2.3.

Неформальное определение: существует средство, которое простаивает в течение длительного промежутка времени (задаваемого числом единичных интервалов длиной delta).

Параметры:

1) уникальный идентификатор средства,

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

Формальное определение:

3 time-moment1, time-moment2 е [0, Tmax] (time-moment1 < time-moment2 & 3 tool-name (V time-moment3 (Allocations (time-moment3, tool-name, List-of<step>) & time-moment1 < time-moment3 & time-moment3 < time-moment2 & |List-of<step>| = 0 &

Parameters-not-used-tool (tool-name, time-period) & time-moment2 - time-moment1 > time-period

^ not-used-tool (time-period, time-moment1, time-moment2) & Visualize (tool-name е Res) ) ) )

Комментарий. Существует промежуток времени [time-moment 1, time-moment2], в течение которого средство tool-name не использовалось, и длина промежутка превышает заданный допустимый период простаивания этого средства time-period. Если условие наличия дефекта выполнено, в графе G будет локализована вершина, соответствующая средству tool-name, в сопровождении информации о заданном значении параметра time-period и промежутке времени, с которым связано наличие рассматриваемого дефекта.

Дефект 2.4.

Неформальное определение: существует исполнитель, который на некотором промежутке времени (или в момент времени, если длина этого промежутка

равна 0) был вынужден одновременно выполнять слишком большое число работ.

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

Формальное определение:

3 time-momentl, time-moment2 е [0, Tmax] (time-momentl < time-moment2 & 3 agent-name (V time-moment3 (Assumptions (time-moment3, agent-name, List-of<effort-unit>) & time-moment1 < time-moment3 & time-moment3 < time-moment2 & Parameter-max-assumptions-for-agent (#effort-units) & |List-of<effort-unit>| > #effort-units

^ too-many-assumptions-for-agent (#effort-unit,

|List-of<effort-unit>|, time-momentl, time-moment2) & Visualize (agent-name е Res) ) ) )

Комментарий. Существует промежуток времени, в течение которого исполнитель agent-name одновременно выполнял больше максимально допустимого числа работ #effort-units. Если это условие наличия дефекта выполнено, в графе G будет локализована вершина, соответствующая исполнителю agent-name, в сопровождении информации о значении параметра, фактическом числе работ, которые был вынужден выполнять исполнитель, и промежутке времени, с которым связано наличие рассматриваемого дефекта.

Дефект 2.5.

Неформальное определение: существует средство, одновременно использовавшееся на некотором промежутке времени при выполнении большого числа работ.

Параметры:

1) уникальный идентификатор средства,

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

Формальное определение:

3 time-momentl, time-moment2 е [0, Tmax] (time-moment1 < time-moment2 & 3 tool-name (V time-moment3 (Allocations (time-moment3, tool-name, List-of<step>) & time-momentl < time-moment3 & time-moment3 < time-moment2 &

Parameters-max-allocations-for-tool (tool-name, #steps) & |List-of<step>| > #steps

^ too-many-allocations-for-tool (#steps,

|List-of<step>|, time-moment1, time-moment2) & Visualize (tool-name е Res) ) ) )

Комментарий. Существует промежуток времени, в течение которого средство tool-name одновременно использовалось при выполнении более чем максимально допустимого числа шагов #steps. Если это условие наличия дефекта выполнено, в графе G будет локализована вершина, соответствующая средству tool-name, в сопровождении информации о заданном значении параметра #steps, фактическом числе шагов, выполнявшихся средством, и промежутке времени, с которым связано наличие рассматриваемого дефекта.

Дефект 2.6.

Неформальное определение: продолжительность выполнения проекта значительно превышает плановое значение.

Параметры:

1) плановая продолжительность проекта,

2) процентная доля допустимого превышения плановой продолжительности для данного проекта.

Формальное определение:

Parameters-project-duration (planned-project-duration, duration-ratio) &

net-process-time > planned-project-duration + planned-project-duration *

duration-ratio / 100

^ project-time-overflow

Комментарий. Если значение продолжительности проекта (Мера 1) превышает запланированную продолжительность выполнения проекта более чем на заданный в процентах размер допустимого отклонения duration-ratio, имеет место рассматриваемый дефект.

Дефект 2.7.

Неформальное определение: продолжительность выполнения вида деятельности значительно превышает плановое значение для этого вида деятельности.

Параметры:

1) название вида деятельности,

2) плановая продолжительность выполнения вида деятельности,

3) процентная доля допустимого превышения плановой продолжительности для данного вида деятельности.

Формальное определение:

Parameters-activity-duration (activity-name, planned-duration, duration-ratio) &

activity-process-time (activity-name) > planned-duration + planned-duration *

duration-ratio / 100

^ activity-duration-overflow (activity-name) Комментарий. Если продолжительность выполнения вида деятельности превышает плановое значение planned-duration более чем на заданный в процентах размер допустимого отклонения duration-ratio, имеет место рассматриваемый дефект. Если это условие наличия дефекта выполнено, будут локализованы либо вершины в графе G, соответствующие всем шагам проекта, на которых выполняются задачи, входящие в вид деятельности activity-name, либо вершина, соответствующая виду деятельности activity-name (при визуализации графа на уровне видов деятельности).

Дефект 2.8.

Неформальное определение: отсутствие прогресса в течение значительного времени.

Параметр: промежуток времени, в течение которого отсутствие прогресса в проекте считается допустимым (задается ненулевым числом единичных интервалов длиной delta).

Формальное определение:

Parameter-max-time-without-progress (time-period) &

3 time-moment1, time-moment2 e [0, Tmax] (time-moment2 - time-moment1 > time-period &

AGd(time-moment1, time-moment2) = <(ATaskS)AD, ARes, (AR1, AR2ARS)> & (ATaskS)AD = 0 & AResARC = 0 & AR1 = 0 & AR2ARS = 0

^ no-progress (time-period, time-moment1, time-moment2 ) Комментарий. Существует промежуток времени, длина которого превышает заданное значение time-period, и приращение динамического графа AGd, построенное на этом промежутке времени, не содержит ни одного элемента.

8. Постановка задачи улучшения плана программного проекта

Целью этого раздела является постановка задачи улучшения плана программного проекта в контексте определенных в разделах 3-6 моделей, а также мер и дефектов, описанных в разделе 7, и схемы на рисунке. Предполагается, что улучшение производится менеджером путем "ручного" выполнения операции модификации плана и в контексте заданных критериев. Введем определения и обозначения, используемые далее при постановке задачи улучшения.

SD

Пусть М - модель плана программного проекта, M = M u M

SD

(parameters), где M - статическая модель плана, M - модель процесса его исполнения при заданных значениях параметров parameters (см. разделы 3 и 4).

Под модификацией модели M понимается либо (1) такое преобразование статической модели M , которое соответствует изменению множеств вершин Res и дуг R2 статического графа G и разметки S, но не изменяет множеств вершин Task и дуг R1 (см. раздел 5), либо (2) изменение значений параметров процесса выполнения parameters без изменения статической модели M .

В разделе 7 данной работы определен набор мер и типов дефектов, каждый из которых устанавливает одну из размерностей для характеристик плана проекта. Предполагается, что с каждым дефектом связан не просто признак его наличия в модели, а счетчик числа таких дефектов Defi. Очевидно, что улучшение в терминах этих счетчиков означает минимизацию числа дефектов каждого типа (Def < Const), вплоть до полного их устранения (Defi.= 0). Тем самым, каждый счетчик дефектов устанавливает абсолютную шкалу, где отношение "лучше" соответствует отношению "<" на множестве натуральных чисел.

Улучшение в терминах меры продолжительность проекта (Мера 1) и меры продолжительность выполнения вида деятельности (Мера 4) означает минимизацию их значений. При этом оптимальным значением такой меры может быть либо запланированная продолжительность выполнения проекта/вида деятельности, если целью является просто их своевременное выполнение, либо наименьшее (найденное экспериментально) значение, если целью является сокращение продолжительности выполнения проекта/вида деятельности.

Улучшение в терминах мер занятость исполнителя в проекте (Мера 2) и средний уровень занятости исполнителей в проекте (Мера 3) означает максимизацию их значений. Идеальное значение этих мер 100% (в этом случае возможности исполнителей полностью использовались в течение всего времени выполнения проекта).

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

Формальное определение понятия "улучшение" плана проекта требует задания комплексного критерия С, базирующегося на наборе размерностей {D1,..,Dn}, где каждая размерность Di связана с одной из мер (см. раздел 7.1) либо с числом дефектов определенного типа (см. раздел 7.2), и описания диапазона приемлемых значений соответствующей шкалы путем задания

пороговых значений (т.е. критерия Q в форме Di > Const или Di < Const). Для критериев Q могут быть также заданы веса, выражающие относительную важность критериев (при этом сумма заданных весов для множества {С1,..,Сп} должна быть равна 1). Тем самым, комплексный критерий С может быть задан одним из следующих трех способов:

(1) арифметическим выражением - взвешенной суммой всех критериев Ci, где достигнутым критериям соответствует значение 1, а не достигнутым -значение 0;

(2) предикатом - логическим выражением, содержащим операции дизъюнкции и конъюнкции над отдельными критериями Q, играющими роль операндов;

(3) кортежем (выборкой) учитываемых размерностей {D1,..,Dn}, где каждый элемент Di связан с определенной мерой или числом дефектов определенного типа.

Фактически заданный комплексный критерий С играет роль непрямой меры качества при измерении плана проекта в каждом конкретном случае.

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

Задача 1. Оценивание плана программного проекта.

Дано:

- модель М;

- комплексный критерий С, заданный способами (1) или (2), а также минимальное приемлемое значение V в случае задания С способом (1) (т.е. С > V, где 0 < V < 1). (При задании С способом (2) приемлемым значением является true для заданного логическим выражением предиката.)

Определить: удовлетворяет ли модель M комплексному критерию С.

Задача 2. Экспериментальное итеративное улучшение плана проекта.

Дано:

- комплексный критерий С, заданный способами (1) или (3),

- модели М и M', где М не удовлетворяет критерию С, и M' получена из M в результате модификации.

Определить: является ли модификация M' по отношению к модели M улучшением относительно заданного комплексного критерия С.

Примечание 1. В случае задания С способом (1) M' считается лучше M, если С(М) > С(М). В случае задания С способом (3) M' считается лучше M, если среди выборки учитываемых размерностей {D1,..,Dn} существует хотя бы одна такая, с точки зрения которой модель M' "лучше" модели М, при том что с точки зрения остальных размерностей модель M' не хуже модели М. Следует отметить, что во втором случае модели M и M' могут оказаться несравнимыми, тогда оценка эффекта от улучшения должна выполняться самим менеджером

путем сравнения соответствующих кортежей значений мер и принятия "волевого" решения.

Примечание 2. В случае если критерий С задан способом (1), предполагается, что итеративная модификация модели М продолжается до тех пор, пока он не будет достигнут.

Заключение

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

1. Реляционная модель, описывающая компоненты процесса производства ПО (задачи, порождаемые ими продукты и используемые ресурсы), их атрибуты и связи между ними, а также ограничения конкретных программных проектов. Разработанная модель согласуется с такими международными стандартами, как КОЛЕС 12207 [12], КОЛЕС 15504 [13], 1ЕЕЕ/Е1А 12207 [9, 10], а также с практикой промышленного программирования, описанной в специальной литературе, и позволяет формально специфицировать план программного проекта.

2. Проблемно-ориентированное исчисление, описывающее "динамику" модели. Оно дает возможность, запустив условные "часы" проекта, моделировать определенные события и атрибуты процесса его исполнения, что позволяет приблизить поведение модели к поведению реального проекта. Предложенное исчисление было реализовано средствами языка Пролог, вместе с тем возможна его более эффективная реализация алгоритмическим средствами.

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

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

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

Литература

1. Артемьева И.Л., Яценко О.С. Модель декларативных продукций с обобщенными операциями: Препринт. Владивосток: ИАПУ ДВО РАН,

1998. 31 c.

2. Артемьева И. Л., Яценко О.С. Модель декларативных продукций с обобщенными операциями (кванторами) N-го порядка: Препринт. Владивосток: ИАПУ ДВО РАН, 1998. 29 c.

3. Успенский В. А., Семенов А.Л. Теория алгоритмов: основные открытия и применения. М.: Наука, 1987. 288 с.

4. Bandinelli S, .Fuggetta A. et al., SPADE: An Environment for Software Process Analysis, Design, and Enactment / Software Process Modeling and Technology (ed. by Finkelstein A., Kramer J., Nuseibeh B.). J. Willey & Sons Inc., 1994. P. 223-247.

5. Byrnes P., Phillips M. Software Capability Evaluation, Version 3.0, Method Description, CMU/SEI-96-TR-002. Software Engineering Institute, 1996.

6. Fenton N.E., Pfleeger S.L. Software metrics: A rigorous and practical approach. Second edition. International Tompson Computer Press, 1996. 638 p.

7. Garg P., Jazayeri M. Process-Centred Software Engineering Environments: A Grand Tour / Software Process (ed. by Fuggetta A., Wolf A.). J. Willey & Sons Ltd., 1996. P. 25-52.

8. Huff K. E. Software Process Modeling / Software Process (ed. by Fuggetta A., Wolf A.). J. Willey & Sons Ltd., 1996. P. 1-24.

9. IEEE/EIA 12207.0-1996. Industry Implementation of International Standard ISO/IEC 12207:1995 - Information Technology - Software life cycle processes // IEEE Software Engineering Standards, Volume One, Customer and Terminology Standards. IEEE, Inc. 1999. 85 p.

10. IEEE/EIA 12207.1-1997. IEEE/EIA Guide for Information Technology. Software life cycle processes - Life cycle data // IEEE Software Engineering Standards, Volume One, Customer and Terminology Standards. IEEE, Inc.

1999. 36 p.

11. ISO/IEC 9126:1991.Information technology - Software quality evaluation -Quality characteristics and guidelines for their use. Geneva: ISO, 1991. 17 p.

12. ISO/IEC 12207:1995. Information technology - Software life cycle processes. Geneva: ISO, 1995. 57 p.

13. ISO/IEC 15504:1998. Information technology - Software process assessment. 9 parts. Geneva: ISO, 1998.

14. Mou G.G. A graph-based process representation for process modeling // Journ. of System Integration. 1998. N. 8. P. 133-142.

15. Paulk M.C., Curtis B. et al. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24. Software Engineering Institute, 1993.

16. Pressman R.S. Software Engineering: Practitioner's Approach. Fifth edition. McGraw-Hill Inc., 2001. 860 p.

17. Reiter R. On Closed World Data Bases / Logic and Data Bases (ed. by Gallaire H., Minker J.), N. Y.: Plenum Press, 1978. P. 55-76.

18. Snowdon R.A., Warboys B.C. An Introduction to Process-Centred Environments / Software Process Modeling and Technology (ed. by Finkelstein A., Kramer J., Nuseibeh B.). J. Willey & Sons Inc., 1994. P. 1-8.

19. http://www.rspa.com/apm/