Содержание к диссертации
Введение
ГЛАВА 1. Методы оценки и проектирования программных систем 10
1.1.Основные стандарты, регламентирующие процесс создания ПС 10
1.2 Моделирование процессов производства ПС. 14
1.2.1 Инструменты моделирования процессов производства ПС 16
1.2.2 Формальные модели процессов 18
1.3 Методы проектирования программных систем 24
1.3.1 Классификация существующих методов моделирования предметной области 27
1.4 Методы оценки трудоемкости разработки программных систем 34
1.4.1 Конструктивная модель стоимости 35
1.4.2 Метод функциональных точек 39
1.4.3 Анализ существующих методов оценки трудоемкости разработки ПС 45
1.5 Выводы 51
ГЛАВА 2. Методы моделирования с возможностью измерения результатов 53
2.1 Метод верификации модели предметной области 54
2.2 Метод определения минимального уровня детализации модели 60
2.3 Определение базовых сущностей 62
2.3.1 Формирование исходных данных метода 64
2.3.2 Анализ использования сущностей в бизнес-процессах 65
2.3.3 Измерение использования сущностей в функциональной модели 66
2.3.4 Выборка базовых сущностей 67
2.4 Выводы 69
ГЛАВА 3. Моделирование процесса производства программной системы 71
3.1 Реляционная модель процесса производства программной системы 72
3.1.1 Элементы модели 72
3.1.2 Отношения, представляющие компоненты модели 74
3.2 Динамическая модель плана проекта разработки программной системы 83
3.2.1 Структура состояния рабочей среды 84
3.2.2 Проблемно-ориентированные правила 86
3.2.3 Универсальное правило вывода 88
3.2.4 Правило остановки 88
3.2.5 Специфицирование параметров динамической реляционной модели плана проекта 89
3.3 Граф плана проекта по созданию программной системы 89
3.3.1 Вершины графа, представляющие задачи 90
3.3.2 Разметка вершин графа 90
3.3.3 Пример разметки графа 92
3.3.4 Дуги графа, представляющие передачу продуктов между задачами 94
3.3.5 Вершины статического графа, представляющие ресурсы 94
3.3.6 Дуги графа, представляющие назначение ресурсов для выполнения шагов проекта 94
3.3.7 Пример графа проекта по созданию программной системы 95
3.4 Выводы 96
ГЛАВА 4. Методы оценки трудоемкости разработки программных систем 98
4.1 Технология оценки трудоемкост и разработки программных систем 98
4.1.1 Метод формализации влияния общесистемных характеристик 101
4.1.2 Метод определения трудоемкости этапа разработки 104
4.1.3 Метод формирования плана на основе шаблона и таблицы трудозатрат 108
4.1.4 Метод коррекции плана проекта 112
4.1.5 Балансировка плана проекта 113
4.1.6 Результаты практического применения методов оценки ПС 114
4.2 Формальное измерение плана проекта разработки программной системы 120
4.2.1 Метрики плана проекта разработки программной системы 120
4.2.2 Дефекты плана проекта разработки программной системы 122
4.3 Выводы 127
Заключение 130
Список литературы
- Инструменты моделирования процессов производства ПС
- Метод определения минимального уровня детализации модели
- Динамическая модель плана проекта разработки программной системы
- Метод формализации влияния общесистемных характеристик
Введение к работе
Актуальность темы. Рост сложности объектов автоматизации предприятий различных сфер деятельности, а также переход от частичной автоматизации к комплексным интегрированным решениям, учитывающим специфические особенности конкретного предприятия, приводят к увеличению сложности и количества проектов по комплексной автоматизации предприятий. При разработке сложных программных систем (ПС), которые, как правило, входят в состав корпоративных информационных систем (КИС), необходимо снизить зависимость качества результатов от таких субъективных факторов, как квалификация исполнителей, их опыт, понизить риск неуспешного завершения проекта. Для этого требуются промышленные технологические методы оценки и разработки программного обеспечения (ПО), позволяющие получать качественные и предсказуемые во времени результаты и подключать большое количество специалистов средней квалификации с самых первых этапов проекта. Также, еще на этапе предпроектного исследования, большое значение имеет точность и быстрота оценки времени и ресурсов требуемых для разработки системы.
На сегодняшний день существует острая потребность в научно обоснованных технологических методах разработки программных систем. Сложность объектов автоматизации в большинстве случаев предопределяет итерационный характер методов разработки, а потребность в их промышленном характере означает необходимость глубокой формализации технологии проектировании, выполнения и оценки всех этапов проекта.
В соответствии с ISO/IEC 12207 начальным этапом процесса "Разработка" является этап анализа, цель которого - выявление, классификация и формализация информации обо всех аспектах предметной области, влияющих на свойства конечного продукта, и именно этот этап оказывает определяющее влияние на качество результатов всего проекта. Отсюда следует особая значимость задач, относящихся к данному этапу. В рамках названной выше проблемы первоочередными являются задачи, направленные на формализацию начального этапа жизненного цикла ПО анализа предметной области и формализацию последующей оценки трудоемкости реализации выявленных требований.
Проблемам моделирования и проектирования программных систем посвящено значительное количество работ. Среди наиболее известных работ, посвященных методам проектирования и оценки программных систем следует отметить работы российских ученых: В.В. Липаева, A.M. Вендрова, С.А. Орлова, Е.З. Зиндера, Г.Н. Калянова и др. Среди зарубежных можно выделить работы таких авторов как G. Booch, Е. Yourdon, I. Jacobson, D. Longstreet, В. Boem, R. Ganter и др. В тоже время, довольно мало внимания уделяется проблеме оценки сложности ПС на ранних этапах разработки. В современных методах практически не представлены формализованные критерии и процедуры для обеспечения функциональной полноты и логической целостности результатов анализа предметной области, отсутствуют гибкие формализованные методы классификации и подсчета трудоемкости разработки программной системы, позволяющие быстро провести такой анализ. Применение существующих методов оценки ПС на практике оказывается весьма трудоемким, кроме того, они не достаточно формализовано и гибко учитывают разнообразные факторы, влияющие на сроки и длительность проекта.
В результате, на сегодняшний день, существуют два противоречащих друг другу фактора: с одной стороны - рост потребностей в заказных проектах, направленных на разработку корпоративных информационных систем, и высоких требований к срокам и качеству результатов, с другой стороны - недостаточное развитие технологий оценки и проектирования программных систем в составе КИС, обеспечивающих качество, структурированность и логическую целостность технико-экономического обоснования (ТЭО) проекта разработки. Таким образом, разработка научно обоснованных методов проектирования и оценки программных систем является актуальной научно-технической проблемой, имеющей существенное значение для экономики страны.
Цель и задачи исследования. Целью диссертационной работы является разработка научно обоснованной технологии оценки трудоемкости разработки программных систем на основе формализованной информации о предметной области и специфике проекта, позволяющей повысить оперативность и качество планирования процесса производства программных систем.
Для достижения вышеуказанной цели поставлены и решены следующие задачи:
S Исследование методологий проектирования и оценки ПС и их применимости для предварительной формализации требований к системе и дальнейшего измерения трудоемкости разработки программной системы.
S Разработка адаптируемых к предметной области и условиям конкретного проекта методов моделирования предметной области корпоративной программной системы, позволяющих формализовать измерение результатов моделирования.
S Разработка моделей, определяющих компоненты процесса производства ПС и связи между ними, позволяющих сымитировать процесс выполнения плана программного проекта, а также визуализировать результаты исполнения и измерения плана проекта.
S Определение набора метрик и дефектов плана программного проекта, позволяющих формализовать методы анализа его характеристик.
•S Разработка технологии оценки трудоемкости разработки ПС, на основе первичных данных о предметной области и специфике проекта с дальнейшей подготовкой ТЭО проекта разработки корпоративной программной системы.
S Экспериментальное подтверждение применимости предложенной технологии на реальных данных предприятия-разработчика программных систем.
Методы исследования. В работе применены аппарат теории матриц и логических операций, методы реляционной алгебры, элементы математической логики.
Научная новизна. Разработана новая технология оценки трудоемкости разработки корпоративных программных систем. К новым результатам относятся:
S Формальная технология оценки трудоемкости разработки ПС, адаптируемая к предметной области и условиям конкретного проекта, инвариантная к размеру исходных данных.
S Методы моделирования предметной области программной системы, обеспечивающие возможность оперативной формальной оценки функционала разрабатываемой программной системы;
S Формальные реляционные модели, позволяющие имитировать процесс производства программного обеспечения и его свойства.
•S Метрики и дефекты плана программного проекта, позволяющие формализовать проведение его анализа.
Практическая значимость работы состоит в разработке программных средств, реализующих новые методы и технологии, позволившие осуществить снижение затрат на предпроектные исследования программной системы и её предметной области у разработчиков ПС, а также уменьшение рисков срыва сроков проекта и/или увеличения сметной стоимости разработки системы. Таким образом, полученные в диссертации научные результаты имеют конкретную прикладную направленность, связанную с повышением качества планирования процесса производства ПС, а также с сокращением по сравнению с существующими технологиями сроков создания ПС.
Результаты проведенных научных исследований и разработок были использованы при разработке КИС на предприятиях сферы услуг, в банковской отрасли и показали экономическую целесообразность применения новых технологий оценки и проектирования ПС.
Основные положения, выносимые на защиту:
•S Структурный метод оценки трудоемкости разработки корпоративных программных систем; •S Реляционные модели процессов производства прикладных корпоративных программного систем: •S Метрики и дефекты плана программного проекта, позволяющие формализовать процесс его анализа;
S Методы моделирования предметной области программной системы, обеспечивающие возможность формальной оценки трудоемкости программной системы.
Реализация результатов.
Результаты работы применяются в «ОАО «Мехкомплект» на этапах предпроектного исследования и анализа предметной области при разработке заказных программных систем и были использованы при реализации различных проектов для Центрального Банка РФ, МЧС - Госпожарнадзора, ТНК-Украина и др.
Апробация работы и публикации. По теме диссертации опубликованы 13 работ и сделаны доклады на следующих семинарах и конференциях:
Научно-техническая конференция студентов, аспирантов и молодых специалистов МИЭМ 2003-2006 гг.
Международная научно-техническая конференция МГТУГА, 2003 г.
Международная конференции "Information and Telecommunication Technologies in Intelligent Systems", Spain, 2003-2005 гг.
IX научно-практический семинар "Новые информационные технологии в автоматизированных системах", МИЭМ, МГТУ им. Н.Э. Баумана, ИПМ им. М.В. Келдыша, 2006
Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения и приложения, содержащего акты внедрения результатов работы. Список использованной литературы содержит 69 наименований. Текст диссертации содержит 137 страниц машинописного текста, включая 30 рисунков и 8 таблиц.
Инструменты моделирования процессов производства ПС
В связи с тем, что процессы производства ПС выполняются совместно людьми и вычислительными машинами, их модели значительно отличаются от большого числа других вычислительных моделей, разработанных в программировании. При выполнении этих процессов рутинная работа сочетается с творческой. Программные процессы могут выполняться в течение значительных промежутков времени — от нескольких дней до нескольких лет. В ходе их выполнения часть видов деятельности внутри процесса может выполняться периодически или эпизодически, в то время как другие виды деятельности — непрерывно [39, 50, 52].
Программные процессы обладают набором характерных свойств.
Параллельность и распределенность. Программные процессы по своей сути параллельны. Они включают параллельные, взаимодействующие между собой задачи, которые могут быть распределены в пространстве или во времени. Задачи могут выполняться группами людей или специальными средствами, при этом многие задачи выполняются совместно несколькими людьми. Они могут выполнять задачу одновременно (например, проводить совместную экспертизу) или параллельно (разрабатывать разные функции одного и того же ПС). При этом люди могут использовать различные методы и средства. Один человек может параллельно выполнять несколько видов деятельности, при этом его рабочее время может быть поделено между ними по-разному: в равных долях, с приоритетов задач, или же он может выполнять задачи последовательно [39, 50].
Неточность и неопределённость. Программные процессы не предопределены. Последовательность выполняемых шагов нельзя предсказать заранее: выбор альтернативных путей может быть сделан уже в ходе работы. Этот выбор зависит от результатов выполнения предыдущих шагов. Такие решения приходится принимать постоянно и в разном масштабе: от решения о повторном тестировании некоторой функции до решения о выпуске на рынок новой версии ПС. Причём причины, побудившие принять то или иное решение, не могут быть полностью описаны моделью программного процесса [39].
При некоторых ракурсах рассмотрения недетерминированный характер программных процессов может быть не очевидным. Простейшее представление каскадной модели полностью детерминировано и последовательно, если же добавить возвраты между фазами, сразу появляются и недетерминированность и параллельность. Те модели, в которых представляются различные роли в программном проекте или организации, ясно показывают параллельный характер процесса [39].
Ошибки, переработка и возникновение других нештатных ситуаций. Как и в других инженерных дисциплинах, при разработке ПС используются проверки, экспертизы, инспекции и другие методы обеспечения качества. В результате обнаруживаются ошибки в созданных продуктах, они исправляются, рассматриваются последствия этих ошибок, при этом часто приходится возвращаться на ранние шаги процесса. Таким образом, процесс, который на первый взгляд казался простым и линейным, в результате различных непредвиденных ситуаций становится более сложным.
Развитие и изменение. Программный процесс, так же как и ПО, имеет свой жизненный цикл, в течение которого его приходится не раз менять по многим причинам. Опыт, полученный при выполнении процесса, ведёт к его улучшению. Появляются новые методы и средства, и процесс приходится менять, для того чтобы он соответствовал им. Могут измениться типы разрабатываемых ПС, опыт персонала и многое другое. Такими эволюционными изменениями необходимо управлять для того, чтобы переход к новому процессу произошёл в наиболее подходящее для этого время [39, 50].
В настоящее время при выполнении любых проектов применяются программные средства (ПС) для их моделирования и планирования. При этом широкое распространение получили лишь несколько средств [17, 23].
Наиболее известным из них является Microsoft Project [17, 23]. Это ПС позволяет задать набор задач проекта, определить их свойства (такие как запланированная продолжительность, дата начала выполнения и др.), задать зависимости между задачами. При этом поддерживается иерархическое представление плана, т.е. его разделение на фазы, виды и подвиды деятельности и отдельные задачи. Microsoft Project позволяет определить доступные для проекта ресурсы и назначить их для выполнения задач.
Контроль выполнения созданного плана поддерживается возможностью внесения фактических данных о ходе проекта и автоматической генерацией отчётов. Microsoft Project поддерживает удобные для анализа формы представления плана, такие как сеть задач проекта, диаграмма Гантта, профили занятости ресурсов и др.
Существенным недостатком рассматриваемого ПС является отсутствие каких-либо возможностей моделирования процесса выполнения плана, его динамических свойств. Кроме этого, отсутствуют средства измерения и оценивания плана, нет возможности сравнить различные варианты плана и выбрать лучший.
Альтернативным средством планирования является Open Plan [17, 26], который предоставляет широкие возможности для управления ресурсами, а именно, объединение ресурсов в группы и манипулирование ими, автоматический подбор свободного ресурса, наиболее подходящего для выполнения некоторой работы, назначение приоритетов задач.
Open Plan позволяет моделировать процесс исполнения запланированного проекта, но при этом не производится автоматического измерения плана, поиска в нём дефектных элементов (чрезмерного распараллеливания исполнителей, задержек из-за неготовности каких-либо продуктов и т.п.). Как и Microsoft Project, Open Plan не позволяет выполнять автоматическое оценивание планов проекта и сравнение их различных вариантов.
Метод определения минимального уровня детализации модели
Для обеспечения необходимого и достаточного уровня детализации функциональной модели предлагается новый критерий определения минимального уровня детализации, который применяется при моделировании предметной области в целом (первая итерация).
Применение данного метода позволяет: обеспечить необходимый и достаточный уровень детализации исходных данных для следующих шагов и этапов проекта; обеспечить единый уровень абстракции модели, построенной несколькими аналитиками; ограничить совокупную сложность функциональной модели.
Необходимость и достаточность исходных данных для следующих шагов и этапов проекта подразумевает глубину функциональной модели, позволяющую сформировать Список Требований и обеспечить тем самым информацию для последующего выделения ЛС (формирования Списка Сущностей), БЛС, построения БМД, проектирования архитектуры программной системы и планирования ее параллельно-последовательной разработки.
Единый уровень абстракции модели необходим для обеспечения логической целостности результатов коллективной работы, что обеспечивается за счет процедур оперативной верификации частных результатов, в процессе которых производится контроль на соответствие глубины детализации данной ветви функциональной модели единому признаку [21, 22].
Ограничение совокупной сложности функциональной модели необходимо для исключения излишних затрат ресурсов в процессе моделирования за счет предотвращения избыточной детализации модели аналитиками. Предлагается следующий признак глубины детализации функциональной модели: Каждому потоку данных нижнего уровня функциональной модели должно соответствовать одно идентифицируемое требование предметной области (ТР).
Данный критерий обеспечивает выявление всей совокупности используемых в предметной области информационных объектов, что является необходимым для выполнения следующих шагов анализа и перехода к проектированию программной системы. Метод подразумевает приоритет информационной составляющей в процессе анализа предметной области. В соответствии с ним построение функциональной модели предметной области должно производиться до тех пор, пока все потоки данных нижнего уровня модели не будут промаркированы требованиями.
Целесообразность применения данного метода подтверждается следующими факторами: Существуют предметные области, информационная составляющая которых является более стабильной и имеет меньшую мощность по сравнению с функциональной составляющей. Данный тезис подтверждается: материалами структурных методов анализа, отдающих приоритет выявлению и формализации информационных элементов (например, JSD DATARUN [58]); материалами объектно-ориентированных методов разработки, ориентированных на выявление в процессе функционального моделирования классов предметной области, являющихся развитием информационных сущностей [10, 63].
Критерий, опирающийся на информационные элементы предметной области (ТР), в отличие от функциональных критериев, является проверяемым в процессе анализа и моделирования, выполняемого в соответствии с методикой, т.к. ТР накапливаются в едином списки проекта (СпТР), проходя при этом процедуру оперативной верификации и унификации синтаксиса и семантики. Предлагаемый признак обеспечивает: исходные данные, достаточные для следующих шагов и этапов проекта: позволяет сформировать Список Требований и обеспечить глубину функциональной модели, достаточную для выделения ЛС, БЛС, построения БМД; глубина детализации функциональной модели позволяет выполнить общесистемное проектирование и планирование параллельно-последовательной разработки подсистем, оставляя более глубокую детализацию функциональных процессов и полный атрибутный анализ информационных элементов на следующие итерации моделирования в процессе работы по частям проекта; единый уровень абстракции функциональной модели; ограничение сложности функциональной модели, предотвращая ее избыточную детализацию.
Таким образом, данный метод позволяет решить вторую из поставленных в диссертационной работе задач и удовлетворить требованию по обеспечению необходимого и достаточного уровня детализации функциональной модели, предъявляемому к методам моделирования, используемым, в том числе, для оценки трудоемкости разработки программных систем.
Для ограничения сложности модели данных на первой итерации моделирования разработан метод, позволяющий выявить ограниченный набор сущностей из общего их числа, которые имеют наибольшие значение в процессе оценки трудоемкости разработки ПС.
Выделение базовых сущностей из всего множества сущностей в системе необходимо как для решения задачи понижения сложности МД, так и для обеспечения логической целостности разрабатываемого информационного и программного обеспечения.
Для обеспечения возможности эффективного применения в любой организации, реализация метода должна обладать следующими свойствами: формализованный характер; независимость от методов анализа; независимость от сложности исходных данных; адаптируемость к условиям конкретного проекта.
Метод определения базовых сущностей должен быть формализованным, поскольку на данном шаге закладывается интегрирующая основа результатов всего проекта, для чего необходимо ограничить влияние субъективных факторов, связанных с личностными качествами и квалификацией исполнителей.
Независимость от сложности исходных данных также не может быть абсолютной, т.к. очевидно, что трудоемкость выполнения даже простейших формальных операций растет при увеличении количества операндов. Однако данное свойство следует трактовать таким образом, что зависеть от сложности могут только формальные операции, допускающие автоматизацию, при которой трудоемкостью их выполнения можно пренебречь.
Динамическая модель плана проекта разработки программной системы
Целью этого раздела является формальное специфицирование реляционной динамической модели плана программного проекта. Эта модель описывает процесс исполнения статической модели плана проекта (см. раздел 3.1) при заданных значениях параметров. Она предназначена для исследования динамических характеристик плана программного проекта без реального выполнения этого плана [66, 67].
Модель процесса исполнения плана программного проекта ниже описана в форме проблемно-ориентированного исчисления, которое включает в себя четыре составляющие [19, 24]: 1) структуру множества состояний рабочей среды, 2) проблемно-ориентированные правила, 3) универсальный рецепт (правила вывода, которые описывают регламент применения проблемно-ориентированных правил), 4) правила остановки. Каждое состояние рабочей среды Wj есть множество кортежей отношений трех типов: 1) отношений, описывающих сам исполняемый план, а именно: Шаги-проекта (Project-steps), Продукты (Products), Ограничения (Constraints), Назначения (Assignments), Предыдущий (Previous), Исполъзуемые-средства (Usedools), Исполъзуемые-методы (Used-methods), Starting-step (НачалънъШ-шаг), описанных в разделе 3.1; значения этих отношений не меняются в процессе исполнения плана, и в каждом состоянии W; они одинаковы; 2) отношения Текущее-время (Currentime), представляющего условные часы и указывающего текущий момент времени ("такт") процесса исполнения плана (значения параметров Ттах и delta задаются извне): Currentime (time-moment, delta), time-moment є [0, Tmax], delta Tmax; 3) отношений, описывающих текущее состояние процесса исполнения модели плана проекта, а именно: Запущен (Started), Текущая доля (Current-ratio), Задания (Assumptions), Выполняет (Performs), Использование-ресурсов (Allocations), Завершён (Finished), Создан (Produced). Представляет момент начала выполнения шага step; Представляет долю работы efforts-ratio, выполненную на шаге step к моменту time-moment;
Начальное состояние - состояние рабочей среды Wj содержащее кортежи отношений первого типа (см. выше), кортеж для начального момента времени Currentime (0, delta), а также по два кортежа третьего типа для каждого используемого в проекте ресурса (кроме методов): (V agent-name (Assignments (_, agent-name, _,_,)— Assumptions (О, agent-name, [])) ( [] обозначает пустой список ) (V tool-name (Usedools (tool-name, _,_)— Allocations (0, tool-name, []) ).
Конечное состояние. Конечным состоянием рабочей среды Wj является состояние, полученное в результате применения правила остановки (см. раздел 3.2.4).
Проблемно-ориентированные правила (применение которых регламентируется универсальным правилом вывода (см. раздел 3.2.3)) определяют операции добавления множества новых кортежей к текущему состоянию рабочей среды W,. Они моделируют изменения, происходящие во время выполнения проекта: начало и завершение шагов проекта, создание рабочих продуктов, назначение новых заданий исполнителям и их освобождение, выполнение исполнителями своей работы. Синтаксис правил основан на положениях математической логики и реляционной алгебры. При этом здесь и далее в работе все переменные, для которых явно не задана область их действия, считаются находящимися под квантором существования, начиная с момента их указания и в пределах области, ограниченной скобками соответствующего уровня вложенности.
Далее приведены основные правила, позволяющее исполнить статическую реляционную модель плана программного проекта и смоделировать процесс выполнения плана.
Процесс вывода останавливается, если достигнуто конечное состояние рабочей среды Wj или превышено установленное на шкале времени максимальное значение, т.е. истинен предикат: (&(Vproduct-ref (Products (product-ref, _,...)) Produced (_, product-ref)) V Currentime (time-moment, _) & time-moment Tmax
Перед началом модельного исполнения плана проекта руководитель проекта должен задать длину единичного временного интервала (delta), используемого во "внутренних часах" процесса выполнения проекта и определяющего точность моделирования динамики проекта. Кроме того, руководитель проекта должен выбрать варианты правил, которые будут использоваться при моделировании, что обеспечивает гибкость моделирования динамики проекта.
В процессе выполнения, в случае выбора вариантов правил с параметрами, необходимо оценивать значения этих параметров в конкретном контексте. После завершения процесса исполнения плана программного проекта, в результате применения проблемно-ориентированных правил к статической реляционной модели плана проекта, будет сгенерирована описывающая его динамическая реляционная модель плана проекта.
Статический граф плана проекта предназначен для визуализации фрагментов плана программного проекта, поддержки процесса его специфицирования и моделирования процесса его.
Предлагаемая графовая модель отражает видение плана программного проекта как сети задач; такое видение является широко распространенным (task network [24], network of tasks [56]). Вершины-задачи связаны дугами, отражающими передачу между задачами производимых ими продуктов. Кроме этого, модель отражает назначение ресурсов (людей, средств и методов) для выполнения шагов проекта. Вершины-ресурсы связаны дугами с теми вершинами-задачами, для выполнения которых они назначены, при этом указаны шаги, на которых выполняются задачи (поскольку одна и та же задача может выполняться многократно).
В качестве структурной модели плана проекта будем использовать связный размеченный ориентированный граф G = Tasks, Res, (Rl, R2) , где Task - множество вершин графа, представляющих множество задач плана программного проекта S - разметка множества вершин Task, определяющая шаги программного проекта и частичный порядок их выполнения Res - множество вершин графа, представляющих те ресурсы, использование которых планируется в моделируемом проекте. R1 - множество дуг графа, представляющих передачи продуктов между задачами плана проекта R2 - множество дуг, представляющих назначение ресурсов для выполнения шагов проекта. В работе [56] аналогичный граф с двумя типами вершин называется многослойным (layered).
Приведенное ниже определение графа G представляет собой набор правил, устанавливающих взаимно-однозначное соответствие между элементами графа G и атрибутами реляционной модели (см. раздел 3.1). Такое определение позволяет, с одной стороны, использовать граф G для специфицирования полной модели плана программного проекта, а с другой — однозначно определять любые фрагменты модели плана при визуализации.
Метод формализации влияния общесистемных характеристик
Для ошибок при оценке трудоемкости возможно брать абсолютные величины значений, так как в обоих случаях неточной оценки для разработчиков следуют неприятные последствия: при недооценке трудоемкости - заниженная сумма затрат на разработку и срыв сроков сдачи проекта, а в случае переоценки трудоемкости - простой команды разработчиков. В тоже время при оценке длительности разработки существенна в основном недооценка длительности разработки. Итак, можно найти величину относительной ошибки оценки трудоемкости разработки ПС структурными методами: где
Тсистемы _ оценочная трудоемкость системы; Т системы _ реальная трудоемкость системы; Наиболее интересной представляется эмпирически полученная степенная зависимость точности оценки трудоемкости разработки программной системы от её размера, а также экспоненциальная, но в нашем случае близкая к линейной, зависимость трудоемкости применения самой технологии оценки от размера будущей системы (Рис. 25). Видно что для крупных проектов значительно повышается эффективность применения технологии, так как при небольшом приросте затрат на оценку по сравнению с небольшими проектами существенно понижается вероятность ошибок оценки.
На Рис. 26 показана трудоемкость оценки проекта по отношению к его размеру. Практически не зависимо от масштаба корпоративной программной системы затраты на её первоначальную оценку структурными методами составят около 0,5% от общих затрат на её создание.
Трудоемкость оценки проектаТаким образом, анализ опыта применения предложенной в работе технологии оценки трудоемкости разработки прикладных корпоративных программных систем структурными методами показал, что данная технология позволяется оценивать проекты среднего и крупного масштаба с минимальными затратами времени, при сохранении высокой точности оценки.
Данный раздел посвящен задачам измерения, оценивания и прослеживания плана программного проекта. Для формального решения задач определения метрик и дефектов используются следующие модели: статическая и динамическая реляционные модели плана проекта, статический граф G = Tasks, Res, (RI, R2) .
Целью этого раздела является формальное определение метрик и дефектов плана программного проекта, обеспечивающих базис для измерения и анализа характеристик различных вариантов плана.
Так как все понятия, используемые при построении формальной модели плана программного проекта, были определены формально (см. выше), метрики плана программного проекта также могут быть формально определены в тех же терминах, что и модель плана проекта. Ниже представлены формальные определения метрик, связанных с наиболее важными свойствами планов программных проектов: продолжительностью проекта и отдельных видов деятельности, занятостью исполнителей [18, 43, 57].
Каждая метрика плана программного проекта определяется как функция, правило вычисления значений которой задается в форме логического правила, причем условие этого правила выполняет роль оператора конкретизации множества значений используемых переменных, а следствие - оператора присваивания значений.
Метрика 1. Продолжительность проекта Фактическая продолжительность программного проекта (сетевое время (net process time [58], длина критического пути (critical path [60])). Формальное определение: Currentime (time-moment, _) — net-processime = time-moment
В соответствии с универсальным правилом вывода (см. раздел 3.2.3), в каждом состоянии рабочей среды Wj процесса исполнения модели плана проекта существует только один кортеж отношения Currentime, который представляет текущее время проекта. Тем самым, по окончании процесса исполнения значение переменной time-moment представляет фактическую продолжительность модельного исполнения проекта.
Метрика 2. Занятость исполнителя в проекте Процентная доля времени занятости исполнителя в проекте по отношению к общей продолжительности проекта. Формальное определение: 3 agent-name Є Agent-names (time-intervals = {time-moment (Performs (time-moment,_,agent-name,_,_) & V time-momentl,time-moment2 Є time-intervals (time-momentl Ф time-moment2))} — agent-usageime-ratio (agent-name) = time-intervals I net-processime 100)
Каждый кортеж отношения Performs определен на промежутке времени длиной delta. В соответствии с правилами моделирования выполнения шага проекта (см. раздел 3.2.2.3), на каждом таком промежутке исполнитель может либо находиться в состоянии "свободен" (если его список назначений пуст), либо быть полностью занятым выполнением работы из текущего списка назначений. Тем самым, время, затраченное исполнителем на работу в проекте, определяется суммарным размером промежутков "занятости" исполнителя. Процентная доля времени, затраченного исполнителем на работу в проекте, по отношению к общей продолжительности проекта (см. Метрику 1) определяет значение рассматриваемой метрики.
Метрика 3. Средний уровень занятости исполнителей в проекте Средняя (медианная) доля занятости исполнителей в проекте при установленных назначениях (относительно общей продолжительности проекта). Формальное определение: V agent-name є Agent-names (all-agent-usageime-ratios = { agent-usageime-ratio (agent-name)} —» resource-capacity-usage-ratio = median (all-agent-usageime-ratios))
Функция median находит среднее медианное значение для заданного набора значений.
Для каждого исполнителя вычисляется процентная доля времени его занятости в проекте (см. определение Метрики 2). Для полученного набора значений при помощи функции median вычисляется средняя процентная доля занятости исполнителей в проекте.
