Оценка трудоемкости и предсказания сроков сдачи программного обеспечения в эксплуатацию Кульдин Сергей Павлович[1], студент[1] МГУ им. М.В.Ломоносова, ф-т ВМиК, Москва, Россия

Введение В любом программном проекте приходится балансировать между стоимостью, временем, качеством и объемом реализуемой функциональности. Соответственно, точный расчет ресурсов, необходимых для реализации данного продукта с заданными требованиями к качеству, является одной из основных проблем в области управления проектами. При этом расчете возникают сложности учета огромного количества факторов, влияющих на жизненный цикл ПО. Как следствие, сегодня многие компании сталкиваются с серьезными проблемами в случае неправильных расчетов необходимых сроков: при недооценке - непредвиденная трата дополнительных средств, недовольство заказчика невыполнением обязательств в срок, "бессонные ночи" сотрудников, сложность управления "обвальным" проектом, низкое качество конечного продукта, слаборазвитые функции системы и т. д; при переоценке - бесполезный расход ресурсов привлеченных к проекту, отказ заказчика от контракта с данными условиями (как следствие, возможно, потеря рабочих мест) и т.д.

На современном рынке крупных программных систем потери могут исчисляться миллионами долларов. Точные оценки издержек производства программного обеспечения важны как разработчикам так и заказчику (клиенту). Они могут использоваться при переговорах о контракте, планировании, контроле и т.п. Таким образом, возникает реальная потребность в разработке методов и средств, позволяющих менеджеру оценить требуемые временные и человеческие ресурсы на основе всех имеющихся характеристик проекта: истории предыдущих подобных проектов, опыта и производительности сотрудников, специфики компании и т. п. Кроме того, требуется также возможность перерасчета и уточнения сроков и ресурсов уже на этапе разработки системы с учетом текущих тенденций, наблюдаемых при реализации проекта. Это поможет менеджеру своевременно обнаружить отклонения от установленного графика и принять соответствующие меры в управлении проектом.

Краткий обзор основных понятий и проблем рассматриваемой области Непосредственные усилия разработчиков (их трудозатраты) обеспечивают большую часть стоимости разработки ПО, и, как привило, методы оценки необходимых средств (как следствие и необходимого времени) сосредотачиваются именно на этом аспекте и дают оценки в человеко-месяцах, которые впоследствии могут быть преобразованы в продолжительность проекта или стоимость. На практике сталкиваются с 3 проблемами, имеющими принципиальное значение: Какую модель оценки использовать? Какую метрику размера ПО использовать (число строк кода (LOC - Lines Of Code), "функциональные точки" (FP - Function Points) или "точки свойств" (feature points))? Что вообще есть хорошая оценка?

Выбор модели оценки Широко применяемым на практике методом оценки трудозатрат, являлась и является экспертная оценка. Однако, такой подход сопряжен с множеством проблем: Основания для получения оценки не являются явными Тяжело находить высоко-квалифицированных экспертов для каждого нового проекта Связь между размером системы и трудозатратами - нелинейна. Трудозатраты возрастают экспоненциально с увеличением объема. Поэтому экспертная оценка получается адекватной, только в случае, если текущий проект и предыдущие примерно одинакового масштаба. Политика руководства направленная на сокращение затрат, как правило ставит под сомнение реальный опыт предыдущих проектов и вносит долю "слепого оптимизма".

За три последних десятилетия было разработано множество различных моделей количественной оценки трудозатрат. Они варьируются от моделей основанных на эмпирических данных (например, модель "COCOMO" Барри Боема [1]) до чисто аналитических моделей. Эмпирические модели используют данные предыдущих проектов чтобы оценить текущий (анализируя закономерности прослеживаемые с помощью имеющихся баз данных предыдущих проектов). С другой стороны, аналитические модели базируются на глобальных предположениях, относительно связи различных параметров, таких, например, как скорость устранения дефектов разработчиком и их количество в определенный момент времени. Каждая модель имеет свои достоинства и недостатки, но ключевым фактором при её рассмотрении, конечно же, является точность.

