Моделирование оценки длительности разработки программного обеспечения

МОДЕЛИРОВАНИЕ ОЦЕНКИ ДЛИТЕЛЬНОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Швакин В.Ю., Куликова Л.Л., Иркутск (ИрГТУ)
Программное обеспечение относится к одному из наиболее дорогостоящих видов имущества предприятий и фирм. В связи с этим актуальны вопросы планирования проектной деятельности на самых ранних стадиях, при решении вопроса о целесообразности разработки программного продукта, его стоимости, длительности разработки, будущей эффективности. Для принятия решений необходим детальные сведения о проекте, но они становятся доступными только после прохождения стадии технического задания и технического проекта, поэтому методы оценки на начальной стадии наименее разработаны. На основе анализа имеющегося программного обеспечения и требований к оценке разработана методика оценки на разных стадиях жизненного цикла ПО. Создана программная система, позволяющая определять длительность процесса разработки на стадии формирование концепции с возможностью адаптации к специфическим характеристикам проектов и расширения функциональности. Данный программный продукт может использоваться при определение ценовых характеристик программного обеспечения, для эффективного принятия решений при инвестировании проектов по разработке ПО, в учебном процессе.

Программное обеспечение относится к одному из наиболее дорогостоящих видов имущества предприятий и фирм. По оценкам экспертов среднегодовой темп роста объемов программного обеспечения в совокупных затратах на информационные технологии на предприятиях до последнего времени составлял 20,4 % в год [1]. Текущий момент характеризуется значительной корректировкой планов внедрения программного обеспечения и сокращения бюджетов на ИТ–проекты. Разработка и внедрение ИТ–проектов не отменяется, но пересматривается структура портфеля проектов. Ужесточаются критерии выбора проектов, все большее внимание уделяется вопросам эффективности внедряемых проектов, методам планирования и контроля за проектной деятельностью.

В связи с этим как никогда актуальными становятся вопросы планирования проектной деятельности на самых ранних стадиях. Именно на этих стадиях решается вопрос о целесообразности разработки программного продукта, его стоимости, длительности разработки, будущей эффективности. Для принятия решений по этим важным вопросам требуется знать такие детальные сведения о проекте, которые становятся доступными только после прохождения стадии технического задания и технического проекта. Эта парадоксальная ситуация на протяжении всего периода существования программной индустрии не позволяла говорить о наличии точных методов расчета эффективности программных продуктов и информационных систем в целом. Еще в 60–х годах прошлого столетия Фредерик П. Брукс в своей знаменитой работе "Мифический человеко–месяц" писал, что "программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым"[2]. Спустя 30 лет отмечалось, что "исследования показали, что на каждые 6 крупных систем программного обеспечения, запущенных в действие, приходится 2 таких, разработка которых была прекращена из-за невозможности добиться удовлетворительного функционирования. Средний проект разработки программного обеспечения затягивается на половину первоначально запланированного срока, крупные проекты и того хуже" [3]. В настоящее время, когда кризис обострил обозначенную проблему, разработка моделей оценивания затрат на разработку проектов является особенно своевременной.

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

, где

Z – общие затраты на проект

L(t) – Затраты на оплату труда разработчиков

E(t_m) – Затраты на электроэнергию

A(t) – Амортизационные отчисления

S(t) – Затраты на содержанию и эксплуатацию технических средств

t – Длительность проекта

t_m – Машинное время

N – другие затраты, не зависящие от времени

Для определения длительности разработки в настоящее время применяются различные методы, такие как параметрические модели; подходы, основанные на экспертной оценке; подходы, ориентированные на изучение опыта выполненных проектов; динамические модели; регрессионные модели; смешанные Байесовские подходы. Основным минусом этих методов является то, что они основаны на использовании в качестве основного параметра количества строк кода (или аналогов — функциональных точек, операторов и т.п.). Эти методы не оценивают современные подходы к программированию. Недостаточная точность экспертных методов и методов аналогов может приводить к значительным расхождениям с реальными результатами из-за которых ИТ-проекты завершаются несвоевременно или прекращаются [4,5].

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

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

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

Оценка на стадии формирования концепции позволяет принять решение о целесообразности реализации проекта, требуемых ресурсах. Методы оценки на этой стадии наименее разработаны, поскольку основная проблема оценки заключается в том, что на этом этапе практически отсутствуют какие-либо количественные параметры разрабатываемого проекта. Поскольку применение аналитических формул для оценки не представляется возможным, целесообразно использовать сочетание экспертных оценок и статистических данных. В качестве статистических данных необходимо сохранять информацию о реальной длительности проекта, принадлежности проекта к отрасли, а также признаки, по которым можно объединить несколько выполненных проектов в один класс с планируемым проектом. Для решения этой задачи возможно использование метода распознавания образов, с классификацией проектов с помощью метода поиска ближайшего соседа. Этот метод обладает следующими преимуществами: 1)предназначен для работы как с количественными, так и с качественными данными; 2)в данном случае полностью решает поставленную задачу без усложнения вычислений; 3)автоматически улучшает точность работы при увеличении количества исторических данных; 4)логично вписывается в концепцию работы с базами данных, содержащими статистические данные; 5)находимые решения не уникальны для конкретной ситуации, возможно их использование для других подобных случаев. Основным недостатком данного подходя является повышенная ресурсоемкость при проведении вычислений, но она значительно снижается применением современных системам управлениями данными [6].

