Система поддержки принятия решений для эффективного управления командой разработчиков программного обеспечения

 

Лаптев Валерий Викторович,

кандидат технических наук, доцент,

Морозов Александр Васильевич,

соискатель, начальник отдела АСУ.

Астраханский государственный технический университет.

 

Отрасль программной индустрии, связанная с разработкой программного обеспечения, на сегодняшний момент испытывает большие проблемы. По данным компании Standish Group International [3] около 47% всех разрабатываемых программных проектов не укладываются в отведенные сроки или бюджет, а 22% вовсе отменяются из-за не рентабельности дальнейшей разработки. Кроме того, согласно данным той же компании, чем дороже разрабатываемый проект, тем меньше вероятность его успешного завершения.

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

Серьезные исследования зарубежных авторов, проводимые с начала 70-х годов 20-го века, свидетельствуют о том, что большинство проблем программного проекта (суммарно до 80% всех временных и финансовых потерь) возникает из-за ошибок в менеджменте и лишь 20% — по причинам технического характера [2]. Ошибки менеджмента, в свою очередь, возникают в основном из-за не правильной оценки трудозатрат во время планирования проекта и трудностей с отслеживанием качественных характеристик при его реализации. Такими навыками оценки большинство менеджеров в достаточной степени не владеют. Либо менеджер просто не является профессиональным разработчиком программного обеспечения, либо вышел из этой среды достаточно давно и не может давать адекватные к современной ситуации оценки. Кроме того, огромное разнообразие средств и платформ разработки приводит к тому, что менеджер тратит много сил и времени на подгонку процесса под новую инфраструктуру разработки, допуская при этом большое количество ошибок.

Стандартным выходом при решении подобного рода проблем является привлечение внешних консультантов для анализа качества и трудозатрат по выполнению проектов. Обычно независимые консультанты или консалтинговые компании проводят комплексное исследование одного из модулей системы и на основе полученных данных дают рекомендации по дальнейшему ведению проекта. Главным недостатком такого подхода является его дороговизна – консалтинговые услуги могут стоить до 30-40% от стоимости разработки. Поэтому к таким услугам прибегают обычно уже при наличии достаточно серьезных проблем в проекте.

Ситуацию могла бы исправить система поддержки принятия решений при разработке программного обеспечения. Функции такой системы представлены в виде диаграммы вариантов использования в нотации UML 2.0 (рис.1). При разработке такой системы необходимо формализовать и решить следующие научно-исследовательские задачи:

1.                  Выбор модели качества проекта.

2.                  Оценка качества проекта и составляющих его артефактов.

3.                  Определение схемы выдачи рекомендаций по рефакторингу артефактов программного проекта.

4.                  Оценка качества работы участников команды разработчиков.

5.                  Определение схемы выдачи рекомендаций по управлению командой.

В рамках данной статьи рассматриваются задачи, связанные с управлением командой разработчиков.

 

Рис. 1. Диаграмма вариантов использования для системы поддержки принятия решений при разработке программного обеспечения.

 

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

1.                  Сложность реализации (complexity, CPLX(X)) – отражает объем затрат материальных и человеческих ресурсов, необходимых для первоначальной реализации проектной модели.

2.                  Сложность модернизации (volatily, VLTL(X)) – отражает объем затрат материальных и человеческих ресурсов, которые потребуются в случае развития функциональности программного продукта.

3.                  Сложность сопровождения (maintenance, MNTN(X)) – отражает объем затрат материальных и человеческих ресурсов, необходимых для поддержания в рабочем состоянии программного продукта без изменения его функциональности.

4.                  Подверженность ошибкам (weakness, WCK(M)) – отражает количество ошибок, которые могут быть допущены разработчиками при реализации программного продукта, основывающегося на анализируемой проектной модели.

5.                  Возможность повторного использования (recycling, RCCL(M)) – отражает степень готовности проектной модели к повторному использованию в случае реализации другого программного продукта в той же предметной области.

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

Поскольку ни одна из предлагаемых к рассмотрению характеристик не может быть оценена формальными методами непосредственно из проектной модели, предлагается автоматизированный подход к их оценке на основе метрик проектной модели. Метрики проектной модели – это некоторые статистические показатели, рассчитывающиеся непосредственно на основе знаний о ее структуре. На сегодняшний день разработано достаточное количество наборов метрик для программных проектов и по многим из них уже собрана достаточная историческая и аналитическая информация для различных типов проектов. Примерами широко используемых наборов метрик являются QMOOD (Quality Model for Object-Oriented Design), MOOSE (Metrics for Object-Oriented Software Engineering), MOOD (Metrics for Object-Oriented Design) и MOOD 2 [4].