Выбор метрики размера Большинство моделей (как эмпирических, так и аналитических) базируются на использовании различных метрик размера разрабатываемой системы (LOC, FP и др.). Точность оценки трудозатрат напрямую зависит от точности оценки размера. Независимо от выбранной метрики размера, определить его заранее точно не представляется возможным, поэтому приходится его уточнять (и, соответственно, производить общую переоценку трудозатрат) уже непосредственно в процессе разработки. Влияние этого фактора заметно уменьшается при использовании достаточно строгой методологии разработки и при детальной проработке требований к системе. В силу особой важности данного вопроса для решения исходной задачи, мы поговорим о нем более подробно в следующем разделе.

Критерии хорошей оценки По Ройсу (Royce [2]), у хорошей оценки издержек производства программного обеспечения должны быть следующие признаки: понята и поддержана менеджером проекта и командой разработчиков одобрена всеми заинтересованными лицами как реально осуществимая основана на четкой модели с заслуживающими доверия основаниями основана на базе данных подобного проекта (с подобными бизнес- процессами, подобными технологиями, подобной внешней средой, подобными людьми и подобными требованиями). определена настолько детально, что ключевые области риска поняты и вероятность успеха объективно оценена Оценка трудоемкости и стоимости, исторически была одной из наиболее сложных проблем при разработке программного обеспечения. Несколько причин этих трудностей: Нехватка исторически сложившейся базы данных оценок трудоемкости Разработка программного обеспечения основана на множестве взаимосвязанных факторов, которые непосредственно влияют на продуктивность и отношения которых полностью не выявлены Нехватка оценщиков с опытом.

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

Число строк кода LOC (Lines Of Code) - число непустых строк исходного текста, исключая комментарии [4]. Несмотря на то, что эта метрика существенно зависит от выбранного языка программирования, она до сих пор остается самой используемой метрикой размера ПО. Конечно, точное число LOC может только быть получено только после того, как проект уже закончен. Поэтому, оценка размера кода программы до его создания, не намного проще оценки реальных трудозатрат например в человеко-месяцах.

Типичный метод осуществления такой оценки использует комбинацию экспертных оценок с техникой под названием PERT [6], заключающейся в следующем: пусть имеется n экспертов, каждый i-ый эксперт высказывает три предположения относительно конечного размера: Li - нижняя оценка размера, Hi - верхняя оценка размера и Mi - наиболее вероятный размер. Тогда размер S может быть вычислен как:

Точность оценки может быть существенно улучшена, если применить PERT не к проекту в целом, а к его отдельным компонентам. Тогда общая оценка размера может быть получена как сумма таких "локальных" оценок.

Метрики Холстеда Холстедом были предложены такие метрики как длина кода и объем [7]. Длина кода определяется как: где N1 - общее количество появлений операторов в программе, а N2 - общее количество их операндов. Объем кода - соответствует объему памяти требуемой для хранения программы и определяется как: где n1 - число различных операторов, и n2 - число различных операндов, появляющихся в программе. Очевидно, оценить общее число операторов и их операндов до завершения проекта как правило еще более затруднительно чем оценить LOC, поэтому в адрес предложенных Холстедом метрик было высказано множество замечаний [14, 15]. Поддержка такого подхода в последние годы постоянно уменьшается.

Функциональные точки (Function points) Наиболее удачной заменой количеству строк кода для измерения размера стали функциональные точки (function points), впервые предложенные сотрудником IBM Аланом Альбрехтом (Allan Albrecht) в 1979 г [8]. Применение функциональных точек основано на оценке объема реализуемой функциональности за счет изучения требований, вследствие чего, оценка необходимых трудозатрат может быть выполнена на самых ранних стадиях работы над проектом и далее будет уточняться по ходу жизненного цикла, а явная связь между требованиями к создаваемой системе и получаемой оценкой позволяет заказчику понять, за что именно он платит, и во что выльется изменение первоначального задания.

Кратко рассмотрим основные принципы метода. Общее количество функциональных точек программы зависит от количества элементарных процессов пяти типов: Входящие транзакции (External inputs (EI)) - транзакции, получающие данные от пользователя. Исходящие транзакции (External outputs (EO)) - транзакции, передающие данные пользователю. Взаимодействия с пользователем (External inquiries (EQ)) - интерактивные диалоги взаимодействия с пользователем (требующие от него каких-либо действий). Файлы внутренней логики (Internal logical files) - файлы (логические группы информации), использующиеся во внутренних взаимодействиях системы. Файлы внешних взаимодействий (External interface filese) - файлы, участвующие во внешних взаимодействиях с другими системами.

Рис. 1. Типы элементарных процессов используемых в методе FP

