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

0030Б4341

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

ПУНТИКОВ Николай Игоревич

МЕТОД ВЫБОРА МОДЕЛИ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО ИЗДЕЛИЯ НА ОСНОВЕ ФОРМАЛИЗАЦИИ ОПИСАНИЯ ПРОСТРАНСТВА ХАРАКТЕРИСТИК ПРОЕКТОВ

Специальность 05 13 01 — системный анализ, управление и обработка

информации

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

0 2 АВГ2007

003064341

Работа выполнена в Санкт-Петербургском институте информатики и автоматизации РАН.

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

кандидат технических наук Морозов Владимир Петрович Официальные оппоненты:

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

Иванович

доктор физико-математических наук,

профессор Терехов Андрей Николаевич

Ведущая организация

Санкт-Петербургский государственный электротехнический университет им. В. И. Ульянова (Ленина)

Защита состоится «11» октября 2007 г. в часов на заседании диссертационного совета Д 002.199.01 при Санкт-Петербургском институте информатики и автоматизации РАН по адресу: 199178, Санкт-Петербург, В.О , 14 линия, 39.

С диссертацией можно ознакомиться в библиотеке Санкт-Петербургского института информатики и автоматизации РАН

Автореферат разослан «13» июля 2007 г

Ученый секретарь

диссертационного совета Д.002.199.01

Ронжин Андрей Леонидович

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

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

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

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

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

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

ПО или близких им по уровню зрелости и специфике разрабатываемых проектов

Основные задачи, решаемые в работе

• Определение функции, описывающей модели процесса разработки ПИ в пространстве характеристик проектов, включающее

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

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

4 задание правила соответствия моделей процессов разработки характеристикам проектов разработки ПИ

• Разработка метода выбора модели процесса разработки ПИ на основе выполненной формализации описания пространства характеристик проектов

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

• Разработка программы, реализующей метод выбора модели процесса разработки ПИ по характеристикам инициируемого проекта Объект исследования. Объектом исследования являются

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

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

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

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

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

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

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

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

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

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

Реализация результатов. Созданная на основе полученных результатов программа, реализующая метод выбора модели процесса разработки ПИ по характеристикам инициируемого проекта, эксплуатируется в ряде компаний-разработчиков программного обеспечения, используется в процессе обучения студентов в дисциплинах, связанных с технологией разработки программною обеспечения Имеются акты внедрения от компаний StarSoft Development Labs, Аурига, а также от

Санкт-Петербургского государственного университета водных коммуникаций.

Апробация работы. Основные положения и результаты диссертационной работы докладывались и обсуждались на X Международной конференции «Региональная информатика 2006» (Санкт-Петербург, Россия, 2006), Второй всероссийской научно-практической конференции по имитационному моделированию и его применению в науке и промышленности «Имитационное моделирование Теория и практика» (Санкт-Петербург, Россия, 2005), IV Международной конференции «Возможности России в области экспорта услуг по разработке программного обеспечения» (Санкт-Петербург, Россия, 2004), IX Международной конференции «Региональная информатика 2004» (Санкт-Петербург, Россия, 2004)

Результаты, выносимые на защиту

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

2 Метод выбора модели процесса разработки ПИ, основанный на формализации описания пространства характеристик проекта

3 Программа, реализующая метод выбора модели процесса разработки ПИ

Публикации. Основные положения диссертации изложены в 5 печатных работах, в том числе 1 работа в журнале из перечня ВАК («Программные продукты и системы»)

Структура работы. Диссертация состоит из введения, 4-х глав, заключения, списка литературы и приложений Диссертация изложена на 129 страницах машинописного текста, содержит 20 таблиц, 16 рисунков, список литературы — 98 наименований, 33 страницы приложений

СОДЕРЖАНИЕ РАБОТЫ

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

Глава первая. Рассматривается концепция проектного процесса в наиболее распространенных стандартах разработки ПО (СММ и ИСО) Определяется наличие этапа выбора модели процесса разработки ПИ в качестве первого шага создания проектного процесса

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

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

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

< М, в, Б, А >. (1)

Здесь М — формализованная модель, описывающая множество допустимых решений/альтернатив (функция, описывающая модели процесса разработки ПИ, используемые в организациях рассматриваемою класса, в пространстве характеристик проектов);

Б — субъект, принимающий решение и ответственный за его последствия (лицо, принимающее решение),

Р — множество исходных отношений предпочтения, задаваемых на множестве допустимых альтернатив,

А — множество правил согласования отношений предпочтения (результирующее отношение предпочтения)

Анализ перечисленных факторов с учетом специфики рассматриваемой проблемы позволил уточнить задачи, решаемые в процессе разработки метода, и его особенности

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

характеристик проектов, которая задается с помощью таблицы (далее функция выбора модели)

Фактор субъект, принимающий решения В рассматриваемом случае субъектом, принимающим решения, является руководитель проекта разработки, те лицо компетентное, имеющее целостное представление об оцениваемом варианте инициируемого проекта, его целостный образ Последний фактор с учетом характера информации, с которой ЛПР имеет дело на этапе инициации проекта, предъявляет к разрабатываемому методу требование максимального учета неформализуемых и/или плохо формализуемых профессиональных знаний ЛПР

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

