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

(* перечень рабочих продуктов, создаваемых в процессе производства *) 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 е [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 е 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 е 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>) &