128 2. Созданы программные средства, для автоматизации выполнения формализованных процедур алгоритма структурного метода оценки трудоемкости разработки программных систем. 3. Разработаны типовые шаблоны документов структурного метода оценки и краткие инструкции по их использованию, позволяющие в кратчайшие сроки начать применение технология оценки трудоемкости разработки программных систем в любой организации. 4. Разработанный набор метрик и дефектов позволяет специфицировать критерии сравнительного оценивания различных вариантов плана программного проекта, а также обеспечивает спецификации методов анализа характеристик плана программного проекта. 5. Определенны метрики, характеризующие продолжительность выполнения всего проекта и отдельных видов деятельности, а также уровень занятости ресурсов при выполнении проекта. Каждая метрика плана программного проекта определяется как функция, способ вычисления значений которой задается в форме логического правила, причем условие этого правила выполняет роль оператора конкретизации множества значений используемых переменных, а следствие оператора присваивания значений. 6. Определен набор дефектов плана программного проекта, который обеспечивает проведение анализа плана проекта с целью выявления фрагментов, связанных с неэффективным использованием ресурсов и нарушением графика работ по проекту. Спецификация каждого дефекта описана в форме правила логического вывода с параметрами. Условие правила определяет предикат, истинность которого указывает на наличие дефекта и фактически описывает метод выявления дефекта в декларативной форме, а следствие правила определяет состав информации, выдаваемой менеджеру проекта при нахождении данного дефекта в модели плана проекта. Проведённые эксперименты показали, что предложенный в работе подход к моделированию, измерению и оцениванию проектов по разработке программных систем позволяет с небольшими затратами времени и усилий на ранних стадиях планирования проекта оценить его основные характеристики и выявить дефекты, что в дальнейшем поможет избежать |
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 Спецификация каждого дефекта описана в форме правила логического вывода с параметрами. Значения параметров задаются до начала этапа анализа плана и оказывают влияние на результаты измерения, в частности на число ситуаций, расцениваемых как дефектные. Условие правила определяет предикат, истинность которого указывает на наличие дефекта, и фактически описывает метод выявления дефекта в декларативной форме, а следствие правила определяет состав информации, выдаваемой менеджеру проекта при нахождении данного дефекта в модели плана проекта (см. схему на рис. 2.1 в Главе 2). В общем случае при выявлении дефекта будет выдана следующая информация: название дефекта; значения заданных параметров правила выявления дефекта; фактические значения атрибутов компонентов плана, которые удовлетворяют условию наличия дефекта; ссылка на компонент плана, к которому относится выявленный дефект, путем локализации соответствующего фрагмента статического графа. При этом используется функция Visualize (graph-fragment), где graph-fragment е Tasks и Res u R2 фрагмент статического графа. г)та функция реализует операцию визуализации заданного фрагмента в соответствии с принципами, описанными в Главе 2. З.1.2.1. Дефекты плана программного проекта, определяемые по его статической модели Выявление дефектов, описанных в данном разделе, может производиться путем анализа статической модели плана проекта и не требует моделирования процесса его выполнения. Дефект 1.1. Неформальное определение: назначение на роль исполнителя с недостаточным опытом. Параметр: число проектов, участие в которых в такой же роли, как и в рассматриваемом проекте, дает исполнителю «достаточный» опыт. 126 -> product-creation-delay (product-ref, time-moment2 time-moment 1)) Комментарий. Продукт product-ref уже создан, однако время его создания не совпадает с запланированным. В случае обнаружения такой ситуации будет выдана информация о продукте, с которым связано выявленное несоответствие между планом и реальным ходом выполнения проекта, и о разнице между реальным и запланированным временем создания продукта. 3.3. Выводы к главе 3 В третьей главе формально определен набор метрик и дефектов плана программного проекта с использованием реляционной и графовых моделей плана проекта, описанных в Главе 2. Также, в данной главе формально определены правила прослеживания плана программного проекта, позволяющие сравнить реальный процесс выполнения проекта с запланированным и обнаружить отклонения от плана. 1. Определенный в работе набор метрик и дефектов позволяет специфицировать критерии сравнительного оценивания различных вариантов плана программного проекта, а также обеспечивает спецификации методов анализа характеристик плана программного проекта. 2. Определенные метрики характеризуют продолжительность выполнения всего проекта и отдельных видов деятельности, а также уровень занятости ресурсов при выполнении проекта. Каждая метрика плана программного проекта определяется как функция, способ вычисления значений которой задается в форме логического правила, причем условие этого правила выполняет роль оператора конкретизации множества значений используемых переменных, а следствие оператора присваивания значений. 3. Определенный набор дефектов плана программного проекта обеспечивает проведение анализа плана проекта с целью выявления фрагментов, связанных с неэффективным использованием ресурсов и нарушением графика работ по проекту. Спецификация каждого дефекта описана в форме правила логического вывода с параметрами. Условие правила определяет предикат, истинность которого указывает на наличие дефекта и |