Software & Systems

Проекты по созданию крупных программных средств (ПС) традиционно начинаются с анализа и разработки технико-экономического обоснования затрат, связанных с их созданием и развитием. Заказчику необходимо оценить объем требующихся ресурсов, а потенциальному разработчику – возможность реализации проекта в условиях и ресурсах, предлагаемых заказчиком.

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

Большей части этих негативных последствий можно избежать, используя современные методы управления проектами для их успешного завершения. При этом важное значение имеет технология формирования точных оценок затрат ресурсов, необходимых для создания и развития ПС.

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

Современные методы оценки трудозатрат на создание и развитие ПС можно разделить на следующие классы:

-     методы структурированной экспертной оценки;

-     методы оценки по математическим моделям, построенным на основе обработки статистических данных.

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

Масштабные исследования в области математического моделирования расходов, связанных с разработкой и эксплуатацией ПС, начались в США в 1965 году. Эти разработки легли в основу нескольких примитивных моделей, созданных в конце 60–начале 70-х годов двадцатого столетия. Потом появились более сложные модели: SLIM [2], метод контрольных точек (Checkpoint) [3], PRICE-S [4], SEER [5] и COCOMO [6]. Разработчики этих моделей оценки затрат столкнулись с одной и той же проблемой: по мере развития технологий разработки ПС происходил значительный рост размеров этого средства и увеличивалась его сложность, что существенно затрудняло точную оценку расходов на разработку [7]. Для построения математических моделей оценки в основном используется регрессионный анализ. Данную группу методов характеризует достаточно высокая точность получаемых оценок. Однако для калибровки моделей требует- ся большая база статистических данных по уже завершенным проектам. Кроме того, не всегда заранее известен вид зависимости входа и выхода модели.

В настоящее время наиболее распространенными методами оценки на основе математических моделей являются методы конструктивной модели стоимости (COCOMO, COCOMO II) [6] и функционально-балльной оценки (FPA) [8].

Опыт использования упомянутых выше математических моделей оценки позволяет выделить основные факторы, влияющие на затраты, связанные с созданием и развитием ПС. Для ПС одного класса наибольшее влияние на трудоемкость разработки оказывает его размер. Данный параметр может изменяться в большом диапазоне: на три-четыре порядка от 104 до 107 строк исходного кода программ [6, 8, 9]. Именно размер ПС определяет основной объем работ по проекту. Поэтому при оценке затрат на разработку ПС размер программы используется в качестве базового доминирующего параметра. Так как точность оценок размера ПС определяет точность оценок прочих стоимостных параметров проекта, методам его оценивания уделяется большое внимание. В качестве единицы измерения размера ПС обычно используется строка исходного кода (SLOC – source line of code). Данная единица измерения требует точного описания понятия «строка кода» [9]. Другая проблема использования единиц измерения размера ПС, основанных на коде, заключается в том, что на ранних стадиях жизненного цикла ПС информация об исходном коде недоступна.

Применяемые подходы для оценки размера создаваемого ПС в методах COCOMO II и FPA имеют ряд недостатков, затрудняющих их применение.

·      Для использования метода функциональных баллов необходимы высококвалифицированные сертифицированные специалисты. При несоблюдении данного условия точность оценок резко снижается.

·      Метод функциональных баллов требует значительного времени на сбор данных о создаваемом ПС. При этом состав собираемых данных подразумевает детальное понимание требований к ПС.

·      Метод функциональных баллов ориентирован в большей степени на процедурное программирование, так как оперирует многими понятиями, не используемыми при объектно-ориентированном подходе.

·      COCOMO II использует метод оценки размера ПС с сильно ограниченным набором программных объектов. Сложность реализации каждого программного объекта определяется с помощью экспертной оценки.

·      Статистике, используемой при калибровке модели СОСОМО II, уже более 15 лет. Как следствие, в ней плохо учтена специфика создания ПС с использованием технологии объектно-ориентированного программирования (которая сейчас широко применяется при создании ПС).

