49. Методы оценки трудозатрат, длительности и стоимости выполнения программного проекта.

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

1. Человеческий фактор, связан с опытом и знаниями компании которая занимается разработкой ПО;

2. Ресурсные факторы, характеризующие наличие ресурсов для разработки программных продуктов;

3. Проблемный фактор, определяемый сложностью проблемы, которая должна быть решена;

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

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

Определение профессионального подхода к разработке ПО, данное Институтом инженеров по электротехнике и радиоэлектронике (Institute of Electrical and Electronics Engineers, IEEE), расширяет разработку информационных систем за границы известной модели усовершенствования процессов разработки программного обеспечения SW CMM2, добавляя такие этапы, как выявление требований, ввод ПО в эксплуатацию, его эксплуатация и сопровождение.

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

• недостаточно продуманный план менеджера проекта (Project Manager), иными словами, неправильное управление проектом;

• неполная или неточная спецификация на проект (Specification), а также требования заказчика, которые меняются в процессе разработки;

• некачественная оценка проекта (Estimation); составляющие бюджета, не оговоренные на предварительных этапах планирования проекта.

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

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

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

Попытаемся выделить факторы, приводящие к неправильной оценке разработки:

• незнание методик или отсутствие опыта оценки проекта: это часто встречающаяся в 1Т-компаниях и, наверное, самая существенная проблема;

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

• ошибка аналитиков в оценке трудоемкости;

• недопонимание ключевых технических проблем (как правило, связано с сжатым графиком работ по проекту);

• недостаток времени на изучение документации заказчика ПО.

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

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

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

Наиболее известными и востребованными методологиями из семейства Agile являются:

• практика экстремального программирования (Extreme Programming, XP);

• методология Scrum.

Компании-разработчики ПО столкнулись сегодня с необходимостью вносить многочисленные изменения в требования к разрабатываемому продукту уже в процессе разработки, а традиционные методологии плохо поддерживают изменения в спецификациях после их первоначального определения. Чем длительнее проект, тем труднее и опаснее вносить в него изменения. С другой стороны, современный программный проект неизбежно сопровождается многочисленными изменениями по ходу дела, и зачастую спецификации успевают устареть еще до того, как они полностью определены. Методология XP — это попытка сформулировать набор практик, которые минимизируют стоимость изменений и позволяют производить их почти одинаково легко и безопасно как в начале, так и в конце проекта. В XP-проекте благодаря таким правилам, как «Модульное тестирование», «Парное программирование», «Ничего заранее», «Простейшие решения» и др. стоимость изменений значительно ниже.

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

1) отказаться от изменения, сочтя его неоправданно дорогостоящим;

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

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

4) перенести изменение на следующую итерацию, переопределив его в пользовательскую историю.

Эта процедура позволяет четко контролировать объем функциональности в пределах итерации и не допускать его непрогнозируемого роста, что в конечном счете выгодно и команде, и заказчику. Без строгого подхода к управлению изменениями заказчик может легко перегрузить команду. Это, в свою очередь, приводит к снижению качества всего проекта или даже его полному провалу. Чтобы избежать возможных недоразумений, менеджеру желательно сразу предупредить неопытного в ХР заказчика, что любая новая функциональность, отсутствующая в первоначальных пользовательских историях и несогласованная в процессе игры в планирование, является изменением, внесенным заказчиком, и требует соответствующей оценки и обсуждения, другими словами, не делается бесплатно.

Основа Scrum — итеративная разработка. Scrum определяет правила, по которым должен планироваться и управляться список требований к продукту для достижения максимальной прибыльности от реализованной функциональности; правила планирования итераций для максимальной заинтересованности команды в результате; основные правила взаимодействия участников команды для максимально быстрой реакции на существующую ситуацию; правила анализа и корректировки процесса разработки для совершенствования взаимодействия внутри команды. Каждую итерацию можно описать так: планируем — фиксируем — реализуем — анализируем. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разработки.

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

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

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

Scrum-команда (Scrum Team) — группа, состоящая из пяти-девяти самостоятельных, инициативных программистов. Первая задача этой команды — поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача — сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по определенным проектом «стандартам кодирования» (coding guidelines), программа протестирована полностью, а все найденные дефекты устранены. Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализировать и улучшать качество взаимодействия и работы. В обязанности всех членов Scrum-команды входит участие в выборе цели итерации и определение результата работы. Они должны делать все возможное и невозможное для достижения цели итерации в рамках, определенных проектом, эффективно взаимодействовать со всеми участниками команды, самостоятельно организовывать свою работу, предоставлять владельцу рабочий продукт в конце каждого цикла.

Классические методики оценки стоимости разработок

Проанализируем, как осуществляется оценка трудоемкости разработки информационных систем в основных моделях: модели функциональных точек (Functional Points) и модели COCOMO II. Эти модели используют все ведущие фирмы по разработке ПО в мире для предварительных оценок как трудозатрат, так и бюджета проекта. Отметим, что заказчики крупных ИС также используют модели оценивания с тем лишь отличием, что в моделях оценивания не учитываются конкретные условия разработки: заказчику интересен результат и стоимость, в то время как для исполнителя важны соответственно условия и в меньшей степени стоимость.

В конце 1970-х гг. Барри Боэмом (Barry Boehm) была предложена модель оценивания объемов работ при разработке информационных систем. Эта модель получила название «конструктивная модель стоимости» (Constructive COst MOdel — COCOMO). На сегодняшний день данная модель оценки трудоемкости разработки программного обеспечения является наиболее известной среди множества подобных. Она основана на анализе ряда проектов, реализованных по заказу Министерства обороны США. В общих чертах данная модель, с одной стороны, определяет соответствие между размером системы в тысячах условных строк кода и «классом» проекта, а с другой — трудоемкость разработки системы.

Модель COCOMO условно разделяет проекты только на три класса: ограниченные, полуинтегрированные, «встроенные системы».

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

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

Проекты «встроенных систем» выполняются при значительных аппаратных, программных и организационных ограничениях; имеются жесткие ограничения по спецификации.

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

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

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

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

• атрибуты команды разработчиков, такие как знания прикладной области, аналитические способности, опыт разработки, опыт в данном языке программирования;

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

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

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

Программное приложение в сущности определяется набором элементарных процессов. Существует два основных типа элементарных процессов — данные в движении и данные в покое. Данные в движении описывают потоки данных из приложения вовне и извне в приложение. На концептуальном уровне анализ функциональных точек помогает определить два абстрактных уровня данных — в покое и в движении.

Описание методики COCOMO II

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