CC BY
49
МОДЕЛЬ ОЦЕНКИ ДЛИТЕЛЬНОСТИ ИТЕРАЦИОННОГО ПРОЕКТА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
А.И. Бриткин, асп. каф. Математического обеспечения и администрирования
информационных систем Тел.: (926) 717-1918; E-mail: sashabritkin@gmail.com Московский государственный университет экономики статистики и информатики
http:llwww.mesi.ru
Mathematical model which allows to estimate the duration of software development project and the risk of schedule failure at the early stage is presented.
В статье представлена математическая модель, позволяющая на ранних стадиях проекта епрогнозировать его длительность и оценить риск незавершения проекта в срок.
Ключевые слова: программное обеспечение, управление проектом, управление рисками. Keywords: software, project management, risk management.
Г J_,
A.M. Бриткин,
1. Введение
В современном мировом хозяйстве XXI века конкурентная позиция экономики определяется способностью страны создавать и применять высокие технологии, производить конкурентоспособную наукоемкую
продукцию, в частности, программное обеспечение. Исследования процессов разработки проектов программного обеспечения показали, что во многих случаях стоимость и длительность их реализации значительно превышали предполагаемые, а характеристики качества не соответствовали требуемым, что наносило ущерб заказчикам, пользователям и разработчикам. Эти потери - ущерб проектов, они могли бы быть значительно уменьшены своевременным анализом, прогнозированием и сокращением рисков возможного нарушения требований контрактов, технических заданий и спецификаций на характеристики, выделяемые ресурсы и технологию создания конкретных комплексов программ.
Проблема исследования и сокращения рисков в процессах разработки ПО развивается вследствие возрастания разнообразия и сложности разрабатываемого программного обеспечения. Неспособность правильно управлять рисками может привести к ощутимым потерям вплоть до серьезных юридических санкций. Использование методов управления и оценки рисков позволит повысить качество управления проектами.
Несмотря на значительный прогресс в процессах и методах разработки, оценка и анализ рисков все еще сильно зависят от экспертных знаний. В данной статье представлена математическая модель, позволяющая автоматизировать оценку рисков на ранних стадиях проекта и уменьшить зависимость оценок от человеческих экспертных знаний и опыта.
В отличие от существующих подходов применения риск-менеджмента как отдельной активности, параллельной всему процессу разработки ПО, автор предлагает включить в итеративный процесс разработки ПО использование описанной в этой статье модели, которая позволяет на ранних стадиях проекта спрогнозировать его длительность и оценить риск незавершения проекта в срок.
2. Модель оценки длительности проекта
Для построения модели необходимо выработать набор метрик для таких важнейших факторов проекта, как требования к разрабатываемой системе, персонал проекта и сложность проекта.
Для требований к системе введем следующие метрики: коэффициент включения требований BR (процент новых требований на каждой итерации проекта) и коэффициент исчезновения требований DR (процент убранных требований на каждой итерации проекта). Их сумма будет определять степень волатильности требований к разрабатываемой системе. Стоить отметить, что в цикле разработки ПО наиболее подвержены ошибкам и рискам стадии разработки требований и дизайн-спецификаций. Эта проблема особенно актуальна в проектах с участи-
ем нескольких заинтересованных лиц, имеющих разные точки зрения на проект.
Оценка эффективности персонала - это процесс измерения вклада каждого исполнителя в успех проекта. Одним из методов оценки эффективности персонала является определение значимости (полезности) показателей исполнителя в соответствии с выбранной шкалой оценок личных качеств и профессионального мастерства. Поскольку определение уровня профессионализма, как правило, субъективно, то в качестве оценки предлагается использовать показатели количества людей в проекте и коэффициент их текучести. Коэффициент текучести дает информацию о потерях в производительности из-за дополнительного обучения, дополнительного времени на набор опыта, налаживание связей в коллективе и т. п.
Сложность проекта имеет влияние на его качество. Качество продукта может быть оценено только после завершения проекта, поэтому очень важно измерять сложность разработки как ранний прогностический фактор для того, чтобы оценить продолжительность проекта. Эту оценку должны также уточнить индикаторы, собранные на стадии определения требований. В условиях, когда программный код еще не доступен, оценку целесообразно проводить на основе спецификаций.
Исследования показали, что существует прямая связь между сложностью разрабатываемого ПО и количеством строк программного кода [2, 3]. Введем метрику СРХ, которая выражает сложность системы в виде произведения сценариев использования системы иС на количество классов (в смысле объектно-ориентированного программирования), на которое была декомпозирована система С:
срх = ис • С.
В качестве оценки сложности ПО можно также использовать метод функциональных точек [4, 5, 6], при котором путем подсчета количества вводов, выводов, запросов, баз данных, а также системных интерфейсов программного обеспечения определяется его мера сложности и объема.
Автором были проанализированы данные нескольких проектов различной степени направленности (среди них телекоммуникации, Интернет, мобильные технологии, клиент-серверное ПО) и была обнаружена высокая степень корреляции между количеством строк в программном обеспечении, на-
писанном на языках Java и PHP, и коэффициентом CPX (см. рис.).
Рис. Корреляция между размером программного кода и параметром СРХ
Время, необходимое для выполнения проекта, предлагается рассчитывать как случайную величину, имеющую трехпарамет-рическое распределение Вейбулла. Плотность и функция распределения Вейбулла представлены следующим образом: 0, при х < у
f (x; а, ß, у) =
F (x; а, ß, у) =
ßa (x -y) a-1 exp
- (T")
при x > y,
0, при x < y
1 - exp
-( ß )
при x > y,
где х - изучаемая случайная величина, в нашем случае это время, необходимое для выполнения проекта;
а - параметр формы распределения, определяющий ширину пика графика плотности;
в - параметр масштаба распределения, растягивающий или сжимающий график плотности по оси х ;
у - параметр положения распределения, сдвигающий график плотности вправо.
Распределение Вейбулла было выбрано на основе проведенной аналитической работы как наиболее подходящее для области разработки ПО. С помощью собранной выборки экспериментальных данных автор проверил эту статистическую гипотезу с помощью критерия А.Н. Колмогорова, где в качестве меры расхождения между теоретической ¥(х) и эмпирической ¥п (х) функциями распределения непрерывной случайной величины используется модуль максимальной разности
dn = max|F(x) - Fn (x)|.
В соответствии с критерием Колмогорова, какова бы ни была функция распределения ¥(х) при неограниченном увеличе-
a
сом» проекта, с одной стороны, и трудоемкостью разработки системы, с другой стороны.
Базовый тип модели СОСОМО учитывает только класс проекта - естественный, полуинтегрированный, «встроенных систем». Естественные проекты - относительно маленькие, разрабатываются командами, знакомыми с прикладной областью. Полуинтегрированные проекты - системы среднего размера и сложности, разрабатываются группами разработчиков с различным опытом. Проекты «встроенных систем» выполняются при значительных аппаратных, программных и организационных ограничениях.
С помощью конструктивной модели стоимости сложность проекта можно выразить как
Y = 2,94 х
32 х cpx + 500 1000
П ш>,
нии количества наблюдений n функция распределения случайной величины dn
асимптотически приближается к функции распределения
да
K(Л) = P(4ndn < Л) = £(-1)k exp(-2k2Л2).
k=-да
Рассмотрим параметры распределения.
Параметр а распределения Вейбулла, определяющий ширину пика, можно ассоциировать с эффективностью персонала проекта. Рассмотрим эффективность персонала через процент текучести T и количество участников проекта P : P
а = —.
T
Параметр в распределения Вейбулла, растягивающий или сжимающий график плотности распределения, моделирует дополнительную работу, инициированную новыми требованиями или изменениями в старых требованиях. Положим параметр в равным степени волатильности требований к системе:
р = BR + DR,
где BR - процент новых требований к продукту; DR - процент исчезнувших требований к продукту.
Параметр у распределения Вейбулла, сдвигающий график плотности распределения вправо, моделирует сложность системы, известную на этапе оценки, и поэтому может быть выражен через метрику CPX.
Одной из наиболее известных моделей для определения объемов работ при разработке информационных систем является конструктивная модель стоимости
(Constructive Cost Model - COCOMO), разработанная в конце 70-х годов Б. Боэмом [7]. Построенная на основе анализа ряда проектов, выполненных, в основном, в интересах Министерства Обороны США, она устанавливает соответствие между размером системы в тысячах условных строк кода и «клас-
Литература
1. Luqi L., Ketabchi M. A Computer-Aided Prototyping System // IEEE Software. - 1988. - Vol. 5. - P. 66-72.
2. Albrecht A. Measuring Application Development Productivity // Proceedings of the Joint SHARE, GUIDE, and IBM Application Development Symposium, Monterey, California, October 14-17, IBM Corporation. - 1979. - P. 83-92.
3. Albrecht A., Gaffney J. Software Function Source Lines of Code and Development Effort Prediction // IEEE Transactions Software Engineering. - 1983. - SE-9. - P. 639- 648.
4. Jones C. Feature Points (Function Point Logic for Real Time and System Software) // Proceedings of the IFPUG Fall 1988. Conference, 1988.
5. Bundschuh M., Dekkers C. Variants of the IFPUG Function Point Counting Method // Springer Berlin Heidelberg - Berlin, 2008. - P. 397-407.
е = 0,91 + 0,01 х^ ,
з=1
где EMi - мультипликаторы модели СОСОМО; БЕз - масштабирующие макрокоэффициенты модели СОСОМО.
3. Заключение
В статье рассмотрена модель оценки длительности проекта разработки программного обеспечения. Она может применяться для оценки рисков срыва сроков проекта. Модель позволяет автоматизировать оценку рисков на ранних стадиях проекта и уменьшить зависимость от человеческих экспертных знаний и опыта.
Автор предлагает усовершенствовать итеративный процесс разработки ПО путем включения в него описанной модели и применять ее в начале каждой итерации при уточнении требований.
6. Стандарт ISO/IEC 20968:2002 Mk II Function Point Analysis - редакция 90.60 - опубл. 18.03.2008.
7. Boehm B.W. Software engineering economics // Prentice-Hall - Englewood Cliffs, NJ, 1981.
РАЗРАБОТКА ИННОВАЦИОННЫХ ОБРАЗОВАТЕЛЬНЫХ ТЕХНОЛОГИЙ НА ОСНОВЕ МОДЕЛИ С ИСПОЛЬЗОВАНИЕМ SCORM-СПЕЦИФИКАЦИЙ
Ю.Ф. Тельнов, д.э.н., проф., проректор по научно-методической работе, зав. каф. Прикладной информатики в экономике; Тел.: (495)442-6098, E-mail: YTelnov@teach.mesi.ru Московский государственный университет экономики, статистики и информатики
http://www.mesi.ru О.В. Рогозин, доц., к.т.н. каф. Программного обеспечения ЭВМ и информационных технологий Тел.:(495) 442-8098; E-mail: orogozin@mail.ru Московский государственный технический университет им. Н.Э. Баумана
This article is devoted to the development of knowledge presentation model in an e-learning system based on the SCORM technology. The Sharable Content Object Reference Model (SCORM) defines a Web-based learning «Content Aggregation Model (CAM)» and «Run-Time Environment» (RTE) for learning objects. The Model is applied in the form of Web application.
Статья посвящена разработке модели представления знаний для инновационных образовательных технологий на основе соответствующей международным стандартам спецификации SCORM. SCORM - технология включает использование модели агрегации контента (CAM) и среду для выполнения обучающих объектов. Разработанная модель реализована в виде веб- приложения.
Ключевые слова: инновация, SCORM, CAM, веб-приложение.
Keywords: Innovation, SCORM, CAM, Web Application.
Введение
Инновационные образовательные технологии включают комплексный подход к учебному процессу, в котором целью обучения является развитие возможностей учащихся осваивать новый опыт на основе целенаправленного формирования творческого и критического мышления, использования инструментария учебно-исследовательской деятельности, ролевого и имитационного моделирования.
В настоящее время обучение через веб является интенсивной областью исследова-
ний и разработок. Польза от использования веб для обучения основана на возможности размещения обучаемых на любых удаленных расстояниях, при этом процесс обучения сохраняет множество отличительных черт, свойственных обучению «вживую». Приложение, установленное и поддерживаемое в одном месте, может использоваться обучаемыми, имеющими компьютер с любым видом подключения к Интернету. Множество курсов и других обучающих приложений стали доступны в веб за последние годы.