Для формирования оценки трудозатрат на работы по созданию и развитию ПС предлагается использовать метод, являющийся развитием методов оценки размера создаваемого ПС, применяемых в FPA и COCOMO II. Это позволит частично или полностью устранить указанные недостатки. Для оценки трудозатрат на создание ПС на основе его размера могут быть использованы откалиброванные модели, применяемые в методах COCOMO II и FPA. Основной задачей является повышение точности и обоснованности оценок размера создаваемого ПС, полученных на ранних этапах жизненного цикла.

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

Для построения моделей оценки размера классов программных объектов были использованы методы искусственного интеллекта: нейронные сети и нечеткая логика (нейро-нечеткие, или гибридные модели). Особенностью этих методов является учет в них априорных сведений об объекте или о процессе исследований в форме нечетких продукционных правил «ЕСЛИ–ТО». Параметры правил определяются по имеющимся статистическим дан- ным с помощью алгоритма обратного распространения ошибки, генетических алгоритмов [10] и др.

Основные преимущества использования нейро-нечетких методов моделирования:

-     позволяют строить модель, используя малые выборки данных (по сравнению со статистическими методами);

-     не требуют предварительного определения вида зависимости вводов и выходов модели;

-     дают возможность моделировать сложные процессы и системы (многомерные, нелинейные);

-     позволяют достаточно легко интерпретировать получаемые модели.

При использовании нейро-нечетких методов моделирования размеры экземпляров програм- мных объектов ПС определяются с помощью базы знаний (БЗ), представляющей собой набор правил нечеткого вывода. Основное назначение БЗ – идентификация нелинейной зависимости y = j(X), где X – вектор значений количественных свойств класса программных объектов ПС; y – значение размера кода программного объекта ПС в SLOC.

Построение моделей оценки размера програм- мных объектов ПС осуществляется в два этапа. На первом этапе формируется нечеткая БЗ. Данная БЗ связывает входы и выходы модели с помощью лингвистических правил «ЕСЛИ–ТО». Набор правил создается на основе извлечения знаний из имеющейся статистики. На следующем этапе производится настройка параметров нечеткой БЗ для достижения минимального отклонения модельных результатов от имеющихся статистических данных. Подобная настройка реализуется с помощью нечетких нейронных сетей, способных одновременно формировать нечеткие правила и адаптировать функции принадлежности путем модификации весов связей в процессе обучения.

Особенность применяемых моделей состоит в том, что заключения правил представляются в фор­ме функциональных зависимостей (нейронная продукционная сеть Такаги–Сугено–Канга):

Пi: ЕСЛИ х1 есть Аi1 И … И хj есть Аij И ... И хm есть Аim, ТО i = 1, …, n, где Aij – нечеткое множество, отражающее значение характеристики программного объекта xj, с функцией принадлежности m(xj); xj – количественная характеристика программного объекта ПС, влияющая на размер кода, который необходимо написать для его создания; y – четкая выходная переменная, равная искомому размеру кода программного объекта ПС; n – количество правил; m – количество входных переменных.

При малом объеме обучающих данных возможно использование упрощенной модели, когда заключения правил заданы константами: y=ci, i = 1, 2, …, n.

Полученная БЗ может быть интерпретирована как некоторое разбиение пространства входных характеристик на нечеткие подобласти, в каждой из которых значение выходной переменной рассчитывается как линейная комбинация входов. Переключение с одного линейного закона «входы–выход» на другой осуществляют правила БЗ. Так как границы подобластей входных переменных размыты, одновременно могут выполняться несколько правил, но с разными весами. Итоговое значение выходной переменной y определяется как суперпозиция линейных зависимостей:

В данном выражении для задания функций принадлежности используется функция Гаусса, где a и b – параметры этой функции.

С использованием данного подхода была разработана информационно-аналитическая система оценивания трудозатрат и стоимости создания ПС. Цель такой системы – обеспечение руководителя проекта инструментарием для оперативной оценки трудозатрат на разработку ПС (как всего проекта, так и его отдельных этапов) и автоматизированной подготовки всех необходимых данных для получения этой оценки.