Таким образом, особенностью разрабатываемого метода является его ориентация на использование неформализуемых и плохо формализуемых профессиональных знаний ЛПР

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

При определении функции выбора модели процесса разработки ПИ в работе использовалась следующая схема анализа материалов

1 Формирование исходных множеств моделей (У) и характеристик (X) путем объединения соответствующих множеств, упомянутых в публикациях

У = {у: (тожедля X)

2 Формирование множеств оригинальных моделей (У) и характеристик (X') на основании анализа элементов исходных множеств (У, X) — множеств, в которых каждому объекту сопоставлено только одно имя У' = {у'. VO'/eY^^6Y') УсУ (то же для X')

3 Формирование множеств используемых моделей (У") и характеристик (X") на основании применения ограничений, которым должны удовлетворять модели (Ку) и характеристики (Кх)

у» = {у"еУ - Ку}, УсУ (то же для X")

4 Формирование правила соответствия между характеристиками проектов разработки ПИ и моделями процесса разработки (осуществляется на основании рекомендаций методик).

(УхеХР) (ЗуеУр) [хБу], ХР сХ", УР сУ"

5 Исследование полученной функции (доопределение, однозначность) (Ухе ХР) (Уу/, у2е УР) [хБу/ л х¥у2 =>угу2]

6 Расширение области определения функции и исследование на однозначность

(Ухе ХР') (Зуе УР) [х¥у], ХР сХР', (Ухе ХР') (УУ!, у[х¥У1 л х¥у2=> угу2]

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

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

Результаты выполнения этапов анализа представлены в табл I

Таблица 1

Изменения множеств моделей и характеристик в ходе анализа

Результаты выполнения этапов Количество элементов в рассматриваемом множестве

модели процессов разработки характеристики проекта

Исходное множество 41 83

Оригинальное множество 26 52

Используемое множество 14 34

Область функции выбора 12 32

Область изменения функции выбора представлена 12-ю моделями классическая каскадная модель, каскадная модель с перекрывающимися процессами, V-образная модель, каскадная модель с подпроцессами, каскадно-возвратная модель, модель ХР, эволюционное прототипирование, экспериментальное прототипирование, модель RAD, пошаговая модель, спиральная модель, сборочное программирование

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

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

Анализ значений характеристик в таблице, задающей функцию выбора (базовые значения), показал возможность расширения области определения функции за счет значений характеристик, являющихся допустимыми для той или иной модели процесса разработки Например, «оригинальность создаваемого изделия» для спиральной модели имеет базовое значение «высокая», однако, ничто не мешает использовать спиральную модель и при средней оригинальности — данное значение характеристики рассматривается как допустимое

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

Формализация описания моделей процесса разработки ПИ в пространстве характеристик обеспечивает необходимые условия для разработки метода выбора модели процесса разработки ПИ

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

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

1 Размерность решаемой задачи не должна превышать возможностей ЛПР в задачах принятия решений — условие, ограничивающее мощность множества объектов, с которыми единовременно может оперировать ЛПР в процессе реализации метода (7±2 блоков, структурных единиц информации)

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

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

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

Опорное множество (S,) — некоторое подмножество характеристик, используемое для оценивания близости инициируемого проекта с проектами, описываемыми таблицей, задающей функцию выбора (эталонными проектами)

Система опорных множеств (Sa) — совокупность опорных множеств, задаваемых из содержательных соображений при определении алгоритма, основанного на вычислении оценок Sa = {S/, S¿ Sz}.

Редукция опорного множества— переход от подмножества характеристик мощностью к к подмножеству характеристик мощностью к—П, где П — шаг редукции

Исходное опорное множество (Si)— опорное множество, из которого путем редукции формируются все опорные множества, в совокупности составляющие систему опорных множеств (Sa)

Класс алгоритмов распознавания, основанных на вычислении оценок (ABO), предложенный Журавлевым Ю И , задается посредством описания шести элементов, его определяющих системы опорных множеств, правила (функции) близости, вычисления оценок по строкам фиксированного опорного множества, вычисления оценки для класса по опорному множеству, оценки для класса по системе опорных множеств и решающего правила

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

соответствующей инициируемому проекту (й)г), и строки, соответствующей

некоторому эталонному проекту таблицы обучения (сог) Возможные определения' строки считаются похожими, если выполняется не менее чем 8 неравенств вида \a.j - ¡3j\ < Sj, J — 1, ..., к Здесь Щ, fíj— значение j-ой характеристики эталонного и инициируемого проектов, £j — порог близости характеристик, 5—порог близости сравниваемых строк (минимальное количество признаков, при совпадении которых строки считаются похожими), к— общее число характеристик, по которым производится сравнение Принятое определение полное совпадение значений всех характеристик эталонного (С0Г) и инициируемого (¿у') проектов в рамках

анализируемого опорного множества (^ = 0, 8— к)

Решающее правило— правило, на основании которого происходит отнесение инициируемого проекта к одной из исследуемых моделей

процесса Возможные определения Г5д(й/, О,) - Г8д(й/, > 7]/, \//,у=1,..., т, max [rsA(ü/, Ü/), rsA(a', Q2),..., rsA(<w', и т д Здесь 7]¡, . — параметр ABO, TsaC^'» Q) — оценка для модели Qr по системе опорных множеств Sa Принятое определение В рассматриваемом случае, когда окончательное решение о выборе модели процесса разработки отдается ЛПР, решающее правило определяется множеством компонентов, поддерживающих это решение К таким компонентам относятся множество рекомендуемых моделей процесса разработки, упорядоченных по убыванию их оценки, дополнительная информация, предоставляемая ЛПР для выбора модели процесса разработки

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

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

Система опорных множеств при наличии ограничений Возможные определения все подмножества множества характеристик {x¡, . , Х32} мощности к (S к,), чибо все непустые подмножества множества характеристик {x¡, . ., Х32} Принятое определение система опорных множеств решаемой задачи представляет собой множество подмножеств с последовательно уменьшающейся мощностью от к до к—п Здесь к — мощность исходного опорного множества, п — число шагов редукции,

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

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

TsA{{o\nq) = —j- (2)

zq Z<H ©,еп9

Здесь zq, Zq.¡ — номер последнего проекта, представляющего текущую и предшествующую модели процесса разработки, соответственно,

У's¡ú) — коэффициент, характеризующий значимость в опорном множестве s, проекта co¡,

р(ú)j, со') — число выполненных равенств значений характеристик для пары (Щ, й/);

k — мощность рассматриваемых опорных множеств

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

оценка модели Q? по системе опорных множеств будет

1 "

rsA(ó)',nq) =---X ю') (3)

Zq Zq-1 ,=1 a)¡

Алгоритм формирования множества рекомендуемых моделей процесса разработки (алгоритм вычисления оценок) предстает в виде

1 Определение количества выполненных равенств для значений характеристик эталонного и инициируемого проектов, принадлежащих исходному опорному множеству (S|)— мощности опорных множеств (kj), начиная с которые для исследуемых пар (су, со*) будет выполняться правило близости

2 Ранжирование моделей процесса разработки (Q.q) в порядке убывания величины (kj)

3 Определение системы опорных множеств (Sa), обеспечивающей решение задачи Sa включает множество всех подмножеств опорных

13

множеств, начиная от мощности к\ до мощности включительно Здесь к\ — мощность исходного опорного множества (81), к] — наибольшая мощность опорного множества упорядоченного списка, А, — мощность опорного множества списка, ближайшая к значению кь удовлетворяющая неравенству к} <к/

