Оценка сложности разработки программных средств на основе использования нейро-нечетких методов - Статья

Массовое создание сложных ПС промышленными методами и большими коллективами специалистов требует четкой организации процесса разработки ПС на основе планирования работ по проекту с оценкой необходимых ресурсов и времени для их реализации. Согласно стандарту ГОСТ Р ИСО/МЭК 12207-99 «Информационные технологии - Процессы жизненного цикла программ» начальным этапом процесса «Разработка» является этап анализа, цель которого - выявление, классификация и формализация информации обо всех аспектах предметной области, влияющих на свойства конечного продукта, и именно этот этап оказывает определяющее влияние на качество результатов всего проекта. На сегодняшний момент времени решение задач оценки технико-экономических параметров проектов разработки ПС производится, в основном, с помощью экспертных методов. Применение существующих методов оценки ПС на практике оказывается весьма трудоемким и доступно только сертифицированным специалистам, кроме того, они не учитывают использование современных технологий разработки ПС. Для каждого класса разрабатывается отдельная модель для оценки его сложности в зависимости от значений характеристик (свойств) программных объектов.

Возрастающая сложность объектов автоматизации и увеличение их количества, а также переход к комплексным интегрированным решениям, приводят к увеличению сложности и количества проектов по созданию программных средств (ПС). Массовое создание сложных ПС промышленными методами и большими коллективами специалистов требует четкой организации процесса разработки ПС на основе планирования работ по проекту с оценкой необходимых ресурсов и времени для их реализации. Точность и оперативность подобных оценок напрямую влияет на качество разрабатываемых ПС и риск неуспешного завершения проекта.

Согласно стандарту ГОСТ Р ИСО/МЭК 12207-99 «Информационные технологии - Процессы жизненного цикла программ» начальным этапом процесса «Разработка» является этап анализа, цель которого - выявление, классификация и формализация информации обо всех аспектах предметной области, влияющих на свойства конечного продукта, и именно этот этап оказывает определяющее влияние на качество результатов всего проекта. На данном этапе разработчику создаваемого ПС необходимо провести оценку реализуемости проекта в условиях и ресурсах, предлагаемых заказчиком. Именно на этом этапе сторонами, участвующими в разработке ПС, принимаются договорные обязательства. Следствием недостатков или отсутствия технико-экономического обоснования проектов разработки ПС является неверная оценка преимуществ новой программной разработки, недооценка роли других конкурирующих предложений, неизбежный перерасход средств и снижение качества ПС.

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

Как показывают исследования Б. Боэма и Л. Путнэма [Boehm, 2000] [Putnam et al., 2003], характер проектируемой системы и сложность ее программного обеспечения, являются самыми значительными факторами, от которых зависят затраты ресурсов на разработку ПС. Сложность ПС в рамках данной работы понимается как характеристика (или их набор) ПС определяющая, прежде всего, трудоемкость его разработки. В современных методах практически не представлены формализованные процедуры для прогнозирования сложности разрабатываемого ПС, адаптируемые к условиям конкретного проекта. Применение существующих методов оценки ПС на практике оказывается весьма трудоемким и доступно только сертифицированным специалистам, кроме того, они не учитывают использование современных технологий разработки ПС.

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

1. Метод моделирования программных систем для оценки их сложности разработки

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

На ранних этапах процесса разработки ПС в качестве характеристики определяющей сложность создаваемого программного продукта обычно используется его размер. Использование размера ПС как единственной характеристики сложности, в рамках одного класса программ, является приемлемым допущением для решения задач оценки технико-экономических параметров проекта разработки ПС на ранних этапах жизненного цикла [Липаев, 2004]. Размер ПС в современной практике, среди всех факторов, влияющих на параметры проекта, изменяется в самом широком диапазоне на три - четыре порядка от 104 до 107 строк текста программ. Поэтому методам его оценивания уделяется большое внимание.

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

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

Шаг 2. Подсчет экземпляров программных объектов, которые должны быть реализованы при создании ПС.

