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

На правах рукописи

Полицын Сергей Александрович

МАТЕМАТИЧЕСКАЯ МОДЕЛЬ И СИСТЕМА ПЛАНИРОВАНИЯ ПРОЕКТОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Специальность 05.13.18 — Математическое моделирование, численные методы и комплексы программ

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата технических наук

12 ДЕК 2013

005543689

Москва-2013

005543689

Работа выполнена в ФГБОУ ВПО «МАТИ - Российский государственный технологический университет имени К.Э. Циолковского».

Научный руководитель: Шилов Валерий Владимирович

кандидат технических наук старший научный сотрудник Официальные оппоненты: Дроздов Александр Юльевич

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

ФГОУ ВПО «Московский физико-технический институт (государственный университет)»

профессор кафедры радиоэлектроники и прикладной информатики

Ермолович Александр Владленович

кандидат технических наук

ЗАО "Интел А/О"

ведущий инженер по разработке программного обеспечения

Ведущая организация: ФГБОУ ВПО "Московский

государственный университет путей сообщения"

Защита состоится « 26 » декабря 2013 г. в 14 ч. 00 мин. на заседании диссертационного совета Д 212.110.08 при ФГБОУ ВПО «МАТИ - Российский государственный технологический университет имени К. Э. Циолковского» по адресу: 121552, Москва, ул. Оршанская, д. 3, ауд. 612а .

С диссертацией можно ознакомиться в библиотеке ФГБОУ ВПО «МАТИ - Российский государственный технологический университет имени К. Э. Циолковского».

Автореферат разослан « 25 » ноября_2013 г.

Учёный секретарь диссертационного совета Д 212.110.08

кандидат физико-математических наук Спыну М.В.

Общая характеристика работы

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

Существующие методики планирования проекта предлагают различные подходы к построению процесса разработки программного обеспечения («каскадный», итерационный, «гибкий»), разработаны программные средства для ведения проектов в рамках той или иной методики (MS Project, Primavera Project Planner, Spider Project и т.д.). Их главным недостатком является то, что ошибки в планировании могут быть учтены уже только после завершения проекта. Поскольку процесс разработки весьма динамичен, требования и набор задач могут часто меняться, ошибка в планировании может привести к значительной задержке времени окончания проекта и/или существенному перерасходу ресурсов. Существующие методы предварительной оценки составленного плана проекта (PERT, СОСОМО) требуют задания для еще неизвестного проекта большого количества характеристик и чаще всего дают недостаточно точные результаты.

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

Цель диссертационной работы. Целью диссертационной работы является создание математической модели процесса разработки программного обеспечения и системы планирования проектов на ее основе.

Исходя из цели, в работе решаются следующие задачи:

• анализ существующих моделей разработки программного обеспечения;

• анализ подходов к планированию проектов разработки программного обеспечения;

• анализ возможностей существующих программных продуктов ведения проектов;

• разработка структуры системы планирования проектов;

• создание математической модели процесса разработки программного обеспечения;

• создание программной системы планирования проектов разработки программного обеспечения на основе предложенной модели;

экспериментальная проверка результатов работы системы.

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

Методы исследования. Методы исследования заимствованы из следующих областей:

• математический анализ;

• математическое моделирование;

• численные методы;

• теория вероятностей и математическая статистика;

• теория массового обслуживания;

• теория графов;

• языки программирования;

• базы данных.

Научная новизна. Научную новизну диссертационной работы составляют результаты, полученные в ходе решения поставленных задач:

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

• структурная схема системы планирования проектов разработки программного обеспечения;

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

• принципы прогнозирования хода выполнения проекта и определения требуемых параметров проекта разработки программного обеспечения.

Практическая ценность работы. Практическую ценность работы составляют следующие результаты:

• система прогнозирования процесса выполнения проекта;

• рекомендации по планированию проекта с предварительной проверкой на модели.

Положения, выносимые на защиту. На защиту выносятся следующие положения:

• методика ведения проекта на основе вероятностной модели;

