Т.О. Матвеева, И.В. Старовойтов (ИАПУ ДВО РАН)

Введение

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

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

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

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

(г) изменение плана с целью минимизации/максимизации значений метрик,

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

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

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

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

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

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

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

Общая схема предлагаемого подхода

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

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

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

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

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

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

Например, ограничения, связанные с шагами проекта, описываются в реляционной модели следующим отношением:

Constraints

(step, (* идентификатор шага, на который наложено ограничение *)

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

List-of-tool-name, (* список критичных для данного шага средств *)

sign, (* признак снятия ограничения извне *)

constrained-date (* дата, ранее которой шаг не может начать выполняться *))

Описанная модель согласуется с такими международными стандартами как ISO/IEC 12207 [4], ISO/IEC 15504 [5] и с практикой промышленного программирования [6].

Моделирование процесса выполнения плана проекта

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

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

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

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

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

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

1) Отношений, описывающих сам исполняемый план. Значения этих отношений не меняются в процессе исполнения плана, и в каждом состоянии Wi они одинаковы.

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

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

3) Отношений, описывающих текущее состояние процесса исполнения модели плана проекта - текущие назначения ресурсов, моменты запуска и завершения шагов проекта, процентные доли выполнения шагов проекта, моменты создания рабочих продуктов. Например, состояния исполнителей, занятых в проекте, определяются следующим отношением:

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

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

Конечное состояние. Конечным состоянием рабочей среды Wi является состояние, полученное в результате применения правила остановки (см. ниже). Проблемно-ориентированные правила (применение которых регламентируется универсальным рецептом) определяют операции добавления множества новых кортежей к текущему состоянию рабочей среды Wi. Синтаксис правил основан на работах [8, 9]. Его использование позволяет сделать правила более компактными по сравнению с традиционными способами их описания. При этом все переменные, для которых явно не задана область их действия, считаются находящимися под квантором существования, начиная с момента их указания и в пределах области, ограниченной скобками соответствующего уровня вложенности. Например, правило инициализации шага проекта в соответствии с наступлением календарной даты его запланированного начала выглядит следующим образом:

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

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

NOT (Started (_, step) ) & (&(" product Î List-of-in-product-ref)

Produced (_, product) ) &

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

(NOT (Constraints (step, _, _, _, _) ) Ú

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

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

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

В качестве универсального правила вывода в данном исчислении используется правило modus ponens и гипотеза о замкнутости мира [10], в соответствии с которой отрицание интерпретируется как неудача (т.е. как отсутствие в текущем состоянии рабочей среды Wi соответствующего кортежа). Описанное проблемно-ориентированное исчисление обладает свойством монотонности относительно значений предикатов, использованных под отрицанием. Дополнительным правилом вывода является правило смены текущего момента времени.

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

(&("product-ref (Products (product-ref, _, ...) ) Produced (_, product-ref)) Ú

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

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

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

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

Графовые модели плана проекта

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

Статический граф G = <Task^S, Res, (R1, R2)>; - многослойный ориентированный граф, где Task - вершины графа, представляющие множество задач плана программного проекта, множество пар S - разметка вершин Task, определяющая шаги проекта и частичный порядок их выполнения, R1 - дуги, представляющие передачу продуктов между задачами проекта, Res - вершины, представляющие ресурсы, R2 - дуги, представляющие назначение ресурсов для выполнения шагов проекта. Такой граф обеспечивает визуализацию фрагментов структуры плана программного проекта, отражая видение плана как сети задач с назначенными для их выполнения ресурсами.

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

Task - множество вершин графа, представляющих множество задач плана программного проекта, Task = {task-name₁, ..., task-name_k}, "i = 1,k (task-name_i Î Task-names), и при этом

$ task-name ÎTask « $ task-name (Tasks(task-name, _,_))

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

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

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

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

Определим G^d (time-moment) = <(Task^S)^D, Res^RС, (R1^PS,R2^RS)> - динамический граф, описывающий состояния вершин и дуг статического графа G в заданный момент процесса исполнения time-moment (time-moment Î [0, T], где дискретное множество [0, T] содержит "такты" условного времени модельного исполнения проекта, заданные значением параметра delta, T - полученная "тактовая" продолжительность процесса модельного исполнения). Множества D, RС, PS и RS представляют возможные состояния элементов графа в заданный момент времени. Например, вершина task^(s1,s2), представляющая шаг проекта, помечается пятёркой (step, step-status, step-progress, starting-moment, finishing- moment) Î D, где step - номер шага, step-status - состояние шага в момент времени time-moment, step-progress - доля выполненной работы на шаге, starting-moment, finishing-moment - моменты начала и завершения выполнения шага. Для всех элементов графа заданы правила определения их состояний при заданном статическом графеG плана проекта и динамической реляционной модели процесса его выполнения.

Приращение динамического графа DG^d(time-moment1, time-moment2) - подграф динамического графа G^d(time-moment2), содержащий только те его элементы, состояния которых не совпадают с их состояниями в графе G^d(time-moment1). Эта модель обеспечивает визуализацию прогресса проекта на заданном промежутке времени. Элементы, входящие в приращение динамического графа, и их состояния, определяются правилами, аналогичными правилам определения состояний вершин динамического графа.

Метрики и дефекты плана проекта

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

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

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

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

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

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

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

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

Программное средство для моделирования, измерения и оценивания планов программных проектов

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

Разработанное ПС позволяет руководителю проекта по разработке ПО провести полный цикл моделирования плана проекта, включающий:

- построение статической модели плана проекта,

- её исполнение и генерацию динамической модели, описывающей процесс модельного исполнения плана,

- измерение формальной модели плана проекта,

- её оценивание на основе заданных критериев,

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

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

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

Заключение

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

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

2. Проблемно-ориентированное исчисление, описывающее "динамику" модели.

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

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

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

Список литературы

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

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

3. Матвеева Т.О., Старовойтов И.В. Улучшение плана программного проекта на основе анализа характеристик его формальной модели. Электронный журнал "Исследовано в России", 6, 1716-1767, 2003. http://zhurnal.ape.relarn.ru/articles/2003/144.pdf

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

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

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

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

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

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

10. 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.