4 Определение множества рекомендуемых моделей определяется как подмножество множества ранжированных моделей (см п 2), мощность опорных множеств которых не превышает величину к

5 Вычисление по формуле 4 оценок рекомендуемых моделей по системе опорных множеств Эд.

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

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

8 Формирование справочной информации о выбранных моделях процесса разработки, их достоинствах и недостатках

9 Завершение работы

Структурная схема метода выбора модели процесса разработки ПИ на основе формализации описания пространства характеристик проектов представлена на рис 1

Как видно из рисунка, метод выбора модели процесса разработки ПИ включает этапы

1 Задание множества характеристик, наиболее полно описывающих специфику инициируемого проекта Характеристики выбираются ЛПР исключительно из множества характеристик, определенных в области задания функции выбора модели процесса разработки 2. Анализ полученного множества на однозначность представления моделей процесса разработки в соответствующем пространстве характеристик

♦ множество обеспечивает однозначный выбор всех моделей процесса разработки, переход к пункту 5,

♦ множество не обеспечивает однозначный выбор всех моделей процесса разработки, переход к пункту 3

♦

Задание характеристик,

определяющих инициируемый проект (исходного опорного множества — ИОП)

Завершение работы

Рис. 1. Структурная схема метода выбора модели процесса разработки.

3 Формирование диагностического сообщения

4 Редактирование исходного множества (ввод/удаление характеристик) Переход к пункту 2

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

6 Формирование множества рекомендованных моделей процесса разработки и дополнительной информации, поддерживающей принятие решений ЛПР

7. Просмотр ЛПР множества рекомендованных моделей и анализ результатов просмотра

♦ Модель процесса разработки выбрана, переход к пункту 9

♦ Среди предложенных вариантов, не оказалось модели, удовлетворяющей представлениям пользователя о специфике инициируемого проекта, переход к пункту 8

8 Анализ дальнейших намерений ЛПР

♦ Продолжить выбор модели, переход к пункту 1

♦ Отложить выбор модели, переход к пункту 9

9 Завершение работы

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

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

Приводится описание системы АРПП, позволяющей на данном этапе решить проблему автоматизации выбора модели процесса разработки ПИ

Система ориентирована на работу с пользователем, имеющим представление о разработке и реализации проектных процессов

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

Схема технологии работы в системе АРПП представлена на рис 2

Рис. 2. Схема технологии работы в системе АРПП.

Работа в системе рассматривается на примере выбора модели процесса разработки для проекта Jamba Clips' Приводится перечень проектов, при выборе модели процесса разработки которых, использовалась система АРПП (в компании StarSoft Development Labs система используется с января 2006 года) Рекомендации системы совпадают с рекомендациями наиболее опытных экспертов компании Успешность проектов подтвердила правильность выбранных моделей процесса разработки

ЗАКЛЮЧЕНИЕ

Результаты, полученные в диссертационной работе, позволили автоматизировать решение задачи выбора модели процесса разработки ПИ и реализовать, таким образом, первый 3täi1 ав!бмаТИзаЦИИ созданий проектных процессов разработки ПО Эксплуатация системы АРПП, созданной на основе метода, предложенного в работе, подтвердила его правильность и эффективность

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

