Математическая модель и система планирования проектов разработки программного обеспечения тема диссертации и автореферата по ВАК РФ 05.13.18, кандидат наук Полицын, Сергей Александрович

• Полицын, Сергей Александрович
• кандидат наук
• 2013

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

СОДЕРЖАНИЕ

Введение

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

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

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

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

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

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

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

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

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

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

1.4.2. Метод PERT

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

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

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

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

1.6. Выводы

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

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

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

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

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

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

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

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

2.4. Выводы

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

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

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

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

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

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

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

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

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

3.6. Выводы

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

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

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

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

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

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

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

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

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

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

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

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

4.8. Выводы

Заключение

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

Приложение 1

Введение диссертации (часть автореферата) на тему «Математическая модель и система планирования проектов разработки программного обеспечения»

Введение

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

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

Существующие методики планирования проекта предлагают различные подходы к построению процесса разработки программного обеспечения («каскадный», итерационный, гибкий), разработаны программные средства для ведения проектов в рамках той или иной методики (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 Обычно речь идёт о совете экспертов, состоящем из аналитика, бизнес-аналитика, ведущего разработчика, менеджера проекта, менеджера по тестированию

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

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

Точные оценки издержек производства программного обеспечения важны как разработчикам, так и заказчику. Возникает потребность в разработке методов и средств, позволяющих менеджеру проекта оценить необходимые временные и человеческие ресурсы на основе всех имеющихся данных: истории предыдущих подобных проектов, опыта и производительности труда сотрудников, специфики компании и т.п. Кроме того, требуется также иметь возможность перерасчета и уточнения сроков и ресурсов уже в ходе разработки программных систем с учетом расхождения текущего состояния проекта и его плана. Это может помочь руководителю своевременно обнаружить отклонения от установленного графика и принять соответствующие меры в управлении проектом[28]. 1.3. Анализ основных подходов к ведению проектов 1.3.1. Треугольник взаимозависимостей частей проекта Большинство проектов имеют определенные дату окончания, бюджет и объем работ. Время, ресурсы и объем работ в литературе [8] обычно называют проектным треугольником (рис. 1.1), т.к. изменения в одном из этих элементов вызывают изменения других. В общем случае, для проекта важны все три составные части, но, как правило, только один из них в зависимости от приоритетов имеет наибольшее влияние на другие. В этом случае говорят о проектах с фиксированным временем выполнения (time-driven, самым существенным параметром является время), с фиксированным объемом работ (feature driven, для реализации

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

Время IMB^^^L Стоимость

Объем работ

Рис. 1.1. Проектный треугольник.

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

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

Объем работ

Рис. 1.2. Качество в проектном треугольнике. 1.3.2. Обзор подходов к ведению проекта на основе ограничений

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

В стандарте ГОСТ ИСО/МЭК 12207-1999 [17] упоминается каскадная, спиральная и эволюционная модели. В новой версии стандарта количество моделей возрастает до четырех (добавляется итерационная модель). В последующих же версиях декларируется множество вариантов организации процесса разработки ПО [18], но основными являются: каскадная, инкрементная и эволюционная.

В работах [10, 54, 58-59] рассматривается множество современных вариантов организации разработки программного обеспечения, вырабатываются критерии оценки и выбора альтернатив, а также и их различные классификации. Однако для большинства современных вариантов построения процесса разработки программного обеспечения точная классификация затруднительна. Практически каждый проект, часто стараясь следовать тем или иным принципам, адаптирует их к своим реалиям, тем самым создавая новый подход. При этом практически всегда команда разработки в чем-либо ограничена. Поэтому в работе эти подходы классифицируются по способу построения процесса разработки программного обеспечения на основе приоритетного типа ограничений.

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

Подходы к разработке ПО, основанные на ограничениях размеров проекта, исторически возникли первыми. Это объясняется в первую очередь тем, что ограничения размеров проекта (как, впрочем, и ресурсов) логически вытекают из самой сути проекта. Как только удается определить и декомпозировать цель проекта сразу возникают рамки проекта {scope), в которых определен проект и ограничения. Проект, не имеющий границ, заранее неуспешен. Все подходы данной группы основаны на четком разделении проекта на фазы, отличаясь только длительностью и степенью проработки фаз.

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

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

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

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

Ограничения

Водопадная, модель, итерационные модели

(работы определяют стоимость и сроки) Объем работ

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

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

Стоимость

Сроки

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

/ Фиксированный^ / объем

Оценки Стоимость Сроки Объем работ

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

Способы построения процесса разработки ПО, основанные на

ограничении ресурсов

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

Способы построения процесса разработки ПО, основанные на

ограничении времени.

17

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

Самым существенным ограничением при подобном варианте построения процесса разработки ПО является время. Обычно на какой-либо короткий промежуток времени (1-3 недели) фиксируется набор функционала будущей системы, подлежащий реализации. При этом проектирование, программирование, тестирование в течение этого мини-цикла идут почти параллельно. Естественно, нельзя реализовывать, а уж тем более проверять модуль, который ещё не спроектирован.

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

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

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

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

Смешанные подходы

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

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

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

19

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

При сетевом планировании общая продолжительность проекта зависит от взаимозависимости работ, от продолжительностей работ и временных ограничений, установленных на сроки работ. Обычно при расчётах рассматриваются детерминированные сетевые модели, взаимная последовательность и продолжительности которых заданы однозначно; выделяется критический путь (работы от точки старта до окончания проекта, которые более не могут быть разделены и выполняются максимальное время), на основе оценок которого оценивается проект целиком. Увеличение фактической продолжительности работ, принадлежащих критическому пути, по какими-либо причинам, приводит к соответствующему увеличению общей продолжительности проекта, в то время как некритические работы обладают некоторыми резервами времени. Однако при увеличении фактических сроков работ некритического пути, стоит учитывать возможность изменения критического пути и, как следствие, появление необходимости полного повторного планирования проекта. Одним из способов снижения риска сдвига сроков окончания работ при детерминированном планировании является выделение так называемого страхового резерва времени, то есть плановый срок принимается на некоторое количество процентов (обычно 10-30 %) меньше договорного, а оставшийся период времени используется для завершения невыполненных в срок работ.

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

Список литературы диссертационного исследования кандидат наук Полицын, Сергей Александрович, 2013 год

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

1. Антонов, А. В. Планирование проектов - ставка на результат // Директор информационной службы, 2007 № 09 [Электронный ресурс] URL: www.osp.ru/cio/2007/09/4370656 (дата обращения 18.08.2013)

2. Алиев, X. Р. Эффективная модель оценки разработки программного обеспечения // Исследовано в России, 2008. - Т. 11. стр. 338-364.

3. Архипенков, С. В. Руководство командой разработчиков программного обеспечения [Электронный ресурс] URL: http://citforum.ru/SE/project/app_thoughts (дата обращения: 18.08.2013).

4. Балакирев, Н.Е., Добрышина, Е.В. Концептуальная модель и структура системы обработки текстовой информации // Информационные технологии, № 2, 2010. - стр. 2-7.

5. Бек, К. Экстремальное программирование: разработка через тестирование. - СПб: Питер, 2003. - 224 с.

6. Бовтеев, С. В., Чайка, Ю. О. Вероятностное планирование строительства объектов [Электронный ресурс] URL: http://prosvet.su/ articles/menegment/articlel (дата обращения 18.08.2013)

7. Богданов, В. В. Планирование проектов [Электронный ресурс] URL: http://www.iteam.ru/publications/project/section_36/article_3496/ (дата обращения: 18.08.2013).

8. Богданов, В. В. Управление проектами в Microsoft Project 2007. -СПб.: Питер, 2008. - 592 с.

9. Браун, К., Калбертсон, Р., Кобб, Г. Быстрое тестирование. - СПб: Вильяме, 2002. -384 с.

Ю.Браунде, Э. Технология разработки программного обеспечения. -СПб.: Питер, 2004. -655 с.

П.Брукс, Ф. Мифический человеко-месяц, или как создаются программные системы. - М: Символ-Плюс, 2010. -304 с.

12.Бызов, JI. Н. Моделирование случайных процессов. Учебное пособие. - СПб: БГТУ им. Д. Ф. Устинова «Военмех», 1998. -125 с.

13.Вентцель, Е. С., Овчаров, JI. А. Теория вероятностей и ее инженерные приложения, 2е изд. -М.:Высшая школа, 2000. -480 с.

М.Верзух, Э. Управление проектами: ускоренный курс по программе MB А: Пер. с англ. - М.: Вильяме, 2006, - 506 с.

15.Гнеденко, Б. В. Курс теории вероятностей. 8-е изд., испр. и доп. -М.: Едиториал, 2005. -448 с.

16.Голенко, Д.И. Статистические методы сетевого планирования и управления. - М.: Главная редакция физико-математической литературы изд-ва "Наука", 1968. -400 с.

17.ГОСТ Р ИСО/МЭК 12207—1999. Информационная технология. Процессы жизненного цикла программных средств. - М.: Издательство стандартов, 1999.

18.ГОСТ Р ИСО/МЭК ТО 15271—2002. Информационная технология. Руководство по применению. ГОСТ Р ИСО/МЭК 12207. - М.: Стандартинформ, 2002.

19.Грашина, М., Ньюэлл, М. Управление рисками как интегральная часать методологии проектного менеджмента // Директор информационной службы. 2002 № 06 [Электронный ресурс] URL: http://www.osp.ru/cio/2002/06/172176/ (дата обращения 04.09.2013)

20.Грекул, В. И., Денищенко, Г. Н., Коровина, Н. JI. Управление внедрением информационных систем. - М.: Бином, 2008. - 224 с.

21.Дитхелм, Г. Управление проектами, т. 1: пер. с нем. - СПб.: Издательский дом «Бизнес-пресса», 2003. -400 с.

22.Иванова, Г. С. Технология проектирования: Учебник для вузов. -М.: Изд-во МГТУ им. Н. Э. Баумана, 2002. - 320 с.

23.Канер, С., Фол к, Дж., Нгуен, Е.К. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений: Пер. с англ. - К.: ДиаСофт, 2001.-544 с.

24.Клиффорд, Ф. Грей, Ларсон, Э. Управление проектами: Практическое руководство, пер. с англ. -М.: Издательство «Дело и Сервис», 2003. -528 с.

25.Ковалев, А. Управление проектом по созданию интернет-сайта. Перевод с английского. М.: Альпина, 2001. - 337 с.

26.Кон, М. Scrum: гибкая разработка ПО. - М.: «Вильяме», 2011. -576 с.

27.Константайн, JL, Локвуд, Л Разработка программного обеспечения, пер. с англ. - СПб: Питер, 2004. - 592 с.

28.Кульдин, С. П. Генетический подход к проблеме оценки трудоемкости и предсказания сроков сдачи программного

обеспечения в эксплуатацию // Современные информационные технологии и ИТ-образование. - М.: 2009. - стр. 114-123.

29.Культин, Н. Б. Управление проектами: инструментальные средства. - СПб.: Политехника, 2002. - 216 с.

30.Лич, JI. Вовремя и в рамках бюджета: Управление проектами по методу критической цепи, пер. с англ. - М: Альпина Паблишер, 2010.-354 с.

31.Локк, Д. Основы управления проектами, пер. с англ. -М.: «HIPPO», 2004. - 253 с.

32.Майерс, Г. Искусство тестирования программ - М.: Финансы и статистика, 1982. - 174 с.

33.Мазур, И.И., Шапиро, В.Д., Ольдерогге, Н.Г. Управление проектами: Учебное пособие для вузов. - М.: ЗАО "Издательство "Экономика", 2001. - 574 с.

34.Михайловский, Н. Сравнение методов оценки стоимости проектов по разработке информационных систем // Публикации NTR Lab [Электронный ресурс] URL http://www.ntrlab.ru/publications/190 (дата обращения 03.09.2013)

35.Орлов, С.А., Цилькер, Б.Я. Технологии разработки программного обеспечения. - СПб: Питер, 2002. - 608 с.

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

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

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

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

40.Полковников, А. В., Дубовик, М. Ф. Внедрение корпоративной системы управления проектами: риски, факторы успеха, выбор

стратегии // Управление проектами и программами, №1, 2006, стр. 11-17

41.Полковников, А.В. ОРМЗ — значительный шаг в направлении развития моделей зрелости управления проектами в организации // Управление проектами и программами, №3, 2007, с. 166-171.

42.Полковникова, Е.В., Полковников, А.В., Планирование и управление проектами с использованием Time Line. - М:Диалог-МИФИ, 1994.-249с

43.Пресняков, В. Основы управления проектами. Учебный курс. [Электронный ресурс] URL: http://www.intmt.ru/ studies/courses/2194/272/info (дата обращения 18.08.2013)

44.Просветов, Г.И. Математические методы в экономике. - М.: Изд-воРДЛ, 2004.-160 с.

45. Разу, М.Л. Управление проектом. Основы проектного управления - М.: КНОРУС, 2006. - 768 с.

46.Ребрин, Ю.И. Основы экономики и управления производством, конспект лекций. - Таганрог: Изд-во ТРТУ, 2000. - 145 с.

47.Сайт компании «Простой бизнес» Управление ресурсами проекта. [Электронный ресурс] URL: http://www.prostoy.ru/23.html (дата обращения: 18 .08.2013).

48.Сайт компании «Технологии управления Спайдер». [Электронный ресурс] URL: http://www.spiderproject.com (дата обращения: 18.08.2013).

49.Сайт компании Microsoft. Microsoft Project [Электронный ресурс] URL: http://www.microsoft.com/project (дата обращения: 18.08.2013).

50.Сайт компании Oracle. Primavera Enterprise Project Portfolio Management [Электронный ресурс] URL: http://www.primavera.com (дата обращения: 18.08.2013).

51.Сайт компании Time Line Solutions. TimeLine [Электронный ресурс] URL: http://www.tlsolutions.com/ (дата обращения: 12.02.2011).

52.Сайт компании Welcome Software. Open Plan [Электронный ресурс] URL: http://www.wst.com (дата обращения: 12.02.2011).

53.Самаров, К. Л. Элементы теории массового обслуживания. -М.: Резольвента, 2009. - 340 с.

54.Скопин, И.Н. Модели жизненного цикла программного обеспечения. // Новосибирская школа программирования. Новосибирск, 2004. - стр. 120-173.

55.Тернер, Дж. Руководство по проектно-ориентированному управлению, пер. с англ. под общ. ред. Воропаева В.И. -М.: Изд. дом Гребенникова, 2007. - 552 с.

56.Троцкий, М., Груча, Б. Управление проектами. - М.: «Финансы и статистика», 2006. - 301 с.

57.Ройс, У. Управление проектами по созданию программного обеспечения. - М:Лори, 2007. - 448 с.

58.Фатрелл, Р. Т., Шафер, Д. Ф., Шафер, Л. И. Управление программными проектами: достижение оптимального качества при минимуме затрат, пер. с англ. - М.: Издательский дом "Вильяме", 2003.-1136 с.

59.Фаулер, М. Новые методологии программирования [Электронный ресурс] URL: http://www.maxkir.com/sd/newmethRUS.html (дата обращения 18.08.2013)

60.Ципес, Г. Л., Товб, А. С. Менеджмент проектов в практике современной компании. - М.: ЗАО «Олимп-Бизнес», 2006. - 304 с.

61.Шелдрейк, Д. Теория менеджмента: от тейлоризма до японизации, пер. с англ. под ред. В. А. Спивака. - СПб: Питер, 2001. - 352 с.

62.Якобсон, А., Буч, Г., Рамбо, Дж. Унифицированный процесс разработки программного обеспечения (RUP). - NY: Addison-Wesley, 2002,492 с.

63.Ahern, D. М., Clouse, A., Turner, R. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. - NY: Addison-Wesley Professional, 2008. - 288 pages.

64.Andersen, E, Grude, K, Haug, T, Turner, J. Goal Directed Project Management. - Kogan Page, 1995. - 253 pages.

65.Badiru, A., Whitehouse, G. Computer Tools, Models and Techniques for Project Management - TAB Professional and Reference Books, 1989.-342 pages.

66.Beizer, B. Software System Testing and Quality Assurance. - NY: Van Nostrand Reinhold, 1984. - 358 pages.

67.Boehm, B. W., Software Cost Estimation with Cocomo II. - Prentice Hall, 2000. - 502 pages.

68.Boehm, B. W., Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed Addison. - NY: Wesley Professional, 2004. -266 pages

69.Caupin, G., Knopfel, H., Koch, G., Pannenbacker, K., ICB - IPMA Competence Baseline. Version 2.0. - Bremen: Eigenverlag, 1999. -230 pages.

70.Caupin, G., Knopfel, H., Koch, G., Pannenbacker K., ICB - IPMA Competence Baseline. Version 3.0. - Bremen: Eigenverlag, 2006. -202 pages.

71.Dymond, K. M., Assessment Coordinator's Handbook: Planning for a Well-Orchestrated Software Appraisal. - Process Transition International, Incorporated, 1997. - 23 pages.

72.Dymond, D. A Guide to the CMMI: Interpreting the Capability Maturity Model Integration, vl.2. - Process Transition International, Inc., 2007.-341 pages.

73.Highsmith, J. A. Agile Software Development Ecosystems. -NY: Addison-Wesley Professional, 2002. - 404 pages.

74.Hooimeijer, P., Weimer, W. Modeling Bug Report Quality // Proc. ASE'07, 2007, Atlanta, Georgia, USA. - p. 34-43.

75.1bbs, W. C., The benefits of Project Management: financial and organizational rewards to corporations - Project Management Institute Education Foundation, 1997. - 347 pages.

76.Kulpa, M. K. International Function Point Users Group IT measurement: practical advice from the experts. - NY: Addison-Wesley, 2002 - 759 pages.

77.KuIpa, M. K., Johnson K. A. Interpreting the CMMI (R): A Process Improvement Approach. - CRC Press, 2008. - 424 pages.

78.Levine, H. A. Project Management Using Microcomputers. - McGraw Hill, 1986.-357 pages.

79.Lynn, C. K., Techniques for Business Process Redesign. - NY: Wiley-IEEE Press, 1995, - 304 pages.

80.Madachy, R. Software Process Dynamics. - NY: Wiley-IEEE Press, 2008. - 601 pages.

81.Meredith, J., Mantel, S., Project Management, Managerial Approach, - NY: Wiley, 1989. - 608 pages.

82.Morris, P. Managing Project Interfaces - Key Points for Project Success, Project Management Handbook, edited by D. Cleland and W. King. - Van Nostrand Reinhold, 1988. - 446 pages.

83.Nawalkha, S. K. Dynamic Term Structure Modeling. - NY: John Wiley & Sons 2007. - 684 pages.

84.Nawalkha, S. K., Soto G.M., Beliaeva, N. K. Interest Rate Risk Modeling: The Fixed Income Valuation Course. - NY: John Wiley & Sons, 2005. - 432 pages.

85.Project Management Institute A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition. - Project Management Institute, 2013. - 589 pages.

86.Robin, A Microsoft Solution Framework White Paper. [Электронный ресурс] URL: http://www.microsoft.com/msf (дата обращения 18.08.2012)

87.Stuckenbruck, L. С. The Implementation of Project Management: The Professional's Handbook. - Addison-Wesley, 1981.- 272 pages.

88.Thuman, J. Development and Implementation of Project Management Systems, Project Management Handbook, edited by D. Cleland and W. King, Van Nostrand Reinhold, 1988. - 606 pages

89.WaIl, A. Project Planning and Control Using Micros. - NCC Publications, 1988. - 456 pages.