• структурная схема программной системы планирования проектов разработки программного обеспечения;

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

• принципы прогнозирования хода выполнения проектов и определения требуемых параметров.

Апробация результатов исследований. Основные результаты, полученные в ходе выполнения диссертационной работы, докладывались на международных молодёжных научных конференциях XXXV Гагаринские чтения (Москва, 2009 г.), XXXVI Гагаринские чтения (Москва, 2010 г.), XXXVII Гагаринские чтения (Москва, 2011 г.), XXXVIII Гагаринские чтения (Москва, 2012 г.), XXXIX Гагаринские чтения (Москва, 2013 г.), XII Международной конференции «Региональная информатика - 2008» (Санкт-Петербург, 2010 г.), X Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2010 г.), XI Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2011 г.), XII Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2012 г.), XIII Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2013 г.), а также докладывались и обсуждались на научных семинарах кафедры «Проектирование вычислительных комплексов» ФГБОУ ВПО «МАТИ — Российский государственный технологический университет имени К. Э. Циолковского».

Публикации. По теме диссертации опубликованы 13 печатных работ, в том числе 3 статьи, из них 3 статьи в журналах, входящих в Перечень ведущих изданий, рекомендованных ВАК.

Структура и объем работы. Работа состоит из введения, четырёх глав, заключения, списка литературы и четырёх приложений. Работа изложена на 101 странице и включает 28 рисунков, 5 таблиц, список литературы из 89 наименований, а также приложения на 3 страницах. Общий объём работы - 105 страниц.

Краткое содержание работы

Во введении обосновывается актуальность темы диссертационной работы. Характеризуется область исследования. Обосновываются научная новизна и практическая значимость выполненного исследования. Формулируются цели исследования и основные положения, выносимые на защиту.

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

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

Далее приведена классификация способов ведения проектов разработки программного обеспечения, основывающаяся на приоритетных ограничениях (рис.1). Рассмотрены и проанализированы подходы к ведению проектов: с фиксированным временем выполнения (time-driven, самым существенным параметром является время), с фиксированным объемом работ (feature driven, для реализации запланированных функций системы могут быть увеличены ресурсы или сроки) и с фиксированной стоимостью (resource driven, приоритетным является ограничение одного из ресурсов).

Ограничения

Водопадная,модель, итерационные модели фаботы определяют стоимость и сроки) Объем работ

Гибкие подходы

р&ъем работ определяется из ограничений по времени и стоимости)

Стоимость

Сроки

/фиксированный\ объем 4

Фиксировнные / , время и/или / стоимость /

/

Оценки

Стоимость

Сроки

Объем работ

Рис. 1. Различие проектных треугольников для различных подходов.

Нахождение верного баланса между ресурсами, временем разработки и возможностями - самый важный момент в построении решения, отвечающего потребностям заказчика.

Опыт последних лет показал, что для большинства проектов разработки систем, требования к которым изменяются достаточно часто, необходимо максимально уменьшить длительность одного этапа жизненного цикла. В связи с этим в настоящее время стали очень популярными короткие жизненные циклы разработки, которые были объединены общим названием «гибкие» методы (Agile, от англ. «гибкий», «быстрый»).

Основная идея жизненного цикла - максимальное укорачивание длительности каждого этапа жизненного цикла и тесное взаимодействие с заказчиком. Проблемой при таком подходе может оказаться отсутствие документированного взаимодействия модулей системы. При «гибком» подходе интерфейсы проектируются одновременно с разрабатываемыми модулями. Отсутствие четкой документированное™ процессов, важность каждого в команде, а также зачастую нехватка системного взгляда на проект — самые серьёзные проблемы этой методики. Но, не смотря на

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

План, разработанный до начала выполнения работ проекта, представляет собой модель направленных на достижение поставленных целей взаимосвязанных производственных процессов. Календарный план должен отвечать противоречивым условиям простоты и достаточной полноты. Для разработки календарных планов используются методы сетевого моделирования, которые позволяют связать различные работы и процессы во времени и получить в результате общую продолжительность всего проекта. В диссертационной работе проведен анализ современного ПО управления проектами (Microsoft Office Project, Primavera, Open Plan, Spider Project). Все они основаны на сетевом моделировании.