пространстве характеристик проектов Функция задана в виде таблицы. В ходе определения функции

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

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

♦ определено правило соответствия моделей процессов разработки характеристикам проекта разработки ПИ

2 На основе выполненной формализации описания моделей разработки в пространстве характеристик проектов разработан метод выбора модели процесса разработки ПИ С учетом специфики решаемой задачи сформулированы требования к методу (ориентация на неформапизуемые и/или плохо формализуемые профессиональные знания ЛПР) и средства, позволяющие эти требования реализовать (постепенная детализация предметной информации, ограничения на сложность операций по переработке информации, осуществляемой ЛПР, интуитивная понятность используемых алгоритмов)

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

4. В рамках системы автоматизации разработки проектного процесса «АРПП» осуществлена программная реализация метода выбора модели процесса Система АРПП может функционировать как в составе системы корпоративного управления проектами STAR Tack, так и автономно Результаты эксплуатации системы в компании StarSoft Development Labs подтвердили совпадение рекомендаций системы с рекомендациями наиболее опытных экспертов компании Как показала практика, система может быть использована в качестве тренажера для повышения квалификации пользователей, связанных с проблемами создания и организации проектных процессов разработки ПИ

Цели, поставленные в начале исследования, в ходе выполнения

работы были достигнуты Решение задачи автоматизации выбора модели

процесса разработки ПИ закладывает основы для успешного решения

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

ОСНОВНЫЕ ПОЛОЖЕНИЯ ДИССЕРТАЦИИ ОПУБЛИКОВАНЫ

В РАБОТАХ

В рецензируемых журналах из списка ВАК'

1 Пунтиков, Н И Определение проектного процесса в организациях, разрабатывающих программные изделия / В П Морозов, Н И Пунтиков//Программные продукты и системы —2005 —№1 — С 6-9

В других изданиях-

2 Пунтиков, Н И Процедуры настройки стандартного процесса разработки программного изделия на реальный проект /НИ Пунтиков // Труды IX Санкт-Петербургской Международной Конференции «Региональная информатика-2004» («РИ-2004»), Санкт-Петербург, 2224 июня 2004 г / СПб Наука —2005 —С 262-268

3 Пунтиков, Н И Система управления проектами STAR Track / Н И Пунтиков // Труды IX Санкт-Петербургской Международной Конференции «Региональная информатика-2004» («РИ-2004»), Санкт-Петербург, 22-24 июня 2004 г / СПб Наука — 2005 — С 269-273

4 Пунтиков, Н И Настройка стандартного процесса организации на реальный проект разработки программного изделия / В П Морозов, Н И Пунтиков // Труды СПИИРАН / СПб Наука, 2005 — Вып. 2 — Т 2 — С 119-123

5 Puntikov, N Distributed Serum Agile Project Management with Outsourced Development Teams / J Sutherland, A Viktorov, J Blount, N Puntikov // 40th Annual Hawan International Conference on System Sciences (HICSS'07), 2007 — p 274-284

Отпечатано в типографии «Микроматикс» Большой пр В О., д. 55, тел 328-52-63 Подписано в печать 13 07.2007, тираж 100 экз , формат 210X148,5

СПИСОК СОКРАЩЕНИЙ.

ВВЕДЕНИЕ.

ГЛАВА 1. АНАЛИЗ ПОДХОДОВ К СОЗДАНИЮ ПРОЕКТНЫХ ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНЫХ ИЗДЕЛИЙ.

1.1. Концепция построения проектных процессов.

1.1.1. Концепция построения проектных процессов в модели СММ.

1.1.2. Концепция построения проектных процессов в стандартах серии ISO.

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

1.3. Выводы.

ГЛАВА 2. ОПИСАНИЕ МОДЕЛЕЙ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНЫХ ИЗДЕЛИЙ В ПРОСТРАНСТВЕ ХАРАКТЕРИСТИК ПРОЕКТОВ.

2.1. Определение множества моделей процесса разработки.

2.2. Определение множества характеристик проекта.

2.3. Функция выбора модели процесса разработки.

2.4. Выводы.

ГЛАВА 3. РАЗРАБОТКА МЕТОДА ВЫБОРА МОДЕЛИ ПРОЦЕССА ПО ХАРАКТЕРИСТИКАМ ИНИЦИИРУЕМОГО ПРОЕКТА.

3.1. Метод выбора модели процесса разработки.

3.2. Алгоритм формирования рекомендуемого множества моделей

3.2.1. Правило близости.

3.2.2. Решающее правило.

3.2.3. Формирование системы опорных множеств.

3.2.4. Вычисление оценок.

3.2.5. Алгоритм вычисления оценок.

3.3. Выводы.

ГЛАВА 4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ МЕТОДА ВЫБОРА МОДЕЛИ ПРОЦЕССА РАЗРАБОТКИ.

4.1. Система корпоративного управления проектами STAR Track.

4.2. Система автоматизации разработки проектного процесса.

4.2.1. Назначение системы.

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

4.2.3. Технология работы в системе.

4.2.4. Пример работы в системе.

4.3. Выводы.

Актуальность темы

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

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

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

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

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

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

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

Основные задачи, решаемые в работе:

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

