Базовая методика оценки затрат заключается в следующем:
Шаг 1. Формируются общие требования к системе исходя из существующего технического задания. Потенциальных разработчиков информируют о том, что ожидают от системы. Этот документ именуют «списком пожеланий». Для более точного определения требуемых ресурсов проводится анализ требований.
Шаг 2. Собирается аналогичная информация, например данные о подобных системах.
Шаг 3. Отбираются основные релевантные данные.
Шаг 4. Проводится предварительная оценка.
Шаг 5. Проводится окончательная оценка системы.
Основной этап этой работы — шаг 4. При его выполнении проводятся следующие действия.
Шаг 4а. Сравнение проектируемой системы с подобными уже разработанными системами.
Шаг 4б. Разбиение системы на части и сравнение каждой из этих частей с подобными ей частями других систем.
Шаг 4в. Планирование работ и оценка затрат на каждый месяц.
Шаг 4г. Разработка соглашений, которые могут быть использованы при работе.
Отметим, что реализация шага 4а при отсутствии достаточного опыта может занять довольно продолжительный период времени. Шаг 4б требует тщательного определения понятия «часть системы». Не отличается строгим регламентом и шаг 4г, так как нет адекватного набора стандартных соглашений. Поэтому в реальной практике используются различные модификации рекомендуемого метода, базирующиеся либо на более формализованных понятиях, либо на субъективных оценках.
Метод экспертных оценок. Оценка производится исходя из личного опыта квалифицированного проектировщика (эксперта). Для многих приложений проектировщики могут прогнозировать сложность системы и оценку ресурсных затрат, даже если алгоритмы еще в явном виде не определены. Подобная оценка основывается на опыте работы проектировщика над схожей системой. Однако при этом очень велико влияние субъективных факторов, так что метод в целом не лучше, чем искусство отдельного проектировщика. Тем не менее при отсутствии строгой теории и недостатке эмпирических знаний этот метод принимается за основу стратегии оценки затрат.
Метод алгоритмического анализа. При данном методе оценки затрат используется некоторый алгоритм. Оценка является объективной и повторяемой. Сейчас теория подобных алгоритмов развивается довольно бурно, однако пока на практике применяется лишь небольшое число подобных алгоритмов. Кроме того, алгоритм приводит к правильным результатам лишь в том случае, если используемые для расчетов данные (спецификации) достаточно точны, что редко бывает на практике.
Пошаговый анализ. Задаются спецификации на основе пошагового анализа по нисходящему либо восходящему принципу, так что каждая определенная таким образом задача оценивается отдельно. Такой полуалгоритмический процесс может быть скомбинирован с такими методами, как метод экспертных оценок.
Закон Паркинсона. Во многих случаях для выполнения некоторой работы (задачи) затрачивается то время, которое отведено для нее, независимо от того, является ли выполнение этой работы необходимым. Каждый исполнитель вносит какой-то вклад в работу над системой и расходует определенное время. Подобный подход опирается на использование других методов, т.е. если оценка уже произведена (например, с помощью экспертов), все привлекаемые исполнители будут выполнять свою работу безотносительно к ее важности и необходимости. При подобном подходе структура системы зачастую определяется составом коллектива разработчиков (если над системой работает 3 человека, то она, скорее всего, будет состоять из трех сегментов).
Затраты на завершение разработки. В некоторых случаях стоимость системы, оговариваемая при заключении договора, намеренно занижается разработчиком системы в надежде, что в последующем ее можно будет существенно увеличить за счет изменения спецификаций. После заключения договора на разработку какой-то части системы изменение спецификаций происходит по соглашению между разработчиком и заказчиком без участия других лиц. В этом случае разработчик находится в более выгодном положении, чем заказчик, поскольку на разработку системы уже затрачены значительные средства и для заказчика нецелесообразно начинать ее заново с привлечением других специалистов. Заказчику следует проявлять осмотрительность в отношении предложений, резко отличающихся от других. Более того, он должен тщательно проводить анализ системных требований, чтобы избежать необходимости изменения спецификаций.
Психологический аспект. В некоторых случаях оценки стоимости системы различными разработчиками довольно близки. Проведенный ими алгоритмический анализ проблемы остается впечатляющим до тех пор, пока не проведен более тщательный анализ. В подобных случаях разработчики просто осведомлены о наличии средств у заказчика.
В общем случае точную оценку затрат можно дать лишь на основе опыта.