В настоящее время известно множество методов вероятностного сетевого планирования, наиболее распространенными из которых являются:

• метод оценки и анализа программ (Program Evaluation and Review Technique, PERT);

• метод статистических испытаний или метод Монте-Карло;

• метод графической оценки и анализа программ (Graphic Evaluation and Review Technique, GERT).

• COCOMO (Constructive Cost Model - модель издержек разработки) - это алгоритмическая методика оценки интегральной стоимости разработки ПО.

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

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

Рассмотрены основные виды активностей, которые в том или ином виде присутствуют вне зависимости от выбранного подхода к разработке.

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

Исходя из этого, в диссертационной работе предлагается подход к ведению проекта (рис. 2), основными идеями которого являются:

1. Проверка плана проекта и его возможная корректировка перед переходом к выполнению задач и после очередной итерации.

2. Максимальный учет результатов предыдущих проектов и завершенных итераций при текущем планировании.

3. Возможность простого внесения изменений в план проекта в процессе выполнения задач после очередной итерации без изменения всего плана проекта целиком.

Инициация Бизнес» Формнро- Системные

проекта требования требований требования

Формирование списка {-Дерево задач* задач

Построений очереди задач приоритетами га Очередь задач „ Построение" очереди единичных задач (г)

с пр> оритетамн

Проверка с помощью модели

Автоматическое составление плана задач

Формирование команды

Формирование списка задач

План итераций і

Выполнение задач

—Выполненные задачи-*

Анализ результатов

Рис. 2. Схема выполнения проекта с учетом корректировки по результатам анализа.

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

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

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

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

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

к=п+1

где рзис — вероятность успеха проекта или итерации; N— общее количество задач; задачи с номерами 1..« - обязательные; р„ - вероятность выполнения

N

Рзис = Рп+ Рк>

всех п обязательных задач; рк — вероятность выполнения к необязательных задач.

Эту вероятность можно вычислять с использованием заранее установленного критерия £=£>,+1 — />,, но, учитывая, что сумма всех вероятностей в любой момент времени равна единице, ее можно заменить на более удобную для расчета:

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

Можно сформулировать следующие требования к системе планирования проектов:

1. Наличие средств прогнозирования хода выполнения и вероятности успешного завершения проекта.

2. Наличие средств определения времени, необходимого для завершения выполнения запланированных задач и определения максимального количества задач, которые могут быть выполнены, в случае неудовлетворительного прогноза.

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

4. Наличие средств составления плана проекта.

5. Возможность изменения плана проекта в ходе его выполнения без полной перестройки процесса.

6. Возможность учета приоритетов задач и связей между ними.

7. Возможность учета квалификации и индивидуальных характеристик членов команды разработки.

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

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

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

п

¡=о

(рис. 3):

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

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

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

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

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

Команду разработки можно рассматривать как систему массового обслуживания (СМО), на вход которой поступает поток требующих решения задач, а на выходе образуется поток выполненных задач. Любая исходная задача может быть декомпозирована на более мелкие, вплоть до совокупности нескольких единичных задач, например, реализующих отдельные методы (единичной будем считать задачу, которую один специалист может выполнить за один рабочий день). Далее формируется очередь единичных задач, которая в соответствии с «гибкими» подходами к ведению проектов {agile), разбивается на несколько итераций. Критерием разбиения на итерации обычно служит или отведенное на итерацию время, или количество составляющих ее задач.

МОДУЛЬ ПОСТАНОВКИ ЗАДАЧ

Рг, [Т~|—

Источники задач приоритета рп

МОДУЛЬ АНАЛИЗА ЗАДАЧ

Модуль создания очереди

Модуль построения дерева задач

Дерево задач 1 с приоритетами

Построение очереди задач

і Построение Учер ь ^ очереди 'шдач единичных

задач

МОДУЛЬ ПРОГНОЗИРОВАНИЯ ИТЕРАЦИЙ ПРОЕКТА

Очередь задач

Очередь ' -единичных*: задач Ь

Модуль составления плана итераций

| План [ итераций

!;..: Модуль прогнозирован ■] ия хода выполнения проекта

Прогноз проекта

Рис. 3. Структурная схема системы.

Задачи План на

1 | 2 ' итерацию

і

о Вероятной выполнения всех

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

каждый день итерации

Вероятность

выполнения

плана на итерацию в срок

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

Система массового обслуживания, представляющая команду разработки, содержит N каналов обслуживания, соответствующих N членам коллектива. Характер случайного процесса выполнения задач членами команды таков, что вероятность любого состояния системы в будущем зависит только от текущего состояния системы и не зависит от того, когда и каким образом система пришла в это состояние. С какой вероятностью и за какое время будут выполнены следующие задачи, не зависит от того, как были выполнены предыдущие. Исходя из этого, моделируемый процесс можно считать Марковским.

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

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

выполнения задач командой X как отношение количества выполненных задач (к) ко времени(0- Значение X пересчитывается после завершения каждой итерации проекта и позволяет адаптировать системе отражать изменение количества и уровня подготовки специалистов. В случае появление нового члена команды средняя интенсивность выполнения задач командой может быть рассчитана по формуле:

^ = (^old + ^-newcomer)/(Aold+l)>

где Xou — текущая интенсивность выполнения задач командой, Xnewcomer — интенсивность труда нового члена команды, Nm — количество

разработчиков в проекте. На основе X вычисляются X.l5 Х2, .... Ху — интенсивности переходов между состояниями в зависимости от количества членов команды.

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

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

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

СМО представляется динамической моделью, переходы между состояниями в которой определяются в зависимости от входных параметров. Каждое состояние системы Sk определяется выполнением К

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

Рис. 5. Граф состояний системы с N специалистами. За время Д/ система массового обслуживания в каждый момент

времени может выполнить от 0 до N задач, где N — количество

специалистов в команде, а значит, перейти в одно из состояний — от 5,-, в котором она находится, до Предлагается метод, который показал

достаточную точность на ряде исследованных проектах. На основе графа состояний для всех случаев составлены уравнения вероятностей нахождения системы в каждом из состояний. Вероятность того, что система через время А1 будет находиться в состоянии Бо, определяется как вероятность отсутствия перехода в любое из состояний ..., 5'л-Р, (/+до=р, (0(1 - я,, м - л2м -...-лцЫ)+р0 (0ЛД1; р2 (?+до=р2 (0(1 - Л ді - А, ді -...- А„ дО+р, (ОМ1+Ро (0Л Ді; рм (г + ДО = Рк (0(1 - А, Д1 - А, Д1 -..А„ ДО + р0 (о Ад, Д1 +

Система уравнений Колмогорова для общего случая имеет вид:

ей <->

<А '-і

Т.Р„= !•

Решением этой системы являются функции зависимости вероятности нахождения системы в указанном состоянии от времени. Для определения вероятности выполнения к задач за время итерации d необходимо решить систему к+1 дифференциальных уравнений. В работе эта система уравнений решена численно методом Рунге-Кутты для проектов разных размеров в среде Maple 16. Программная реализация численного метода позволяет получать значения за достаточное время, в результате получаются значения вероятностей нахождения системы в каждом из состояний, затем можно рассчитать вероятность успешного выполнения проекта целиком.

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

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

• Модуль формирования команды для задания информации о команде разработки, автоматической или ручной корректировки сведений о производительности команды.

• Модуль формирования списка задач. Модуль позволяет построить сетевой график, а затем произвести его «обход», сформировав список задач с учетом приоритетов.

• Модуль прогнозирования, в котором реализована предлагаемая математическая модель, с помощью которой рассчитывается вероятность выполнения заданного количества задач, а также предлагаются возможные варианты повышения этой вероятности, в случае если она ниже пороговой.

В самом успешном случае, после внесения задач по проекту, пользователю необходимо только фиксировать выполнение задач, такая функция доступна в главном окне системы (рис. 6).

В случае неудовлетворительного прогноза подсвечиваются ячейки, соответствующие количеству задач на итерацию для заданных параметров системы &opt и/или количеству дней для решения выбранного количества задач dopt при условии не снижения вероятности выполнения их ниже заданного порогового значения.

Исторически первым подходом к планированию проектов являлся метод PERT, который, даже не смотря на свои недостатки,

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

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

Затем в соответствии с методом было получено время ТЕ время выполнения задач критического пути, и стандартное отклонение выполнение задач проекта.

Продолжительность задач критического пути: 12,5 дней. Стандартное отклонение для проекта: 2,17 дней. Для определения вероятности выполнения итерации за 14 дней (Ts) необходимо вычислить величину Z - количество стандартных отклонений от средней величины.

Затем по статистическим таблицам определяется соответствующая вероятность - 76%.

Таким образом, оценки в 76% для PERT и 90% для предложенного подхода не противоречат друг другу. В табл. 1 приведены аналогичные оценки для 5 итераций проекта.

Таблица 1

Сравнение предложенного метода с методом PERT

Номер PERT Предложенный Успешная

итерации метод итерация

1. 71% 82% Да

2. 65% 41% Нет

3. 70% 70% Да

4. 76% 90% Да

5. 77% 90% В процессе выполнения

Для 1-3 итерации количество задач было задано вручную, для 4 и далее количество задач итерации было определено автоматически, исходя из условия 90% вероятности успеха, что соответствует двум режимам работы системы планирования.

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

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

проектов, потребуется возможность удобного графического представления накопленной статистической информации, например о совпадении прогнозов и результатов для более точного определения пороговой вероятности принятия задачи в итерацию. Это может быть внедрено в т. ч. с помощью \уеЬ-интерфейса. Кроме очевидных преимуществ в мобильности и использовании тонких клиентов, \¥еЬ-система позволит проще вести централизованную базу проектов и прогнозов.

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

Выводы по результатам диссертации

В ходе решения поставленной задачи были получены следующие результаты:

1. Проанализированы современные подходы к ведению проектов разработки ПО и поддерживающие их автоматизированные системы ведения проектов.

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

3. Предложена математическая модель выполнения проекта разработки ПО.

4. Предложена методика декомпозиции дерева задач проекта на единичные задачи для дальнейшей оценки проекта с помощью предложенной модели.

5. Разработана программная система планирования проектов разработки ПО на основе этой модели.

6. Проведен эксперимент по оценке работы созданной программной системы на примере проекта разработки системы автоматизированного анализа текста.

Список публикаций по теме диссертации

1. Полицын С. А. Роль, цель и стратегия автоматизации тестирования приложений // Научные труды Международной молодежной научной конференции «XXXV Гагаринские чтения». Т. 4. М.: МАТИ, 2009. С. 143144.

2. Полицын С. А. Применение метрик тестирования для оценки временных затрат при разработке ПО// Материалы X Международной научно-методической конференции "Информатика: проблемы, методология, технологии". Т. 1. Воронеж, 2010.

3. Полицын С. А. Подходы к оценке взаимного влияния параметров на сроки завершения проектов разработки программного обеспечения // Научные труды Международной молодежной научной конференции «XXXVI Гагаринские чтения». Т. 4. М.: МАТИ, 2010. С 124-125

4. Поли цып С. А. Оценка влияния параметров разработки программного обеспечения на сроки завершения проектов // Материалы XII Санкт-Петербургской международной конференции «Региональная информатика-2010». СПб.: СПИИРАН, 2010. С.58-59.

5. Полицын С. А. Классификация ошибок и их влияние на процесс разработки программного обеспечения // Материалы XI Международной научно-методической конференции "Информатика: проблемы, методология, технологии". Т. 2. Воронеж, 2011. С. 186-189/

6. Полицын С. А. О влиянии ошибок на процесс разработки программного обеспечения // Научные труды Международной молодежной научной конференции «XXXVII Гагаринские чтения». Т. 4. М.: МАТИ, 2011.С. 97-99.

7. Полицын С. А. Подходы к вычислению временных затрат на проекты в сфере разработки программного обеспечения на основе использования прецедентов // Программная инженерия. 2011. № 7, С. 915.

8. Полицын С. А. Методика прогнозирования времени окончания проектов разработки программного обеспечения на основе модели системы массового обслуживания // Материалы XII Международной научно-методической конференции "Информатика: проблемы, методология, технологии", 2012. Т. 1. Воронеж, С 322-323.

9. Полицын С. А. Использование моделей систем массового обслуживания в прогнозировании времени окончания проектов разработки программного обеспечения // Научные труды Международной молодежной научной конференции «XXXVIII Гагаринские чтения». Т. 4. М.: МАТИ, 2012. С. 145-146.

10. Полицын С. А. Прогнозирование хода выполнения задач в проекте разработки программного обеспечения. Материалы XIII Международной научно-методической конференции "Информатика: проблемы, методология, технологии", 2013. Т. 3, Воронеж, С. 75-80.

11. Полицын С. А. Подход к оценке времени для руководителей коллективов разработки программного обеспечения // Научные труды Международной молодежной научной конференции «XXXVII Гагаринские чтения». Т. 4. М.: МАТИ, 2013, С. 57-58.

12. Полицын С. А. Система планирования проектов разработки программного обеспечения // Вестник В ГУ, серия: системный анализ и информационные технологии, 2013, № 1,С. 136-141.

13. Полицын С. А., Шилов В. В. Математическая модель процесса выполнения задач при разработке программного обеспечения // Информационные технологии, №10,2013, С. 24-29.

Подписано в печать: 23.11.2013 Объем: 1,0 п.л. Тираж: 100 экз. Заказ № 314 Отпечатано в типографии «Реглет» 119526, г. Москва, пр-т Вернадского, д. 39 (495) 363-78-90; www.reglet.ru

ФГБОУ ВПО «МАТИ - Российский государственный технологический университет имени К.Э. Циолковского»

На правах рукописи

04201451 *НЗ

ПОЛИЦЫН Сергей Александрович

МАТЕМАТИЧЕСКАЯ МОДЕЛЬ И СИСТЕМА ПЛАНИРОВАНИЯ ПРОЕКТОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Специальность 05.13.18 - Математическое моделирование, численные

методы и комплексы программ

Диссертация на соискание учёной степени кандидата технических наук

Научный руководитель к.т.н, с.н.с. Шилов В.В.

Москва-2013

СОДЕРЖАНИЕ

Введение...................................................................................5

1. Анализ подходов к планированию проектов разработки программного обеспечения............................................................................10

1.1. Определение понятия проекта.........................................................10

1.2. Анализ проблем планирования проектов.........................................11

1.2.1. Определение цели проекта.........................................................11

1.2.2. Анализ проблемы планирования ресурсов проекта..................12

1.3. Анализ основных подходов к ведению проектов.............................13

1.3.1. Треугольник взаимозависимостей частей проекта................13

1.3.2. Обзор подходов к ведению проекта на основе ограничений... 15

1.4. Анализ основных подходов к планированию проектов...................19

1.4.1. Сетевое планирование................................................................20

1.4.2. Метод PERT.................................................................................22

1.4.3. Метод Монте-Карло..................................................................24

1.4.5. Модель планирования проектов СОСОМО/ СОСОМОII.......25

1.4.6. Необходимость создания метода планирования.....................26

1.5. Обзор и анализ систем ведения проекта........................................27

1.6. Выводы................................................................................................34

2. Разработка структуры системы планирования проектов разработки программного обеспечения............................................................................36

2.1. Общая схема ведения проекта..............................................................36

2.2. Требования к системе............................................................................38

2.3. Структура системы..............................................................................42

2.3.1. Основные модули системы.............................................................42

2.3.2. Модуль постановки задач...............................................................43

2.3.3. Модуль анализа задач......................................................................46

2.3.4. Модуль прогнозирования итераций проекта................................49

2.4. Выводы.....................................................................................................54

3. Построение математической модели процесса выполнения задач при разработке программного обеспечения...............................................55

3.1. Команда разработки как система массового обслуживания...........55

3.2. Основные элементы и характеристики системы..............................56

3.3. Расчет вероятностей выполнения задач............................................59

3.3.1. Состояния системы........................................................................59

3.3.2. Уравнения состояний системы.....................................................63

3.3.3. Функции вероятностей состояний системы...............................66

3.4. Расчет вероятностей выполнения плана задач на итерацию..........69

3.5. Схема работы модуля прогнозирования результатов.......................72

3.6. Выводы.....................................................................................................74

4. Прогнозирование выполнения задач проекта разработки программного обеспечения............................................................................76

4.1. Интерфейс системы планирования и прогнозирования проекта.....76

4.2. Описание проекта..................................................................................78

4.3. Составление списка задач по проекту.................................................80

4.4. Составление плана задач.......................................................................81

4.5. Составление плана проекта..................................................................83

4.5.1. Формирование плана итераций......................................................83

4.5.2. Контроль хода выполнения проекта.............................................85

4.5.3. Анализ прогноза и корректировка плана итераций.....................87

4.5.4 Выбор оптимальных параметров проекта...................................89

4.6. Сравнение предлагаемого способа с расчетом методом PERT.......90

4.7. Использование системы.........................................................................92

4.8. Выводы.....................................................................................................94

Заключение.......................................................................................................96

Список литературы.........................................................................................97

Приложение 1...............................................................................104

Введение

Актуальность темы диссертации

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

Существующие методики планирования проекта предлагают различные подходы к построению процесса разработки программного обеспечения («каскадный», итерационный, гибкий), разработаны программные средства для ведения проектов в рамках той или иной методики (MS Project, Primavera Project Planner, Spider Project и т.д.). Их главным недостатком является то, что ошибки в планировании могут быть учтены уже только после завершения проекта. Поскольку процесс разработки весьма динамичен, требования и набор задач могут часто меняться, ошибка в планировании может привести к значительной задержке времени окончания проекта и/или существенному перерасходу ресурсов. Существующие методы предварительной оценки составленного плана проекта (PERT, СОСОМО) требуют задания для еще неизвестного проекта большого количества характеристик и чаще всего дают недостаточно точные результаты.

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

Цель диссертационной работы

Целью диссертационной работы является создание математической модели процесса разработки программного обеспечения и программной системы планирования проектов на ее основе.

Исходя из цели, в работе решаются следующие задачи:

• анализ известных моделей разработки программного обеспечения;

• анализ подходов к планированию проектов разработки программного обеспечения;

• анализ возможностей существующих программных продуктов ведения проектов;

• разработка структуры системы планирования проектов;

• создание математической модели процесса разработки программного обеспечения;

• создание программной системы планирования проектов разработки программного обеспечения на основе предложенной модели;

• экспериментальная проверка результатов работы системы. Предмет исследования

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

Методы исследования

Методы исследования заимствованы из следующих областей:

• математический анализ;

• математическое моделирование;

• численные методы;

• теория вероятностей и математическая статистика;

• теория массового обслуживания;

• теория графов;

• языки программирования;

• базы данных. Научная новизна

Научную новизну диссертационной работы составляют результаты, полученные в ходе решения поставленных задач:

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

• структурная схема системы планирования проектов разработки программного обеспечения;

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

• принципы прогнозирования хода выполнения проекта и определения требуемых параметров проекта разработки программного обеспечения.

Практическая ценность работы

Практическую ценность работы составляют следующие результаты:

• система прогнозирования процесса выполнения проекта;

• способ планирования проекта с предварительной проверкой на модели.

Положения, выносимые на защиту На защиту выносятся следующие положения:

• методика ведения проекта на основе вероятностной модели;

• структурная схема программной системы планирования проектов разработки программного обеспечения;

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

• принципы прогнозирования хода выполнения проекта и

определения требуемых параметров. Апробация результатов исследований

Основные результаты, полученные в ходе выполнения диссертационной работы, докладывались на международных молодёжных научных конференциях XXXV Гагаринские чтения (Москва, 2009 г.), XXXVI Гагаринские чтения (Москва, 2010 г.), XXXVII Гагаринские чтения (Москва, 2011 г.) и XXXVIII Гагаринские чтения (Москва, 2012 г.), XII Международной конференции «Региональная информатика - 2008» (Санкт-Петербург, 2010 г.), X Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2010 г.), XI Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2011 г.), XII Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2012 г.), XIII Международной научно-методической конференции «Информатика: проблемы, методология, технологии» (Воронеж, 2013 г.), а также докладывались и обсуждались на научных семинарах кафедры «Проектирование вычислительных комплексов» МАТИ - РГТУ имени К.Э. Циолковского.