В данной терминологии, транзакция - элементарный неделимый замкнутый процесс, представляющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое. Каждому из этих типов назначают один из трех уровней сложности (1 = простой, 2 = средний, 3 = сложный), а каждой паре (тип, уровень сложности) ставят в соответствие вес представляющий собой количество не выровненных функциональных точек (UFP), который изменяется от 3 (для простой входящей транзакции) до 15 (для сложных внутренних файлов). Общая оценка размера в UFP рассчитывается как: где Nij и Wij - соответственно число и вес элементов системы класса i со сложностью j.

Например, если в системе - 2 простых входа (Wij = 3), 2 сложных выхода (Wij = 7) и 1 сложный внутренний файл (Wij = 15). Тогда UFP = 2*3 + 2*7 +1*15 = 35. Это число функциональных точек может как непосредственно использоваться для оценки стоимости/трудоемкости так и может быть еще уточнено с помощью фактора выравнивания (VAF), который вычисляется на основании характеристик общей сложности проекта, таких как: степень распределенноcти обработки и хранения данных, требования к производительности системы, требования к безопасности и т.д. При этом окончательная оценка размера в выровненных функциональных точках, рассчитывается как: где CFP - дополнительные функциональные точки, которые потребуются, например, для установки или миграции данных. Общая схема процедуры оценки представлена на рис. 2.

Рис. 2. Процедура оценки функционального размера по методу FP

Число UFP может и число строк кода (LOC) связаны линейно: Параметры a и b могут быть получены, с помощью линейной регрессии на основании имеющихся данных о завершенных проектах.

Точки свойств (Feature points) В условиях, когда сформулированные требования не отражают истинной сложности реализации (что особенно характерно для системного ПО, критически важных программных комплексов и пр.), метод функциональных точек себя не оправдывает. В этом случае на помощь приходит его модифицированный вариант, предложенный в 1988 г. Кейперсом Джонсом (Capers Jones [9]), который учитывает не только требования к системе, но и внутренние особенности ее реализации – метод точек свойств (feature points). Он очень близок к методу функциональных точек, с тем лишь отличием, что предусматривает корректирование получаемой оценки с учетом алгоритмической сложности. К перечисленным выше 5-ти элементарным классам функциональных объектов, добавляется класс алгоритмов. Алгоритм определяется как свод правил, который решает какую-либо существенную вычислительную задачу. Например, вычисление квадратного корня можно рассмотреть как алгоритм. Каждому используемому алгоритму сопоставляют вес в пределах от 1 (элементарный) до 10 (очень сложные алгоритмы) и количество точек свойств рассчитывается как взвешенная сумма алгоритмов плюс число функциональных точек. Эта метрика особенно полезна для систем с незначительным вводом/выводом, но с высокой алгоритмическая сложностью, таких как математическое программное обеспечение, системы дискретного моделирования, военные приложения и т.п.

Объектные точки (Object points) Поскольку классическая интерпретация метода функциональных точек не предусматривает применения объектно-ориентированного подхода, в современных проектах используется его адаптированный вариант, оперирующий именно терминами ОО-технологии. Принципиальным его отличием от других методов, производных от классического FP, является то, что он не расширяет базовый набор элементарных классов FP, а вводит совершенно иные: окна (screens), отчеты (reports) и 3GL компоненты. Каждому из этих объектов назначается вес в пределах от 1 (простое окно) до 10 (3GL компонент) и количество объектных точек рассчитывается по формуле, аналогичной (4). Это - относительно новая метрика и она пока не настолько популярна как FP. Но в силу своего удобства в применении на самых ранних этапах жизненного цикла ОО-проектов, (причем с неплохими показателями), она нашла успешное применение в некоторых разновидностях COCOMO [1].

Обзор и классификация методов оценки трудозатрат В самом общем смысле, все методы оценки проектов разделяются на две группы: Методы микрооценки, основаны на точном знании всех составляющих жизненного цикла. Например, Oracle AIM (Oracle Application Implementation Method – методика внедрения готовых приложений, разработана компанией Oracle для внедрения пакета готовых приложений Oracle E-Business Suite) и оценки трудоемкости для него. В этом методе для построения оценки необходимо построение разбивки работ и оценка каждой индивидуальной работы. Методы макрооценки, основаны на функциональных требованиях и/или других определениях конечного продукта. Таковы, например, методы функциональных точек и СОСОМО. С другой стороны, все методы оценки можно разделить также на алгоритмические и неалгоритмические. Сначала будет приведен общий обзор неалгоритмических методов, будут указаны их недостатки, которые делают резонным выбор именно алгоритмических методов, к числу которых и относится описываемый в данной работе генетический подход.

