CC BY
422
ПРИКЛАДНАЯ ИНФОРМАТИКА ___________
------- т 5(23) 2009
X. Р. Алиев, С. О. Андржеевский, М. Б. Борисов
Модели оценки стоимости информационных систем в методологиях разработки программного обеспечения
В статье описаны наиболее актуальные и востребованные на рынке ¡Т-услуг методологии разработки программного обеспечения, на их основе проведен анализ методик определения трудозатрат. На базе наиболее популярных математических моделей рассмотрены вопросы оценки трудоемкости и стоимости программного обеспечения.
Профессиональная разработка программного обеспечения, согласно стандарту IEEE 610.12, — это применение методичного, упорядоченного, количественно измеримого подхода к проектированию, созданию, эксплуатации и поддержке программного обеспечения (ПО). Именно такими качествами отличается профессиональный инженерный подход к разработке ПО1.
Определение профессионального подхода к разработке ПО, данное Институтом инженеров по электротехнике и радиоэлектронике (Institute of Electrical and Electronics Engineers, IEEE), расширяет разработку информационных систем за границы известной модели усовершенствования процессов разработки программного обеспечения SW CMM2, добавляя такие этапы, как выявление требований, ввод ПО в эксплуатацию, его эксплуатация и сопровождение.
Разработка крупных информационных систем (ИС) — процесс трудоемкий, требующий комплексного решения проблем времени, бюджета и самой функциональности разрабатываемой системы. Зачастую проекты завершаются не в срок, их бюджет превышает первоначально заданный и т. д. — примеров мож-
но привести множество. Причинами подобных негативных результатов являются:
• недостаточно продуманный план менеджера проекта (Project Manager), иными словами, неправильное управление проектом;
• неполная или неточная спецификация на проект (Specification), а также требования заказчика, которые меняются в процессе разработки;
• некачественная оценка проекта (Estimation); составляющие бюджета, не оговоренные на предварительных этапах планирования проекта.
Для заказчика и исполнителя адекватная оценка стоимости проекта является очень важным фактором, который будет влиять на договор между ними. Добиться правильной оценки на предварительных стадиях разработки отнюдь не просто. Неправильная оценка — особенно на предварительных этапах — влечет серьезные проблемы на переходной стадии в проектирование.
По мнению авторов статьи, ресурсы менеджера проекта не позволяют исправить последствия ошибки в оценке проекта, если их допустила команда аналитиков компании-поставщика.
1 Стандартный глоссарий терминологии разработки программного обеспечения Института инженеров электрической и электронной аппаратуры (IEEE Standart Glossary of Software Engineering Terminology. IEEE Standard 610.12-1990. New-York: Institute of Electrical and Electronics Engineers, 1990).
2 SW CMM — Capability Maturity Model. Первая модель CMM создана в SEI (ноябрь 1986 г.), модель зрелости процессов, предназначенная для того, чтобы оказать поддержку организациям в улучшении процессов, связанных с разработкой ИС. Полностью разработанная модель (версии 1.1) вышла в свет в 1993 г.
33
№5(23)2009
о
0 %
€
1
0 &
g
s
£ а
t If
1
0 §
€ «о
1
§
a sr а €
Si §
a
g
a
5
о
На этапе планирования на основе запрошенных работ осуществляется предварительная оценка, а именно оцениваются масштаб и атрибуты рабочих продуктов и задач. Для того чтобы установить границы планирования, строится модель жизненного цикла проекта. Затем производятся оценки трудозатрат и стоимости. Эти оценки используются в качестве основы для разработки проектных планов. С учетом плана устанавливаются бюджет и график проекта, выявляются проектные риски и создаются планы управления информацией и ресурсами, определяется потребность в знаниях и навыках, планируется привлечение дополнительных участников. На заключительной стадии планирования появляется острая необходимость привести запланированные ресурсы в соответствие с фактически имеющимися.
Попытаемся выделить факторы, приводящие к неправильной оценке разработки:
• незнание методик или отсутствие опыта оценки проекта: это часто встречающаяся в 1Т-компаниях и, наверное, самая существенная проблема;
• неправильная оценка рисков проекта (имеются в виду непредвиденные затруднения в используемых средствах и компонентах);
• ошибка аналитиков в оценке трудоемкости;
• недопонимание ключевых технических проблем (как правило, связано с сжатым графиком работ по проекту);
• недостаток времени на изучение документации заказчика ПО.
Для классического проекта изменения, возникающие после первоначального определения спецификаций, являются постоянной головной болью разработчиков. Стоимость изменений растет экспоненциально по мере длительности классического проекта, но есть методологии разработки ПО, для которых изменения требований во время процесса проектирования системы не столь критичны.
Перспективные методологии разработки ПО
Речь идет об ДдИе-методологиях, в литературе их именуют «методологии быстрой раз-
работки ПО». Различные Agile-технологии позволяют организовать процесс постепенного приближения к цели проекта путем проведения циклов испытаний с корректировкой последующих, основанных на анализе результатов предыдущих.
Наиболее известными и востребованными методологиями из семейства Agile являются:
• практика экстремального программирования (Extreme Programming, XP);
• методология Scrum.
Компании-разработчики ПО столкнулись
сегодня с необходимостью вносить многочисленные изменения в требования к разрабатываемому продукту уже в процессе разработки, а традиционные методологии плохо поддерживают изменения в спецификациях после их первоначального определения. Чем длительнее проект, тем труднее и опаснее вносить в него изменения. С другой стороны, современный программный проект неизбежно сопровождается многочисленными изменениями по ходу дела, и зачастую спецификации успевают устареть еще до того, как они полностью определены. Методология XP — это попытка сформулировать набор практик, которые минимизируют стоимость изменений и позволяют производить их почти одинаково легко и безопасно как в начале, так и в конце проекта. В XP-проекте благодаря таким правилам, как «Модульное тестирование», «Парное программирование», «Ничего заранее», «Простейшие решения» и др. стоимость изменений значительно ниже.
Процедура управления изменениями, которые вносит заказчик, в XP подробно определена. При получении требования на внесение изменения менеджер проекта просит ведущего программиста и ведущего тестера сделать оценку. Затем он сообщает стоимость изменения в терминах идеальных часов заказчику, который может:
1) отказаться от изменения, сочтя его неоправданно дорогостоящим;
2) попросить включить изменение в текущий план итерации (однако только первоначальная функциональность, согласованная на игре в планирование, является обязательством, которое разработчики должны выпол-
34
№5(23)2009
нить к концу итерации; команда будет стараться внести все изменения, но не гарантирует этого);
3) заменить часть первоначальных требований на данное изменение, чтобы гарантировать его выполнение в течение именно этой итерации (если изменение является высокоприоритетным);
4) перенести изменение на следующую итерацию, переопределив его в пользовательскую историю.
Эта процедура позволяет четко контролировать объем функциональности в пределах итерации и не допускать его непрогнозируемого роста, что в конечном счете выгодно и команде, и заказчику. Без строгого подхода к управлению изменениями заказчик может легко перегрузить команду. Это, в свою очередь, приводит к снижению качества всего проекта или даже его полному провалу. Чтобы избежать возможных недоразумений, менеджеру желательно сразу предупредить неопытного в ХР заказчика, что любая новая функциональность, отсутствующая в первоначальных пользовательских историях и несогласованная в процессе игры в планирование, является изменением, внесенным заказчиком, и требует соответствующей оценки и обсуждения, другими словами, не делается бесплатно.
Стоимость изменений, вносимых по ходу ХР-проекта, значительно ниже по сравнению с классической разработкой. ХР обеспечивает стабильно хорошие результаты, и если команда и заказчик грамотно применяют достаточно простые правила ХР, то сложно сделать проект неудачным. Естественно, подразумевается, что профессионализм команды достаточно высок — ХР сильно помогает, но не может полностью заменить технических знаний и опыта разработчиков. В ХР дата окончания итерации всегда жестко фиксирована. В худшем случае к концу итерации некоторые низкоприоритетные пользовательские истории могут быть не закончены, но большинство историй будет полностью завершены, протестированы, и соответствующая функциональность будет доступна для заказчика.
В классических проектах часто архитектурные слои делаются последовательно, «по го-
ризонтали». Например, сначала разрабатывают уровень базы данных, потом бизнес-классы, потом графический интерфейс. Из-за этого легко может возникнуть ситуация, когда, например, к дате выпуска версии 100% базы данных сделано, 100% бизнес-классов написано, но успели запрограммировать только 50% графического интерфейса. Соответственно, заказчику практически не на что смотреть и нечем пользоваться. В XP функциональность делается по пользовательским историям, и для каждой истории все необходимые уровни разрабатываются одновременно «по вертикали», а затем сразу же тестируются. Таким образом, заказчик имеет возможность гораздо раньше предоставить комментарии разработчикам и пользоваться различными частями приложения.
XP-проект может стартовать с очень простым набором требований заказчика. Иногда одной странички первоначальных пользовательских историй достаточно, чтобы начать большой и сложный проект. Заказчику не обязательно перед началом разработки готовить спецификации на весь период проекта, достаточно заранее приготовить требования для каждой конкретной итерации. В целом XP-проекты предлагают более дружественную и неформальную обстановку как внутри команды, так и в отношениях с заказчиком. Это делает работу более приятной и уменьшает бюрократию. Неопытные программисты и тестеры могут быстро и эффективно обучаться благодаря парному программированию и акценту на коммуникацию в команде, а, как известно, фактор коммуникации в оценке трудоемкости реализации ПО играет очень существенную роль.
Scrum — одна из первых методологий циклического наращивания функциональности и корректировки хода проекта на основе анализа обратной связи от пользователей. Термин «Scrum» был впервые озвучен в работе Хиротаки Такеучи и Икуджиро Нонака, опубликованной в «Harvard Business Review», в которой авторы отметили успешность проектов, использующих небольшие команды без жесткой специализации. Такие команды чем-то напоминают конструкцию схватки (scrum) в регби, которая назначается при нарушении пра-
S §■
ю
8
«о
О!
1 %
§
35
№5(23)2009
о
0 %
€
1 &
0 &
g
s
£ а
t If
Г*
1
0 §
€ «о
1
§
a sr а €
Si §
a
a
5
о
3=
вил или остановке игры. Джеф Сазерленд использовал эту работу при создании методологии для корпорации Easel в 1993 г., которую по аналогии и назвал Scrum, а Кен Швабер формализовал процесс для использования в индустрии разработки программного обеспечения, представив в 1995 г. работу на конференции Object-Oriented Programming Systems, Languages & Applications.
Основа Scrum — итеративная разработка. Scrum определяет правила, по которым должен планироваться и управляться список требований к продукту для достижения максимальной прибыльности от реализованной функциональности; правила планирования итераций для максимальной заинтересованности команды в результате; основные правила взаимодействия участников команды для максимально быстрой реакции на существующую ситуацию; правила анализа и корректировки процесса разработки для совершенствования взаимодействия внутри команды. Каждую итерацию можно описать так: планируем — фиксируем — реализуем — анализируем. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разработки.
Методология Scrum ориентирована на оперативное приспособление к изменениям требований, что позволяет команде быстро адаптировать продукт к нуждам заказчика. Такая адаптация достигается за счет получения обратной связи по результатам итерации: имея после каждой итерации продукт, который уже можно использовать, показывать и обсуждать, легче собирать информацию, делать правильные корректировки и изменять приоритеты требований. Например, если показать каркас сайта потенциальным пользователям, то появится много вопросов, на основании которых можно скорректировать то, что уже написано или еще не реализовано, понять, что более важно пользователю.
Владелец продукта (Product Owner) — человек, поставляющий требования программистам. От того, как четко написаны требования, зависит, насколько часто команде придется переключаться с задачи на задачу в свя-
зи с отсутствием нужной информации, как много нужно задать вопросов, на которые уходит дополнительное время, как сильно придется изменить уже написанную функциональность от итерации к итерации и, соответственно, эффективность разработки в целом. Обычно владелец продукта является представителем или доверенным лицом заказчика.
От Scrum-мастера (Scrum Master) во многом зависит самостоятельность, инициативность программистов, удовлетворенность сделанной работой, атмосфера в команде и результат всей работы. Этот человек должен быть одним из членов команды разработки и участвовать в проекте как разработчик. Он отвечает за своевременное решение текущих проблем, от ремонта сломанного стула до обеспечения необходимой информацией членов команды для продолжения их работы и загруженности, за поддержание нужных технических практик, используемых на проекте.
Scrum-команда (Scrum Team) — группа, состоящая из пяти-девяти самостоятельных, инициативных программистов. Первая задача этой команды — поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача — сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по определенным проектом «стандартам кодирования» (coding guidelines), программа протестирована полностью, а все найденные дефекты устранены. Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализировать и улучшать качество взаимодействия и работы. В обязанности всех членов Scrum-команды входит участие в выборе цели итерации и определение результата работы. Они должны делать все возможное и невозможное для достижения цели итерации в рамках, определенных проектом, эффективно взаимодействовать со всеми участниками команды, самостоятельно организовывать свою работу, предоставлять владельцу рабочий продукт в конце каждого цикла.
36
№5(23)2009
В начале проекта владелец продукта готовит журнал продукта — список требований, отсортированных по значимости, а Scrum-ко-манда дополняет этот журнал оценками стоимости реализации требований. Список должен включать функциональные и технические требования, необходимые для реализации продукта. Самые приоритетные из них должны быть достаточно детально прописаны, чтобы их можно было оценить и протестировать. О своевременной детализации требований должен заботиться владелец продукта и предоставлять необходимый объем в нужное время. В этом смысле программисты являются заказчиками требований для владельца продукта. И отношение владельца продукта должно быть соответствующее — каковы требования, такова и их реализация. В дальнейшем остальные требования должны постепенно уточняться и детализироваться до такого же уровня. Главное, чтобы у команды всегда был достаточный объем требований, подготовленных к реализации.
После того, как команда во время сессии планирования выбрала и обязалась реализовать набор требований из журнала продукта, эти требования разбиваются на более мелкие задачи, составляющие детализированный список требований — журнал спринта. Разбивку нужно сделать таким образом, чтобы выполнение одной задачи занимало не больше двух дней (считается, что менее детальная разбивка, например, полдня, приводит к более грубой оценке, чем та, что приемлема в большинстве проектов, использующих методологию Scrum). Разбивка поможет так спланировать итерацию, чтобы в конце не осталось ни одной невыполненной задачи и, соответственно, достичь ее цели. После завершения детализации оценка журнала спринта сравнивается с первичной оценкой в журнале продукта. Если существует значительное расхождение, команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем будет перенесен на следующую. Менее важные и мало влияющие на цель итерации задачи выносятся из журнала спринта.
График спринта (Burndown Chart) показывает ежедневное изменение общего объема работ, оставшегося до окончания итерации. Этот график позволяет команде разработчиков делать анализ текущей ситуации и своевременно реагировать на отклонения. График спринта также позволяет владельцу продукта наблюдать за ходом итерации — если общий объем работ не уменьшается каждый день, значит, что-то идет не так. Во время сессии планирования команда находит и оценивает задачи, которые надо выполнить для успешного завершения итерации. Сумма оценок всех задач в журнале спринта является общим объемом работы, который надо выполнить за итерацию. После завершения каждой задачи Scrum-мастер пересчитывает объем оставшейся работы и отмечает это на графике спринта. Только в том случае, если объем работ по окончании итерации закончился (в журнале спринта не осталось незавершенных задач), итерация считается успешной. График спринта используется как вспомогательный инструмент, позволяющий корректировать работу для завершения итерации вовремя, с работающим кодом и требуемым качеством.
Время между итерациями — это время принятия основополагающих решений, влияющих на ход всего проекта. Во время итерации нельзя производить никаких изменений извне. После того как команда дала обязательство реализовать журнал спринта, он фиксируется, и изменения в нем могут быть сделаны только по следующим причинам:
• Scrum-команда в течение итерации получила лучшее представление о требованиях и нуждается в дополнительных задачах для успешного завершения итерации;
• найдены дефекты, которые нужно обязательно исправить для успешного завершения итерации;
• Scrum-мастер и Scrum-команда решают, что небольшие изменения, не влияющие на общий объем работ, могут быть реализованы в связи с возникшей у владельца продукта необходимостью.
Исходя из того, что журнал спринта не может быть изменен извне во время итерации, нужно выбирать ее длину, основываясь на ста-
Si
ю
8
«о
1 %
§
37
№5(23)2009
о
0 %
€
1
0 &
g
s
£ а
t If
1
0 §
€ «о
1
§
a sr а €
Si §
a
a
S
о
бильности требований. Если требования стабильны, меняются или дополняются редко, то можно выбрать шестинедельный цикл. В этом случае экономится время на переключение команды с активной разработки на планирование и демонстрационные митинги. Если требования часто меняются и дополняются, нужно отталкиваться от двухнедельного цикла. В любом случае длина итерации — это величина экспериментальная.
Основной упор методология Scrum делает на управление проектами и не задает никаких технических практик, что дает возможность использовать весь технический багаж, накопленный компанией. При внедрении Scrum чаще всего возникают две проблемы. Первая — добиться активного участия от каждого разработчика и слаженной коллективной работы в команде. Похожую задачу решает тренер спортивной команды. Вторая — вовлечь поставщика требований в активное участие в проекте, заинтересовать его динамикой развития продукта, дать возможность быть активным болельщиком и спонсором команды. Несмотря на это, использование методологии Scrum в проекте MediaFACEonline3 позволило за одиннадцать месяцев с высоким качеством и в рамках бюджета реализовать большой объем функциональности, спецификации на которую отсутствовали на момент начала проекта. Согласно статистике использования сайта MediaFACEonline, накопленной за несколько месяцев работы, практически все реализованные функции активно используются посетителями, что в очередной раз подтверждает эффективность использования методологии Scrum в отношении обеспечения максимальной бизнес-ценности производимого продукта. Благодаря Scrum была достигнута высокая сопровождаемость кода (возможность внесения изменений с минимальными трудозатратами) — стоимость изменений, вносимых в продукт, практически эквивалентна стоимости разработки аналогичных функций продукта в начале проекта, что редко достигается в так называемой «водопадной» модели производ-
ства, для которой характерен экспоненциальный рост стоимости изменений по мере выполнения проекта.
Классические методики оценки стоимости разработок
Проанализируем, как осуществляется оценка трудоемкости разработки информационных систем в основных моделях: модели функциональных точек (Functional Points) и модели COCOMO II. Эти модели используют все ведущие фирмы по разработке ПО в мире для предварительных оценок как трудозатрат, так и бюджета проекта. Отметим, что заказчики крупных ИС также используют модели оценивания с тем лишь отличием, что в моделях оценивания не учитываются конкретные условия разработки: заказчику интересен результат и стоимость, в то время как для исполнителя важны соответственно условия и в меньшей степени стоимость.
В конце 1970-х гг. Барри Боэмом (Barry Boehm) была предложена модель оценивания объемов работ при разработке информационных систем. Эта модель получила название «конструктивная модель стоимости» (Constructive COst MOdel — COCOMO). На сегодняшний день данная модель оценки трудоемкости разработки программного обеспечения является наиболее известной среди множества подобных. Она основана на анализе ряда проектов, реализованных по заказу Министерства обороны США. В общих чертах данная модель, с одной стороны, определяет соответствие между размером системы в тысячах условных строк кода и «классом» проекта, а с другой — трудоемкость разработки системы.
Модель COCOMO условно разделяет проекты только на три класса: ограниченные, полуинтегрированные, «встроенные системы».
Ограниченные проекты — относительно небольшие разработки, выполняемые командами, знакомыми с прикладной областью. Эти проекты отличаются относительно менее жесткими требованиями к разрабатываемому ПО.
3 Коммерческий проект для компании №а1:о, система для создание образов на РУР,СР-носителях. Ссылка на проект: http:/www.neato.com/product/Med¡aFACEonl¡ne-Plus-Ed¡t¡on.
38
№5(23)2009
Полуинтегрированные проекты характеризуются средним размером и сложностью и выполняются группами разработчиков с различным опытом. При этом требования к ПО являются более жесткими.
Проекты «встроенных систем» выполняются при значительных аппаратных, программных и организационных ограничениях; имеются жесткие ограничения по спецификации.
В основе СОСОМО вычисление стоимости разработки программного обеспечения в зависимости от оценок размера кода программы и комплекса «издержек», которые включают субъективную оценку товара, оборудования, персонала и проектных характеристик. Есть различные варианты модели СОСОМО, которые включают все характеристики, с оценкой стоимости управляющих воздействий на каждый шаг (анализ, проектирование и т.д.) в процессе разработки программного обеспечения.
Модель вводит 15 поправочных факторов, принадлежащих к одной из четырех категорий, которые в свою очередь получают оценку по шестибалльной шкале:
• атрибуты продукта, такие как его сложность и требования к его надежности, размер базы данных, сложность архитектуры приложения;
• атрибуты системы, такие как ограничения на оперативную память и время выполнения, время компиляции (сборка приложения), надежность используемых виртуальных машин;
• атрибуты команды разработчиков, такие как знания прикладной области, аналитические способности, опыт разработки, опыт в данном языке программирования;
• атрибуты проекта, такие как используемые средства разработки, применение методов разработки программного обеспечения, системы контроля разработки приложения.
У модели есть ряд недостатков. Например, недостатком является то, что она основана на тысячах условных строк кода, т. е. на размере самого кода программного комплекса. В середине 1970-х гг. был разработан метод функциональных точек. Его автором является Алан
Альбрехт (Alan Albrecht). Это одна из первых попыток провести оценку ПО без метрик размера системы, т. е. количества исходного кода ПО, идея разработки механизма и алгоритма предсказаний усилий, непосредственно сопряженных с разработкой программных систем.
Результаты разработки были впервые опубликованы в 1979 г. Альбрехт работал над модернизацией и усовершенствованием своего метода, и впоследствии были опубликованы несколько ревизий. А в середине 1980-х гг. была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group — IFPUG).
В качестве национального стандарта Великобритании принят метод функциональных точек Mark II FPA. Его автором является Чарльз Саймон (Charles Symon). Этот метод похож на предыдущий, но он более логичен и использует современную терминологию. В отличие от FPA IFPUG здесь применяется единое понятие транзакции, имеющей вход, обработку и выход.
Также необходимо указать в целом аналогичные, но более специализированные методы:
• Feature Points, разработанный Кэйпер-сом Джонсом (Capers Jones);
• 3D Points, разработанный в компании «Боинг» (Boeing).
С течением времени и ростом требований к системам модель СОСОМО оказалась устаревшей в значительной своей части. Непосредственно по этой и ряду других немаловажных причин была разработана модель СОСОМО II (результаты соответствующих разработок были обнародованы в 1999 г.) Она усовершенствует оригинальную модель по следующим пунктам:
• использование входных данных, доступных на ранних этапах жизненного цикла системы для оценки ее сложности (в частности, функциональных точек);
• подходы, основанные на повторном использовании, включая интеграцию коммерческих продуктов, реинжиниринг, генерацию приложений;
Si
ю
(S
«о
Ol
1 %
§
39
№5(23)2009
о
0 %
€
1
0 &
s; s
£
а &
11
1
ль
0 g
€ «о
1
a »
а €
8-
§
a
• объектно-ориентированные подходы, поддерживаемые распределенным ПО промежуточного слоя;
• новые — циклические и обобщенные — модели процессов разработки [1];
• влияние зрелости процессов разработки.
Методология функциональных точек в оценке разработки программного обеспечения
Задача метода — разбить систему на мелкие части. Это позволит их лучше понять и проанализировать, что обеспечит более структурированный подход к решению проблемы. Функциональные точки — это то же, что часы в качестве измерения времени или километры в качестве измерения расстояния. Это подход к измерению.
Программное приложение в сущности определяется набором элементарных процессов. Существует два основных типа элементарных процессов — данные в движении и данные в покое. Данные в движении описывают потоки данных из приложения вовне и извне в приложение. На концептуальном уровне анализ функциональных точек помогает определить два абстрактных уровня данных — в покое и в движении.
Формула, определяющая продуктивность программного обеспечения:
Количество функциональных точек
Продуктивность=-.
Количество инпутов
(за период времени,
с учетом качества4)
Данная методика позволяет рассчитывать такой экономический параметр, как маргинальные издержки. Они определяются вели-
чиной затрат на увеличение числа функциональных точек на единицу.
Маргинальные издержки увеличиваются в связи с тем, что по мере увеличения размера проекта:
1) увеличивается сложность;
2) растет количество заданий, требующих завершения;
3) больший размер команды программистов затрудняет управление.
Функциональные точки — это единицы измерения проекта. Они остаются постоянными в независимости от программистов или языка реализации проекта.
Оценка по функциональным точкам определяется суммированием по всем информационным объектам и элементарным операциям, относительная погрешность лежит в пределах 35% (0,35). Для выравнивания рассчитанных объемов функциональных точек необходим коэффициент подстройки.
Уравнение коэффициента подстройки5:
VAF=0,65
ЕС
100.
где С, — влияние каждой характеристики системы.
Всего существует 14 характеристик:
1) связи данных — как много связей используется для передачи данных внутри системы;
2) распределенная обработка данных — как обрабатываются распределенные данные;
3) требования по производительности;
4) требования по аппаратной части;
5) как часто выполняются транзакции (ежедневно, еженедельно...);
6) какой процент информации вводится онлайн;
7) эффективность для конечного пользователя;
0
1
о
а
5
о
3=
4 Качество — это совокупность свойств программной системы, обеспечивающих ее способность удовлетворять установленные или предполагаемые потребности в соответствии с назначением. Контролем и обеспечением гарантии качества занимается отдел SQA (Software Quality Assurance), который определяет параметры соответствия техническому заданию и ведет расчет количества дефектов в системе для дальнейшего регулирования уровня качества.
5 Коэффициент получен путем статического анализа фактических данных по информационным проектам. Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group — IFPUG). URL: http:Zwww.ifpug.com.
40
№5(23)2009
8) как много ИР обновляются онлайн;
9) используется ли сложная логическая или математическая обработка;
10) была ли спроектирована программа для одного или многих пользователей;
11) насколько сложна инсталляция;
12) насколько эффективны или автоматизированы старт, резервное копирование и восстановление;
13) было ли приложение спроектировано, разработано для множества сотрудников множества организаций;
14) было ли приложение спроектировано для упрощения дальнейших изменений в нем.
По каждому пункту используется пятибалльная система оценки.
FP = UAF ■VAF,
где FP — конечное количество функциональных точек;
UAF — количество функциональных точек
без подстройки;
VAF — коэффициент подстройки
UAF = EI + EO + EQ + ^ + EIF,
где EI — внешние входящие потоки; EO — внешние исходящие потоки; EQ — внешние запросы; ILF — внутренние логические файлы; EIF — внешние файлы интерфейса.
Учет разработки с предварительной обработкой данных:
DFP = (^Р + CFP)■VAF,
где DFP — количество функциональных точек разработки;
UFP — количество функциональных точек без подстройки;
CFP — количество функциональных точек, добавленных для обработки прочих функциональных точек; VAF — коэффициент подстройки.
Учет дополнительных требований:
EFP = [(ADD + CHGA + CFP)-VAFA] + (DEL ■VAFB)
где EFP — количество дополнительных функциональных точек;
ADD — количество функциональных точек без подстройки, которые были добавлены по дополнительным требованиям; CHGA — количество функциональных точек без подстройки, которые были изменены по дополнительным требованиям; CFP — количество функциональных точек без подстройки, которые были добавлены после преобразований (обычно CFP = 0); VAFA — коэффициент подстройки после дополнительных требований; VAFB — коэффициент подстройки до дополнительных требований; DEL — количество функциональных точек без подстройки, которые были удалены после преобразований.
Описание методики COCOMO II
Качество подсчета бюджета по отношению к модели COCOMO II зависит от адекватности количественных показателей ее факторов, соответственно, от опыта и информированности ответственного за расчет. Роль личности или группы ответственных за просчет бюджетов крупных проектов не может быть недооценена, она требует квалификации аналитика системы.
Базовая формула определения объемов работ на разработку программного обеспечения:
Effort=A ■ Size6.
Size представляет собой оценку размера экранов, форм, отчетов, компонентов и модулей будущей системы. Каждый элемент оценивается коэффициентом от 1 до 10 в зависимости от сложности.
Коэффициент A учитывает возможное повторное использование части компонентов и производительность разработки, зависящую от опыта команды разработчиков и применяе-
Si
ю
8
«о
О!
1 %
§
и
6 Данная формула интегрируется с другими составляющими модели СОСОМО II для оценки трудоемкости на различных этапах разработки программной системы.
41
№5(23)2009
мых инструментов, и оценивается числом от 4 до 50.
Процент 100— повторного использования
Производительность
Когда требования к системе уже определены и начинается процесс разработки архитектуры ПО, используется модель этапа предварительного проектирования (Early Design Model) и применяются следующие формулы.
§
о
0 %
€
1 &
0 &
5 S
£ а
t If
1
0
1 € «о
I
I
a sr а €
Si §
a
0
1
о
5
a
S
о
Для трудоемкости (в человеко-месяцах):
Effort=A •(Size)B • ME
Трудозатраты на автоматически генерируемый код.
Коэффициент A считается равным 2,45, а T — 3,67.
Size — оценка размера ПО в тысячах строк кода (SLOC).
B — фактор процесса разработки, который вычисляется по формуле:
B =0,91 + 0,01 = 5 W,,
где факторы Wi принимают значения от 0 до 5: W1 — предсказуемость проекта для данной организации, от полностью знакомого (0) до совсем непредсказуемого (5); W2 — гибкость процесса разработки, от полностью определяемого командой при выполнении общих целей проекта (0) до полностью фиксированного и строгого (5); W3 — степень удаления рисков, от полной (0) до небольшой (5) — оставляющей около 80% рисков;
W4 — сплоченность команды проекта, от безукоризненного взаимодействия (0) до больших трудностей при взаимодействии (5); W5 — зрелость процессов в организации, от 0 до 5 в виде взвешенного количества положительных ответов на вопросы о поддержке ключевых областей процесса в модели CMM.
ME — произведение семи коэффициентов затрат, каждый из которых лежит в интервале от 1 до 6:
□ возможности персонала;
□ надежность и сложность продукта;
□ требуемый уровень повторного использования;
□ сложность платформы;
□ опытность персонала;
□ использование инструментов;
□ плотность графика проекта.
Для времени (в месяцах):
Time = T • Effort<0'28+0*(B—1'01)) • Seed.
где EffortS — оценка трудоемкости без учета плотности графика;
Seed — требуемое сжатие времени выполнения проекта.
После того как разработана архитектура ПО, оценки должны выполняться с использованием постархитектурной модели (Post-Architecture Model).
Формула для трудоемкости (в человеко-месяцах):
Трудозатраты Effort=A •(Kreq • Size)B • MP + на автоматически
генерируемый код.
Для времени используется та же формула, что и в предыдущей модели (в месяцах):
Time=T • Effort^8+0'2 (B—1'01)) • Seed ;
Размер Size = нового кода + RSize, (в тыс. строк)
где RSize
Размер "
повторно 100 — АТ^
используемого 100 кода (в тыс. строку
АА + 0,4 • йМ + 0,3 •СМ + 0,3 • 1М + Би
х-,
100
АТ — процент автоматически генерируемого кода;
АА — фактор трудоемкости перевода компонентов в повторно используемые, от 0 до 8; йМ — процент модифицируемых для повторного использования проектных моделей;
42
A
№5(23)2009
СМ — процент модифицируемого для повторного использования кода; 1М — процент затрат на интеграцию и тестирование повторно используемых компонентов;
Би — фактор понятности повторного использования кода, от 10 для простого, хорошо структурированного, до 50 для сложного и непонятного; равен 0, если СМ = РМ = 0.
Все коэффициенты, кроме Кгеч и МР, имеют те же значения, что и в предыдущей модели. Коэффициент Кгеч вычисляется как:
Процент кода, выброшенного из-за изменений в требованих 100 .
Kn
= 1 +
повых «классических» архитектур разработки программного обеспечения.
Полезность моделей оценки трудоемкости разработки программных систем заключается в наличии не интуитивного, а собирательного вычислительного инструментария, основанного на анализе опыта разработки множества проектов и выделения закономерностей поведения затрат в зависимости от множества факторов. Эта модель, как и любая другая, — лишь упрощенное отражение реальности. Она не претендует на стопроцентную точность. Это и есть компромисс между опытом программистской общественности и индивидуумом или группой аналитиков, которым предстоит оценить трудоемкость разработки и, следовательно, ее бюджет.
Si
ю
8
«о
О!
1 %
§
Коэффициент МР является произведением 17 коэффициентов затрат, имеющих значения от 1 до 6:
• надежность продукта;
• сложность продукта;
• размер базы данных разрабатываемого приложения;
• требуемый уровень повторного использования;
• требуемый уровень документированности;
• уровень производительности по времени;
• уровень требований к занимаемой оперативной памяти;
• изменчивость платформы;
• возможности аналитика проекта;
• возможности программистов;
• опыт работы команды в данной предметной области;
• опыт работы команды с используемыми платформами;
• опыт работы команды с используемыми языками и инструментами;
• уровень текучести персонала в команде;
• возможности используемых инструментов;
• возможности общения между членами команды;
• фактор сжатия графика проекта.
Расчетные методики, приведенные выше,
предназначены, прежде всего, для оценки стоимости программных систем на основе ти-
СПИСОК ЛИТЕРАТУРЫ
1. Михайловский Н. Методы оценки стоимости проектов по разработке информационных систем / Лаборатория НИР. 2008. URL: http:/www.ntrlab.ru/ publications/190.
2. Алиев X. Р. Эффективная модель оценки разработки программного обеспечения // Исследовано в России. 2008. № 2.
3. Борисов М. Б. Scrum: гибкое управление разработкой / Открытые системы. 2007. № 5. URL: http:/ www.osp.ru.
4. Андржеевский С. О. Практики XP: Гибкое управление разработкой // Открытые системы, 2008. № 3. URL: http:Zwww.osp.ru/os/2008/os/2007/04/4220063.
5. Morris P. M. and Desharnais J. M. Function Point Analysis Vlidating The Result / New-York. 2001. July 19.
6. Barry W. Boehm Software Cost Estimation with Cocomo II // Prentice Hall PTR. 2000. August 11.
7. Dennis M. A., Clouse A., Turner R. CMMI Distilled (A Practical Introduction to Integrated Process Improvement). Second Edition. New York: Addison Wesley, 2005.
8. Nonaka I., Takeuchi H. The New Product Development Game / Harvard Business Review. 1986. January-February.
9. Schwaber K., Sutherland J., Scrum Development Process in OOPSLA Business Object Design and Implementation Workshop. London: Springer, 1997.
10. Schwaber K. Agile Project Management with Scrum // Microsoft Press. 2004.
43