• разработка метода выбора модели процесса разработки ПИ на основе выполненной формализации описания пространства характеристик проектов;

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

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

Объект исследования

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

Предмет исследования

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

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

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

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

2. Разработан метод выбора модели процесса разработки ПИ. Метод ориентирован на вовлечение в процесс решения неформализуемых и/или плохо формализуемых предметных знаний пользователя. Особенностями 7 метода являются постепенная детализация информации, запрашиваемой и предлагаемой для анализа пользователю в процессе решения задачи; ориентация на операции по переработке информации, доступные человеку по сложности; использование алгоритма формирования множества решений, интуитивно понятного лицу, принимающему решение. 3. Разработан алгоритм формирования множества рекомендуемых моделей процесса разработки, принадлежащий классу алгоритмов распознавания, основанных на вычислении оценок. Особенностями алгоритма являются использование множества рекомендуемых моделей в качестве конечного результата; использование редукции как способа формирования системы опорных множеств, гарантирующей формирование множества моделей; отказ от использования весовых коэффициентов, как средства выявления приоритетов лица, принимающего решение. Теоретическая значимость

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

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

Созданная на основе полученных результатов программа, реализующая метод выбора модели процесса разработки ПИ по характеристикам 8 инициируемого проекта, эксплуатируется в ряде компаний-разработчиков программного обеспечения, используется в процессе обучения студентов в дисциплинах, связанных с технологией разработки программного обеспечения. Имеются акты внедрения от компаний StarSoft Development Labs, Аурига, а также от Санкт-Петербургского государственного университета водных коммуникаций.

Апробация работы

Основные положения и результаты диссертационной работы докладывались и обсуждались на X Международной конференции «Региональная информатика 2006» (Санкт-Петербург, Россия, 2006), Второй всероссийской научно-практической конференции по имитационному моделированию и его применению в науке и промышленности «Имитационное моделирование. Теория и практика» (Санкт-Петербург, Россия, 2005), IV Международной конференции «Возможности России в области экспорта услуг по разработке программного обеспечения» (Санкт-Петербург, Россия, 2004), IX Международной конференции «Региональная информатика 2004» (Санкт-Петербург, Россия, 2004).

Результаты, выносимые на защиту

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

2. Метод выбора модели процесса разработки ПИ, основанный на формализации описания пространства характеристик проекта.

3. Программа, реализующая метод выбора модели процесса разработки ПИ. Публикации

Основные положения диссертации изложены в 5 печатных работах, в том числе 1 работа в журнале из перечня ВАК («Программные продукты и системы»).

Структура работы

Диссертация состоит из введения, 4-х глав, заключения, списка литературы и приложений. Диссертация изложена на 129 страницах машинописного текста, содержит 20 таблиц, 16 рисунков, список литературы— 98 наименований, 33 страницы приложений.

4.3. Выводы

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

2. Эксплуатация системы подтвердила правильность заложенных в нее положений. Рекомендации системы совпадают с рекомендациями наиболее опытных экспертов организации. Интуитивно понятный интерфейс сокращает время ее освоения.

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

4. Система реализована в рамках системы корпоративного управления проектами STAR Track и используется на этапе инициации проекта. Система может эксплуатироваться как в составе STAR Track, так и автономно. Язык реализации — Visual Basic for Applications.

ЗАКЛЮЧЕНИЕ

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

К основным результатам диссертационной работы следует отнести:

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

2. На основе выполненной формализации описания моделей разработки в пространстве характеристик проектов разработан метод выбора модели процесса разработки ПИ. С учетом специфики решаемой задачи сформулированы требования к методу (ориентация на неформализуемые и/или плохо формализуемые профессиональные знания ЛПР) и средства, позволяющие эти требования реализовать (постепенная детализация предметной информации, ограничения на сложность операций по переработке информации, осуществляемой ЛПР, интуитивная понятность используемых алгоритмов).

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

4. В рамках системы автоматизации разработки проектного процесса «АРПП» осуществлена программная реализация метода выбора модели процесса. Система АРПП может функционировать как в составе системы корпоративного управления проектами STAR Tack, так и автономно. Результаты эксплуатации системы в компании StarSoft Development Labs подтвердили совпадение рекомендаций системы с рекомендациями наиболее опытных экспертов компании. Как показала практика, система может быть использована в качестве тренажера для повышения квалификации пользователей, связанных с проблемами создания и организации проектных процессов разработки ПИ.

Цели, поставленные в начале исследования, в ходе выполнения работы были достигнуты. Решение задачи автоматизации выбора модели процесса разработки ПИ закладывает основы для успешного решения проблемы автоматизации разработки проектного процесса в целом.

1. Модель зрелости процессов разработки программного обеспечения -Capability Maturity Model for Software (СММ) / M. Паулк и др...— М.: Богородский печатник, 2002. — 256 с.

2. Стандарты для ИТ-индустрии / Компьютер Информ. — 2002. — №2.

3. Деминг, Э. Выход из кризиса / Э. Деминг. — Тверь: Альба, 1994. — 498 с.

4. Нив, Г. Пространство Деминга. В 2 кн. Кн.1. / Г. Нив; общ. ред. Ю. Т. Рубаника, 10. П. Адлера. М.: Госкомитет по высшему образованию, 1996, —344 с.

