Оценка программного обеспечения

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

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

«Дайте свои собственные оценки, а затем умножьте их на три». Так, согласно этой известной мудрости, и следует действовать при оценке затрат на разработку программного обеспечения. А эту важнейшую задачу бизнеса, как считает Стив Макконнелл, хорошо умеют решать лишь очень немногие компании. Макконнелл — ведущий разработчик ПО компании Construx Software Builders, занимающейся созданием программного обеспечения, обучением и консалтингом. Ему принадлежит также и книга «Оценка программного обеспечения: разоблачение черной магии» (Software Estimation: Demystifying the Black Art), Microsoft Press, 2006.

В то же время точно оценить затраты на разработку программного обеспечения становится довольно просто, если понять, из чего состоит процесс создания ПО. Макконнелл ответил на вопросы корреспондента Computerworld Джулии Кинг.

Оценка — это определение аналитическими средствами, в какую сумму обойдется проект и сколько времени потребуется на его реализацию. Цель — это описание желательного результата: «Выпустить продукт к открытию выставки или к началу сезона предпраздничных распродаж». Цель вовсе не обязательно выражает то, что возможно. Здесь как раз вполне допустимо принимать желаемое за действительное.

Зачастую высшее руководство ошибочно принимает за цель проекта, например, непревышение некоего уровня затрат на него. Отсюда впоследствии и возникает недовольство по поводу чрезмерных расходов.

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

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

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

Цель сбора такой информации — создать модель, которую можно будет использовать для оценок затрат в будущем. Когда именно вы сможете начать собирать такие данные, зависит от модели, принятой для управления проектом. Если используется интерактивный подход и компания выпускает программное обеспечение отдельными компонентами, то соответствующие сведения можно получить уже после того, как выполнено всего 5-7% проекта. Если для управления проектом выбрана более последовательная каскадная модель, то нужную информацию быстро получить не удастся.

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

Десять советов, как получить точную оценку затрат

1. Не следует умышленно ее занижать. Заведомо нереальные показатели в итоге обойдутся дороже, чем завышенная оценка.
2. Не следует указывать "процент уверенности", если у вас для этого нет количественной базы.
3. Не занижайте оценки, данные разработчиками, поскольку, скорее всего, эти показатели и так чересчур оптимистичны.
4. Попытайтесь оценить размер создаваемого программного обеспечения (в строках кода). В первую очередь именно этот показатель позволяет определить трудозатраты и установить сроки выполнения проекта.
5. Не следует рассчитывать на то, что трудозатраты будут расти линейно при увеличении масштабов проекта. Скорее они будут увеличиваться экспоненциально.
6. Используйте уже имеющиеся данные как основу для оценки производительности.
7. Используйте сведения, касающиеся уже выполненного объема работ, для получения более точных оценок затрат по оставшейся части проекта.
8. Оценки на уровне задач должны делать те специалисты, которые будут выполнять эту работу.
9. Сравнивайте реальную производительность с предполагаемой для того, чтобы со временем уточнять оценки производительности каждого отдельного участника проекта.
10. Не следует сокращать сроки реализации, если вы одновременно не предполагаете увеличить трудозатраты.

Из книги «Оценка программного обеспечения: разоблачение черной магии»