Задачу определения характеристик на основе вычисленных метрик проектной модели предметной области можно свести к задаче классификации, которая, однако, имеет следующие особенности:

1.                  Объект классификации представлен вектором четких величин – значений метрик проектной модели программного обеспечения.

2.                  Результат решения задачи – лингвистическая величина – значение характеристики.

3.                  Не определены однозначные зависимости между значениями метрик проектной модели и ее характеристиками.

4.                  Существует ограниченное количество доступных в открытом виде данных о метриках проектов и оценках их успешности.

Для решения поставленной задачи предлагается применить подход, основанный на концепции нечетких нейронных продукционных сетей. В качестве основной выбрана структура сети, предложенная Вангом и Менделем (L.-X. Wang J.M. Mendel) [1].

Нечеткая продукционная сеть  Ванга-Менделя реализует нечеткую продукционную модель, основанную на правилах с MISO – структурой:

Если x₁ есть A_i1 И… И x_j  есть A_ij И… И x_m  есть A_im ТО y есть B_i, i=1,…,n

Структура применяемой нечеткой нейронной сети представлена четырьмя слоями:

Слой 1 выполняет фаззификацию входных переменных x_j ( j=1,…n). Элементы этого слоя вычисляют значения функций принадлежности μA_ij(x’_j), заданных гауссовыми функциями принадлежности с параметрами a_ij и  b_ij.

В слое 2, число элементов которого равно количеству правил в базе, осуществляется агрегирование степеней истинности предпосылок соответствующих правил.

В слое 3 первый служит для активизации заключений правил ci в соответствии со значениями агрегированных на предыдущем слое степеней истинности предпосылок правил. Второй элемент слоя проводит вспомогательные вычисления для последующей дефаззификации результата.

Слой 4, состоящий из одного элемента, выполняет дефаззификацию выходной переменной.

Параметрическими слоями сети являются первый и третий слои, а настраиваемыми параметрами служат соответственно параметры термов посылок и заключений a_ij, b_ij и  c_i.

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

,

где c_i, d_i – соответственно центры и ширина гауссовых функций, представляющих функции принадлежности нечетких множеств B_i заключений правил; a_ij, b_ij – соответственно центры и ширина гауссовых функций, представляющих функции принадлежности нечетких множеств A_ij предпосылок правил.

Обучение нейронной сети осуществляется методом обратного распространения ошибки путем корректировки параметров 1-го и 3-го слоев.

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

1.                  Сохранять и накапливать версии артефактов проекта, а также обеспечивать оперативный доступ к ним всех участников проекта.

2.                  Сохранять информацию об авторе конкретной версии.

Системы контроля версий используются сейчас повсеместно и встраиваются в большинство современных средств разработки. Среди них следует назвать такие системы как Subversion, CVS, Visual SourceSafe, Microsoft Team Server.

Для каждой сохраненной версии артефактов проекта можно вычислить вектор дефаззифицированных значений качественных показателей:

Y_K = { y’_Ki } = { WM_K( {M_j(X_i)} ) } ,

где X_i – артефакты проекта с номером версии i;

{M_j(X_i)} – вектор метрических показателей для версии проекта с номером i;

WM_K – оператор применения вычислений нейронной сети Ванга-Менделя для характеристики K.

Тогда для каждого участника команды разработки можно вычислить вектор факторов его влияния на проект:

,

где m – идентификатор автора;

i – номер версии, автором изменений к которым является автор m;

I_mk – фактор влияния автора m на характеристику k.

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

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

Если I_m1 между [A_i1, B_i1] И… И I_mk между [A_ik, B_ik]

ТО выдать рекомендацию R_i, i=1,…,n

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

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

 

Литература.

 

1.                  Борисов В.В., Круглов В.В., Федулов А.С. Нечеткие модели и сети. — М.: Горячая линия –Телеком, 2007.

2.                  Фатрелл Р. T., Шафер Д.Ф., Шафер Л.И. Управление программными проектами. Достижение оптимального качества при минимуме затрат. — М.: Вильямс, 2004.

3.                  Сайт компании «The Standish group international». – Режим доступа: http://www.standishgroup.com/.

4.                  http://www.ndepend.com/Metrics.aspx.

 

Поступила в редакцию 14.08.2008 г.