CC BY
120
№5(23)2009
А. Л. Баденко, М. Е. Бачуринская, К. В. Кутикова
Прикладная методика оценки ресурсоемкости разработки АРМ
Оценка технико-экономических показателей проекта является важнейшим процессом при предпроектной проработке информационной системы. Она позволяет до начала разработки определить потребность в различных видах ресурсов и рассчитать возможные риски проекта, влияющие на его конечную стоимость. В конечном счете предварительная оценка технико-экономических показателей позволяет прогнозировать эффективность затрат на разработку и эксплуатацию информационной системы.
Важность данной темы видна из многочисленных зарубежных исследований, посвященных проблемам эффективности вложений в создание проектов специализированного программного обеспечения для информационных систем. Наиболее часто встречающийся в них тезис: «Приблизительно 75% всех программных проектов либо запаздывают, либо отменяются» [1].
Названия книг гуру управления программными проектами говорят сами за себя, например «Путь камикадзе» [2]. В этих книгах можно найти впечатляющие высказывания, справедливость которых каждый руководитель проекта почувствовал на собственной шкуре: «...средний проект обычно запаздывает на 6-12 месяцев и выходит за рамки бюджета на 50-100%. Мрачная действительность заключается в том, что в своем проекте вы должны рассчитывать на такие условия, которые почти наверняка приведут менеджера проекта и его сотрудников на путь камикадзе». В этих работах перечисляются основные проблемы, вызывающие затягивание и удорожание проекта [3].
1. Проектирование не имеет четкой выраженности. Невозможно отделить стадию проектирования от предыдущей и последующей стадий, поскольку все они перекрываются и влияют друг на друга.
2. Не существует правила остановки. Нет критерия, который позволяет понять, что достигнуто оптимальное решение.
44 V
3. Решения не бывают верными или неверными. Проектирование связано с поиском компромиссов между потенциально конфликтующими сущностями. Проектировщики должны найти скорее несколько приемлемых решений, чем одно наилучшее.
Основные попытки преодолеть сложившуюся ситуацию связаны с разработкой стандартов, которые могли бы помочь как заказчикам, так и подрядчикам (разработчикам) специализированного программного обеспечения минимизировать негативное влияние описанных проблем.
Достаточно успешным можно считать стандарт ISO/IEC 15504. Он создан в рамках совместного проекта международных организаций ISO и IEC под названием SPICE (Software Process Improvement for Capability dEtermination), стартовавшего в 1993 г. ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Текущая версия документа датирована 2004 г.
Помимо модели оценивания и усовершенствования процессов разработки программных систем, предлагаемой стандартом ISO/IEC 15504, существуют и другие модели. Самая известная из них — SW-CMM (Capability
№5(23)2009
Maturity Model for Software), опубликованная SEI в 1993 г. и с тех пор непрерывно совершенствуемая.
Предпроектная оценка ресурсоемкости проекта создания специализированного программного обеспечения занимает особое место среди прочих методов оценки. Это обусловлено тем, что при прогнозировании ре-сурсоемкости очень многое определяется персональным опытом ответственных представителей заказчика и разработчика. Условно можно выделить следующие особенности рассматриваемых групп:
• разработчики делятся на «оптимистов», «реалистов» и «пессимистов»;
• разработчики с чрезмерно оптимистичными оценками склонны предлагать самые дешевые решения (далеко не всегда проверенные в конкретной предметной области);
• заказчики требуют контракта с твердой ценой;
• заказчики склонны выбирать разработчика, предлагающего решение по самой низкой цене (далеко не всегда получая ожидаемую функциональность специализированного ПО).
Предпроектная оценка трудозатрат проекта разработки может осуществляться с помощью различных моделей. В настоящее время наиболее часто используется модель COCOMO II (Constructive COst MOdel II), разработанная Барри Боэмом. Данная модель составлена таким образом, что в ней используются коэффициенты, отражающие особенности конкретного проекта и команды разработчиков. Это позволяет учесть при расчете предварительных оценок проекта даже те факторы, которые трудно поддаются количественной оценке.
Предпроектная оценка специализированного ПО для информационной системы происходит на основе подхода, предполагающего реализацию последовательных взаимосвязанных этапов.
1. Анализ предметной области.
2. Формирование модели бизнес-процессов.
3. Определение исходных данных для оценки трудозатрат и времени разработки программного приложения.
4. Подготовка отчета по разработанным прогнозам.
Предложенная последовательность этапов подходит как для учетных систем, так и для автоматизированных систем управления технологическими процессами. Наша практика показывает недостаточную эффективность подхода при предпроектной оценке специализированного ПО для аналитических систем.
Модель СОСОМО II объединяет в себе две различные подмодели:
1) модель ранней разработки проекта, или модель этапа предварительного проектирования, — применяется для расчета приближенных оценок по проекту после определения требований к системе, но при отсутствии определения ее четкой архитектуры и использует в качестве метрик количество строк кода или функциональные точки;
2) постархитектурную модель — детализированную модель, которая применяется уже после разработки архитектуры системы и использует в качестве метрик количество строк кода или функциональные точки.
Как известно, в модели СОСОМО II для определения строк кода используется метод функциональных точек, основная идея которого заключается в определении функциональных точек — единиц измерения проекта, остающихся постоянными в независимости от программистов или языка реализации проекта. После определения функциональных точек осуществляется попытка их минимизации и рассчитывается количество строк кода для всего проекта. На основании этого количества и экспертных оценок различных факторов, влияющих на стоимость и трудоемкость проекта, определяется оценка трудозатрат по нему.
Для системы документооборота была проведена проверка методики СОСОМО II с помощью метода минимизации и оценки трудозатрат по функциональным точкам. Применение к системе документооборота метода функциональных точек является возможным, так как в данном процессе чаще всего происходит обработка информационных сущностей, что позволяет выделить подпроцессы и атрибуты.
Сравнительный анализ результатов проведенных работ по предварительной оценке
«з «о
1
t
I
ас
а &
а ю
8 £
а ю
45
№5(23)2009
t! 3
J
a t
а §
§
I
53 &
g
sr о
s
о p
£ is
а
трудозатрат, полученных после применения двух моделей — функциональных точек и COCOMO II — позволяет сделать вывод, что модель COCOMO II дает более точную оценку ресурсов при создании учетных ИС, благодаря возможности учета качественных показателей. Этот результат позволяет рассматривать модель COCOMO II как наиболее перспективную для проведения предпроектной оценки потребности в ресурсах на разработку ИС и/или ее частей.
В автоматизированных системах управления технологическими процессами в отличие от систем документооборота обрабатываются не информационные сущности, а сигналы управления. Это делает затруднительным применение метода функциональных точек к данному классу систем.
План оценивания трудозатрат и времени разработки проектов системы документооборота и автоматизированной системы управления технологическими процессами в случае применения модели COCOMO II следующий:
1) выделение функциональных точек процесса;
2) получение оценки количества строк кода на выбранном языке программирования;
3) определение оценок значений факторов, влияющих на трудоемкость и время выполнения проекта согласно модели COCOMO II;
4) расчет трудоемкости и времени разработки проекта.
Одним из пунктов плана оценивания является определение оценок значений следующих факторов модели COCOMO II:
• предсказуемость проекта (PREC);
• гибкость процесса разработки (FLEX);
• степень устранения рисков (RESL);
• взаимодействие команды проекта (TEAM);
• зрелость процессов организации разработчика (PMAT);
• надежность и сложность продукта (RCPX);
• требуемый уровень повторного использования (RUSE);
• возможности персонала (PERS);
• опытность персонала (PREX);
• использование инструментов (FCIL);
• плотность графика проекта (SCED).
У каждого из факторов существуют уровни с соответствующими значениями. При этом для предварительной оценки автоматизированных систем управления технологическими процессами не рекомендуется использовать унифицированные балльные оценки, рекомендованные в некоторых интерпретациях модели СОСОМО II.
В российской практике описанные выше методы должны быть адаптированы к действующим в настоящее время нормативным документам, например, к методике Госкомтруда 1986 г. и методике Министерства финансов РК 1994 г.
Методика Госкомтруда 1986 г. основана на принципе «Базовая трудоемкость разработки программных средств определяется в зависимости от группы сложности и от объема» и предполагает, что:
• группа сложности программных средств (ПС) определяется в зависимости от наличия или отсутствия у разрабатываемого ПС одной или нескольких из 11 основных характеристик;
• объем каждой отдельной функции разрабатываемого ПС, выраженный числом условных машинных команд, определяется по Каталогу функций ПС для соответствующего типа ЭВМ (больших ЭВМ, малых ЭВМ или ПЭВМ) на основании имеющейся информации о составе функций разрабатываемого ПС.
Методика Министерства финансов РК 1994 г. нормирует трудозатраты по проектам (создание очередей систем; разработка и внедрение проекта функционального комплекса задач; привязка проектов; сопровождение проекта; использование ПЭВМ для отладки и ввода в действие). Она подразумевает, что:
• при расчете трудоемкости разработки и внедрения систем (очередей) учитывается: число задач; степень применения стандартных программных продуктов; применение Техно-рабочего проекта по техническому и системному программному обеспечению; доля оптимизационных и прогнозных задач; доля задач, решаемых в реальном масштабе времени; доля задач в ответно-запросном режиме; коэффициент технологии разработки системы; опыт организации-разработчика;
46
№5(23)2009
• при расчете трудоемкости разработки и внедрения локальных проектов учитываются сложность автоматизируемых функций (задач); сложность алгоритмов решения; сложность выбранной технологии решения; форма представления входной и выходной информации; имеющаяся в вычислительном центре технология проектирования и отладки; использование стандартных модулей и стандартных программных продуктов; этапность проектирования; конфигурация технических средств; количество циклов расчета во время опытной эксплуатации.
В настоящее время изложенные принципы можно считать устаревшими. Однако на государственном уровне не появилось более актуальных документов, в то время как в коммерческих разработках применяются корпоративные стандарты, которые в большей степени адекватны современному уровню ведения программных проектов.
Тем не менее, статистика реализации отечественных и зарубежных проектов показывает, что большая доля оригинальных проектов разработки специализированного программного обеспечения (не имеющего аналогов и/или прототипов) не укладывается в лимиты ассигнованных ресурсов. Разработчики постоянно вспоминают принцип Мэрфи: «Все продолжается дольше и стоит дороже, чем предполагалось». Приведем самые обобщенные данные по разработке программных продуктов для государственных нужд. Среднее увеличение реальной длительности разработки — 1,5-2 раза. При этом основной объем доработок и исправлений ошибок приходится на стадию сопровождения программного продукта, что существенно увеличивает объем расходов.
Рассмотрим пример микропроекта — модуль контроля работоспособности блока автоматизированного ввода документации. В табл. 1 приведен пример идентификации функциональных точек (ФТ) и экспертные оценки их сложности.
Условия для расчета:
1) разработка ведется на С++;
2) статистически определенный средний объем трудозатрат ФТ = 3 чел./час.
Результаты расчета:
1) метод функциональных точек — 0,89 чел./мес.;
2) по СОСОМО II (3700 Б1_ОС) — 0,99 чел./мес, при этом затраты календарного времени определяются в 2,5 месяца.
По приведенным результатам можно сделать вывод, что статистический подход (наиболее часто применяемый для микропроектов) дает сопоставимые с СОСОМО II результаты. Однако если СОСОМО II будет эффективно работать и для более крупных проектов, то статистический метод окажется здесь совершенно неприменим. Более того, статистические методы не позволяют прогнозировать затраты календарного времени.
Некоторые поправки к представленным расчетам (с целью достичь большего соответствия реальным затратам для более крупных проектов) можно делать на основе простейших методов предпроектного анализа рисков, которые имеют свои особенности для каждой страны (в том числе и для России), что отражает особенности национального менталитета. По результатам многочисленных консультаций и обсуждений на конференциях разработчиков программного обеспечения можно составить примерный перечень и дать характеристики основных видов рисков разработки специализированного программного обеспечения, которые стоит оценивать на предпро-ектной стадии (см. табл. 2).
Методика оценки степени влияния того или иного фактора риска, знакомого каждому разработчику, основана на экспертных оценках, подготовка которых требует специального рассмотрения и обсуждения. В рамках настоящей публикации приведем оправдавшие себя (в нашей практике) при формировании экспертных оценок оценочные таблицы (см. табл. 3 и 4). В приведенных в настоящей статье материалах рассматриваются так называемые «бинарные» риски, т. е. последствия наступления риска оцениваются в двух вариантах оценки:
1) «оптимистичная — минимальное влияние»;
2) «пессимистичная — максимальное влияние».
«3
«о 1
I
I
ас
а &
а ю
8 £
а ю
47
№5(23)2009 ^
Таблица 1
Пример идентификации функциональных точек алгоритма работы модуля информационной системы и экспертные оценки относительной сложности (трудоемкости) их программной
реализации
Код ФТ Наименование ФТ Сложность ФТ
А1.4.2.1 Идентификация пароля 0,5
А1.4.2.2 Ввод имени пользователя, пароля 0,5
А1.4.2.5 Открытие рабочего сеанса АРМ РД 0,5
А1.4.2.6 Запуск отработки тестовой задачи 0,4
А1.4.2.7.1 Сканирование двух страниц тестового документа 1,2
А1.4.2.7.3 Формирование растровых изображений отсканированных тестовых страниц 1,0
А1.4.2.7.4 Формирование многостраничного РРР-файла 1,0
А1.4.2.7.6 Формирование сообщений об ошибках 0,7
А1.4.2.7.7 Отображение многостраничного РРР-файла 0,5
А1.4.2.7.9 Формирование отчета об отработке тестовой задачи 1,0
А1.4.2.11 Индикация отработки тестовой задачи АРМ РД 0,5
А1.4.2.12 Создание отчета об отработке тестовой задачи АРМ РД 1,0
А1.4.2.13 Создание записи в журнале АРМ РД 0,4
Таблица 2
I! ^
а
I
а
I
а
5 §
I
53
6
ш £
гг о
8
о
р
£
8 а
Риски программных проектов, заказанных российскими потребителями, в практике их реализации силами российских разработчиков
№ п\п Название риска Характеристика риска
1 Обязательство высшего руководства Отсутствие обязательства высшего руководства по отношению к проекту: недостаточный контроль со стороны исполнителей над выполнением обязательств, обеспечением необходимыми ресурсами, изменением политики в случае необходимости
2 Обязательство пользователя Невыполнение пользовательского обязательства: возложение вины за отсутствие ответственности у клиента на руководителя проекта, а не на пользователей
3 Понимание требований Неверное понимание требований: неясное определение требований новой системы перед началом работы, вызывающее непонимание организации процесса работы, требуемых профессиональных навыков и технологии, необходимой для создания продукта
4 Участие пользователя Отсутствие адекватного участия пользователя: отсутствие официально выделенного представителя конечного пользователя, отвечающего за контакты, конструктивное обсуждение и согласование технических решений разработчика; официальные пользователи должны активно
48
№5(23)2009
Продолжение табл. 2
№ п\п Название риска Характеристика риска
участвовать в команде, работающей над проектом, и брать на себя обязательства по обеспечению результатов работ и соответствующие обязанности
5 Навыки управления проектом Отсутствие эффективных навыков управления проектом: руководители проекта должны быть необходимым образом уведомлены о его ходе, проблемах и промежуточных результатах, а также об исполнении графика использования ресурсов, ассигнованных на проект, для своевременного принятия управленческих решений; команды для работы над проектом сформированы, но менеджер проекта не обладает достаточными навыками для успешной реализации проекта
6 Управление изменениями Неверное управление изменениями: каждому проекту необходима технология для управления изменениями; для контроля объема и бюджета; увеличение объема проекта является следствием неэффективного управления изменениями и неточного определения критериев успеха
7 Стабильность требований Отсутствие постоянных требований: вследствие изменения потребностей пользователей меняются и требования, в результате чего система не будет запущена никогда, так как ни одно из требований не будет выполнено окончательно
8 Требуемые знания Недостаток требуемых знаний/навыков у участников проекта: например, в области технологии, деловых отношений и опыта разработки ПО
9 Изменение целей Изменение объема/целей: в ходе работы вносятся существенные изменения целей и задач проекта или происходит реорганизация компании-потребителя, вызывающая такого рода изменения
10 Новая технология Внедрение новой технологии: использование новой или новейшей технологии, успех применения которой не проверен на опыте других компаний и/или серьезное изменение технологии во время реализации проекта
11 Ожидания конечного пользователя Невозможность оправдать ожидания конечного пользователя: невыполненные ожидания предопределяют невозможность выполнения последующей стадии проекта; ожидания, не согласованные с результатом работ, — слишком завышенные или слишком заниженные — приводят к появлению проблем сдачи-приемки результатов проекта в целом или одной из его стадий
12 Кадровое обеспечение Недостаточное/несоответствующее кадровое обеспечение: недостаточное количество сотрудников или сотрудники, не обладающие нужной/обладающие недостаточной квалификацией, участвуют в работе над проектом независимо от работоспособности
13 Сотрудничество с пользователями Отсутствие стремления к сотрудничеству со стороны пользователей: пользователи отказываются выставлять требования и/или проводить приемочные испытания
а
«о
1 I
49
№5(23)2009 ^
Окончание табл. 2
№ п\п Название риска Характеристика риска
14 Изменение права собственности Изменение права собственности или верхних эшелонов управления: новые владельцы и/или менеджеры определяют новое коммерческое направление, что приводит к несоответствию между корпоративными нуждами и целями проекта
15 Конфликт между пользователями Конфликт между пользовательскими отделами: серьезные разногласия по поводу целей проекта, результатов работы, дизайна и т. д. ставят под сомнение концепцию разделенного права собственности
16 Планирование Отсутствие планирования или неадекватное планирование: отношение руководства компании-разработчика к планированию как к несущественной или неосуществимой процедуре
Таблица 3
Шкала оценки вероятности наступления риска (пятибалльная шкала, бинарные риски)
I! ^
а
I
а
I
а
5 §
I
53
6
ш 5
гг о
8
о
р
£
8 а
Шкала вероятности Описание Значение Оптимистичное Пессимистичное
1 Риск идентифицирован, но очень мала вероятность его осуществления 0,001 0,01
2 Осуществление риска возможно, но вероятность невелика 0,01 0,05
3 Рисктипичен, принимается во внимание в оценках и проектном плане 0,05 0,15
4 Осуществление риска имеет высокую вероятность, риск важен для проекта; принимается во внимание в проектных оценках 0,15 0,30
5 Осуществление риска имеет очень высокую вероятность, является решающим для проекта и его участниками; рискдолжен отслеживаться различными средствами 0,30 0,50
Таблица 4
Шкала оценки степени влияния (увеличение объемов затрат) на бюджет проекта наступления риска (пятибалльная шкала, бинарные риски)
Шкала Описание Значение степени влияния, % от бюджета проекта Значение стоимости мер по предотвращению, % от бюджета проекта
Оптимистичное Пессимистичное Оптимистичное Пессимистичное
1 Незначительное влияние, нет необходимости реагировать немедленно 0,1 1 0,1 10
2 Возможно, но достаточно низкое влияние, нет необходимости предотвращать, если имеет место единичный случай 1 5 10 50
50
№5(23)2009
Окончание табл. 4
Шкала Описание Значение степени влияния, % от бюджета проекта Значение стоимости мер по предотвращению, % от бюджета проекта
Оптимистичное Пессимистичное Оптимистичное Пессимистичное
3 Типично, можно предотвращать единичные случаи 5 20 50 150
4 Большое влияние, важно контролировать и предотвращать; предотвращение риска является очевидно выгодным 20 50 150 500
5 Очень большое влияние; должно контролироваться постоянно, если случается часто 50 100 500 1000
а
«о
1
t оо Sc
I"
ас
а &
а ю
Si 5
а ю
Примечание. Под «стоимостью мер по предотвращению» понимается непредвиденное (по сравнению со случаем отсутствия риска) увеличение статьи расходов проекта «Управленческие расходы».
Естественно, валидность экспертных оценок является следствием опыта каждого конкретного эксперта. Поэтому важно рассматривать оценки, полученные от различных экспертов, и применять статистические методы получения сводных экспертных оценок.
В целом благодаря применению представленного подхода (с точки зрения разработчика) достигалось удовлетворительное качество прогнозирования бюджета ресурсоемкости проекта, включая все виды ресурсов, привлекаемых для его реализации (отклонения составляли порядка 30%).
Рассмотренные в статье материалы показывают важность предпроектной (до начала стадии разработки кода программного продукта) оценки необходимых ресурсов и идентификации рисков. Конечному пользователю программного продукта предварительные оценки позволяют адекватно определить и согласовать с разработчиком его стоимость с точки зрения стоимости владения (включая разработку и сопровождение программного продукта или системы). Разработчику периодические переоценки позволяют своевременно информировать заказчика об изменении стоимости проекта и совместно принимать меры по предупреждению возможных убытков.
В заключение стоит отметить, что в практике подготовки специалистов высшей квалификации в Российской Федерации до сих пор отсутствует специализация оценщиков программного обеспечения, в то время как за рубежом осуществляется профессиональная подготовка по этой специализации, существуют профессиональные объединения оценщиков программных проектов. Успехи Российской Федерации в поддержании своей конкурентоспособности в области разработки программных продуктов не в последней степени зависят от формирования отечественных кадров оценщиков программного обеспечения.
СПИСОК ЛИТЕРАТУРЫ
1. HilburnT., Humphrey W. The Impending Changes in Software Education. IEEE Software, 2002. Vol. 19, № 5.
2. Yourdon E. Death March. The Complete Software Developer's Guide to Surviving «Mission Impossible» Projects. Prentice Hall, 1997.
3. BudgenD. Software Design. Addison-Wesley, 2003.
51
