Оценка программных проектов

Я думаю каждый разработчик сталкивается с вопросом: «Сколько это займет времени?». Мы слышим этот вопрос в своей работе почти всегда:

  • Начальство хочет запустить новый проект? Сколько времени займет разработка?
  • Необходимо реализовать новую фичу в уже работающем проекте? Сколько времени это займет?
  • Необходимо полностью переделать проект? Сколько?

Сколько? Сколько? Сколько? Одним сплошные вопросы.

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

Для начала Стив говорит, что оценка при разработке программного обеспечения напрямую связана с целями организации. Цели могут быть разными:

  • Выпустить новую версия ПО к выставке.
  • Уложиться в определенные затраты, так как больше денег просто нет.
  • и т.д.

Оценка программных проектовЗная цели организации всегда можно найти какой-то компромисс. Предположим, что Ваш менеджер попросил Вас оценить проект. Вы не долго думая прикинули и определили, что проект займет полгода. На представленные Вами данные менеджер помотает головой и скажет: «У нас нет столько времени. 4 месяца не более.» Вот тут и начинается самое интересное. Дело в том, что от Вас не ожидали оценки, она никому не нужна. Начальство хочет просто услышать: «Да мы выполним эту работу за 4 месяца.» Брать на себя такие обязательства самоубийство потому Вы решаете узнать, почему необходимо выполнить проект за 4 месяца. Оказывается, ровно через 4 месяца необходимо представить продукт потенциальным покупателям, если этого не сделать, то компания не получит финансирования.

Выход из такой казалось бы безвыходной ситуации есть, и он прост. Можно предложить реализовать за 4 месяца основной функционал и выпустить бета-версию по которой можно будет оценить программу. С одной стороны ПО не будет закончено до конца, но с другой стороны цель (показать рабочую программу потенциальным покупателям) будет выполнена, и полная версия будет спокойно выпущена через 6 месяцев.

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

Размер проекта измеряют в строках кода, и он является одним из самых важных факторов. Благодаря количеству строк мы можем точно сказать, что проект в 25 000 строк будет явно меньше, чем проект в 150 000 строк.

Тип разрабатываемого ПО - фактор по которому мы можем сравнить производительности написания кода. Например, у нас есть три проекта: «Проект А» (100 000 строк), «Проект Б» (125 000 строк) и «Проект В» (90 000 строк). Кажется, что затраты на все эти проекты должны быть примерно идентичны. Однако мы не указали типы наших проектов из которых следует, что «Проект А» разрабатывался для космической промышленности, а остальные проекты являются обычными бизнес-системами. Зная это можно сказать, что усилия, затраченные на проекты Б и В были раз в 10 меньше, чем на проект А, так как примерно на столько различается скорость генерации кода для данных типов систем.

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

Книга будет полезна любому, кого интересует оценка программных проектов.