|
123 Так как все понятия, используемые при построении формальной модели плана программного проекта, были определены формально (Глава 2), дефекты плана программного проекта также могут быть формально определены в тех же терминах, что и модель плана проекта. Ниже представлены формальные определения наиболее распространённых дефектов планов программных проектов [18, 43, 57]. Спецификация каждого дефекта описана в форме правила логического вывода с параметрами. Значения параметров задаются до начала этапа анализа плана и оказывают влияние на результаты измерения, в частности на число ситуаций, расцениваемых как дефектные. Условие правила определяет предикат, истинность которого указывает на наличие дефекта, и фактически описывает метод выявления дефекта в декларативной форме, а следствие правила определяет состав информации, выдаваемой менеджеру проекта при нахождении данного дефекта в модели плана проекта. 4.2.2.1 Дефекты плана программного проекта, определяемые по его статической модели Выявление дефектов, описанных в данном разделе, может производиться путем анализа статической модели плана проекта и не требует моделирования процесса его выполнения. 4.2.2.1.1 Дефект 1.1. Назначение на роль исполнителя с недостаточным опытом. Параметр: число проектов, участие в которых в такой же роли, как и в рассматриваемом проекте, дает исполнителю «достаточный» опыт. Формальное определение: 3 agent-name, role-name, step (Assignments (_, agent-name, role-name, step, _) & Staff (agent-name, experience-records) & Parameter-sufficient-experience (role-name, #previous-projects) & relevant-records = { role-name, ...> S experience-records } & relevant-records < #previous-projects unexperienced-agent (agent-name, //previous-project, relevant-records) На шаге step на роль role-name назначен исполнитель agent-name, причем число проектов, в которых он выполнял эту роль ранее, меньше числа проектов, участие в которых (в соответствии с заданным значением |
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. Занятость исполнителя в проекте. Неформальное определение: процентная доля времени занятости исполнителя в проекте по отношению к общей продолжительности проекта. 109 Finished (time-moment2, step2) & latest-moment > time-moment2 ) ) v List-of Здесь и далее символ в отношении означает вхождение множества анонимных свободных переменных. Комментарий. В составе вида деятельности activity-name существуют задача first-task, выполнение которой началось раньше (не позже) выполнения всех остальных задач этого вида деятельности, и задача last-task, выполнение которой завершилось позже (не раньше) выполнения всех остальных задач этого вида деятельности. Фактическое время выполнения вида деятельности определяется промежутком времени от момента начала выполнения задачи first-task до завершения выполнения задачи last-task. В самом тривиальном случае вид деятельности содержит одну задачу, время выполнения которой и определяет продолжительность выполнения этого вида деятельности. i 3ll.2. Дефекты плана программного проекта Дефектом плана программного проекта считается несоответствие значения некоторой его характеристики заранее установленному пороговому значению. Например, если максимально допустимое число одновременно выполняемых исполнителем задач в проекте установлено равным трём, то одновременное выполнение исполнителем четырёх и более задач будет считаться дефектом плана проекта. Так как все понятия, используемые при построении формальной модели плана программного проекта, были определены формально (Глава 2), дефекты плана программного проекта также могут быть формально определены в тех же терминах, что и модель плана проекта. Ниже представлены формальные определения наиболее распространённых дефектов планов программных проектов [34, 77, 92, 97]. 110 Спецификация каждого дефекта описана в форме правила логического вывода с параметрами. Значения параметров задаются до начала этапа анализа плана и оказывают влияние на результаты измерения, в частности на число ситуаций, расцениваемых как дефектные. Условие правила определяет предикат, истинность которого указывает на наличие дефекта, и фактически описывает метод выявления дефекта в декларативной форме, а следствие правила определяет состав информации, выдаваемой менеджеру проекта при нахождении данного дефекта в модели плана проекта (см. схему на рис. 2.1 в Главе 2). В общем случае при выявлении дефекта будет выдана следующая информация: название дефекта; значения заданных параметров правила выявления дефекта; фактические значения атрибутов компонентов плана, которые удовлетворяют условию наличия дефекта; ссылка на компонент плана, к которому относится выявленный дефект, путем локализации соответствующего фрагмента статического графа. При этом используется функция Visualize (graph-fragment), где graph-fragment е Tasks и Res u R2 фрагмент статического графа. г)та функция реализует операцию визуализации заданного фрагмента в соответствии с принципами, описанными в Главе 2. З.1.2.1. Дефекты плана программного проекта, определяемые по его статической модели Выявление дефектов, описанных в данном разделе, может производиться путем анализа статической модели плана проекта и не требует моделирования процесса его выполнения. Дефект 1.1. Неформальное определение: назначение на роль исполнителя с недостаточным опытом. Параметр: число проектов, участие в которых в такой же роли, как и в рассматриваемом проекте, дает исполнителю «достаточный» опыт. |