Содержание к диссертации
Введение
Глава 1. Исследование моделирования оценки стоимости программных проектов 9
1.1. История развития моделирования оценки стоимости программных проектов 9
1.2. Основные направления оценки стоимости 12
1.2.1. Модель SLIM 13
1.2.2. Модель Checkpoint 15
1.2.3. Модель SEER 17
1.2.4. Модель СОСОМО 18
1.2.5. Методика Госкомтруда 19
1.2.5. Модель Delphi 21
1.2.6. Оценка по структуре работ 22
1.2.7. Case модель 23
1.2.8. Нейронные сети 24
1.2.9. Динамические модели 25
1.2.9. Регрессионные модели 27
1.2.10. Композитные техники 28
1.3. Сравнительный анализ методов оценки стоимости 29
1.4. Программная реализация моделей оценки стоимости 33
1.4.1. SLIM Tools 33
1.4.2. KnowledgePlan и Charismatek's Function Point WORKBENCH (FPW) 35
1.4.3. Cost XPert 36
1.4.4. Borland CaliberRM 37
1.4.5. Другие программные продукты оценки стоимости 38
1.5. Сравнительный анализ программных продуктов, предназначенных для оценки стоимости программного проекта 42
Выводы по главе 1 48
Глава 2. Проектирование системы оценки стоимости программного проекта 49
2.1. Задачи, решаемые системой оценки стоимости 49
2.2. Описание модели СОСОМО П 51
2.2.1. Общее описание модели 51
2.2.2. Способы оценки размера программного кода 52
2.2.2.1. Объектные точки 52
2.2.2.2. Строки кода 54
2.2.2.3. Функциональные точки 55
2.2.3. Факторы влияния на проект в СОСОМО П и уравнение модели на разных тапах 58
2.3. Пути улучшения моделей оценки стоимости 65
2.3.1. Разработка новой модели 65
2.3.2. Добавление новых факторов в модель 67
2.3.3. Калибровка модели 71
2.4. Проверка и корректировка модели СОСОМО П. 75
2.5. Исследование структуры и состава информационных потоков 85
2.5.1. Информационная модель 85
2.6. Программное обеспечение задачи 95
2.6.1. Общие положения (дерево функций и сценарий диалога) 95
2.6.1.1. Функции подсистемы разграничения доступов 96
2.6.1.2. Функции подсистемы хранения и анализа 96
2.6.1.3. Функции подсистемы справочников 97
2.6.1.4. Функции подсистемы настройки 97
2.6.1.5. Функции подсистемы оценки стоимости 98
2.6.1.6. Функции подсистемы калибровки 98
2.6.1.7. Сценарий диалога системы 99
2.6.2. Особенности программного продукта 106
Выводы по главе 2 109
Глава 3. Практическое применение системы оценки стоимости 110
3.1. Пример расчета оценки стоимости программного проекта с помощью моделей СОСОМО П и COCOMO-PJ ПО
3.2. Расчет оценки стоимости программного проекта с помощью системы оценки стоимости 123
3.3. Расчет экономической эффективности и результаты внедрения проекта 128
Выводы по главе 3 144
Заключение 145
Список использованных источников. 148
- История развития моделирования оценки стоимости программных проектов
- Сравнительный анализ программных продуктов, предназначенных для оценки стоимости программного проекта
- Факторы влияния на проект в СОСОМО П и уравнение модели на разных тапах
- Расчет оценки стоимости программного проекта с помощью системы оценки стоимости
Введение к работе
В эпоху быстро развивающихся информационных технологий, растущего числа высоко бюджетных проектов в области разработки программного обеспечения, очень важным становится умение оценить на ранних этапах возможные выгоды и убытки от проекта, проанализировать возможные сценарии развития событий. Ошибка, недооценка сложностей, с которыми предстоит столкнуться в процессе разработки, переоценка сил команды, просто непринятие в расчет тех или иных факторов, часто приводит к многомиллионным потерям, и даже банкротству компаний. По статистике примерно четверть всех начатых проектов завершается своевременно, четверть отменяется, и около половины всех проектов завершается с превышением бюджетных затрат или с опозданием. Согласно ежегодно публикуемому обзору группы The Standish Group в среднем превышение сроков составляет порядка 120%, а затрат — около 100%. Реальная оценка может быть еще менее оптимистичной, так как у части завершенных с превышением сроков и стоимости проектов оказались частично урезаны функции, описанные в первоначальном проекте.
В таблице 1 [22] приведена информация по наиболее серьезным ошибкам оценки, приведшим к закрытию проектов.
непродуманные и необоснованные оценки, незнание предметной области, упрощение оценки при передаче ее на верхние уровни управления, отсутствие единого механизма оценки стоимости. Последнее является важной проблемой, особенно для крупных предприятий, где количество больших проектов может достигать более сотни в год. Для выполнения корректной оценки требуется высококлассный специалист, которого на предприятии может не быть, или же который не в состоянии оценить затраты по всем проектам Необходимо получить такой инструмент, который бы позволял производить точные оценки даже начинающему менеджеру. Причем для предприятия, использующего современные информационные технологии в своей работе, существенно, чтобы инструмент был частично или полностью автоматизирован.
Первоочередную задачу — получение точных оценок путем несложных расчетов, доступных начинающему менеджеру, позволяет решить механизм построения модели оценки стоимости. Модель оценки стоимости — это математический алгоритм, используемый для того, чтобы оценить стоимость продукта или проекта.
Можно выделить следующие случаи, в которых может потребоваться использование модели оценки стоимости [22]:
• требуется определить, делать ли инвестиции, или принять иные финансовые решения, касающиеся разработки программного продукта;
• необходимо осуществлять процесс контроля за бюджетом и расписанием проекта. Например, могут потребоваться такие оценки: сколько людей требуется привлечь к выполнению проекта на той или иной его стадии, а также сколько денежных и трудовых затрат потребуется, чтобы достигнуть главных целей проекта;
• надо принять решение, чем стоит пожертвовать в данной ситуации -денежными затратами, временем, функциональностью, интерфейсом или качеством. Это важно, например, если надо определиться, что будет дешевле и выгоднее - разработать недорогую или же полнофункциональную, отвечающую всем стандартам качества программную систему;
• если принимаются решения относительно рисков, связанных со стоимостью проекта и графиком работ. Например, когда пользователь не до конца уверен, к чему может привести то или иное решение, он может провести моделирование, и посмотреть на последствия тех или иных изменений в проекте;
• необходимо решить, какую часть программного обеспечения следует разработать, какую — повторно использовать, а какую приобрести у внешнего производителя. Хорошая модель оценки стоимости позволит понять, что будет дешевле — разработать компоненту заново, приобрести ее, или же переработать уже существующую;
• требуется определить, какие части программного обеспечения модифицировать в первую очередь, какие убрать, на разработку каких назначить внешних исполнителей в случае разработки новой версии системы;
• ведется процесс разработки стратегии улучшения процессов внутри организации путем повторного использования кода, более совершенного инструментария для разработки, повышения зрелости процессов. Используя модель оценки, пользователь может оценить, какая стратегия будет максимально эффективной, а какая принесет минимум улучшений при большом количестве затрат.
На данный момент времени существует множество различных моделей оценки стоимости. При выборе, какая модель лучше всего подойдет для нужд конкретного предприятия, важной задачей является выработка списка единых критериев, по которым можно оценить эти модели, провести их сравнительный анализ и выбрать ту, которая наиболее полно и правильно описывает процесс разработки, позволяя получить точные результаты.
Следующей задачей, с которой сталкивается менеджер, отвечающий за оценку стоимости программных проектов на предприятии, является анализ существующего рынка программного обеспечения, которое реализует возможность оценки стоимости проекта. У продуктов следует рассмотреть сильные и слабые стороны, выделить те требования, следуя которым стало бы возможным нахождение программного обеспечения по оценке стоимости, которое бы удовлетворяло бы потребностям предприятия. В том случае, если на рынке отсутствует продукт, удовлетворяющий всем необходимым требованиям, то следует разработать такую систему.
Наконец, выбранные модель и программное обеспечение должны быть проверены на реальных проектах с целью выявления расхождений между теми значениями, которые были получены через модель и программное обеспечение, и фактическими значениями по проекту. На основании полученных результатов можно будет сделать вывод о целесообразности использования в качестве оценки модели стоимости. В случае выявления расхождений необходимо найти механизм по их устранению, возможности по улучшению модели, повышению точности ее оценок.
Полученные результаты позволят улучшить качество результатов работы менеджеров проектов предприятия, делая их оценки обоснованными и максимально приближенными к реальным результатам, уменьшат финансовые потери предприятия.
Данное диссертационное исследование посвящено проблемам выбора модели и программного продукта по оценке стоимости. Рассматриваются пути улучшения точности моделей, разработки программного обеспечения по оценке стоимости.
В первой главе описана история направления моделирования оценки стоимости, приводится классификация методов оценки, краткое описание каждого из них. Проводится сравнительный анализ методов оценки, выявляются характерные черты, сильные и слабые стороны каждого метода, на основании которого делается вывод о наиболее предпочтительных для использования на современных ИТ-предприятиях моделях оценки. Рассматриваются существующие программные продукты по оценке стоимости, проводится их сравнительных анализ, выделяются требования, которым должна отвечать полноценная система оценки стоимости. Поскольку на данный момент не существует программного продукта, отвечающего этим требованиям, принимается решение о разработке такого продукта.
Во второй главе приводится подробное описание выбранной модели оценки стоимости, которая стала основой для разрабатываемой системы оценки — СОСОМО П. Описываются возможные способы оценки размера программного кода - показателя, который используется в модели, факторы влияния на проект в модели СОСОМО П. Рассматриваются возможные пути и алгоритмы улучшения моделей стоимости, процесс доработки модели и ее калибровки под предприятие, проводится сравнительный анализ результатов, полученных до и после улучшения модели. Для нового программного продукта по оценке стоимости проводится построение информационной модели, описываются функции, сценарий диалога, приводится краткое описание внутренней структуры.
В третьей главе исследования работы модели СОСОМО П на фактических данных предприятия. Приводится пример расчета оценки стоимости с помощью модели СОСОМО Л и доработанной модели - COCOMO-PJ. Обосновывается экономическая эффективность проекта, проводится расчет основных ее показателей.
Задачей исследования является изучение предметной области моделирования оценки стоимости программного проекта, моделей и программных продуктов, предназначенных для оценки стоимости, выявление наиболее полной модели, а также программного продукта, выделение их преимуществ и недостатков, оценка возможности их использования в рамках системы управления проектами, нахождение путей по повышению точности оценок. Если продукта, отвечающего всем требованиям, найдено не будет, необходимо спроектировать и реализовать оригинальный программный продукт на основе наиболее полной модели, который будет отвечать всем современным требованиям к продуктам такого рода.
История развития моделирования оценки стоимости программных проектов
Первоначально, в период до возникновения моделей оценки, для оценки стоимости программного продукта использовалось так называемое «правило большого пальца». Согласно нему создаваемое приложение часто ограничивалось определенной сферой деятельности, в которой были свои эксперты. Эти специалисты могли с той или иной степенью достоверности сказать, каков будет размер создаваемого кода и его стоимость. Применяемое в большинстве случаев, оно часто не подходило для нетиповых проектов разработки. Также активно использовалось оценивание по аналогии — данные брались из похожего, успешно завершенного проекта и перекладывались на новый проект. Разумеется, степень достоверности таких оценок была очень невысока.
Постепенно, вместе с увеличением количества и размеров программных проектов, область оценки их стоимости тоже начала расширяться. Эксперты, работающие в области управления программными проектами, стали определять общие тенденции и правила оценки стоимости, которые активно использовали в своей работе. Накопив материал на достаточно большом количестве проектов, они старались вывести формулы для оценки стоимости. Разумеется, риск неточности расчетов продолжал быть высоким, поскольку границы действия правил, выводимых экспертами, можно было определить лишь со временем, с увеличением числа проектов, на которых эти правила проверялись.
Начало интенсивных исследований в области моделирования оценки стоимости датируется 1965-1966 годами, когда Э.А.Нельсон, сотрудник компании System Development Corporation (SDC), выполнявшей исследование в области подсчета стоимости программного обеспечения для Военно-воздушных сил США, опубликовал работу под названием «Настольная книга по управлению оценкой стоимости затрат на программирование» [23]. Книга содержала в себе результаты статистического анализа затрат и факторов затрат, характеризующих процессы проектирования, программирования и тестирования 169 законченных программных проектов. Книга содержала также расчеты по оценке таких затрат, как человеко-месяцы, советы по их использованию. Это привело к появлению достаточно большого количества моделей оценки в конце 60-х и в начале 70-х — Delphi, Wolverton и др.
Модель Delphi была создана корпорацией Rand еще в далеком 1940 году, однако результаты исследований были опубликованы только в 70-е годы. Эта техника во многом опиралась на мнение экспертов, нежели чем на результаты расчетов и поэтому могла использоваться только с учетом доли погрешности, но поскольку она требовала мнения нескольких экспертов и их обсуждения, вероятность ошибки несколько уменьшалась.
Модель Р.У. Волвертона, сотрудника компании TRW, позже ставшего, вместе с группой других исследователей, создателем одной из наиболее широко используемых моделей оценки стоимости, СОСОМО, появилась в 1974 году. Это было одной из наиболее ранних попыток формально измерить продуктивность работы программиста с использованием количества строк кода. Он предложил использовать объектные инструкции на человеко-месяц как меру производительности и опубликовал типовые значения для использования [57].
Проблемой оставался тот факт, что измерения происходили в единицах количества строк кода, которые, во-первых, изменялись от проекта к проекту при использовании разных языков программирования, и во-вторых могли использоваться уже на этапе программирования, когда разработчик мог с большой долей вероятности оценить предполагаемый размер программного кода.
Важной вехой в развитии направления оценки программного проекта стало появление концепции функциональных точек [32]. В 1977 году они были впервые представлены сотрудником компании IBM Аланом Альбрехтом. Функциональные точки позволяли оценивать сложность и приблизительный размер программного продукта на ранних стадиях разработки — на этапах анализа и проектирования. В 1984 году Альбрехт усовершенствовал механизм оценки, а в 1986 году появилась международная группа пользователей метода функциональных точек (International Function Point User Group (IFPUG)). В 1988 году Кэперс Джонс, основатель и ведущий специалист по науке компании Software Productivity Research LLC, предлагает расширение для модели функциональных точек, которое дает возможность оценивать системы реального времени путем использования нового, дополнительного параметра [37]. В 1988[52] и в 1991[93] годах эта модель была модифицирована Чарльзом Симонсом, исследователем из компании Nolan, Norton & Со (NNC), Лондон, и до сих пор широко используется в Европе и США. 1977 год стал также годом появления первого коммерческого продукта по оценке стоимости программного проекта. Им стала модель PRICE-S, разработанная сотрудниками компании Martin Marietta Price Systems Ф.Фреймэном и доктором Р.Парком [50]. В модели использовались как концепция количества строк программного кода, так и концепция функциональных точек, что сделала ее универсальной и широко используемой. В 1987 году PRICE-S была модифицирована с учетом практики современных проектов. Чуть позже, в 1978 году появляется вторая коммерческая модель — SLIM, созданная компанией Quantitative Software Management, Inc. (QSM). К концу 70-х - началу 80-х появляются еще ряд серьезных моделей, таких как SEER, ESTIMACS. В 1981 году доктор Барри Боэм, исследователь, директор центра системного и программного обеспечения университета южной Калифорнии, предложил свою модель СОСОМО (The Constructive COst MOdel - конструктивная модуль затрат), которая основывалась на метрике подсчета строк кода [22]. Благодаря ее высокой точности и возможности ее калибровки для разных проектов, она быстро стала одной из наиболее популярных и широко используемых. В 1995 году был опубликован обновленный вариант модели [63]. В 80-е годы к исследованию проблемы оценки стоимости подключаются крупные организации, такие как Rome Air Development Center (RADC) и NASA.
Хотя большинство из перечисленных исследователей работали независимо, рано или поздно они вставали перед дилеммой - с ростом размера программного продукта возрастала и его сложность, тем самым, делая процесс оценки более сложным и часто даже полностью невозможным. Эта сложность подкрепляла интерес исследователей.
Но, тем не менее, в данной области существовало множество слабых мест. Быстрое изменение природы разработки программного обеспечения, появление новых технологий, делало очень сложным выделение параметрических моделей, которые бы отвечали всем требованиям и могли использоваться во всех отраслях разработки. Одной из важнейших целей специалистов по информационным технологиям стало создание такой модели. Но если рассмотреть современные разработки, то можно сказать, что они во многом построены на основе тех моделей, которые создавались в 70-80 годах. Наиболее часто появлялись методы, включающие классический мультипликативный регрессионный подход [65]. Однако этот классический подход не всегда был лучшим решением.
Кроме регрессии появился ряд других методов, основанных на других подходах. В частности, среди наиболее современных моделей оценки, появились модели, основанные на нейронных сетях [65]. Обладая возможностью обучения, эти модели считаются достаточно перспективными, особенно учитывая факт постоянного развития информационных технологий и возрастания сложности проектов. Также появились модели, использующие композитный подход [65]. Однако коммерческих продуктов на основе этих моделей пока не создано — еще не накоплено достаточного количества информации для того, чтобы подтвердить или опровергнуть их корректность.
Сравнительный анализ программных продуктов, предназначенных для оценки стоимости программного проекта
Рассмотрев продукты SLIM Tools, KnowledgePlan и Charismatek s Function Point WORKBENCH (FPW), Cost XPert, Borland CaliberRM, можно получить некоторое общее представление о требованиях к программному продукту, основанному на математической модели оценки стоимости программного проекта, сложившихся в отрасли. Продукт должен иметь: возможность хранения и повторного использования данных об оценке; возможность ввода, хранения, повторного использования информации по проектам, проведения сравнительного анализа проектов и их оценок; гибкую отчетность, наглядное и простое представление результатов работы системы оценки; возможность анализа "что если", возможность построения прогнозов; по возможности поддерживать не одну, а несколько моделей оценки или хотя бы методов оценки величины программного кода; поддерживать разные модели жизненного цикла, разные языки программирования, на которых реализуется оцениваемый программный проект; возможность калибровки программы под конкретное предприятие на основе данных по проектам; возможность календарного планирования с учетом произведенного анализа.
Если же рассматривать программный продукт, который будет использоваться на крупном предприятии, тут нужно добавить еще условие: высокая безопасность продукта. Это подразумевает наличие подсистемы, отвечающей за защиту информации от несанкционированной утечки. Информация по проектам обладает высоким уровнем конфиденциальности, поэтому в системе должно быть четкое разграничение доступов. Продукт Описание Характеристики разработки программного обеспечении. 1.5. Сравнительный анализ программных продуктов, предназначенных для оценки стоимости программного проекта возможность хранения и повторного использования данных об оценке; возможность ввода, хранения, повторного использования информации по проектам, проведения сравнительного анализа проектов и их оценок; гибкую отчетность, наглядное и простое представление результатов работы системы оценки; возможность анализа "что если", возможность построения прогнозов; по возможности поддерживать не одну, а несколько моделей оценки или хотя бы методов оценки величины программного кода; поддерживать разные модели жизненного цикла, разные языки программирования, на которых реализуется оцениваемый программный проект; возможность калибровки программы под конкретное предприятие на основе данных по проектам; возможность календарного планирования с учетом произведенного анализа. Если же рассматривать программный продукт, который будет использоваться на крупном предприятии, тут нужно добавить еще условие: высокая безопасность продукта. \
Наличие репозитория,возможности хранения истории + Возможность переноса данных из истории натекущую оценку, имеется база знаний +Есть база знаний + +возможность хранения информации о завершенных проектах и дальнейшего ее использования Наименование характеристики SLIM Tools KnowledgePlan FPW Cost XPert Borland CaliberRM Возможности экспорта/импорта +MS Office, html +MS Project, связь с внешними системами через ODBC +.html, .xml - форматы + MS Project, Primavera + Наличие механизма поддержки принятия решений + предлагает варианты решения проблемы Гибкость оценки размера кода + 5 различных методик + + Возможность калибровки + + + + Возможность совместной работы групп пользователей, занимающихся разработкой + + + Разграничение доступов + возможность администрирования
Возможность коммуникаций внутри системы + В процессе исследования программных продуктов по оценке стоимости проектов было установлено, что последнее условие не было реализовано полностью ни в одной из рассмотренных систем, тогда как является тоже весьма существенным. Оно предполагает возможность ограничения просмотра информации пользователям системы в зависимости от их привилегий, а также возможность ограничения их действий внутри системы. К примеру, ряду пользователей нужно давать доступ только на просмотр информации, другим же - менеджерам проекта — нужна возможность выполнения оценки и прогнозирования, но в рамках только проектов, в которых они участвуют. Третьей группе сотрудников может понадобиться полная информация по всем существующим проектам для возможности составления прогнозов и анализа эффективности работы предприятия в целом. Исходя из этого, система разграничения доступов обязательно должна присутствовать.
Другим обязательным требованием для системы в крупной компании является возможность совместной работы групп пользователей, занимающихся разработкой. Необходимо, чтобы была возможность разделения данных и использования их таким образом, чтобы было удобно для всех пользователей. Такая возможность имеется лишь в трех системах из рассматриваемых пяти: в KnowledgePlan, в FPW и в Borland CaliberRM.
Система оценки стоимости программного продукта также должна встраиваться в корпоративную систему предприятия. В противном случае возникает громадное количество проблем экспорта/импорта данных - по сути, получается «лоскутная» автоматизация вместо целостной. К примеру, если компания использует систему управления предприятием, одним из компонентов которой является система управления проектами, но для оценки стоимости проекта используется сторонний продукт, то это означает, что данные необходимо дублировать. Кроме того, при переносе велика вероятность ошибки, а также если это продукт без возможности совместного использования, то такой вариант может принести больше проблем, чем пользы. При наличии связи системы оценки стоимости с системой управления предприятием появляется возможность переноса разграничения доступов в соответствии с должностными полномочиями, а также, при наличии системы коммуникации, совместное информационное пространство, в рамках которого можно производить обсуждение проекта, сохранять комментарии, которые могут быть полезны для последующего использования.
Сравнив характеристики выделенных программных продуктов, можно выделить Borland CaliberRM как отвечающий наибольшему количеству выработанных требований. В отличие от других представителей данного класса программного обеспечения, он имеет ряд возможностей по разграничению доступа внутри системы, что, как отмечалось ранее, существенно для современных систем оценки стоимости. Серьезным недостатком является отсутствие в нем поддержки различных моделей жизненного цикла — без этого достаточно сложно произвести подстройку системы под нужды конкретного предприятия, со своей технологией разработки программного обеспечения.
На втором месте по набору характеристик идут программные системы SLIM Tools и Cost XPert. Наиболее существенным недостатком данных продуктов является отсутствие возможности разграничения доступов и совместной работы пользователей с системой. Это уменьшает их применимость для крупных предприятий. В качестве плюсов систем можно отметить простоту использования — наличие режимов быстрой оценки проекта, что позволяет сэкономить время и дает возможность работать с продуктом даже менеджеру-новичку.
Однако ни одно из рассмотренных программных продуктов в полной мере не обладает всеми вышеперечисленными характеристиками. Использование нескольких продуктов для оценки представляется непродуктивной вследствие большого количества дублирования информации между двумя системами, что, как следствие, приводит к замедлению работы пользователей. Доработка же существующих программных продуктов невозможна по причине того, что они являются коммерческими системами с закрытым программным кодом.
Факторы влияния на проект в СОСОМО П и уравнение модели на разных тапах
На ранних этапах разработки программного обеспечения, когда используется модель композиции приложения, в расчет не принимается большинство факторов, которые начинают серьезно влиять на модель на следующем этапе, когда стабилизировались требования - на этапе раннего проектирования.
Если В 1, то проект представляет собой экономию масштаба. Если размер продукта увеличивается вдвое, то затраты на проект возрастают менее чем в 2 раза. Продуктивность проекта возрастает с увеличением его размера.
Если В=1, то экономия и издержки находятся в равновесии. Эта линейная модель часто используется для оценки мелких проектов. Она используется в модели композиции приложения СОСОМО П.
Если В 1, то проект представляет собой ситуацию, обратную экономии масштаба. Обычно это происходит из-за влияния двух факторов — роста числа внутренних коммуникаций и роста количества необходимых компонентов для интеграции системы. В больших проектах задействовано больше персонала и, как следствие этого, количество коммуникаций возрастает. Интеграция небольшого продукта в состав большего продукта требует не только затрат на создание меньшего продукта, но и дополнительных затрат на проектирование, поддержку, интеграцию и тестирование его интерфейса во взаимодействии с основной системой.
Гибкость среды разработки FLEX Означает, определены ли полностью цели разработки, этапы работы. Низкий уровень означает, что процесс полностью распланирован и изучен, сверхвысокий - что клиент определил только общие цели.
Риск архитектуры RESL Определяет, насколько полно произведен анализ рисков проекта. Очень низкий уровень означает, что анализ практически не проводился, сверхвысокий - означает полный анализ риска.
Связность команды TEAM Отражает сплоченность группы разработчиков, работающих над проектом. Очень низкий уровень означает, что взаимодействия между разработчиками очень трудные, сверхвысокий - сплоченную группу, без проблем во взаимодействии.
Зрелость процесса РМАТ Отражает зрелость процессов в организации согласно модели СММ. Вычисление этого фактора выполняется по вопроснику СММ из расчета взвешенного среднего значения.
Зрелость организации РМАТ определяется в соответствии со шкалой, созданной SEI, состоящей из оценки 18 ключевых процессов проекта или же в соответствии с оценкой уровня зрелости с возможными значениями от 1 до 5. Более полное описание факторов масштаба приведено в таблице 1.1 приложения 1. Если рассмотреть полное уравнение, описывающее модель раннего этапа проектирования, то она выглядит следующим образом: Затраты = АхРазмерв хМе + Затраты аи1о[чел. —мес] где А — коэффициент масштаба, являющийся константой, определенной разработчиками модели (для модели СОСОМО П калибровки 2000 года это значение равно 2,94). Размер — размер программного кода в строках. В - фактор издержек масштаба. Затратьіаию — отражает затраты на код, генерируемый программой автоматически. Затраты — итоговые затраты по проекту в человеко-месяцах. Me — множитель поправки, который состоит из множества факторов формирования затрат, количество которых варьируется от типа модели. Для модели раннего этапа проектирования их количество равно 7, а в модели этапа пост-архитектуры это количество возрастает до 17. Me определяется по формуле: Me=f\EMn где ЕМІ — числовое значение і-го фактора формирования затрат, характеризующего ситуацию на проекте.
Расчет оценки стоимости программного проекта с помощью системы оценки стоимости
В правой части формы содержится основная информация по проекту оценки - проект, с которым связана оценка, наименование проекта оценки, верхний проект, в случае древовидной структуры проектов оценки, наименование проекта оценки, тип проекта, автор, модель, код, комментарий, уникальный номер для хранения в системе - S\N, дата создания проекта и дата завершения реализации (на случай если проект был закрыт или изменен - в системе поддерживается версионность и возможность просмотра предыстории).
На панели управления находятся стандартные кнопки по работе с проектами оценки. Они стандартные почти для всех форм системы: а - создание нового объекта; а - редактирование объекта; а - удаление объекта; в - поиск объекта; с - сохранение изменений; V - откат изменений; а - вызов связанного с форме
Помимо стандартных кнопок на панели управления навигатора также содержатся следующие кнопки:
В - переход в режим табличного просмотра информации по проектам оценки; Г - настройка доступов; - переход в форму работы с объектами; S - переход в форму работы с элементами; D - переход в форму работы с факторами; О - переход в форму работы с мультипликаторами.
Для удобства пользователя цветовая схема форм настроена таким образом, чтобы те поля, которые пользователь может редактировать, изменять, отображались белым цветом, а те, которые он изменять не может — заполняемые автоматически, или предназначенные для просмотра — отображаются серым цветом.
При создании объекта пользователь может сразу же оценить ожидаемый размер кода объекта путем ввода худшей, лучшей и наиболее вероятной оценки (рис. 3.4 приложения 3).
В данном примере представлено создание объекта типа «форма» системы управления проектами - PJWORKLIST - Список работ проекта. Также произведена оценка ожидаемого размера кода. По результатам расчета системы размер кода получается равным 438,33.
После создания объекта становится доступной его оценка как в объектных, так и в функциональных точках. Данные действия можно произвести через формы «Объектные точки проекта» (рис. 3.5 приложения 3) и «Функциональные точки проекта» (рис. 3.7 приложения 3) соответственно. На рис. 3.6 и 3.8 приложения 3 представлен внешний вид экранных форм по созданию новых функциональных и объектных точек. На примере показано создание объектной точки, связанной с формой PJ_WORKLIST. После ввода количества окон, серверных и клиентских таблиц, система автоматически оценивает сложность формы как «Сложную» и вес как равный 3. В качестве примера создания функциональной точки взята функциональная точка для объекта типа «внешний интерфейсный файл» выгрузки данных по проекту из системы управления проектами PJ в MS Project. На основе входных данных - числу типов файлов и элементов - получается оценка сложности как средняя и вес объекта как равный 7.
Оценки факторов проекта можно посмотреть и изменить в рабочем месте «Факторы проекта» (рис. 3.9 приложения 3). На рис. ЗЛО приложения 3 представлен процесс ввода данных о новом факторе, в данном случае, факторе предсказуемости. Для упрощения ввода информации в текстовых полях системы предусмотрен вывод списков, чтобы пользователь мог выбрать из готовых значений то, что ему требуется. Внешний вид списка представлен на рис. 3.10 приложения 3. В качестве примера производится оценка фактора «Предсказуемость». Значение его для данного проекта оценено как «низкое».
В качестве примера рассматривается создание и последующее изменение значения мультипликатора «Возможности персонала». Первоначально он оценивается как «номинальный», а в последующем его значение изменяется на «высокий». При этом пользователь в любой удобный момент может просмотреть полную историю изменений мультипликатора, посмотреть, кто, когда, из какого рабочего места производил изменения мультипликатора.
Настройка значений списков выполняется через рабочее место «Справочники», представленное на рис. 3.13 приложения 3. Данная форма содержит множество вкладок, каждая из которых отвечает за работу с терминами определенного списка, в данном случае, с терминами списка «Типы моделей».
Через рабочие места «Настройка факторов» и «Настройка мультипликаторов» (рис. 3.14, 3.15 приложения 3) выполняется настройка данных, на основе которых производится оценка стоимости в системе. Первоначально они содержат данные, описанные в модели СОСОМО П, а в дальнейшем пользователь может изменять их, подстраивая под нужды конкретной организации. На данных примерах производится настройка фактора «Гибкость разработки» и мультипликатора «Трудность платформы». Формы имеют похожую структуру — сначала пользователь заполняет верхнюю часть формы - создает фактор или мультипликатор, описывает их основные параметры, а затем производит детализацию их значений в нижнем блоке формы. Так, для фактора «гибкость разработки» указано одно возможное значение, со сложностью «очень низкий» и числовым значением 5.
Разграничение доступов по проекту доступно через экранные формы «Роли сотрудников по проекту» (рис. 3.16 приложения 3) и «Состав роли» (рис. 3.17 приложения 3). Первоначально, в экранной форме «Состав роли» администратор создает нужную роль проекта и определяет список действий, включаемых в нее. После этого, в экранной форме «Роли сотрудников по проекту» администратор может назначить роли конкретным сотрудникам предприятия, тем самым дав им права на проведения данных действий. В качестве примера для проекта «Разработка системы управления проектами» создается роль «Аналитик». Аналитику устанавливаются доступными операции создания нового проекта оценки и просмотра всех отчетов о проектах оценки. После этого на роль аналитика проекта назначается Петров Петр Петрович.
На рис. 3.18 приложения 3 представлена канва «Моделирование» формы оценки стоимости проекта. С ее помощью пользователь может выбрать любой проект оценки, произвести по нему расчет и получить результат в виде оценки по стоимости и по срокам. Через эту форму он также может вызвать подробную информацию по проекту, к которому относится заданный проект оценки, подробную информацию по выбранному проекту оценки, добавить новый проект оценки и отредактировать уже существующий. Также из этой канвы доступен вызов отчета о результатах оценки. В качестве примера на канве произведена оценка по ранее введенным данным «Проект оценки стоимости». В результате расчета по данному проекту оценки получается, что стоимость проекта будет равна 1099000, длительность — 15,7 человеко-месяцев, и проект завершится не ранее 12.12.2007.
На рис. 3.19 приложения 3 представлена канва «Анализ что если» формы оценки стоимости проекта. С ее помощью пользователь может выбрать базовый проект оценки, указать те параметры, которые будут изменяться, и посмотреть результаты, которые получатся в результате развития событий по такому сценарию. Результаты будут представлены в блоке «Результаты анализа», причем черным цветом выделяются результаты расчета по базовому сценарию, синим — по новому, зеленым цветом отмечаются отклонения в сторону экономии, красным - в сторону перерасхода. На данном примере оценка по новому сценарию оказалась удачнее оценки по базовому — результаты сравнения окрашены зеленым цветом, причем сроки и стоимость сократились почти вдвое. Это произошло из-за того, что были изменены мультипликаторы модели - уменьшены надежность, время, и увеличены мультипликаторы, касающиеся опытности персонала, как можно видеть в экранной форме «Корректировка условий анализа».
