Проверяемый текст
Старовойтов, Илья Владимирович. Разработка и исследование моделей, методов и средств оценивания процесса производства программного обеспечения (Диссертация 2003)
[стр. 71]

72 параметров новых проектов по принципу аналогии.
Тем самым, модель процесса производства организации включает в себя также спецификацию состава базы данных (БД) по выполненным ранее проектам, а также концепцию зависимости значений оцениваемых параметров от контекста (конкретных атрибутов компонентов процесса производства).
Такой подход позволяет поддерживать получение
реалистичной оценки параметров планируемых проектов.
Формальная модель компонентов процесса производства
ПС, охватывающая описанные выше понятия, представлена в разделе 3.1.
3.1 Реляционная модель процесса производства программной системы Целью этого раздела является формальное специфицирование компонентов статической модели процесса производства ПС.
Эта модель обеспечивает базис для построения статической реляционной модели плана программного проекта, определения процесса исполнения этой модели
а также для формального определения набора графовых моделей, облегчающих специфицирование плана и визуальный анализ его характеристик.
3.1.1 ЭЛЕМЕНТЫ МОДЕЛИ При определении модели процесса производства программного обеспечения будут использоваться следующие элементарные понятия: Process-names множество названий процессов (например, процесс разработки, процесс документирования [42]), Process-types множество названий категорий процессов (например, основные процессы, поддерживающие процессы и процессы управления [76]), LC-model-names — множество названий моделей жизненного цикла (например, линейная модель, спиральная модель, прототипирование [55]), Activity-names — множество названий видов деятельности (например, детальное проектирование, тестирование приемлемости [42]),
[стр. 42]

42 данные о выполненных программных проектах и используют эти "точечные" данные для оценки параметров новых проектов по принципу аналогии.
Тем самым, модель процесса производства организации включает в себя также спецификацию состава базы данных (БД) по выполненным ранее проектам, а также концепцию зависимости значений оцениваемых параметров от контекста (конкретных атрибутов компонентов процесса производства).
Такой подход позволяет поддерживать получение
менеджером реалистичной оценки параметров планируемых проектов (например, оценки минимальной продолжительности выполнения задачи конкретной бригадой в контексте проекта с определенным набором свойств).
(3) Уровень конкретного программного проекта.
Планирование программного проекта включает в себя определение поставляемых заказчику продуктов, разбиение работы, которая должна быть для этого выполнена, на задачи, распределение ресурсов для выполнения этих задач и составление графика, устанавливающего очередность их выполнения [97].
I Используя общую модель процесса производства и параметры ее адаптации к условиям конкретного проекта (такие как оцениваемый размер нового проекта, тип его приложения, оцениваемая стабильность требований и т.п.
[97]), менеджер проекта выбирает общую структуру проекта — так называемую сеть задач (task network).
Следующим шагом является назначение ресурсов для выполнения задач, после чего может быть оценена продолжительность выполнения каждой задачи.
Последним шагом является установление временного графика (timeline chart), предполагающего определение очередности выполнения задач (с учетом возможности параллельного выполнения некоторых из них) и оценку даты начала и завершения каждой задачи.
Формальная модель компонентов процесса производства
ПО, охватывающая описанные выше понятия, представлена в разделе 2.3.


[стр.,45]

45 определит значения параметров поведения модели (см.
раздел 2.4.5) при помощи специального средства поддержки, сформированная реляционная модель может интерпретироваться средством исполнения модели плана проекта, в результате чего будет сгенерирована реляционная динамическая модель процесса исполнения плана проекта (см.
раздел 2.4).
Менеджер может увидеть эту модель в удобной для него форме с помощью специализированного средства визуализации (см.
подраздел 2.7.2).
При этом он может получать ответы на запросы о состоянии как динамической модели в целом, так и отдельных ее фрагментов в разные моменты времени.
Динамическая модель плана проекта может быть измерена средством измерения, которое использует для этого формализованные знания о метриках и дефектах планов программных проектов.
Это позволяет установить характеристики динамической модели.
Значения метрик и данные о дефектах плана проекта анализируются и оцениваются на основе критериев оценивания, заданных менеджером проекта (см.
Главу 3).
Менеджер получает доступ к результатам измерения и оценивания плана проекта через средство визуализации.
На основании полученной информации менеджер проекта может изменить модель плана проекта, после чего она снова пройдет все описанные выше стадии.
Результаты измерения различных реляционных динамических моделей сравниваются автоматически на основе критериев, заданных менеджером проекта, что позволяет определить, привели изменения плана проекта к его улучшению или нет.
2.3.
Реляционная модель процесса производства программного обеспечения
Целью этого • раздела является формальное специфицирование компонентов статической модели процесса производства ПО.
Эта модель обеспечивает базис для построения статической реляционной модели плана программного проекта, определения процесса исполнения этой модели
(см.
раздел 2.4), а также для формального определения набора графовых моделей (см.
разделы 2.5 и 2.6), облегчающих специфицирование плана и визуальный анализ его характеристик (см.
раздел 2.7).


[стр.,46]

46 2.3.1.
Элементы модели При определении модели процесса производства программного обеспечения будут использоваться следующие элементарные понятия: Process-names множество названий процессов (например, процесс разработки, процесс документирования
[76]), Process-types — множество названий категорий процессов (например, основные процессы, поддерживающие процессы и процессы управления [76]), LC-model-names множество названий моделей жизненного цикла (например, линейная модель, спиральная модель, прототипирование [97]), Activity-names множество названий видов деятельности (например, детальное проектирование, тестирование приемлемости [76]), Activity-types множество названий типов деятельности, являющихся «конкретизацией» вида деятельности (например, генерация отчетов, объектноориентированный анализ), Task-names множество названий задач (например, разработка набора ( тестовых ситуаций), i Product-names — множество названий продуктов, создаваемых в процессе выполнения задач (например, план испытаний, спецификация системы [77]), Product-types множество названий типов рабочих продуктов (например, отчет, план [80]), Project-names множество названий программных Проектов (например, Logiscope, РЕПРО2), Role-names множество названий ролей исполнителей при выполнении задач (например, кодировщик, инспектор, менеджер по тестированию), Method-names множество названий применяемых в организации методов выполнения программных проектов (например, SA/SD method, Jackson diagrams [97]),

[Back]