По теме диссертации опубликованы 13 печатных работ, в том числе 3 статьи, из них 3 статьи в журналах, входящих в Перечень ведущих изданий, рекомендованных ВАК.

Структура и объем работы

Работа состоит из введения, четырёх глав, заключения, списка литературы и четырёх приложений. Работа изложена на 103 страницах и включает 28 рисунков, 5 таблиц, список литературы из 89 наименований, а также приложение на 2 страницах. Общий объём работы - 105 страниц.

Краткое содержание работы

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

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

В третьей главе исследуется система массового обслуживания, определяются ее основные характеристики, строится граф состояний. Составляется и решается система уравнений Колмогорова для частных случаев небольших команд разработки, затем для общего случая коллективов, состоящих из N сотрудников. Для решения системы, состоящей из большого числа дифференциальных уравнений, применяется численный метод решения - метод Рунге-Кутты.

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

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

1. Анализ подходов к планированию проектов разработки программного обеспечения 1.1. Определение понятия проекта

Проект обычно определяется как уникальный набор скоординированных действий с заданным началом и завершением, осуществляемых индивидуумом или организацией для решения специфических задач в соответствии с имеющимся расписанием, затратами и параметрами выполнения[85].

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

Управление проектами состоит из двух основных частей: составление плана и контроль хода работ по нему. Качественный план проекта облегчает в дальнейшем выполнение проектных задач и повышает вероятность удачного завершения проекта. Имеется множество факторов, которые положительно и отрицательно влияют на ход проекта. Например, декомпозиция целей на более мелкие и более понятные обычно положительно влияет на ход проекта[1].

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

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