Оценка по аналогии Этот метод требует наличия одного или нескольких законченных проектов, которые подобны новому проекту. Оценка получается путем сравнения текущего проекта с предыдущими, с использованием реальных наблюдавшихся в них показателей. Оценка по аналогии может быть сделана или на уровне проекта в целом или на уровне отдельных подсистем. Преимуществом оценки по аналогии всего проекта в целом, является учет всех возможных составляющих факторов (например учет накладных расходов на организацию должного взаимодействия всех компонентов в целом). Оценка же по отдельным компонентам позволяет обеспечить более детальный учет общих черт и различий между новым проектом и законченными проектами. Достоинство этого метода: оценка основана на фактическом проектных результатах. Конечно не всегда корректно переносить результаты предыдущих проектов на текущий, т.к. нельзя с уверенностью сказать, что ограничения и условия предыдущего проекта можно перенести и использовать в новом проекте. Более детальное рассмотрение данного метода можно найти в [16].

Экспертная оценка Для получения оценки с помощью этого метода используются мнения нескольких экспертов. Эксперты полагаются на их собственные методы и опыт. Для достижения коллективного согласия, используются такие механизмы как техника Delphi или PERT (см. выше). Техника Delphi заключается в следующем: Координатор выдает каждому эксперту спецификацию и форму для выставления оценок. Каждый эксперт заполняет форму строго индивидуально, однако разрешено задавать вопросы координатору. Координатор подготавливает свод всех экспертных оценок (который включает также их средние значения и пояснения) на другой форме, которая раздается каждому эксперту для проведения следующей итерации. Шаги 2)-3) повторяются до достижения необходимой степени единообразия оценок. Модификация техники Delphi, предложенная Боемом [3], показала себя, более эффективной: предварительно производится совещание координатора и экспертов, на котором обсуждаются проблемы оценки. На шаге 3), эксперты не дают никакого объяснения своих оценок. Вместо этого после каждой итерации координатор проводит собрание, на котором обсуждаются детали оценки, по которым были выявлены наибольшие разногласия.

Принцип Паркинсона В соответствии с этим принципом "работа расширяется заполняя весь доступный объем" [5]: трудозатраты определяются не за счет объективной оценки, основанной на функциональности конечного продукта, а доступными ресурсами. Т.е. например, если конечный продукт должен быть передан заказчику через 12 месяцев и в проекте задействовано 5 человек, то оценка трудозатрат составит 60 человеко- месяцев. Иногда такой подход и бывает успешным, однако его применение чаще приводит к целому ряду негативных последствий, начиная от работы разработчиков в сверхурочное время и заканчивая расторжением контракта со стороны заказчика в случае невыполнений обязательств в срок из-за слишком нереалистичных сроков. Кроме всего прочего, принцип Парикнсона, как правило, приводит к созданию очень некачественного конечного продукта.

Цена победы При данном подходе оценка трудозатрат производится таким образом, чтобы она была самой выгодной для заказчика и контракт был бы гарантированно заключен. Т.о. оценка основывается на бюджете заказчика а не на конечной функциональности ПО. Например, если разумная оценка для проекта составляет 100 человеко-месяцев, но заказчик может оплатить только 60 человеко-месяцев, то оценщика просят изменить оценку, до 60-ти человеко-месяцев, чтобы выиграть проект. Это также очень плохой подход, который однако очень часто встречается на практике вследствие "политических игр руководства", и он с очень высокой степенью вероятности, вызовет задержку поставки или вынудит команду работать в сверхурочное время.

. Алгоритмические методы Используемый в алгоритмических моделях математический аппарат весьма разнообразен и варьируется от простых линейный формул, использующих математическое ожидание и среднеквадратичное отклонение, до сложных регрессионных моделей [12] и дифференциальных уравнений [11]. Как правило, чтобы улучшить точность алгоритмических моделей, их требуется приспособить (например, с помощью пересчета основных параметров и коэффициентов) к конкретным обстоятельствам. Причем, даже после такой калибровки точность может оставлять желать лучшего. Поэтому, можно считать, что у каждой конкретной модели есть своя конкретная область применения, в которой она может дать адекватный конечный результат. Все алгоритмические методы основаны на математических моделях которые определяют трудозатраты как функцию зависящую от множества переменных соответствующих основным влияющим на трудозатраты факторам и имеют общий вид:

Здесь E - суммарный объем трудозатрат (например, в человеко- часах), а xi, i = 1,...,n - учитывающиеся факторы. Соответственно многообразие алгоритмических методов обуславливается двумя основными аспектами: выбором факторов и формой функции f.

В зависимости от этого, среди алгоритмических моделей могут быть выделены 3 основных группы: Линейные модели Мультипликативные модели Степенные модели

в первых двух группах коэффициенты a1,...,an выбираются на основании данных предыдущих проектов; в третьей группе: S – размер проекта (основной фактор), a, b – функции (как правило очень простые) других факторов трудозатрат. Линейные модели не оправдали себя на практике и не раз подвергались объективной критике [5]. В частности, зависимость от большого числа факторов влияющих на разработку ПО имеет явно нелинейный характер, что приводит к явной неэффективности данного класса моделей. Мультипликативные модели (например модель Валстона- Феликса [12]) сложны в калибровке (рассчете и уточнении коэффициентов) и не нашли обширного практического применения. В силу указанных причин, мы не будем далее рассматривать методы данных классов, а кратко опишем один из наиболее популярных и эффективных степенных алгоритмических методов.

COCOMO COCOMO (COnstructive COst MOdel) и её производные являются пожалуй самыми популярными алгоритмическими моделями для оценки трудоемкости разработки ПО, которые де-факто стали стандартом. Модели относятся к классу степенных (см. выше). Базовая модель была представлена в 1981 г. Барри Боемом (Barry Boehm) [1]. С момента своего появления модель постепенно эволюционировала и можно обозначить основные этапы её развития следующим образом: 1. Базовая модель COCOMO. Размер проекта S измеряется в LOC (KLOC), а трудозатраты в человеко-месяцах. Cоздана на основе анализа статистических данных 63 проектов (в основном Министерства Обороны США) различных типов. Используется три набора параметров {a, b} в зависимости от сложности разрабатываемого программного обеспечения: –Для простых, легко понимаемых проектов, а = 2.4, b = 1.05 –Для сложных систем, a = 3.0, b = 1.15 –Для встроенных систем, a = 3.6, b = Модель была проста в использовании, но не обеспечивала должной точности.

COCOMO 2. Детализированная модель COCOMO. Уточнены наборы параметров {a, b}, и, кроме того, общая формула приняла форму, где M – уточняющий коэффициент, рассчитывающийся как произведение 15-ти поправочных факторов из 4-х категорий (факторы конечного продукта, вычислительной среды, персонала, проекта) варьирующихся в диапазоне от 0.7 до 1.66, которые могут быть найдены в специальной таблице. Эти изменения базовой модели позволили существенно улучшить точность оценки, особенно в случае применения метода к отдельным компонентам, а не к системе в целом.

COCOMO 3. COCOMO II. (1997 г.) Имеет много общего со своей предшественницей, однако во многом основана на новых идеях, а также адаптирована к современным методологиям разработки ПО (в частности, если COCOMO подразумевала только каскадную модель жизненного цикла, то COCOMO II также пригодна для спиральной и итеративной). При построении COCOMO II для обработки статистических данных использовался Байесовский анализ, который дает лучшие результаты для программных проектов, характеризующихся неполнотой и неоднозначностью, в отличие от многофакторного регрессионного, примененного в COCOMO. Также в ней допускается измерять размер проекта не только числом строк кода (LOC), но и более современными функциональными и объектными точками (см. выше). Помимо прочего, при расчете показателей COCOMO II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI CMM/CMMI. [15]

COCOMO Общее плановое время разработки в модели COCOMO рассчитывается по формуле: где c – коэффициент сжатия нормального графика, а p – функция зависящая от факторов масштаба системы. Детальное описание модели COCOMO II может быть найдено в [[1]].