5. Paulk, М. С. An Executive Introduction to СММ— Based Software Process Improvement 1 Nov 1999 Carnegie Mellon University Software Engineering Institute Электронный ресурс. / M. С. Paulk. — Режим доступа: http://www.sei.cmu.edu.

6. Абарыков, А., Сапрыкина, H. Через ISO 9001:2000 к зрелости no SW-CMM Электронный ресурс. / А. Абарыков, Н. Сапрыкина. — Режим доступа:http://www.adj.ru.

7. Paulk, M. С. How ISO 9001 Compares With CMM IEEE Software / M. Paulk Электронный ресурс. // 1995.— January.— PP. 74-83.— Режим доступа: http://www.sei.cmu.edu.

8. Paulk, M. C. Extreme Programming from a CMM Perspective IEEE Software / M. C. Paulk//2001. — №6. — Vol. 18. PP. 19-26.

9. Paulk, M. C. Using the Software CMM in Small Organizations / M. Paulk Электронный ресурс. // Режим доступа: http: / /www. sei. emu. edu.

10. Процесс разработки программных изделий / С.Н.Баранов и др..— М.: Наука, Физматлит, 2000. — 176 с.

11. Домарацкий, А. Н. Управление улучшением стандартного процесса и качеством программных изделий / А. Н. Домарацкий // Программные продукты и системы. — 1998. — № 4. — С. 20-24.

12. Пунтиков, Н. И. Определение проектного процесса в организациях, разрабатывающих программные изделия / В. П. Морозов, Н. И. Пунтиков // Программные продукты и системы. — 2005. — №1. — С. 6-9.

13. Стандарты ISO общие замечания. Сайт компании Adjust Media QM Consulting Электронный ресурс. / Режим доступа: http: //www. adj. ru/index. php?lang=rus&link=library//iso9000.

14. ГОСТ P ИСО/МЭК 12207-99 ИТ. Процессы жизненного цикла программных средств.

15. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504-СММ) / М.: Книга и бизнес, 2001. — 348 с.

16. Липаев, В. В. Технологические процессы и стандарты обеспечения функциональной безопасности в жизненном цикле программных средств / В. В. Липаев // Jet Info Информационный бюллетень. — 2004. — №3 (130).

17. Богданов, Д. В. Стандартизация процессов обеспечения качества программного обеспечения / Д. В. Богданов, В. А. Путилов, В. В. Фильчаков. —Апатиты.: КФ ПетрГУ, 1997. — 152 с.

18. Липаев, В. В. Качество программных средств / В. В. Липаев. — М.: Янус-К, 2002. —370 с.

19. Терехов, А. Современные модели качества программного обеспечения BYTE / А. Терехов, В. Туньон // Россия. — 1999. — №12.

20. Баранов, С. Н. Автоматизация процесса управления проектом программных изделий / С. Н. Баранов и др.// Программные продукты и системы. — 1998. — №4 — С. 46-48.

21. Боэм, Б. У. Инженерное проектирование программного обеспечения / Б. У. Боэм. — М.: Радио и связь, 1985. — 512 с.

22. Ройс, У. Управление проектами по созданию программного обеспечения. Унифицированный подход / У. Ройс. — М.: «ЛОРИ», 2002. — 424 с.

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

24. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. — М.: Бином, 1999. — 560 с.

25. Кантор, М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения / М. Кантор. — М.: Издательский дом «Вильяме», 2002. — 176 с.

26. Родыгин, А. Процесс разработки или .разрабатываем процесс! Электронный ресурс. / А. Родыгин. — Режим доступа: http://www.citforum.ru/programming/theory/devprocess.shtml.

27. Пройдаков, Э. Залог успеха— в быстрой разработке приложений / Э. Пройдаков, А. Ливеровский // PCWeek. — 1998. —№8

28. Вендров, А. М. CASE-технологии. Современные методы и средства проектирования информационных систем / А. М. Вендров. М.: Финансы и статистика, 1998. — 176 с.

29. Вендров, А. М. Современные технологии создания программного обеспечения (обзор) / А. М. Вендров // Jet Info Информационный бюллетень. — 2004. —№4(131). —32 с.

30. Коберн, А. Быстрая разработка программного обеспечения / А. Коберн. — М.: ЛОРИ, 2002. —314 с.

31. Хайсмит, Д. Устаревшие методологии — на пенсию! Электронный ресурс. / Д. Хайсмит.— Режим доступа: http://asmodeus.com.ua/library/progr/ projects/projectsdev.htm.

32. Puntikov, N. Distributed Scrum: Agile Project Management with Outsourced Development Teams / J. Sutherland, A. Viktorov, J. Blount, N. Puntikov // 40th Annual Hawaii International Conference on System Sciences (HICSS'07) / 2007. — P. 274-284.

33. Пунтиков, Н. И. Настройка стандартного процесса организации на реальный проект разработки программного изделия / В. П. Морозов, Н. И. Пунтиков // Труды СПИИРАН / СПб.: Наука, 2005. — Вып. 2. — Т. 2. — С. 119-123.

34. Терехов, А. Н. Опыт разработки и использования промышленной технологии программирования / А. Н. Терехов. — Л.: ЛГУ, 1990.

35. Соммервилл, И. Инженерия программного обеспечения / И. Соммервилл. — М.: Издательский дом «Вильяме», 2002. — 624 с.

