CC BY
356
№ 5(29) 2010
С. П. Кульдин
Генетический подход к проблеме оценки сроков и трудоемкости разработки программного обеспечения с заданными требованиями к качеству1
Основной проблемой современных методов оценки трудозатрат является сложность их адаптации к каждому конкретному проекту. В статье предложен принципиально новый, неклассический генетический подход к этой проблеме, главные принципы которого — обеспечение
простоты применимости метода на практике
Точный расчет ресурсов, необходимых для реализации данного программного продукта с заданными требованиями к качеству, является одной из основных проблем в области управления проектами. Однако при таком расчете возникают сложности учета огромного количества факторов, влияющих на жизненный цикл ПО. Выяснить скрытые закономерности и связи между этими параметрами, а также произвести аналитический расчет в подавляющем большинстве случаев не представляется возможным. В любом программном проекте приходится балансировать между стоимостью, временем, качеством и объемом реализуемой функциональности. Как следствие, на сегодняшний день многие компании сталкиваются с серьезными проблемами в случае неправильных расчетов необходимых сроков:
• при недооценке — непредвиденная трата дополнительных средств, недовольство заказчика невыполнением обязательств в срок, «бессонные ночи» сотрудников, сложность управления «обвальным» про-
1 Статья подготовлена по материалам доклада на пленарном заседании IV международной научнопрактической конференции «Современные информационные технологии и 1Т-образование», прошедшей в МГУ им. М. В. Ломоносова 14-16 декабря 2009 г. (прим. ред.).
учет специфической информации.
ектом, низкое качество конечного продукта, слаборазвитые функции системы и т. д;
• при переоценке — бесполезный расход ресурсов, привлеченных к проекту, отказ заказчика от контракта с данными условиями (в результате возможна потеря рабочих мест) и т.д.
На современном рынке крупных программных систем потери могут исчисляться миллионами долларов.
Точные оценки издержек производства программного обеспечения важны как разработчикам, так и заказчику (клиенту). Они могут использоваться при переговорах о контракте, планировании, контроле и т. п. Таким образом, возникает реальная потребность в разработке методов и средств, позволяющих менеджеру оценить требуемые временные и человеческие ресурсы на основе всех имеющихся характеристик проекта: истории предыдущих подобных проектов, опыта и производительности сотрудников, специфики компании и т. п. Кроме того, требуется возможность перерасчета и уточнения сроков и ресурсов уже на этапе разработки системы с учетом текущих тенденций, наблюдаемых при реализации проекта. Это поможет менеджеру своевременно обнаружить отклонения от установленного графика и принять соответствующие меры в управлении проектом.
№ 5(29) 2010
Краткий обзор основных понятий и проблем рассматриваемой области
Непосредственные усилия производителей (их трудозатраты) обеспечивают большую часть стоимости разработки ПО, и, как правило, методы оценки необходимых средств (как следствие, и времени) сосредотачиваются именно на этом аспекте и дают оценки в человеко-месяцах, которые впоследствии могут быть преобразованы в продолжительность проекта или стоимость.
На практике часто сталкиваются с тремя проблемами, имеющими принципиальное значение:
1) какуюмодельоценкивыбрать?
2) какую метрику размера ПО использовать (число строк кода (LOC — Lines Of Code), «функциональные точки» (FP — Function Points) или «точки свойств» (feature points))?
3) что можно считать хорошей оценкой?
Выбор модели оценки
Широко применяемый на практике метод оценки трудозатрат — экспертная оценка. Однако такой подход сопряжен со множеством проблем:
— основания для получения оценки не являются явными;
— тяжело находить высококвалифицированных экспертов для каждого нового проекта;
— связь между размером системы и трудозатратами нелинейна. Трудозатраты возрастают экспоненциально с увеличением объема. Поэтому экспертная оценка получается адекватной только в случае, если текущий и предыдущие проекты примерно одинакового масштаба;
— политика руководства, направленная на сокращение затрат, как правило, ставит под сомнение реальный опыт предыдущих проектов и вносит долю «слепого оптимизма».
За три последних десятилетия было разработано множество различных моделей количественной оценки трудозатрат.
Они варьируются от моделей, основанных на эмпирических данных(например, модель «СОСОМО» Б. Боема [1]) до чисто аналитических. Эмпирические модели используют данные предыдущих проектов, чтобы оценить текущий (анализируя закономерности, прослеживаемые в предыдущих проектах). С другой стороны, аналитические модели базируются на глобальных предположениях относительно связи различных параметров, таких как скорость устранения разработчиком дефектов и их количество в определенный момент времени. Каждая модель имеет свои достоинства и недостатки, но ключевым фактором при ее рассмотрении, конечно же, является точность.
Выбор метрики размера
Большинство моделей (как эмпирических, так и аналитических) базируются на использовании различных метрик размера разрабатываемой системы (LOC, FP и др.). Точность оценки трудозатрат напрямую зависит от точности оценки размера. Независимо от выбранной метрики размера определить его заранее точно не представляется возможным, поэтому приходится его уточнять (и соответственно производить общую переоценку трудозатрат) уже непосредственно в процессе разработки. Влияние этого фактора заметно уменьшается при использовании достаточно строгой методологии разработки и детальной проработке требований к системе. В силу особой важности данного вопроса для решения исходной задачи более подробно он будет рассмотрен в разделе «Сравнение метрик размера ПО».
Критерии хорошей оценки
По Ройсу [2], хорошая оценка издержек производства программного обеспечения должна быть:
— понятной и поддержанной менеджером проекта и командой разработчиков;
— одобреной всеми заинтересованными лицами как реально осуществимая;
С. П. Кульдин
Генетический подходкпроблеме оценки сроков и трудоемкости разработки программного обеспечения с заданными требованиямиккачеству
№ 5(29) 2010
— базирующейся на четкой модели с заслуживающими доверия основаниями, а также на данных подобного проекта (с подобными бизнес-процессами, технологиями, внешней средой, людьми и требованиями);
— определена настолько детально, что ключевые области риска понятны, и вероятность успеха объективно оценена.
Оценка трудоемкости и стоимости была одной из наиболее сложных проблем при разработке программного обеспечения. Тому есть несколько причин:
— нехватка исторически сложившейся базы данных оценок трудоемкости;
— разработка ПО основана на множестве взаимосвязанных факторов, непосредственно влияющих на продуктивность, отношения которых полностью не выявлены;
— нехватка оценщиков с опытом.
Сравнение метрик размера ПО
Размер программного обеспечения — наиболее важный фактор, определяющий трудоемкость реализации ПО. Далее автор опишет пять метрик размера программного обеспечения, используемых на практике. Число строк исходного кода и функциональные точки — самые популярные метрики из пяти рассмотренных.
Число строк кода
LOC (Lines Of Code) — число непустых строк исходного текста, исключая комментарии [4]. Несмотря на то что эта метрика существенно зависит от выбранного языка программирования, она до сих пор остается самой используемой метрикой размера ПО. Точное число LOC может быть получено только после того, как проект уже закончен. Поэтому оценка размера кода программы до его создания не намного проще оценки реальных трудозатрат, например, в человеко-месяцах.
Типичный метод осуществления такой оценки использует комбинацию экспертных
оценок с техникой под названием PERT [6], заключающейся в следующем: пусть имеется п экспертов, каждый /'-й эксперт высказывает три предположения относительно конечного размера: L, — нижняя оценка размера; Н1 — верхняя оценка размера; М1 — наиболее вероятный размер. Тогда размер S можно вычислить как
Точность оценки может быть существенно улучшена, если применить PERT не к проекту в целом, а к его отдельным компонентам. В этом случае общую оценку размера можно получить как сумму «локальных» оценок.
Метрики Холстеда
М. Холстедом были предложены такие метрики, как длина кода и объем [7]. Длина кода определяется как
N = N, + N2, (2)
где N1 — общее количество появлений операторов в программе; N2 — общее количество их операндов. Объем кода соответствует объему памяти, требуемой для хранения программы, и вычисляется по формуле:
V = N log(n1 + п2), (3)
где п1 — число различных операторов; п2 — число различных операндов, появляющихся в программе.
Очевидно, что оценить общее число операторов и их операндов до завершения проекта, как правило, еще более затруднительно, чем оценить LOC, поэтому в адрес предложенных Холстедом метрик было высказано множество замечаний [14, 15]. Поддержка такого подхода в последние годы постоянно уменьшается.
№ 5(29) 2010
Функциональные точки (Function points)
Наиболее удачной заменой количеству строк кода для измерения размера стали функциональные точки (function points), впервые предложенные сотрудником IBM А. Альбрехтом в 1979 г. [8]. Применение функциональных точек основано на оценке объема реализуемой функциональности за счет изучения требований, вследствие чего оценка необходимых трудозатрат может быть выполнена на самых ранних стадиях работы над проектом и далее будет уточняться по ходу жизненного цикла, а явная связь между требованиями к создаваемой системе и получаемой оценкой позволяет заказчику понять, за что именно он платит, и во что выльется изменение первоначального задания.
Автор кратко рассмотрит основные принципы данного метода. Общее число функциональных точек программы зависит от количества элементарных процессов пяти типов (рис. 1):
1) входящие транзакции (External inputs (El)) — получают данные от пользователя;
2) исходящие транзакции (External outputs (ЕО)) — передают данные пользователю;
3) взаимодействия с пользователем (External inquiries (EQ)) — интерактивные диалоги с пользователем (требующие от него каких-либо действий);
4) файлы внутренней логики (Internal logical files (ILF)) — файлы (логические группы информации), использующиеся во внутренних взаимодействиях системы;
5) файлы внешних взаимодействий (External interface filese (EIF)) — участвуют во внешних взаимодействиях с другими системами.
В данной терминологии транзакция — элементарный неделимый замкнутый процесс, имеющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое.
Каждому из пяти типов назначают один из трех уровней сложности (1 = простой, 2 = средний, 3 = сложный), а каждой паре (тип, уровень сложности) ставят в соответствие вес, представляющий собой количество невыровненных функциональных точек (UFP), который изменяется от 3 (для простой входящей транзакции) до 15 (для сложных внутренних файлов). Общая оценка размера в UFP рассчитывается как
(4)
/=1 ;=1
где Nj¡v\Wj¡ — соответственно число и вес элементов системы класса / со сложностью/.
Например, если в системе 2 простых входа (INa = 3), 2 сложных выхода (I= 7) и 1 сложный внутренний файл {Wfj = 15), тогда UFP = 2-3 + 2-7 +1-15 = 35.
Это число функциональных точек может непосредственно использоваться для оценки стоимости/трудоемкости и уточняться с помощью фактора выравнивания (VAF), который вычисляется на основании харак-
Перемещение данных (data in motion) — простые транзакции
■С
External
input (El) J
External outputs (EO) J
External inquiries (EQ) j
Хранение данных (data at rest)
Internal logical files (ILF)
<j
External interface files
îles (EIF)')
Рис. 1. Типы элементарных процессов, используемых в методе FP
33
С. П. Кульдин
Генетический подходкпроблеме оценки сроков и трудоемкости разработки программного обеспечения с заданными требованиямиккачеству
№ 5(29) 2010
теристик общей сложности проекта, таких как: степень распределенности обработки и хранения данных, требования к производительности системы, требования к безопасности и т.д. При этом окончательная оценка размера в выровненных функциональных точках рассчитывается как
AFP = (UFP + CFP) • VAF, (5)
где CFP — дополнительные функциональные точки, которые потребуются, например, для установки или миграции данных. Общая схема процедуры оценки представлена на рис. 2.
Число UFP и число строк кода (LOC) связаны линейно:
LOC = а ■ UFP + b. (6)
Параметры а и b могут быть получены с помощью линейной регрессии на основании имеющихся данных о завершенных проектах.
Точки свойств (Feature points)
В условиях, когда сформулированные требования не отражают истинной сложности реализации (что особенно характерно для системного ПО, критически важных программных комплексов и пр.), метод функциональных точек себя не оправдывает. В этом случае на помощь приходит его мо-
дифицированный вариант, предложенный в 1988 г. К. Джонсом [9], который учитывает не только требования к системе, но и внутренние особенности ее реализации — метод точек свойств (feature points). Он очень близок к методу функциональных точек, с тем лишь отличием, что предусматривает корректирование получаемой оценки с учетом алгоритмической сложности. К перечисленным ранее пяти элементарным классам функциональных объектов добавляется класс алгоритмов. Определяется алгоритм как свод правил, который решает какую-либо существенную вычислительную задачу. Например, вычисление квадратного корня можно рассмотреть как алгоритм. Каждому используемому алгоритму сопоставляют вес в пределах от 1 (элементарный) до 10 (очень сложные алгоритмы), и количество точек свойств рассчитывается как взвешенная сумма алгоритмов плюс число функциональных точек. Эта метрика особенно полезна для систем с незначительным вводом/выводом, но с высокой алгоритмической сложностью, таких как математическое программное обеспечение, системы дискретного моделирования, военные приложения и т. п.
Объектные точки (Object points)
Поскольку классическая интерпретация метода функциональных точек не предусматривает применения объектно-ориентированного подхода, в современных проектах ис-
Выровненные FP (AFP)
Рис. 2. Процедура оценки функционального размера по методу FP
№ 5(29) 2010
пользуется его адаптированный вариант, оперирующий терминами ОО-технологии. Принципиальным его отличием от других методов, производных от классического FP, является то, что он не расширяет базовый набор элементарных классов FP, а вводит совершенно иные: окна (screens), отчеты (reports) и 301_-компоненты. Каждому из этих объектов назначается вес в пределах от 1 (простое окно) до 10 (301_-компоненты), и количество объектных точек рассчитывается по формуле, аналогичной (4). Это относительно новая метрика и пока не настолько популярная, как FP. Но в силу своего удобства в применении на самых ранних этапах жизненного цикла ОО-проектов (причем с неплохими показателями), она успешно используется в некоторых разновидностях СОСОМО [1].
Обзор и классификация методов оценки трудозатрат
В самом общем смысле все методы оценки проектов разделяют на две группы:
1. Методы микрооценки — основаны на точном знании всех составляющих жизненного цикла. Например, Oracle AIM (Oracle Application Implementation Method — методика внедрения готовых приложений, разработанная компанией Oracle для пакета Oracle E-Business Suite, включающая оценку трудоемкости). В этом методе для получения результата необходимы построение структуры разбиения работ и оценка каждой индивидуальной работы.
2. Методы макрооценки — основаны на функциональных требованиях и/или других определениях конечного продукта. Таковы, например, методы функциональных точек и СОСОМО.
С другой стороны, все методы оценки можно разделить и на алгоритмические, неалгоритмические. Далее приведен общий обзор неалгоритмических методов, указаны их недостатки, что делает резонным выбор именно алгоритмических методов, к числу которых и относится описываемый в данной работе генетический подход.
Неалгоритмические методы
Оценка по аналогии
Этот метод требует наличия одного или нескольких законченных проектов, которые подобны новому проекту. Оценку получают путем сравнения текущего проекта с предыдущими с использованием реальных наблюдавшихся в них показателей. Оценка по аналогии может быть сделана или на уровне проекта в целом, или отдельных подсистем. Преимуществом оценки по аналогии всего проекта является учет возможных составляющих факторов (например, накладных расходов на организацию должного взаимодействия всех компонентов). Оценка же по отдельным компонентам позволяет обеспечить более детальный учет общих черт и различий между новым проектом и законченными проектами. Достоинство этого метода — оценка основана на фактических проектных результатах.
Не всегда корректно переносить результаты предыдущих проектов на текущий, так как нельзя с уверенностью сказать, что ограничения и условия предыдущего проекта можно перенести и использовать в новом проекте. Более детальное рассмотрение данного метода представлено в [16].
Экспертная оценка
Для получения оценки с помощью этого метода учитываются мнения нескольких экспертов, которые полагаются на собственные методы и опыт. Для достижения коллективного согласия применяются такие механизмы, кактехника Delphi или PERT.
Техника Delphi заключается в следующем:
— координатор выдает каждому эксперту спецификацию и форму для выставления оценок;
— каждый эксперт заполняет форму строго индивидуально, однако, разрешено задавать вопросы координатору;
— координатор подготавливает свод всех экспертных оценок (включающий так-
С. П. Кульдин
Генетический подходкпроблеме оценки сроков и трудоемкости разработки программного обеспечения с заданными требованиямиккачеству
№ 5(29) 2010
же их средние значения и пояснения) на другой форме, которая раздается каждому эксперту для проведения следующей итерации;
— шаги 2-3 повторяются до достижения необходимой степени единообразия оценок.
Модификация техники Ое1рЫ, предложенная Б. Боемом [3], показала себя как более эффективная: предварительно производится совещание координатора и экспертов, на котором рассматриваются проблемы оценки. На шаге 3 эксперты не дают никакого объяснения своих оценок. Вместо этого после каждой итерации координатор проводит собрание. На нем обсуждаются детали оценки, по которым были выявлены наибольшие разногласия.
Принцип Паркинсона
В соответствии с этим принципом «работа расширяется, заполняя весь доступный объем» [5]: трудозатраты определяются не за счет объективной оценки, основанной на функциональности конечного продукта, а доступными ресурсами. Например, если конечный продукт должен быть передан заказчику через 12 месяцев и в проекте задействовано 5 человек, то оценка трудозатрат составит 60 человеко-месяцев. Иногда такой подход бывает успешным, однако, его применение чаще связано с целым рядом негативных последствий, начиная от работы сотрудников в сверхурочное время и заканчивая расторжением контракта со стороны заказчика в случае невыполнения обязательств из-за слишком нереалистичных сроков. Кроме всего прочего, принцип Па-рикнсона, как правило, приводит к созданию очень некачественного конечного продукта.
Цена победы
При данном подходе оценка трудозатрат производится таким образом, чтобы она оказалась самой выгодной для заказчика,
и контракт был бы гарантированно заключен. То есть оценка основывается на бюджете заказчика, а не на конечной функциональности ПО. Например, если разумная оценка для проекта составляет 100 человеко-месяцев, но заказчик может оплатить только 60 человеко-месяцев, то оценщика просят изменить оценку до 60 человеко-месяцев, чтобы выиграть проект. Это также плохой подход, который, однако, часто встречается на практике вследствие политических игр руководства, и с очень высокой степенью вероятности он вызовет задержку поставки или вынудит команду работать в сверхурочное время.
Алгоритмические методы
В алгоритмических моделях математический аппарат весьма разнообразен и варьируется от простых линейный формул, использующих математическое ожидание и среднеквадратичное отклонение, до сложных регрессионных моделей [12] и дифференциальных уравнений [11]. Как правило, чтобы улучшить точность алгоритмических моделей, требуется приспособить их (например, с помощью пересчета основных параметров и коэффициентов) к конкретным обстоятельствам. Причем даже после такой калибровки точность зачастую оставляет желать лучшего. Поэтому можно считать, что у каждой конкретной модели есть своя конкретная область применения, в которой она может дать адекватный конечный результат.
Все алгоритмические методы основаны на математических моделях, определяющих трудозатраты как функцию, зависящую от множества переменных, соответствующих основным влияющим на трудозатраты факторам, и имеют общий вид:
Е = Д х, хп), (7)
где Е — суммарный объем трудозатрат (например, в человеко-часах); х(, /' = 1,...,п — учитывающиеся факторы.
№ 5(29) 2010
Соответственно многообразие алгоритмических методов обусловливается, главным образом, двумя аспектами: выбором факторов и формой функции f. В зависимости от этого среди алгоритмических моделей могут быть выделены три основные группы:
1) линейные модели (Е = а0 + ^п а(х();
2) мультипликативные модели:
№ = а„ П
3) степенныемодели( Е = а■ Sb).
В первых двух группах коэффициенты аь...,ап выбираются на основании данных предыдущих проектов; в третьей группе: S — размер проекта (основной фактор);
а, b — функции (как правило, очень простые) других факторов трудозатрат.
Линейные модели не оправдали себя на практике и не раз подвергались объективной критике [5]. В частности, зависимость от большого числа факторов, влияющих на разработку ПО, имеет явно нелинейный характер, что приводит к неэффективности данного класса моделей. Мультипликативные модели (например, модель Валсто-на — Феликса [12]) сложны в калибровке (расчете и уточнении коэффициентов) и не нашли широкого практического применения. В силу указанных причин автор не будет рассматривать методы данных классов, а кратко опишет один из наиболее популярных и эффективных степенных алгоритмических методов.
СОСОМО
СОСОМО (Constructive COst MOdel) и ее производные являются, пожалуй, самыми популярными алгоритмическими моделями для оценки трудоемкости разработки ПО, которые де-факто стали стандартом. Эти модели относятся к классу степенных. Базовая модель была представлена в 1981 г. Б. Боемом [1]. С момента своего появления СОСОМО постепенно эволюционировала.
Основные тапы ее развития можно обозначить следующим образом.
1. Базовая модель СОСОМО. Размер проекта S измеряется в LOC (KLOC), а трудозатраты — в человеко-месяцах. Создана на основе анализа статистических данных 63 проектов (главным образом, Министерства обороны США) различных типов. Используются три набора параметров {а, to} в зависимости от сложности разрабатываемого программного обеспечения:
a) для простых, легко понимаемых проектов, а = 2,4, b = 1,05;
b) для сложных систем, а = 3,0, b = = 1,15;
c) для встроенных систем, а = 3,6, b = 1,20.
Модель была проста в применении, но не обеспечивала должной точности.
2. Детализированная модель СОСОМО. Уточнены наборы параметров {a, to}, кроме того, общая формула приняла вид: Е = М • а • Sb, где М — уточняющий коэффициент, рассчитывающийся как произведение 15 поправочных факторов из 4-х категорий (факторы конечного продукта, вычислительной среды, персонала, проекта), варьирующихся в диапазоне от 0,7 до 1,66, которые могут быть найдены в специальной таблице. Эти изменения базовой модели позволили существенно улучшить точность оценки, особенно в случае применения метода к отдельным компонентам, а не к системе в целом.
3. СОСОМО II. (1997 г.). Имеет много общего со своей предшественницей, однако, во многом основана на новых идеях, а также адаптирована к современным методологиям разработки ПО (в частности, если СОСОМО подразумевала только каскадную модель жизненного цикла, то СОСОМО II пригодна для спиральной и итеративной моделей). При построении СОСОМО II для обработки статистических данных использовался байесовский анализ, который дает лучшие ре-
С. П. Кульдин
Генетический подходкпроблеме оценки сроков и трудоемкости разработки программного обеспечения с заданными требованиямиккачеству
№ 5(29) 2010
зультаты для программных проектов, характеризующихся неполнотой и неоднозначностью, в отличие от многофакторного регрессионного, примененного в СОСОМО. Также в ней допускается измерять размер проекта не только числом строк кода (LOC), но и более современными функциональными и объектными точками. Помимо прочего, при расчете показателей СОСОМО II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI СММ/ CMMI [15].
Общее плановое время разработки в модели СОСОМО рассчитывается по формуле:
ЯРЙП = с • Ер, (8)
где с — коэффициент сжатия нормального графика; р — функция, зависящая от факторов масштаба системы. Детальное описание модели СОСОМО II можно найти в [1].
Основная идея генетического подхода
Главной проблемой современных методов оценки трудозатрат является сложность их адаптации к конкретному проекту (калибровки коэффициетов модели). Каждый проект — это своя команда, свои условия труда, специфика разработки. Обобщенные модели, такие как СОСОМО, разработанные с учетом данных о большом количестве проектов, не могут полностью учесть этой специфики.
В настоящей статье автор предлагает принципиально новый, некпассический генетический подход к проблеме, основными принципами которого являются обеспечение простоты применимости метода на практике и учет информации, специфической для каждого конкретного проекта. В его основе лежит идея разделения общей задачи (предсказания необходимых ресурсов) на фиксированную и динамическую составляющие. При решении фиксированной части можно абстрагироваться от многих факторов, определяющих проектную специфику, и использовать какой-ли-
бо современный метод оценки трудозатрат так, словно он применяется к какому-нибудь типичному «среднестатистическому» проекту (например, СОСОМО). Это позволяет не учитывать множество дополнительных факторов и существенно упрощает реализацию метода. Главная же инновационная и не имеющая аналогов составляющая предлагаемого подхода заключается в способе решения динамической части задачи. Динамическая часть — оценка ресурсов, необходимых для устранения дефектов и других проблем, возникающих в процессе разработки системы, не укладывающихся в имеющиеся модели. Было замечено, что эти дефекты живут и развиваются подобно биологической популяции, подверженной определенным воздействиям окружающей среды — множества сотрудников со своими показателями производительности. Эта среда и порождает такие дефекты, стремится их устранить впоследствии.
Дефекты претерпевают мутации (проявляют заранее непредвиденные свойства), скрещиваются между собой, порождая новые, подвергаются отбору в соответствии со сложностью их устранения и т. п. Проведенные параллели с классическими понятиями теории эволюции биологических систем позволяют создать очень точную модель эволюции проекта в целом и рассчитывать необходимое дополнительное время, эмулируя жизнь этой популяции. Более того, ни один современный программный проект не обходится без системы багтрекинга, позволяющей учитывать и контролировать ошибки, найденные в программе, а также следить за процессом их устранения. Главный компонент такой системы — база данных, содержащая сведения об обнаруженных ошибках. Одна строка БД = одна ошибка = одна хромосома генетической популяции. Использование этой БД создает идеальные условия для применения разрабатываемой модели. Если же БД пуста (реализация проекта еще не началась), возможно обращение к БД предыдущего проекта, в котором работали те же сотрудники.
Итак, выявлены три принципиально новые идеи, предлагаемые в подходе:
1) разделение исходной задачи на фиксированную и динамическую составляющие;
2) интерпретация множества дефектов как хромосомной популяции;
3) использование имеющейся в багтре-кере (системе контроля дефектов) информации для уточнения оценки, полученной с помощью какого-либо метода на ранних стадиях жизненного цикла.
Кроме того, этот подход позволяет провести все необходимые расчеты любому менеджеру, даже не являющемуся экспертом в области предсказания сроков, так как база данных может быть проанализирована автоматически.
На рисунке 3 изображена общая схема применения предлагаемого подхода: менеджер в свое распоряжение получает набор временных характеристик, соответствующих трудозатратам по каждому отдельному компоненту разрабатываемой системы, и составляет на их основе календарный план.
Следует отметить, что использование в модели нечеткой генетической популяции позволяет с минимальными трудоза-
тратами осуществить настройку параметров модели под каждую конкретную среду и условия, в которых происходит разработка системы. Это достигается за счет того, что, имитируя внешние условия достаточно простым заданием параметров разнообразных генетических операторов (т. е. явно задавая окружающую среду), не нужно что-либо рассчитывать аналитически. Тем самым обеспечивается применимость подхода к достаточно широкому классу проектов без привлечения специалистов, владеющих методами математического прогнозирования, что и является его ключевым преимуществом перед всеми другими алгоритмическими методами.
Стоимость конечной реализации предлагаемого подхода во много раз меньше имеющихся систем.
Формальное описание метода
Необходимо определить с приемлемой точностью функцию времени до релиза проекта Я(Г), зависящую от текущего момента времени Г, отсчитываемого от начала работы над проектом. Причем Я(0) = Я0 — общее первоначальное плановое время ра-
генетического алгоритма
С. П. Кульдин
Генетический подходкпроблеме оценки сроков и трудоемкости разработки программного обеспечения с заданными требованиямиккачеству
боты над проектом. Функцию предлагается искать в виде fî(t) = fîplan (f) + fîbugs (В (Г)), где Яр|ап(t) — идеальное плановое время до релиза (фиксированная составляющая), рассчитанное на текущий момент времени t, без учета возможных дефектов на всех этапах разработки. В общем случае нелинейно зависит от t, определяется с помощью какой-либо упрощенной модели оценки трудозатрат (любой), например, СОСОМО II [1]); fîbugs (S(t)) — время, необходимое для устранения дефектов и достижения искомого показателя качества ПО (динамическая составляющая); В(t) — имеющаяся на момент времени t база данных дефектов.
По сути, смысл подхода заключается в разделении исходной задачи на «четкую» и «нечеткую» составляющие.
Вычисление четкой составляющей представляет собой достаточно простую задачу расчета планового времени в идеальном случае, для решения которой существует большое количество методик, основанных на различных метриках разрабатываемого ПО.
Непосредственно сам генетический подход применяется для расчета fîbugs (В (Г)). Как уже отмечалось ранее, он предполагает рассмотрение базы данных ошибок в качестве хромосомной популяции. Одной ошибке ставится в соответствие одна хромосо-
ма. На множестве хромосом популяции Q задается оценочная функция Durability (ю), которая рассчитывается динамически на основании макроскопических характеристик популяции. В данной интерпретации оценочная функция характеризует время жизни «хромосомы-дефекта» по ее характеристикам (например: дата и время, когда была обнаружена проблема, ее серьезность (критичность) и приоритет решения, какие-либо характеристики сложности решения и т.п.). К популяции применяются генетические операторы скрещивания С{Q), мутации М(Q) и отбора S(Q), использующие оценочную функцию, эмулируя эволюцию популяции (процесс возникновения новых дефектов и устранения старых) через некоторые фиксированные (в простейшем случае) промежутки времени. Алгоритм использует макропоказатели базы данных S(t) (N(t) — количество ошибок; N'(t) — скорость их появления и др.) таким образом, чтобы верно рассчитать параметры генетических операторов, обеспечив правильную скорость сходимости размера популяции к 0. Как только IQI < е, считаем, что система достигла заданного качества и процесс дальше можно не продолжать. Гипотетическое время этого процесса эволюции популяции и есть Rbugs(В{Г)). Общая схема работы метода представлена на рис. 4.
Операторы:
С — скрещивание М — мутация
Условие завершения ЮІ < є
Рис. 4. Общая схема работы динамической части генетического алгоритма
40
№ 5(29) 2010
Условия применимости
Несмотря на достаточную универсальность метода, он все же требует определенных условий, при которых его применение оправдывается в полной мере.
1. Наличие багтрекера, включающего обязательные поля:
a. Время сообщения об ошибке.
b. Время установления статуса «принято к исполнению».
c. Время установления статуса «исправлено».
с1. Промежуточная версия компонента.
е. Сотрудник, ответственный за исправление.
2. Наличие в распоряжении какого-либо средства для вычисления фиксированной составляющей (например, пакета на основе СОСОМО II).
3. Базы данных ошибок от предыдущих проектов (чем больше, тем лучше), в которых участвовали те же разработчики, что и в текущем проекте — для расчета сроков на самых начальных его этапах. В случае отсутствия таких баз данных для этого коллектива можно воспользоваться базами данных другого коллектива, работавшего над проектами, подобными текущему, но эффективность метода заметно ухудшается.
4. Практика регрессионных методов тестирования на протяжении всего жизненного цикла проекта.
Последнее требование не является обязательным, однако, модель по своему построению такова, что идеальным условием
для ее применимости было бы обнаружение ошибок сразу после их совершения. На практике это не представляется возможным и приходится мириться с тем, что тестирование, как правило, имеет неравномерный характер. Неравномерность обнаружения ошибок может быть сглажена путем настройки оператора мутации.
В целом за счет того, что данный подход можно применять в любом программном проекте, использующем систему контроля ошибок (багтрекер), на современном этапе это означает, что он применим практически везде (за исключением, возможно, лишь проектов, реализуемых 1-2 разработчиками, где багтрекер не задействуется). На сегодняшний день рассмотрена применимость только к программным проектам, но в перспективе описанные идеи могут быть актуальны и в любых других разработках, использующих системы протоколирования возникающих дефектов. Кроме того, предполагается возможность применения идей метода для калибровки существующих моделей оценки трудозатрат и сроков.
Полученные результаты
Описанные идеи позволили разработать прототип системы уточнения оценок трудозатрат, основанных на модели СОСОМО II. По базам данных багтрекеров трех opensource-проектов (Firefox, Fedora, KDE) произведены оценки, которые в среднем оказались на 4% точнее, чем оценки, полученные с помощью СОСОМО II, без уточнения посредством рассмотренного метода (табл. 1). В дальней-
Таблица 1
Увеличение точности оценки для некоторых opensource-npoeKTQB
Проект Имитируемая дата осуществления предсказания Фактическая дата релиза СОСОМО II СОСОМО II + Genetic Увеличение точности, %
Firefox 3.5 15.04.2009 30.06.2009 24.06.2009 26.06.2009 2,7
Fedora 9 10.03.2008 11.05.2008 3.05.2008 14.05.2008 8,1
KDE 4.1 4.06.2008 29.07.2009 28.07.2009 29.07.2009 1,3
С. П. Кульдин
Генетический подходкпроблеме оценки сроков и трудоемкости разработки программного обеспечения с заданными требованиямиккачеству
№ 5(29) 2010
шем планируется дополнить разрабатываемую систему упрощенными версиями существующих методов, что сделает возможным ее использование как полноценного самостоятельного программного пакета.
Перспективы развития предложенных идей
На сегодняшний день существует достаточное количество развитых средств анализа репозиториев проекта (например, SolidSTA), однако, они не осуществляют никаких предсказаний касательно реальных сроков, как правило, приспособлены только для использования менеджерами или аналитиками и, по сути, обеспечивают лишь сбор статистики и визуализацию, не производя подробного анализа, так как при этом возникают сложности учета огромного количества факторов, колеблющихся от проекта к проекту.
Целью дальнейших исследований и разработок является создание расширения для IDE, которое должно удовлетворять следующим требованиям:
— предоставить возможность контроля производительности и каждого отдельного разработчика, и всей команды в целом;
— на основании анализа проектных репозиториев сигнализировать об отклонениях от запланированного графика и в режиме one-click производить перерасчет сроков сдачи проекта (и/или отдельного разрабатываемого модуля/сборки) в эксплуатацию на текущий момент;
— обладать достаточной степенью универсальности (не должно ориентироваться на какую-либо конкретную модель разработки, язык программирования и т. п.);
— должно быть рассчитано не только на менеджеров проекта, но и на рядовых разработчиков, а также всех, кто заинтересован в получении представления о текущих темпах разработки и укпадки в запланированный график (для самоконтроля, проведения различных форм аналитики и др.);
— предоставить возможность наглядной визуализации результатов анализа.
Список литературы
1. Boehm В. Software Cost Estimation with Cocomo II. NewJersey, Prentice-Hall, 1981.
2. Royce W. Software project management: a unified framework. Reading, Addison-Wesley Professional, 1998.
3. Boehm B. Software engineering economics. New Jersey, Prentice-Hall, 1981.
4. Fenton N. Software Metrics: A Rigorous and Practical Approach, London, Chapman and Hall, 1991.
5. Parkinson G. Parkinson’s Law and Other Studies in Administration NY, Houghton-Miffin, 1962.
6. Aron J. Estimating Resource for Large Programming Systems Rome, NATO Science Committee, 1969.
7. Halstead M. Elements of software science, NY, Elsevier, 1977.
8. Albrecht J., Gaffney J. E. Software function, source lines of codes, and development effort prediction: a software science validation, IEEE Trans Software Eng. SE-9, 1983. P. 639-648.
9. Jones C. Applied Software Measurement, Assuring Productivityand Quality, NY, McGraw-Hill, 1977.
10. St-PierreD., Maya М., Abran A.} Deshamais J. and Bourque P. Full Function Points: Counting Practice Manual, Technical Report 1997-04, University of Quebec at Montreal, 1997.
11. Putnam L. A general empirical solution to the macro software sizing and estimating problem, IEEE Trans. Soft. Eng., July 1978. P. 345-361.
12. Walston C., Felix C. A method of programming measurement and estimation, IBM Systems Journal, vol. 16, no. 1, 1977. P. 54-73.
13. Hamer P., Frewin G. М. H. Halstead’s Software Science — a critical examinatio, Proceedings of the 6th International Conference on Software Engineering, Sept. 13-16, 1982. P. 197-206.
14. Shen V., Conte S., Dunsmore H. Software Science revisited: a critical analysis of the theory and its empirical support, IEEE Transactions on Software Engineering, 9, 2, 1983. P. 155-165.
15. Колдовский В. Разработка ПО: оценка результата. http://itc.ua.
16. Shepperd М., Schofield С. stimating software project effort using analogy, IEEE Trans. Soft. Eng. SE-23:12, 1997. P. 736-743.
