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

108 4.1.3 МЕТОД ФОРМИРОВАНИЯ ПЛАНА НА ОСНОВЕ ШАБЛОНА И ТАБЛИЦЫ ТРУДОЗАТРАТ Генерация плана на основе шаблона и "таблицы Л Перенос структуры 4, i подсистем в шаблон плана ; , Заполнение трудоемкости ~х \ задачи "разработки" J Ф .
______хЗаполнение трудоемкости остальных задач '.
на основе типовой зависимости ) Управление параметрами плана (набор задач, зависимости и т.п.) j Задание типовой зависимости от этапа "Разработка" Рис.
19.
Алгоритм генерация плана проекта Планирование проекта разработки программной системы включает в себя определение состава поставляемой заказчику системы, разбиение работы, которая должна быть для этого выполнена, на задачи, распределение ресурсов для выполнения этих задач и составление графика, устанавливающего очередность их выполнения.
Описанный в Главе 3 набор отношений позволяет формально представить план программного проекта в виде реляционной модели, охватив при этом такие виды деятельности, как выбор модели ЖЦ, адаптация стандартизованных знаний о процессе производства ПС к условиям конкретной организации и адаптация общей модели процесса производства организации к условиям конкретного программного проекта, а также основные этапы процесса планирования, а именно: определение состава создаваемых продуктов, построение так называемой сети задач, назначение задачам ресурсов, оценку основных параметров шагов проекта, установление временного графика для выполнения запланированных шагов.
Используя общую модель процесса производства и параметры ее адаптации к условиям конкретного проекта (такие как оцениваемый размер нового проекта, тип его приложения, оцениваемая стабильность требований и т.п.),
менеджер проекта создает общую структуру проекта — так называемую сеть задач (task network).
Следующим шагом является назначение ресурсов для выполнения задач, после чего может быть оценена
[стр. 42]

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


[стр.,59]

59 3.
На каждую роль должен быть назначен хотя бы один исполнитель, причем соотношение ролей и исполнителей не ограничено.
4.
Идентификаторы ресурсов уникальны в пределах объединения множеств названий методов, средств и идентификаторов исполнителей.
5.
Перед исполнением все атрибуты элементов модели, определенной в разделе 2.3, должны быть определены или оценены.
Помимо этого должны быть определены параметры процесса исполнения модели плана (т.е.
выбран вариант правил выполнения и заданы значения для Ттах и At (см.
раздел 2.4)).
6.
В случае выбора правил выполнения с параметрами в процессе исполнения модели плана менеджер должен доопределить значение отношения Constraints и определить значение функции Effort-ratio, устанавливающей размер долевого участия конкретного исполнителя в параллельно выполняемых им работах.
7.
Методы являются ресурсом, доступным без каких-либо ограничений.
8.
Средства используются в равной доле всеми видами работ; для выполнения I которых они назначены в текущий момент времени.
9.
Все единицы измерения атрибутов предварительно согласованы и не требуют дополнительного перевода при сравнении значений и использовании их при вычислениях.
Описанный набор отношений позволяет, формально представить план программного проекта в виде реляционной модели, охватив при этом такие виды деятельности, как выбор модели ЖЦ, адаптация стандартизованных знаний о процессе производства ПО к условиям конкретной организации и адаптация общей модели процесса производства организации к условиям конкретного программного проекта, а также основные этапы процесса планирования, а именно: (1) определение состава создаваемых продуктов, (2) построение так называемой сети задач, (3) назначение задачам ресурсов, (4) оценку основных параметров шагов проекта, (5) установление временного графика для выполнения запланированных шагов.

[Back]