36. Одинцов, И. О. Профессиональное программирование. Системный подход / И. О. Одинцов. — СПб.: БХВ-Петербург, 2004. — 624 с.

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

38. Орлов, С. А. Технология разработки программного обеспечения. Учебник для вузов / С. А. Орлов. — СПб.: Питер, 2004. — 527 с.

39. Volodin, М. A. Customization Guidelines Process version 2.4 / M. A. Volodin. — SPb.: StarSoft Development Labs, 2003. — 7 p.

40. Volodin, M. A. Software process policies. Process version 2.4 / M. A. Volodin. — SPb.: StarSoft Development Labs, 2003. — 26 p.

41. Volodin, M. A. Development processes. Process version 2.4 / M. A. Volodin. — SPb.: StarSoft Development Labs, 2003. — 12 p.

42. Ларичев, О. И. Теория и методы принятия решений / О. И. Ларичев. — М.: Логос, 2006. — 392 с.

43. Черноруцкий, И. Г. Методы принятия решений / И. Г. Черноруцкий. — СПб.: БХВ-Петербург, 2005. — 416 с.

44. Емельянов, С. В. Многокритериальные методы принятия решений / С. В. Емельянов, О. И. Ларичев. — М.: Знание, 1985. — 32 с.

45. Фрумкина, P.M. Экспертные оценки (вопросы кибернетики) / Р. М. Фрумкина // Фрумкина Р. М. О некоторых особенностях экспертного понимания (на материалах экспертных оценок психических состояний). — М.: ВИНИТИ, 1979.

46. Микони, С. В. Теория и практика рационального выбора / С. В. Микони. — М.: Маршрут, 2004. — 436 с.

47. Морозов, В. П. Программные системы, ориентированные на привлечение знаний экспертов в процессе решения задач / В. П. Морозов // Программные продукты и системы. — 2001. — №1. — С. 33-35.

48. Математическая энциклопедия / Гл. ред. И.М.Виноградов.— М.: Советская Энциклопедия, 1984. — Т.4. — С. 872-873.

49. Энциклопедия кибернетики. / Гл. ред. В.М. Глушков. Киев: Гл. редакция украинской советской энциклопедии, 1974. — Т. 2. 619 с.

50. Бек, К. Экстремальное программирование / К. Бек. — СПб.: Питер, 2002. — 224 с.

51. Бек, К. Экстремальное программирование: Планирование / К. Бек, М. Фаулер. — СПб.: Питер, 2003. — 144 с.

52. Royce, W. W. Managing the development of large software system: concepts and techniques / W. W. Royce // In. Proc. IEEE WESTCON. Los Angeles. — 1970. — August. —PP. 1-9.

53. Mills, H. D. The management of software engineering / H. D. Mills, D. O'Neill, et al // IBM Sys.J. — 1980. — № 24(2) —. P. 414^93.

54. Millington, D. Special report: developing a RAD Standard / D. Millington, J. Stapleton//IEEE Software. — 1995. — № 12(1). —P. 85-180.

55. Beck. "Extreme Programming: A Humanistic Discipline of Software Development" / Beck, Kent // FASE. Lisbon, Portugal, part of ETAPS. — 1998.

56. Gordon, V. S. Rapid prototyping: lessons learned / V.S.Gordon, J. Bieman // IEEE Software. — 1995. — № 12(5). — PP. 54-60.

57. Boehm, B. W. A spiral model of software development and enhancement / B. W. Boehm //IEEE Computer. — 1988. — № 21(5). — PP. 61-133.

58. Szyperski, С. Component Software: Beyond Object-Oriented Programming / C. Szyperski // MA: Addison-Wesley. — 1988.

59. Воробьев, В. И. Метрики для объектно-ориентированного проектирования сложных систем / В. И. Воробьев, С. В. Афанасьев // Вестник гражданских инженеров. —2005. — N4.

60. Boehm, В. СОСОМО II Model Definition Manual— Computer Science Dept / B. Boehm. — University of Southern California, 1997.

61. Липаев, В. В. Технико-экономическое обоснование проектов сложных программных средств / В. В. Липаев. — М.: СИНТЕГ, 2004. — 284 с.

62. Пфанцагль, И. Теория измерений / И. Пфанцагль. — М.: Мир, 1976. — 248 с.

63. Горелик, А. Л. Методы распознавания / А. Л. Горелик, В. А. Скрипкин. — М.: Высшая школа, 2004. — 261 с.

64. Кладки, Р. Память человека: структуры и процессы / Р. Клацки. — М.: Мир, 1970. —216 с.

65. Козлецкий, Ю. Психологическая теория решений / 10. Козлецкий: пер. с польск. —М.: Прогресс, 1979. — 504 с.

66. Горелик, А. Л. Современное состояние проблемы распознавания: Некоторые аспекты / А. Л. Горелик, И. Б. Гуревич, В. А. Скрипкин. — М.: Радио и связь, 1985. — 160 с.

67. Александров, В. В. Анализ данных на ЭВМ (на примере системы СИТО) / В. В. Александров, А. И. Алексеев, Н. Д. Горский. — М.: Финансы и статистика, 1990. — 192 с.

68. Васильев, В. И. Распознающие системы: Справочник / В.И.Васильев.— Киев: Наукова думка, 1983. — 230 с.