Основная идея предлагаемого генетического подхода Основной проблемой современных методов оценки трудозатрат является сложность их адаптации к каждому конкретному проекту (калибровки коэффициетов модели). Каждый проект – это своя комманда, свои условия труда, своя специфика разработки. Обобщенные модели, такие как COCOMO, разработанные с учетом данных о большом количестве проектов не могут полностью учесть этой специфики. В данной работе предлагается принципиально новый, неклассический генетический подход к проблеме, основными принципами которого являются обеспечение простоты применимости метода на практике и учет информации, специфической для каждого конкретного проекта. В его основе лежит идея разделения общей задачи (предсказания необходимых ресурсов) на фиксированную и динамическую составляющие. При решении фиксированной части можно абстрагироваться от многих факторов, определяющих проектную специфику и применить какой-либо современный метод оценки трудозатрат, так словно он применяется к какому-нибудь типичному среднестатистическому проекту (например COCOMO). Это позволяет не учитывать при этом множество дополнительных факторов и существенно упростить реализацию метода.

Основная идея предлагаемого генетического подхода Главная же инновационная составляющая предлагаемого подхода заключается в способе решения динамической части задачи. Динамическая часть – оценка ресурсов, необходимых для устранения дефектов и других проблем, возникающих в процессе разработки системы, не укладывающихся в имеющиеся модели. Было замечено, что множество этих дефектов живет и развивается подобно биологической популяции, подверженной определённым воздействиям окружающей среды – множества сотрудников со своими показателями производительности. Эта среда как порождает эти дефекты, так и стремится их устранить впоследствии. Дефекты претерпевают мутации (проявляют заранее непредвиденные свойства), скрещиваются между собой, порождая новые, подвергаются отбору в соответствии со сложностью их устранения и т.п. Проведенные параллели с классическими понятиями теории эволюции биологических систем позволяют создать очень точную модель эволюции проекта в целом и рассчитывать необходимое дополнительное время, эмулируя жизнь этой популяции. Более того, ни один современный программный проект не обходится без системы багтрекинга, позволяющей учитывать и контролировать ошибки, найденные в программе, а также следить за процессом их устранения. Главный компонент такой системы база данных, содержащая сведения об обнаруженных ошибках. Одна строка БД = одна ошибка = одна хромосома генетической популяции. Использование этой БД создает идеальные условия для применения разрабатываемой модели. Если же БД пуста (реализация проекта еще не началась), возможно использование БД предыдущего проекта, в котором работали те же сотрудники.

Основная идея предлагаемого генетического подхода Итак, три принципиально новых идеи, предлагаемые в подходе: Разделение исходной задачи на фиксированную и динамическую составляющие. Интерпретация множества дефектов как хромосомной популяции. Использование имеющейся в багтрекере (системе контроля дефектов) информации для уточнения оценки полученной с помощью какого-либо метода оценки трудозатрат на ранних стадиях жизненного цикла. Кроме того, данный подход позволяет провести все необходимые расчеты любому менеджеру, даже не являющемуся экспертом в области предсказания сроков, т.к. база данных может быть проанализирована автоматически. Стоимость конечной реализации предлагаемого подхода во много раз меньше имеющихся систем.

Формальное описание генетического метода Необходимо определить с приемлемой точностью функцию времени до релиза проекта R(t), зависящую от текущего момента времени t, отсчитываемого от начала работы над проектом. Причем R(0) = R0 – общее первоначальное плановое время работы над проектом. Искомую функцию предлагается искать в виде R(t) = Rplan(t) + Rbugs(B(t)), где Rplan(t) – идеальное плановое время до релиза (фиксированная составляющая), рассчитанное на текущий момент времени t, без учета возможных дефектов на всех этапах разработки. Rplan(t) в общем случае нелинейно зависит от t, рассчитывается с помощью какой-либо упрощенной модели оценки трудозатрат (любой (!), например COCOMO II [1]). Rbugs(B(t)) – время, необходимое для устранения имеющихся дефектов и для достижения необходимого показателя качества ПО (динамическая составляющая). B(t) – имеющаяся на момент времени t база данных дефектов. Т.е. по сути, смысл подхода в разделении исходной задачи на четкую и нечеткую составляющие. Первая часть работы посвящена исследованию применимости имеющихся методов расчета планового времени в идеальном случае, т.к. для этого разработано большое количество методик, основанных на различных метриках разрабатываемого ПО.

