Методы оценки проекта при разработке ПО

Хорошая статья о методологии оценок проекта при разработке ПО.

Методы оценки проекта разработки ПО

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

Итак, Методы оценки проекта разработки ПО…

Существует как минимум 3 смертельных ошибки, которые может совершить менеджмент проекта разработки ПО. Плохое управление проектом, «плывущие» требования и неправильная оценка проекта. Неправильную оценку проекта нельзя исправить никакими подходами к управлению проектом. Ее можно только искупить, например, заплатив неустойку. Основные причины неправильной оценки проекта:

1. Отсутствие опыта или методики оценки проекта
2. Непредвиденные проблемы в используемых средствах и компонентах
3. Непонимание ключевых технических проблем проекта

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

1. Методы микрооценки основаны на точном знании процесса. Например, Oracle AIM и оценки трудоемкости для него. В этом методе для построения оценки необходимо построение разбивки работ и оценка каждой индивидуальной работы.
2. Методы макрооценки, основаны на функциональных требованиях и/или продукте. Таковы методы функциональных точек и методы типа СОСОМО.

Микрооценка хороша своей предельной конкретикой. Оценка обосновывается не на базе подсчета неких «функциональных точек» или кем-то собранной статистики, а на основе анализа выявленных задач. Это вызывает доверие заказчика.
Простое и верное применение метода микрооценки излагает в своем блоге Станислав Малкин. Его правила вполне подходят для фрилансера или для небольшой команды:

1. Разбейте общую задачу на подзадачи, так, чтобы каждая подзадача минимально была связана с другой подзадачей.
2. Проанализируйте требования клиента, насколько они детальны? Если не хватает детализации – значит нужно выяснить у клиента эти моменты.
3. Попробуйте оценить каждую из подзадач по срокам.
4. Добавьте к срокам, определенным Вами в п.3 +25-30% от времени. Как бы это не звучало странно – мы всегда оценивает сроки слишком оптимистично и как правило ошибаемся. Буфер в 25-30% должен Вам помочь в решении этой проблемы.
5. Ответьте на вопрос: будете ли Вы тратить какое-то количество времени на общение с клиентом? Если да – то заложите это время тоже в бюджет. Вы не должны делать это за бесплатно.
6. Сложите количество часов, полученных в результате пунктов 1-5, и сделайте оценку проекту, исходя из оплаты за час Вашей работы.

Другой, тоже довольно удачный свод правил для оценки на английском языке вы найдете в статье 7 Tips on Quoting Freelance Projects.

Намного более серьезно проработана методика Oracle AIM – Application Implementation Method – методика внедрения готовых приложений, разработана компанией Оракл для внедрения пакета готовых приложений Oracle E-Business Suite. Эта методика вполне подходит и для оценки проектов. По сути это те же 6 правил фрилансера, поднятые на более высокий уровень.
AIM(Applications Implementation Method – представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности выполнения и ответственных ролей проектной группы. Задача в терминах методики AIM представляет собой элементарный (неделимый) объем работ, который обязательно заканчивается формально фиксируемым результатом. Схема ниже иллюстрирует разбиение задач по процессам и фазам внедрения. По горизонтали указаны процессы, разбиение по вертикали – фазы.

Oracle AIM

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

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

1. Если платят за время, то оплата производится регулярно, как правило, помесячно. Бюджет определен нечетко. Исполнитель не связан никакими рамками по стоимости и любые запросы заказчика исполняются без пререканий ( что желаете за ваши деньги ). Все риски тут ложатся на заказчиков, в этом случае заказчики как правило стремятся к микроменеджменту. Микроменеджмент – это зло, с которым очень трудно бороться (потому что носителем зла является руководство компании) и которое разрушает любой бизнес.

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

Нужна единица измерения проекта, которая:

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

Такой единицей измерения предлагается считать «функциональную точку», впервые предложенную сотрудником IBM Аланом Альбрехтом (Allan Albrecht) в 1979 г. В контексте анализа требований к системе «функциональная точка» это отдельное поведение, видимое извне и поддающееся проверке. Неплохая статья есть на CodeProject. Только список аббревиатур напоминает пантеон богов индуисского храма 🙂 Функциональная точка удачно пришла на замену количеству строк кода.

Методы макрооценки использующие именно эту единицу измерения призваны разрешить непреодолимое противоречие контракта, с которым заказчики и исполнители сталкиваются при использовании методов микрооценки.

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

Другую группу методов макрооценки составляют экспертные или эмпирические методы. Кратко познакомимся с одним таким методом COCOMO II (COCOMO – COnstructive COst Model ). Это де факто стандарт эмпирической оценки. COCOMO создана на основе анализа статистических данных 63 проектов различных типов. Фактически под общим названием скрываются три уровня детализации: базовый, промежуточный и подробный. Также предусмотрено три режима использования модели в зависимости от размеров команды и проекта. В сущности, этот метод представляет собой классификацию проектов и набор соответствующих формул и коэффициентов расчета стоимости для каждого отдельного типа проекта.

На практике, чаще конечно применяется микрооценка, как более понятная методика. Ее результаты проще использовать при заключении контрактов. Макрооценку исполнители применяют для внутреннего аудита проекта.

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

В заключение хочу привести слова Уокера Ройса, генерального директора Rational Software,: «на самом деле, в большинстве случаев стоимостные модели используются “от противного” (для подтверждения объявленной стоимости), а вовсе не по прямому назначению (для определения той цены, которую следовало бы запросить).»