Д
ля вычисления степени близости можно использовать обобщенную формулу вида:

где w_j – вес j-го признака, x_ij и y_kj – значения признака x_j для текущего случая(k) и прецедента(i), соответственно.

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

П
ризнаки проектов, используемые при выделении, разделены на следующие группы:

Признаки группы разработчиков: опыт работы в прикладной области, навыки владения языками и инструментарием, знание одних и тех же принципов разработки, общая квалификация программистов, слаженность команды, использование программных инструментов
Признаки заказчика: количество отделов, количество филиалов, число сотрудников, число квалифицированных ИТ–сотрудников, число сотрудников с высшим образованием, характеристика продуктов/услуг, сменяемость персонала, количество сотрудников, непосредственно отвечающих за разрабатываемое ПО.
Признаки проекта: объем обрабатываемых данных, степень требуемой документированности, похожесть на прошлые проекты, сложность продукта, необходимая надежность, требования по быстродействию, аппаратные ограничения, уровень предполагаемого пользователя, количество пользователей, требования к безопасности, поддержка различных платформ
Признаки, характерные для конкретной группы продуктов. На данном этапе разработки выделены признаки для одной из групп ПО – web-приложений. К ним относятся: 1)расположение (внешнее, внутреннее); 2)частота обновлений; 3)интеграция с существующими системами (текущими, планируемыми); 4)количество стандартных модулей; 5)количество нестандартных модулей.

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

Рис. 1. Архитектура системы
анный фреймворк является шаблоном для разработки архитектуры приложения (используя модель MVC). Для выполнения основных действий над объектами, отображаемыми в таблицы базы данных (поиск, просмотр, добавление, изменение, удаление, работа со списками, экспорт и импорт, изменение свойств и методов объектов) предоставляет собственные методы. Имеется поддержка разграничения доступа, средства авторизации, позволяет необходимым образом обрабатывать возникающие ошибки и записывать необходимую информацию в лог-файлы. Фреймворк предоставляет средства для создания интерфейса разрабатываемой системы: темизация внешнего вида, средства для управления меню (главным и индивидуальным для раздела). Для повышения удобства работы пользователя встроена библиотека jQuery, позволяющая создавать интерфейс на основе AJAX технологий.
Основные объекты системы оценивания (Рис. 2):

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

Рис. 2. Основные объекты

Общий алгоритм работы системы на первой стадии может быть представлен как линейная последовательность действий (Рис. 3), и состоит из: подготовки данных для вычислений, подсчета мера близости для заданного типа проектов и временном сохранение результатов, выбора наиболее близких проектов на основе рассчитанной меры близости и формирования требуемых результатов. При реальной работе пользователя с программой этот алгоритм расширяется (Рис. 4): 1)пользователь должен быть зарегистрирован в системе (самостоятельно или администратором); 2)для расчета необходимо ввести информацию о новом проекте и его характеристиках; 3)пользователь может выбирать наиболее подходящую шкалу коэффициентов, позволяющую корректировать расчеты меры близости; 4)результаты расчета и служебные данные сохраняются для анализа точности системы и её корректирования. В процессе работы система обучается за счет увеличения базы прецедентов, и может настраиваться с использованием анализа статистики работы (собираемой автоматически).

Рис. 3. Общий алгоритм

Рис. 4. Алгоритм работы пользователя

мы

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

ЛИТЕРАТУРА

В.Буров, С. Карелов Реальный ИТ–рынок. Аналитическое исследование. М.:ООО РЕАЛ – ИТ, 2007.
Брукс Ф. Мифический человеко - месяц или Как создаются программные системы. СПб.: Символ-Плюс, 2007. - 304 с.
W. Wayt Gibbs. Software’s Chronic Crisis .Scientific American, сентябрь 1994
Макконнелл С. Сколько стоит программный проект. СПб.: Питер, 2007. - 304 стр.
Государственный испытательный сертификационный центр программных средств вычислительной техники [Электронный ресурс]. - Режим доступа: http://www.gicpsvt.ru/, свободный.
Data Mining - Интернет Университет информационных технологий [Электронный ресурс]. - Режим доступа: http://www.intuit.ru/department/database/datamining, требуется регистрация.