Популярное

Мифы о звукоизоляции



Как построить дом из пеноблоков



Как построить лестницы на садовом участке



Подбираем краску для ремонта



Каркасные дома из дерева


Главная » Улучшение плана программного

1 2 3 4 ... 6

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

Матвеева Т.О., Старовойтов И.В. (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). Он получает доступ



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


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

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



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

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 управляющие связи между видами деятельности и некоторыми задачами*))

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





1 2 3 4 ... 6
© 2017 РубинГудс.
Копирование запрещено.