Формальное описание генетического метода Вторая часть – непосредственно рассмотрение генетического подхода применительно к расчету Rbugs(B(t)). Как уже отмечалось ранее, генетический подход предполагает рассмотрение базы данных ошибок в качестве хромосомной популяции. Одной ошибке ставится в соответствие одна хромосома. На множестве хромосом популяции задается оценочная функция Durability(ω), которая рассчитывается динамически на основании макроскопических характеристик популяции. В данной интерпретации оценочная функция характеризует время жизни хромосомы-дефекта на основании ее характеристик (например: дата и время, когда была обнаружена проблема, серьёзность (критичность) проблемы и приоритет её решения, какие-либо характеристики сложности ее решения и т. п.). К популяции применяются генетические операторы скрещивания C(), мутации M() и отбора S(), использующие оценочную функцию, эмулируя эволюцию популяции (процесс возникновения новых дефектов и устранения старых) через некоторые фиксированные (в простейшем случае) промежутки времени. Алгоритм использует макропоказатели базы данных B(t) (N(t) – количество ошибок, N'(t) – скорость их появления и др.) таким образом, чтобы правильно рассчитать параметры генетических операторов, обеспечив правильную скорость сходимости размера популяции к 0. Как только || < ε, считаем, что система достигла заданного качества и процесс можно дальше не продолжать. Гипотетическое время этого процесса эволюции популяции и есть Rbugs(B(t)). Общая схема работы метода приведена на рис. 1.

Рис 1. Общая схема работы динамической части генетического алгоритма. Ω Условие завершения |Ω| < ε База данных багтрекера Ω C,M,S С,M,S Операторы: С – скрещивание M – мутация S - отбор Время эволюции = время работы над проектом

Области применения Подход можно применять в любом программном проекте, использующем систему контроля ошибок (багтрекер), на современном этапе это означает, что применять его можно практически везде (за исключением, возможно, лишь проектов реализуемых 1-2 разработчиками). На сегодняшний день, рассмотрена применимость только к программным проектам, но в перспективе, описанные идеи можно будет применить и в любых других разработках, использующих системы протоколирования возникающих дефектов. Кроме того, предполагается возможность использования идей метода для калибровки существующих моделей оценки трудозатрат и сроков.

Полученные результаты На основании описанных идей был разработан прототип системы уточнения оценок трудозатрат основанных на модели COCOMO II. На основании баз данных баг-трекеров трех opensource-проектов (Firefox, Fedora, KDE) были произведены оценки, которые в среднем оказались на 4% точнее чем оценки произведенные с помощью COCOMO II, без уточнения с помощью описанного метода. В дальнейшем планируется дополнить разрабатываемую систему упрощенными версиями существующих методов, что позволит использовать её как полноценный самостоятельный программный пакет.

Литература: 1. B. Boehm. ``Software Cost Estimation with Cocomo II''. 2. W. Royce. ``Software project management: a unified framework'' 3. B.Boehm. ``Software engineering economics'' 4. N. Fenton. S. Pfleeger. ``Software Metrics: A Rigorous and Practical Approach''. 5. G. Parkinson. ``Parkinson's Law and Other Studies in Administration, Houghton-Miffin'' 6. J. Aron. ``Estimating Resource for Large Programming Systems, NATO Science Committee'' 7. M. Halstead. ``Elements of software science'' 8. J. Albrecht, J. E. Gaffney. ``Software function, source lines of codes, and development effort prediction: a software science validation'', IEEE Trans Software Eng. SE-9, 1983, pp C. Jones. `Applied Software Measurement, Assuring Productivity and Quality''. 10. D. St-Pierre, M Maya, A. Abran, J. Desharnais and P. Bourque. ``Full Function Points: Counting Practice Manual'', Technical Report , University of Quebec at Montreal, L. Putnam. ``A general empirical solution to the macro software sizing and estimating problem'', IEEE Trans. Soft. Eng., July 1978, pp C. Walston, C. Felix. ``A method of programming measurement and estimation'', IBM Systems Journal, vol. 16, no. 1, 1977, pp P. Hamer, G. Frewin. ``M.H. Halsteads Software Science – a critical examinatio'', Proceedings of the 6th International Conference on Software Engineering, Sept , 1982, pp V. Shen, S. Conte, H. Dunsmore. ``Software Science revisited: a critical analysis of the theory and its empirical support'', IEEE Transactions on Software Engineering, 9, 2, 1983, pp Вячеслав Колдовский. ``Разработка ПО: оценка результата, сен г. 16. M. Shepperd, C. Schofield. Estimating software project effort using analogy, IEEE Trans. Soft. Eng. SE-23:12, 1997, pp

Спасибо за внимание!