Содержание к диссертации
Введение
Глава 1. Стандарты процесса производства программного обеспечения, средства и формальные методы моделирования планов программных проектов 11
1.1 Основные понятия, используемые при моделировании процесса производства программного обеспечения 13
1.2 Основные стандарты, связанные с процессом производства программного обеспечения 17
1.3 Формальное моделирование процессов производства программного обеспечения 25
1.4 Выводы из обзора и задачи диссертационной работы . 37
Глава 2. Формальные модели плана программного проекта . 39
2.1 Основные компоненты модели процесса производства программного обеспечения 39
2.2 Общая схема моделирования и улучшения плана программного проекта 43
2.3 Реляционная модель процесса производства программного обеспечения 45
2.4 Динамическая модель плана программного проекта . 60
2.5 Статический граф плана программного проекта... 69
2.6 Динамический граф плана программного проекта . 78
2.7 Специфицирование и визуализация плана программного проекта 92
2.8 Выводы к главе 2 103
Глава 3. Измерение, оценивание и прослеживание плана программного проекта 105
3.1 Метрики и дефекты плана программного проекта 105
3.2 Прослеживание плана программного проекта . 121
3.3 Выводы к главе 3 126
Глава 4. Программное средство для моделирования планов программных проектов 128
4.1 Специфицирование статической реляционной модели плана проекта с использованием его графовой модели . 128
4.2 Исполнение статической реляционной модели плана проекта и визуализация динамической модели . 133
4.3 Измерение и оценивание плана программного проекта . 136
4.4 Выводы к главе 4 140
Глава 5. Экспериментальное исследование планов программных проектов при помощи специализированного средства моделирования 141
5.1 Оценивание процесса производства программного обеспечения с использованием специализированного средства моделирования 141
5.2 Условия проведения экспериментов 143
5.3 Результаты экспериментов 146
5.4 Выводы к главе 5 154
Заключение 155
Литература . 157
Приложение 1 168
Приложение 2 169
- Основные стандарты, связанные с процессом производства программного обеспечения
- Реляционная модель процесса производства программного обеспечения
- Исполнение статической реляционной модели плана проекта и визуализация динамической модели
- Оценивание процесса производства программного обеспечения с использованием специализированного средства моделирования
Введение к работе
Актуальность проблемы. В последние .два десятилетия основной целью промышленного производства программных средств считается достижение их высокого качества. Первоначально эта задача решалась, в "основном, применением соответствующих методов контроля качества программных продуктов [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 22, 31, 32, 40, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62]. В настоящее время разработчики программных средств сосредоточили свое внимание на методах организации такого процесса их производства, который, благодаря своим внутренним свойствам, "автоматически" ведет к получению высококачественных продуктов [34, 97, 103].
Появление в последнее время неформальных определений программных процессов предоставило производителям программного обеспечения возможность обсуждения вопросов моделирования, измерения, оценивания и улучшения процессов производства, на понятном им языке [77, 92].
В настоящее время каждая организация, разрабатывающая программное обеспечение, строит собственную детальную модель процесса его производства на основе одной из наиболее авторитетных в мире высокоуровневых моделей процесса производства программного обеспечения (ISO/IEC 12207 [76], ISO/IEC 15504 [77], SW СММ [92]). В терминах этой модели формулируются цели и стратегия улучшения процесса производства программного обеспечения в организации. В связи с необходимостью моделирования различных процессов производства, в том числе и процессов производства программного обеспечения, были созданы полу формальные и формальные модели этих процессов.
Широкое применение на практике получили такие средства создания полуформальных моделей (языки), как SADT (System Analysis and Design Technique), ETVX (Entry conditions, Tasks, Verification activities, and eXit criteria) [38, 56], UML (Unified Modeling Language) [14], а также средства создания графовых моделей [52]. Все они достаточно просты и позволяют представлять модель процесса производства в удобной для визуального анализа форме. Более глубокий анализ характеристик планируемого проекта обеспечивают формальные модели процесса производства - конечные автоматы, сети Петри, продукционные системы [71, 74, 88, 101, 100]). Эти модели позволяют моделировать не только статическую структуру процессов производства, но и их динамические свойства.
Существующие программные средства для моделирования процессов производства, основанные на формальных моделях (Microsoft Project, Open Plan, Spider Project, Adaptable Process Model [33, 37, 98]), поддерживают планирования проектов по разработке программного обеспечения, а некоторые из них (Spider Project) и моделирование динамических свойств этих проектов.
Однако среди работ по моделированию процессов производства, опубликованных в отечественных и зарубежных журналах, нет таких, которые охватывали бы полный цикл улучшения плана программного проекта и обеспечивали развитый анализ создаваемых вариантов плана. Обычно рассматриваются лишь отдельные аспекты этой деятельности.
Большинство применяемых формальных моделей процессов производства на уровне отдельного проекта оставляют без внимания то, что в организации, имеющей хотя бы 2-й уровень зрелости (согласно шкале СММ [92]), все выполняемые проекты имеют общие черты. Современные же модели процесса производства (представленные в ISO/IEC 12207 [76] и в таких моделях как СММ) предполагают, что модель плана конкретного программного проекта должна конструироваться путем адаптации моделей процесса более высокого уровня, компоненты которых в значительной степени стандартизованы.
Формальные модели, обеспечивающие анализ плана программного проекта, слишком сложны и- громоздки, чтобы с ними было удобно работать менеджерам из промышленности.
Существующие средства моделирования планов проектов не позволяют проводить автоматическое измерение и количественное оценивание планов программных проектов, что создаёт трудности при управлении проектами.
Современное состояние программной промышленности настоятельно требует [34, 97, 101. 103] создания формально определённых моделей и методик, позволяющих предприятиям-разработчикам программного обеспечения организованно достигать целей, связанных с моделированием, измерением, оцениванием и улучшением своего производства.
Создание формальных моделей процесса производства программного обеспечения, средств моделирования видов деятельности проекта на их основе и исследование разработанных моделей и средств необходимо для того, чтобы формально решать задачи моделирования, измерения и оценивания процесса производства программного обеспечения и организовывать в условиях конкретного предприятия согласованную деятельность по улучшению производства в зависимости от свойств реализуемых программных проектов и текущего уровня развития организации. Актуальность этой задачи определила выбор цели диссертационной работы.
Цель работы. Целью диссертационной работы является создание и исследование единой системы моделей, методов и средств поддержки планирования проектов разработки программного обеспечения, сочетающих в себе достоинства формализмов и полуформальных средств визуализации.
Достижение цели работы предполагало решение следующих четырёх задач:
1) разработка формальных моделей процесса производства программных средств, основанных на современных стандартах технологии программирования и обеспечивающих измерение и формальное оценивание процессов производства;
2) разработка методов решения задач измерения, оценивания и прослеживания плана программного проекта с использованием предложенных формальных моделей процесса производства программного обеспечения;
3) разработка методов реализации программного средства для моделирования, измерения и оценивания планов программных проектов;
4) экспериментальное исследование разработанных моделей, методов и средств на реальных данных программного предприятия. Методы исследований. Для решения указанных задач использовались элементы теории реляционных отношений, теории графов, теории измерений, методы технологии программирования, методы измерений и методы системного программирования.
Научная новизна работы состоит в следующем.
1. Разработан метод математического описания программных процессов, позволяющий моделировать процесс производства программного обеспечения и его статические свойства на всех уровнях рассмотрения: высокоуровневый процесс производства, процесс производства в организации, процесс производства в отдельном проекте.
2. Разработано проблемно-ориентированное исчисление, интерпретирующее формальную статическую модель плана программного проекта и имитирующее процесс его выполнения с целью анализа динамических свойств плана.
3. Формально определен набор метрик и дефектов плана программного проекта с использованием его реляционной и грифовых моделей, позволяющий специфицировать критерии сравнительного оценивания различных вариантовплана программного проекта и методы анализа характеристик планапрограммного проекта.
Практическая ценность работы состоит в том, что полученные в диссертации научные результаты имеют конкретную прикладную направленность, связанную с повышением качества планирования процесса производства программного обеспечения.
Разработанные модели и методы применены при реализации программного средства для моделирования, измерения и оценивания планов проектов по разработке программного обеспечения.
В работе получены следующие основные практические результаты.
1. Разработана реляционная модель, определяющая компоненты процесса производства программного обеспечения (процессы, виды деятельности, задачи, порождаемые ими продукты и используемые ресурсы), их атрибуты и связи между ними, а также ограничения конкретных программных проектов. Модель основана на международных стандартах, других авторитетных документах (модель SW СММ, национальные стандарты) и на практике промышленного программирования.
Эта обобщённая модель позволяет построить модель процесса производства ПО в конкретной организации, которая в дальнейшем будет использоваться для создания формальных моделей планов проектов по разработке ПО.
2. Формально определены правила прослеживания плана программногопроекта, позволяющие сравнивать реальный процесс выполнения проекта с запланированным и обнаруживать отклонения от плана.
Правила прослеживания обеспечивают контроль за выполнением созданного плана программного проекта.
3. Разработано программное средство для моделирования планов программных проектов, позволяющее строить формальную статическую модель плана проекта, исполнять её для получения динамической модели плана, описывающей процесс его выполнения, проводить измерение и оценивание плана проекта, модифицировать его с целью улучшения и сравнивать различные варианты плана для выбора лучшего. Вышеуказанное программное средство используется для моделирования, измерения и оценивания планов проектов в ООО «Ронда Лимитед», для исследований в
Институте автоматики и процессов управления (ИАПУ) ДВО РАН и в учебном процессе на кафедре программного обеспечения ЭВМ Института математики и компьютерных наук Дальневосточного государственного университета (ДВГУ).
Результаты работы включены в спецкурс «Метрология качества программного обеспечения», читаемый для студентов кафедры программного обеспечения ЭВМ Института математики и компьютерных наук ДВГУ.
Реализация результатов работы. Представленные в работе исследования методов и средств формального специфицирования моделей и метрик программ были выполнены в рамках научно-исследовательской темы ИАПУ ДВО РАН:
"Методы и средства технологии автоматизированной обработки знаний, специфицирования и анализа программного обеспечения, распределенных вычислительных систем, обработки и визуализации графической информации с применением параллельных вычислений", № гос. регистрации 01.99.00 05772. В указанной НИР автор принимал участие в качестве исполнителя.
Апробация работы. Основные научные и практические результаты докладывались и обсуждались на следующих конференциях и семинарах:
• XXVI-й, XXVII-й и XXVIII-й Дальневосточной математической школе-семинаре имени академика Е.В. Золотова (Владивосток, 2001, 2002 и 2003),
• IV-й Всероссийской научной Internet-конференции «Компьютерное и математическое моделирование в естественных и технических науках» (Тамбов, 2002).
• IV-й Всероссийской конференции молодых учёных по математическому моделированию и информационным технологиям (Красноярск, 2003).
• совместных семинарах отдела экспертных систем ИАПУ ДВО РАН и факультета компьютерных наук Института математики и компьютерных наук ДВГУ (2001-2003).
Публикация результатов работы. По теме диссертации опубликовано 8 работ [23, 24, 25, 26, 27, 28, 29, 30, 35].
Структура и объем работы. Диссертация состоит из введения, пяти глав, заключения, списка литературы и двух приложений. Основная часть работы содержит 168 страниц текста, 9 таблиц и 32 рисунка. Список литературы содержит 103 наименования.
КРАТКОЕ СОДЕРЖАНИЕ РАБОТЫ
Во введении обосновывается актуальность выполненных в диссертации исследований, формулируется цель работы, рассматривается научная и практическая значимость результатов, приводятся сведения об апробации и реализации основных положений диссертации. В первой главе диссертационной работы рассматриваются используемые в работе понятия и анализируются основные литературные источники в области моделирования процессов производства программного обеспечения.
Вторая глава диссертационной работы посвящена разработке реляционных и грифовых моделей процесса производства программного обеспечения.
Третья глава диссертационной работы посвящена формальному определению набора метрик и дефектов планов проектов по производству программного обеспечения в терминах предложенных реляционных и грифовых моделей и методики их применения для оценивания процесса производства.
В четвертой главе диссертационной работы описывается разработанное программное средство для моделирования, измерения и оценивания планов проектов по производству программного обеспечения.
Пятая глава диссертационной работы посвящена экспериментальному исследованию разработанных моделей, методов и средства на реальных данных программного предприятия.
Приложение 1 содержит акты внедрения результатов работы.
Приложение 2 содержит реляционную модель процесса производства программного обеспечения.
Основные стандарты, связанные с процессом производства программного обеспечения
Определённый процесс (defined process) согласно ISO/IEC 15504 [77] - это «рабочее определение множества видов деятельности для достижения специфичной цели». Определённый процесс может быть охарактеризован наличием стандартов, процедур, программы обучения, средств и методов [77]. Одной из целей моделирования процессов производства является их улучшение, т.е. повышение их возможностей [41, 74, 97].
Стандарт ISO/IEC 15504 [77] определяет возможности процесса (process capability) как «способность процесса достигать требуемой цели». В модели SW СММ [92] это же понятие определяется как «диапазон ожидаемых результатов, которые могут быть получены при следовании программному процессу». Возможности программного процесса организации обеспечивают предсказание наиболее вероятных результатов очередного проекта, выполняемого организацией [92]. В I современных моделях возможностей процесса производства ПО выделяют уровни возможностей [77], или уровни зрелости [92, 50], характеризующие стабильность и качество процесса [97].
Уровень возможностей (процесса) ((process) capability level) определяется стандартом ISO/IEC 15504 [77] как «значение на шкале из шести значений (возможностей процесса), представляющее увеличение возможностей выполняемого процесса». Аналогичное понятие уровень зрелости в СММ [92] определено как «хорошо определённая эволюционная ступень на пути к получению зрелого программного процесса». Таким образом, уровни возможностей (или зрелости) процесса производства определяют путь для улучшения процесса.
Стандарт ISO/IEC 15504 [77] определяет улучшение процесса (process improvement) как «действия, предпринимаемые для изменения процесса в организации для того, чтобы он удовлетворял её деловым потребностям и позволял более эффективно достигать её деловых целей». Улучшение достигается за счёт действий по улучшению процесса (process improvement action), т. е. «действий, запланированных и выполненных для улучшения всего программного процесса или его части» [77]. Действия по улучшению процесса обычно организуются в виде программы улучшения процесса (process improvement program), определённой в стандарте ISO/IEC 15504 [77] как «все стратегии, политики, цели, ответственности и виды деятельности, направленные на достижение установленных целей улучшения». Отдельные элементы единой программы улучшения процесса организуются в виде проектов по улучшению процесса. Это понятие определено в стандарте ISO/IEC 15504 [77] как «любое подмножество программы улучшения процесса, формирующее связное множество действий для достижения некоторого улучшения».
Модель процесса производства ПО включает в себя три основные составляющие: модель задач (или практик, как они называются в ISO/IEC 15504 [77]), выполняемых в процессе, модель продуктов (артефактов), которые создаются при выполнении этих задач, используются ими и передаются между ними, и модель ресурсов (средств, методов, исполнителей (агентов)) [97, 103, 74].
В стандарте ISO/IEC 15504 задача (практика) определяется как «инженерная или управленческая деятельность, участвующая в создании выходных результатов процесса (рабочих продуктов) или в улучшении процесса». Задачи являются основой всех моделей процесса разработки ПО [76, 77, 97, 103]. Большинство формальных средств моделирования позволяют выполнять иерархическую декомпозицию задач, где некоторые задачи распадаются на подзадачи, другие же являются атомарными [74, 95, 91]. Модель задач должна описывать не только набор выполняемых шагов, но их взаимосвязи, последовательность выполнения, точки принятия решений, итерационное выполнение некоторых шагов и повторное выполнение, распараллеливание и синхронизацию, ограничения, предусловия и постусловия выполнения задач [74, 97].
Программный продукт (software product) определён в стандарте ISO/IEC 12207 [76] как «множество компьютерных программ, процедур и, возможно, связанной с ними документации и данных».
Согласно стандарту IEEE Std 610.12-1990 [78] слова программный продукт относятся к двум понятиям. Это: 1) «полный набор программ ЭВМ, процедур и, возможно, связанных с ними документации и данных, предназначенных для поставки пользователю»; 2) «любой из отдельных компонентов из (1)». При моделировании процесса производства ПО обычно подразумевается второе толкование этих слов, поскольку первое из них используется, главным образом, продавцами ПС, а не разработчиками ПО. Похожее определение продукта приводится и в [97], где он определяется как «программы, документы и данные, составляющие программное обеспечение». В формальных средствах моделирования процессов используются разные способы представления взаимоотношений задач и продуктов. В некоторых случаях описывается структура процесса, построенная из задач, где продукты будут входной и выходной информацией [74, 77], в других случаях задачи описываются через состояние продуктов [74] (например, если некоторый продукт находится в состоянии «прошёл экспертизу», то это значит, что задача «проведение экспертизы» уже завершена).
Помимо понятия программный продукт (program product) существует ещё понятие программное обслуживание (program service), определяемого стандартом ISO/IEC 12207 [76] как «выполнение видов деятельности, работ или служебных обязанностей, связанных с программным продуктом, таких как его разработка, эксплуатация и сопровождение».
В литературе упоминаются три типа ресурсов, используемых в процессе производства ПО: исполнители, методы и средства [74, 97, 103]. При описании процесса производства ПО обычно определяют роли исполнителей, такие как менеджер, проектировщик, оценщик и другие [97, 103]. Роль описывает множество видов ответственности, прав и навыков, необходимых для деятельности в рамках программного процесса [63]. Методы обеспечивают технические возможности для создания ПО и охватывают широкий диапазон задач, включающий анализ требований, проектирование, создание программ, тестирование и поддержку [97, 103]. Средства разработки ПО обеспечивают автоматическую или полуавтоматическую поддержку процесса производства и методов разработки [97, 103]. Они характеризуются выполняемыми операциями, стоимостью их использования и доступностью [63].
Реляционная модель процесса производства программного обеспечения
Руководства и инструкции помогают человеку, выполняющему процесс, понять, что и в каком порядке делать. Руководства представляют собой различные документы о выполняемых в организации процессах. Кроме того, используются данные о текущем состоянии процесса, списки шагов, которые необходимо выполнить, и данные об уже выполненных шагах. Автоматизация процесса представляет собой нечто большее, чем просто автоматизация отдельных шагов в процессе. Когда автоматизированы лишь отдельные шаги процесса, человек, выполняющий этот процесс, отвечает за гармоничное сочетание его шагов. Он должен следить за тем, какие шаги уже завершены, какие выполняются, как они взаимодействуют между собой. Когда же процесс является полностью автоматическим, часть этих забот переходит к механизму выполнения процесса. Он может отслеживать завершение одних шагов и после этого запускать следующие, автоматически проверять различные ограничения и осуществлять связь между разработчиками. Необходимое принуждение, которое гарантирует, что процесс выполняется так, как он определён, может быть конечной целью автоматизации или просто побочным эффектом. Его цель - гарантировать точное соблюдение всех правил, норм и инструкций сотрудниками организации. Однако разработчикам должна предоставляться некоторая свобода действий для разрешения нештатных ситуаций, они не должны быть в слишком жёстких рамках, за исключением тех случаев, когда это действительно необходимо . Обязательно должен существовать мониторинг процесса, состоящий в сборе данных, необходимых для вычисления значений метрик процесса, сборе и хранении исторических данных о выполненных шагах [74].
Для успешного выполнения процесса, обеспечения некоторой степени принуждения сотрудников, а также для мониторинга процесса крайне полезна, а иногда и незаменима модель процесса, которая даёт ясное и строго описанное представление о процессе, который реально протекает в организации [74, 97].
В настоящее время при выполнении любых проектов применяются программные средства (ПС) для их моделирования и планирования. При этом широкое распространение получили лишь несколько средств [33, 37].
Наиболее известным из них является Microsoft Project [33, 37]. Это ПС позволяет задать набор задач проекта, определить их свойства (такие как запланированная продолжительность, дата начала выполнения и др.), задать зависимости между задачами. При этом поддерживается иерархическое представление плана, т.е. его разделение на фазы, виды и подвиды деятельности и отдельные задачи. Microsoft Project позволяет определить доступные для проекта ресурсы и назначить их для выполнения задач.
Контроль выполнения созданного плана поддерживается возможностью внесения фактических данных о ходе проекта и автоматической генерацией отчётов. Microsoft Project поддерживает удобные для анализа формы представления плана, такие как сеть задач проекта, диаграмма Гантта, профили занятости ресурсов и др.
Существенным недостатком рассматриваемого ПС является отсутствие каких-либо возможностей моделирования процесса выполнения плана, его динамических свойств. Кроме этого, отсутствуют средства измерения и оценивания плана, нет возможности сравнить различные варианты плана и выбрать лучший. В связи с этим, Microsoft Project часто относят к непрофессиональным средствам планирования.
Более мощным средством планирования является Open Plan [33, 37]. Обладая всеми функциональными возможностями Microsoft Project a, это ПС позволяет планировать одновременно несколько проектов, использующих общие ресурсы, и управлять ими. Open Plan предоставляет широкие возможности для управления ресурсами, а именно, объединение ресурсов в группы и манипулирование ими, автоматический подбор свободного ресурса, наиболее подходящего для выполнения некоторой работы, назначение приоритетов задач.
Open Plan позволяет моделировать процесс исполнения запланированного проекта, но при этом не производится автоматического измерения плана, поиска в нём дефектных { элементов (чрезмерного распараллеливания исполнителей, задержек из-за неготовности каких-либо продуктов и т.п.). Как и Microsoft Project, Open Plan не позволяет выполнять автоматическое оценивание планов проекта и сравнение их различных вариантов.
Другим известным средством планирования проектов и управления ими является Spider Project [33]. Это ПС, обладающее всеми функциональными возможностями описанных выше средств, предоставляет некоторые дополнительные возможности. В Spider Project e существует возможность не задавать планируемую продолжительность выполнения задач, а вычислять её на основе данных о запланированных объёмах работ и производительности ресурсов. К сожалению, эта возможность не применима к проектам по разработке ПО, так как не существует общепринятых моделей производительности труда программистов. Другим важным отличием рассматриваемого ПС является неограниченная иерархичность ресурсов, т.е. возможность создавать группы ресурсов, объединения групп ресурсов и т. д. При этом ресурсы делятся на возобновляемые (люди, механизмы) и невозобновляемые (материалы). Spider Project позволяет автоматически сгенерировать оптимальный план проекта с учётом начального назначения ресурсов, однако он не предоставляет никаких возможностей для измерения и оценивания планов проектов.
Ещё одним широко распространённым средством планирования и управления проектами является Primavera Project Planner (РЗ) [33]. Это ПС предоставляет все функциональные возможности перечисленных выше средств, кроме автоматической генерации оптимального плана проекта. Дополнительно РЗ позволяет сохранять фрагменты планов ранее выполненных проектов и затем повторно использовать их при создании новых планов, что обеспечивает возможность со временем создать библиотеку повторно используемых компонентов плана. Это ПС ориентировано на планирование крупных проектов. Для работы с небольшими проектами существует упрощённая версия РЗ - SureTrak Project Manager [33]. В этом средстве отсутствуют некоторые функции, например, одновременная работа с несколькими проектами. Так же, как и все рассмотренные выше средства, РЗ и SureTrak Project Manager не позволяют проводить измерение и оценивание создаваемых планов.
Помимо описанных выше средств существуют ещё два известных продукта, связанных с планированием проектов - Project Expert и 1С-Рарус [33]. Оба эти средства ориентированы в большей степени на финансовую сторону проектов - вычисление расходов, создание финансовых отчётов и т.п. Они обычно используются совместно с каким-либо из перечисленных выше средств планирования проектов.
Исполнение статической реляционной модели плана проекта и визуализация динамической модели
Целью этого раздела является описание схемы применения предлагаемого в работе подхода к моделированию и улучшению плана программного проекта. В остальных разделах данной главы, а также в Главе 3 детально определяется каждый из элементов этой схемы. Общая трехуровневая схема процесса моделирования и улучшения плана программного проекта представлена на рис. 2.1.
На верхнем уровне из создаваемых различными авторитетными организациями (такими как ISO, SEI и т.п.) стандартов и руководств, связанных с определением процессов ЖЦ ПО, извлекаются онтология этой предметной области и знания. Затем знания формализуются.
Онтология и знания предметной области используются средством поддержки инженерии процесса на втором уровне схемы. При помощи этого средства менеджер процессов организации-разработчика ПО выбирает элементы модели . процессов, связывает их в шаблоны и формирует модель процесса производства организации (см. раздел 2.3). При этом в своих действиях он руководствуется политикой организации, которая определяет набор используемых стандартов и моделей процессов ЖЦ ПО. На этом же уровне находится база данных (БД) с информацией о предыдущих программных проектах, выполненных в данной организации. На основе схемы этой БД и онтологии, полученной на верхнем уровне схемы, формируется метод специфицирования планов новых программных проектов (см. подраздел 2.7.1), который встраивается в средства нижнего уровня схемы, представленной на рис. 2.1.
Модель процесса организации и информация из БД о предыдущих проектах поступают на вход графическому редактору модели плана проекта (на третьем (нижнем) уровне схемы). При помощи этого редактора менеджер конкретного программного проекта адаптирует модель процесса организации к планируемому проекту и устанавливает значения параметров модели на основе исторической информации из БД. Полученная модель плана проекта автоматически преобразуется во внутренний формат. После того как менеджер определит значения параметров поведения модели (см. раздел 2.4.5) при помощи специального средства поддержки, сформированная реляционная модель может интерпретироваться средством исполнения модели плана проекта, в результате чего будет сгенерирована реляционная динамическая модель процесса исполнения плана проекта (см. раздел 2.4). Менеджер может увидеть эту модель в удобной для него форме с помощью специализированного средства визуализации (см. подраздел 2.7.2). При этом он может получать ответы на запросы о состоянии как динамической модели в целом, так и отдельных ее фрагментов в разные моменты времени.
Динамическая модель плана проекта может быть измерена средством измерения, которое использует для этого формализованные знания о метриках и дефектах планов программных проектов. Это позволяет установить характеристики динамической модели. Значения метрик и данные о дефектах плана проекта анализируются и оцениваются на основе критериев оценивания, заданных менеджером проекта (см. Главу 3). Менеджер получает доступ к результатам измерения и оценивания плана проекта через средство визуализации. На основании полученной информации менеджер проекта может изменить модель плана проекта, после чего она снова пройдет все описанные выше стадии. Результаты измерения различных реляционных динамических моделей сравниваются автоматически на основе критериев, заданных менеджером проекта, что позволяет определить, привели изменения плана проекта к его улучшению или нет.
Целью этого раздела является формальное специфицирование компонентов статической модели процесса производства ПО. Эта модель обеспечивает базис для построения статической реляционной модели плана программного проекта, определения процесса исполнения этой модели (см. раздел 2.4), а также для формального определения набора графовых моделей (см. разделы 2.5 и 2.6), облегчающих специфицирование плана и визуальный анализ его характеристик (см. раздел 2.7).
При определении модели процесса производства программного обеспечения будут использоваться следующие элементарные понятия: Process-names - множество названий процессов (например, процесс разработки, процесс документирования [76]), Processypes - множество названий категорий процессов (например, основные процессы, поддерживающие процессы и процессы управления [76]), LC-model-names - множество названий моделей жизненного цикла (например, линейная модель, спиральная модель, прототипирование [97]), Activity-names — множество названий видов деятельности (например, детальное проектирование, тестирование приемлемости [76]), Activityypes - множество названий типов деятельности, являющихся «конкретизацией» вида деятельности (например, генерация отчетов, объектно-ориентированный анализ), Task-names - множество названий задач (например, разработка набора тестовых ситуаций), і Product-names — множество названий продуктов, создаваемых в процессе выполнения задач (например, план испытаний, спецификация системы [77]), Productypes - множество названий типов рабочих продуктов (например, отчет, план [80]), Project-names - множество названий программных проектов (например, Logiscope, РЕПР02), Role-names - множество названий ролей исполнителей при выполнении задач (например, кодировщик, инспектор, менеджер по тестированию), Method-names - множество названий применяемых в организации методов выполнения программных проектов (например, SA/SD method, Jackson diagrams [97]).
Оценивание процесса производства программного обеспечения с использованием специализированного средства моделирования
Перед началом модельного исполнения плана проекта руководитель проекта должен задать длину единичного временного интервала (delta), используемого во "внутренних часах" процесса выполнения проекта и определяющего точность моделирования динамики проекта. Кроме того, руководитель проекта должен выбрать варианты правил (см. раздел 2.4.2), которые будут использоваться при моделировании, что обеспечивает гибкость моделирования динамики проекта. Последнее относится к правилу инициализации шага проекта (для которого возможна альтернатива: (1) инициализация шага в соответствии с наступлением календарной даты его запланированного начала и (2) инициализация шага в соответствии с запланированной очередностью выполнения шагов) и к правилу выполнения части работы на шаге проекта (для которого возможны три варианта: (1) выполнение работ в равных долях, (2) выполнение работ последовательно и (3) выполнение работ с учетом указанных весовых долей).
В процессе модельного выполнения, в случае выбора вариантов правил с параметрами, необходимо оценивать значения этих параметров в конкретном контексте. К таким параметрам относится (1) признак снятия ограничений на инициализацию шага (см. раздел 2.4.2, Правило 1), обусловленных фактической доступностью критичных ресурсов или другими причинами (для этой цели используется атрибут sign в отношении Constraints), а также (2) весовая доля распределения рабочего времени исполнителя в зависимости от текущего списка его назначений (см. раздел 2.4.2, Правило 3, Вариант 3). Задание значений этих параметров производится менеджером в процессе применения правил с параметрами по запросу средства исполнения модели плана проекта (см. рис. 2.1). При этом менеджер должен учитывать особенности планируемого проекта и исходить из собственного опыта.
После завершения Процесса модельного исполнения плана программного проекта, в результате применения проблемно-ориентированных правил к статической реляционной модели плана проекта, будет сгенерирована описывающая его динамическая реляционная модель плана проекта.
Целью этого раздела является формальное определение понятия статический граф плана программного проекта. Статический граф плана проекта предназначен для визуализации фрагментов этого плана, поддержки процесса его специфицирования (см. раздел 2.7) и моделирования процесса его исполнения (см. раздел 2.4).
Предлагаемая графовая модель отражает видение плана программного проекта как сети задач; такое видение является широко распространенным (task network [97], network of tasks [91]). Вершины-задачи связаны дугами, отражающими передачу между задачами производимых ими продуктов. Кроме этого, модель отражает назначение ресурсов (людей, средств и методов) для выполнения шагов проекта. Вершины-ресурсы связаны дугами с теми вершинами-задачами, для выполнения которых они назначены, при этом указаны шаги, на которых выполняются задачи (поскольку одна и та же задача может выполняться многократно). Разметка множества вершин-задач графа задает частичный порядок выполнения шагов проекта, определяемый запланированным временным графиком.
В качестве структурной модели плана проекта будем использовать связный размеченный ориентированный граф G = Tasks, Res, (Rl, R2) . В работе [91] аналогичный граф с двумя типами вершин называется многослойным (layered).
Приведенное ниже определение графа G представляет собой набор правил, устанавливающих взаимно-однозначное соответствие между элементами графа G и атрибутами реляционной модели (см. раздел 2.3]). Такое определение позволяет, с одной стороны, использовать граф G для специфицирования полной модели плана программного проекта, а с другой — однозначно определять любые фрагменты модели плана при визуализации (см. раздел 2.7). Task - множество вершин графа, представляющих множество задач плана программного проекта, Task = {task-nameі, ..., task-name }, Vi = l,k (task-name; є Task-names), и при этом 3 task-name є Task -» 3 task-name (Tasks (task-name, _,_) )
Комментарий. Вершина графа task-name существует тогда и только тогда (т. и тт.), когда в реляционной модели плана проекта определена задача с именем task-name. разметка множества вершин Task, определяющая шаги программного проекта и частичный порядок их выполнения. Каждой вершине соответствует непустое множество меток, где меткой является либо 0, либо пара натуральных.
Комментарий. Вершина графа task-name2 помечена меткой (i,K2) т. и тт., когда существует вершина графа task-name 1 (возможно, совпадающая с task-name2), помеченная меткой (М,К1), и в реляционной модели плана проекта определены шаги с номерами К1 и К2, на которых выполняются задачи task-name 1 и task-name2 соответственно, причем установлено, что шаг с номером К1 должен выполняться перед шагом с номером К2 и для каждой вершины графа task-патеЗ, помеченной меткой (t,K3), определен шаг с номером КЗ, на котором выполняется задача task-патеЗ и который должен выполняться перед шагом с номером К2; при этом первый индекс метки (і-1,К1) не меньше первого индекса метки (t,K3). Тем самым при построении разметки из всех меток вершин-задач предшествующих шагов выбирается метка с наибольшим первым индексом, указывающим на наиболее позднее выполнение задачи.