Шаг 3. Определение значений характеристик программных объектов, используемых в выбранной модели оценки их размера.

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

Шаг 5. Получение итоговой оценки размера ПС, путем аккумулирования значений частных оценок.

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

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

Основная особенность рассматриваемых моделей заключается в том, что заключения правил представляются не в виде принадлежности выходной переменной к нечетким множествам, а в форме функциональных зависимостей (нейронная продукционная сеть Такаги-Сугено-Канга) [Борисов и др., 2007]: Пі: ЕСЛИ х1 есть Аі1 И … И xj есть Aij И... И хм есть Аім, ТО , где Aij - нечеткое множество, отражающее значение характеристики программного объекта xj, с функцией принадлежности m(xj); xj - количественная характеристика объекта ПС, определяющая его сложность; y - четкая выходная переменная равная искомому размеру объекта ПС, определяемая четкой функцией от значений характеристик объекта ПС; n - количество правил; m - количество входных переменных.

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

Использование разработанного метода позволит добиться следующих преимуществ: · метод позволяет использовать имеющуюся статистическую информацию по завершенным проектам разработки ПС как количественной, так и качественной природы, отображая ее в терминах естественного языка - в форме нечетких продукционных правил ЕСЛИ - ТО. Это позволяет учесть массу факторов связанных с технологическим процессом разработки ПС в конкретной проектной организации;

· предлагаемый метод не предполагает наличия каких-либо сведений о виде функциональных зависимостей входов и выходов модели;

· получаемые с помощью разработанного метода модели допускают достаточно понятную интерпретацию.

2. Результаты применения предлагаемого подхода к оценке сложности ПС

С использованием предложенного метода были разработаны модели оценки размера объектов ПС этапа проектирования интерфейса пользователя для класса систем обработки данных. На данном этапе количество типов объектов, которые можно использовать при подсчете размера ПС, увеличивается, что позволяет построить более точные модели для оценки сложности разрабатываемого ПС. В качестве элементов ПС на данном этапе выделялись следующие классы объектов: экранные формы, диалоги, отчеты, файлы данных (таблицы РСУБД), функции импорта/экспорта данных. Для измерения размера в моделях использовались метрики LOC (line of code) - строки кода и функциональные баллы (functional point). Данные для построения моделей были получены исходя из анализа ПС, поступивших на сертификационные испытания в ОАО «ГИЦ ПС ВТ» (Государственный испытательный центр программных средств и вычислительной техники).

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

Были проведены оценки ряда реальных проектов среднего и крупного масштаба с размером ПС от 104 до 106 в строках исходного кода. Все оценки проводились на этапе проектирования интерфейса пользователя ПС. В результате оценки было получено, что оценочные данные о размере проекта, рассчитанные с использованием созданных моделей отличаются от фактических на 3-5% для крупных проектов и 5-10% для средних. Данные цифры говорят о достаточно высокой степени точности оценок, полученных на начальных этапах разработки [MCCONNELL, 2004]. Рост точности оценки для крупных проектов объясняется увеличением количества программных объектов, из которых оно состоит. Это приводит к уменьшению влияния отдельных больших смещений в оценке на общий результат. Следовательно, нецелесообразно применять предложенный метод оценки размера ПС для очень малых проектов (менее 5000 строк кода).

Результаты работы были использованы в НИОКР «Разработка методического и инструментального обеспечения поддержки планирования материальных и временных затрат на разработку программного обеспечения АИС органов государственной власти, создаваемого в рамках работ по реализации мероприятий федеральной целевой программы «Электронная Россия (2002-2010 годы)». Указанная НИОКР зарегистрирована в едином реестре результатов научно-технической деятельности Роснауки номер 13293.6904003214.07.1.001.2.

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

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

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

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

3. Boehm B.W. Software cost estimation with COCOMO II. Prentice Hall PTR. New Jersey. 2000.

4. MCCONNELL S. Professional Software Development. Boston, MA: Addison-Wesley. 2004.

5. Putnam L. H. Five Core Metrics. New York, NY: Dorset House. 2003.

Размещено на .ru