Информационно-аналитическая система оценивания трудозатрат и стоимости создания ПС реализует следующие функции:

-     ведение БД статистики по завершенным проектам разработки ПС;

-     описание структуры проекта в разрезе классов программных объектов ПС;

-     выбор вида модели нечеткого вывода формируемой БЗ;

-     генерация структуры лингвистических переменных, входящих в БЗ, на основе имеющейся статистики по завершенным проектам;

-     генерация базы нечетких решающих правил;

-     решение задачи оптимизации баз нечетких правил;

-     оптимизация параметров баз нечетких решающих правил на основе имеющейся статистики по завершенным проектам;

-     оценка технико-экономических параметров проекта с использованием БЗ;

-     экспорт данных с результатами оценки технико-экономических параметров проекта во внешние приложения (ПО календарного планирования проектов).

Архитектура информационно-аналитической системы оценивания трудозатрат и стоимости создания ПС представлена на рисунке. По своему составу она близка к экспертным системам.

Информационно-аналитическая система оценивания трудозатрат и стоимости создания ПС может работать в одном из четырех режимов:

-     ввод исходных данных для построения моделей оценки размера кода программных объектов ПС;

-     построение математических моделей оценки размера кода программных объектов ПС;

-     настройка (адаптация) параметров полученных моделей;

-     использование сгенерированных моделей оценки размера кода программных объектов ПС для оценивания трудозатрат и стоимости их создания.

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

Разработанная информационно-аналитическая система апробирована в Главном испытательном сертификационном центре безопасности программных средств и вычислительной техники (г. Тверь). Исходные данные для формирования моделей оценки получены исходя из анализа ПС, поступивших на сертификационные испытания. Полученные результаты оценки размера ПС сравнивались с оценками, полученными по методу функциональных баллов. Были проанализированы завершенные проекты с размером ПС от 104 до 106 в строках исходного кода (SLOC). Результаты оценки размера ПС, полученные с использованием нейро-нечетких методов моделирования, отличаются от фактических на 5–10 %. Данные, полученные с использованием метода функциональных баллов, отличаются от фактических на 10–23 %. Оценка размера создаваемого ПС вышеперечисленными методами производилась на этапе проектирования интерфейса пользователя, после чего результат сравнивался с фактическим размером ПС после завершения его разработки.

На данный момент результаты исследования были апробированы и успешно внедрены в Банке России и Федеральной таможенной службе.

Литература

1.     Липаев В.В. Технико-экономическое обоснование проектов сложных программных средств. М.: СИНТЕГ, 2004. 284 с.

2.     Jensen Dr. Randall W., Putnam Lawrence H. Sr., Roetzheim William. Software estimating models: three viewpoints. Software Technology Support Center, 2006, pp. 23–29.

3.     Jones C., Bonsignour O. The economics of software quality. Addison-Wesley, 2012, pp. 105–109.

4.        Shermon D. System cost engineering. Gower Publ., 2009, 326 p.

5.        Fischman Lee, McRitchie Karen, Galorath Daniel D. Inside SEER-SEM, CROSSTALK The Jour. of Defense Soft. Eng., 2005, pp. 26–28.

6.     Boehm B., Abts C., Brown A.W., Chulani S., Clark B.K., Horowitz E., Madachy R., Reifer D.J., Steece B. Software Cost Estimation with COCOMO II. Englewood Cliffs, NJ, Prentice-Hall, 2000, 544 p.

7.     Котов С.Л. Нормирование жизненного цикла программной продукции. М.: ЮНИТИ, 2002. 143 с.

8.     Garmus D., Herron D. Functional point analysis. Addison-Wesley, 2000, 400 p.

9.     McConnell S. Software estimation: demystifying the black art. Microsoft Press, 2006, 308 p.

10.   Борисов В.В. Нечеткие модели и сети. М.: Горячая линия–Телеком, 2007. 284 p.