• временные ресурсы;

• человеческие ресурсы;

• финансовые ресурсы (бюджет).

При планировании производится общий анализ работ и ресурсов, также необходимо учитывать их ограниченность и предполагаемое распределение на основе потребностей проектов. Ресурсное планирование включает в себя анализ ресурсов и работ, разработку системы распределения ресурсов, контроль над ходом работ, выбор корректирующих мер [47].

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

1.2. Анализ процесса планирования проектов

1.2.1. Определение цели проекта

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

Затем обычно составляется план в традиционном понимании, где планирование состоит в назначении работ, определению их

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

1.2.2. Анализ проблемы планирования ресурсов проекта

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

В любом проекте приходится балансировать между стоимостью, временем, качеством и объемом реализуемой функциональности. Точный расчет ресурсов, необходимых для реализации данного продукта при определенных требованиях к качеству, является одной из основных проблем в области управления проектами. Особенно если речь идет о проектах разработки программного обеспечения. При этом многими авторами выделяется, в первую очередь, большая творческая составляющая процесса разработки программного обеспечения (ПО) [64]. Поэтому в расчетах характеристик проектов возникают сложности учета огромного количества факторов, в том числе трудноформализуемых, влияющих на жизненный путь проекта. Как следствие, сегодня многие компании сталкиваются с серьезными проблемами в случае неправильных расчетов необходимых сроков:

1 Обычно речь идёт о совете экспертов, состоящем из аналитика, бизнес-аналитика, ведущего разработчика, менеджера проекта, менеджера по тестированию

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