69. Барабаш, Ю. Л. Вопросы статистической теории распознавания / Ю. Л. Барабаш и др.. — М.: Советское радио, 1967. — 400 с.

70. Вапник, В. Н. Теория распознавания образов / В. Н. Вапник, Я. А Червоненкис. — М.: Наука, 1974. — 415 с.

71. Дуда, Р. Распознавание образов и анализ сцен / Р. Дуда, П. Харт.— М.: Мир, 1978. —510 с.

72. Дюк, В. А. Компьютерная психодиагностика / В. А. Дюк. — СПб.: Братство, 1994. —365 с.

73. Компьютер и задачи выбора / Автор предисл. Ю. И. Журавлев. — М.: Наука,1989, —208 с.

74. Патрик, Э. Основы теории распознавания образов / Э.Патрик.— М.: Сов. радио, 1970. —408 с.

75. Айзерман, М. А. Метод потенциальных функций в теории обучения машин / М. А. Айзерман, Э. М. Браверманн, Л. И. Розоноэр. — М.: 1970. — 236 с.

76. Дж.-О., К. Факторный, дикриминантный и кластерный анализ / Ким Дж.-О., Ч. У. Мьюллер, У. Р. Клекка. — М.: Финансы и статистика, 1989. — 215 с.

77. Фукунага, К. Введение в статистическую теорию распознавания образов / К. Фукунага. — М.: Наука, 1979. — 368 с.

78. Журавлев, 10. И. Непараметрические задачи распознавания образов / Ю. И. Журавлев // Кибернетика. — 1976. — № 6. — С. 93-103.

79. Журавлев, Ю. И. Об алгебраическом подходе к решению задач распознавания и классификации / Ю. И. Журавлев // Проблемы кибернетики. — М.: Наука, 1978. — Вып. 33. — С. 5-68.

80. Журавлев, Ю. И. Распознавание образов и анализ изображений: Искусственный интеллект. В 3 кн. Кн. 2 Модели и методы: справочник / Ю. И. Журавлев, И. Б. Гуревич; под ред. Д. А. Поспелова. — М.: Радио и связь,1990. —304 с.

81. Журавлев, Ю. И. Алгоритмы распознавания, основанные на вычислении оценок / Ю. И. Журавлев, В. В. Никифоров // Кибернетика. — 1971. — №3. — С. 1-11.

82. Лбов, Г. С. Логические функции в задачах эмпирического предсказания / Г. С. Лбов // Эмпирическое предсказание и распознавание образов: Вычислительные системы. — 1978. — Вып. 76. — С. 34-64.

83. Фу, К. Структурные методы в распознавании образов / К. Фу. — М.: Мир, 1977. —320 с.

84. Колесов, А. К вопросу о выборе инструментов разработки. BYTE /

85. A. Колесов Электронный ресурс. // Россия. — 2006. — №7-8. — Режим доступа: http://www.bytemag.ru/?ID=622452.

86. Лесин, Д. A. RATIONAL— 2004. Обзор программных пакетов от IBM Rational Электронный ресурс. / Д. А. Лесин // Режим доступа: http://www.citforum.ru/products/rational/rational2004/.

87. Маклаков, С. В. Создание информационных систем с AllFusion Modeling Suite / С. В. Маклаков. — М.: ДИАЛОГ-МИФИ, 2003. — 432 с.

88. Драница, А. Третья мировая война / А. Драница Электронный ресурс. // Бумажная Компьютера.— 2004.— №5(529)— Режим доступа: http://www.kinnet.ru/cterra/529/3207 6.html.

89. Корпорация Oracle презентовала среду разработки Oracle9i Developer Suite Электронный ресурс. / Режим доступа: http://www.cnews.ru/news/line/index.shtml72002/05/28/131310.

90. Пунтиков, Н. И. Методология построения модели стандартного процесса организации, разрабатывающей программные изделия / А. В. Иконникова,

91. B. П. Морозов, Н. И. Пунтиков // Труды Второй всероссийской научно-практической конференции по имитационному моделированию и его применению в науке и промышленности «Имитационное моделирование.

92. Теория и практика», Санкт-Петербург, 19-21 октября 2005 года / СПб.: ФГУП ЦНИИТС, 2005. — Т. 2. — С. 113-114.

93. Пунтиков, Н. И. Система управления проектами STAR Track / Н. И. Пунтиков // Труды IX Санкт-Петербургской Международной Конференции «Региональная информатика-2004» («РИ-2004»), Санкт-Петербург, 22-24 июня 2004 года / СПб.: Наука, 2005. — С. 269-273.

94. Хабрейкен, Дж. Microsoft Office 2003: Word, Excel, Access, PowerPoint, Publisher, Outlook. / Хабрейкен, Дж. — M.: Издательский дом «Вильяме», 2006. — 864 с.

95. Блаттнер, П. Использование Microsoft Office Excel 2003 / П. Блаттнер. — М.: Издательский дом «Вильяме», 2004. — 864 с.

96. Гетц, К. Программирование в Microsoft Office. Полное руководство по VBA / К. Гетц, М. Джилберт. — К.: Издательская группа BHV, 1999. — 768 с.

97. Гарнаев, A.IO. VBA / А. 10. Гарнаев. — СПб.: БХВ-Петербург, 2005. — 848 с.