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

128 2.
Созданы программные средства, для автоматизации выполнения формализованных процедур алгоритма структурного метода оценки трудоемкости разработки программных систем.
3.
Разработаны типовые шаблоны документов структурного метода оценки и краткие инструкции по их использованию, позволяющие в кратчайшие сроки начать применение технология оценки трудоемкости разработки программных систем в любой организации.
4.
Разработанный набор метрик и дефектов позволяет специфицировать критерии сравнительного оценивания различных вариантов плана программного проекта, а также обеспечивает спецификации методов анализа характеристик плана программного проекта.
5.
Определенны метрики, характеризующие продолжительность выполнения всего проекта и отдельных видов деятельности, а также уровень занятости ресурсов при выполнении проекта.
Каждая метрика плана программного проекта определяется как функция,
способ вычисления значений которой задается в форме логического правила, причем условие этого правила выполняет роль оператора конкретизации множества значений используемых переменных, а следствие оператора присваивания значений.

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

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

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

106 Так как все понятия, используемые при построении формальной модели плана программного проекта, были определены формально (Глава 2), метрики плана программного проекта также могут быть формально определены в тех же терминах, что и модель плана проекта.
Ниже представлены формальные определения метрик, связанных с наиболее важными свойствами планов программных проектов: продолжительностью проекта и отдельных видов деятельности, занятостью исполнителей [34, 77, 92, 97].
Каждая метрика плана программного проекта определяется как функция,
правило вычисления значений которой задается в форме логического правила, причем условие этого правила выполняет роль оператора конкретизации множества значений используемых переменных, а следствие оператора присваивания значений.
Метрика 1.
Продолжительность проекта.
Неформальное определение: фактическая продолжительность программного проекта (сетевое время (net process time [93], длина критического пути (critical path [98])).
• Формальное определение: I ! Current-time (time-moment, _) —> net-process-time = time-moment Примечание.
Здесь и далее символ в отношении означает вхождение анонимной свободной переменной.
Комментарий.
В соответствии с описанным в Главе 2 универсальным рецептом, в каждом состоянии рабочей среды Wj процесса исполнения модели плана проекта существует только один кортеж отношения Current-time, который представляет текущее время проекта.
Тем самым, по окончании процесса исполнения значение переменной time-moment представляет фактическую продолжительность модельного исполнения проекта.
Метрика 2.
Занятость исполнителя в проекте.
Неформальное определение: процентная доля времени занятости исполнителя в проекте по отношению к общей продолжительности проекта.


[стр.,110]

110 Спецификация каждого дефекта описана в форме правила логического вывода с параметрами.
Значения параметров задаются до начала этапа анализа плана и оказывают влияние на результаты измерения, в частности на число ситуаций, расцениваемых как дефектные.
Условие правила определяет предикат, истинность которого указывает на наличие дефекта, и фактически описывает метод выявления дефекта в декларативной форме, а следствие правила определяет состав информации, выдаваемой менеджеру проекта при нахождении данного дефекта в модели плана проекта
(см.
схему на рис.
2.1 в Главе 2).
В общем случае при выявлении дефекта будет выдана следующая информация: название дефекта; значения заданных параметров правила выявления дефекта; фактические значения атрибутов компонентов плана, которые удовлетворяют условию наличия дефекта; ссылка на компонент плана, к которому относится выявленный дефект, путем локализации соответствующего фрагмента статического графа.
При этом используется функция Visualize (graph-fragment), где graph-fragment е Tasks и Res u R2 фрагмент статического графа.
г)та функция реализует операцию визуализации заданного фрагмента в соответствии с принципами, описанными в Главе 2.
З.1.2.1.
Дефекты плана программного проекта, определяемые по его статической модели Выявление дефектов, описанных в данном разделе, может производиться путем анализа статической модели плана проекта и не требует моделирования процесса его выполнения.
Дефект 1.1.
Неформальное определение: назначение на роль исполнителя с недостаточным опытом.
Параметр: число проектов, участие в которых в такой же роли, как и в рассматриваемом проекте, дает исполнителю «достаточный» опыт.


[стр.,126]

126 -> product-creation-delay (product-ref, time-moment2 time-moment 1)) Комментарий.
Продукт product-ref уже создан, однако время его создания не совпадает с запланированным.
В случае обнаружения такой ситуации будет выдана информация о продукте, с которым связано выявленное несоответствие между планом и реальным ходом выполнения проекта, и о разнице между реальным и запланированным временем создания продукта.
3.3.
Выводы к главе 3 В третьей главе формально определен набор метрик и дефектов плана программного проекта с использованием реляционной и графовых моделей плана проекта, описанных в Главе 2.
Также, в данной главе формально определены правила прослеживания плана программного проекта, позволяющие сравнить реальный процесс выполнения проекта с запланированным и обнаружить отклонения от плана.
1.
Определенный в работе набор метрик и дефектов позволяет специфицировать критерии сравнительного оценивания различных вариантов плана программного проекта, а также обеспечивает спецификации методов анализа характеристик плана программного проекта.
2.
Определенные метрики характеризуют продолжительность выполнения всего проекта и отдельных видов деятельности, а также уровень занятости ресурсов при выполнении проекта.
Каждая метрика плана программного проекта определяется как функция, способ вычисления значений которой задается в форме логического правила, причем условие этого правила выполняет роль оператора конкретизации множества значений используемых переменных, а следствие оператора присваивания значений.

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

[Back]