С. Б.
Кэтлин Питерс, редактор журнала Application development strategies, задается вопросом: как оценить размер проекта по созданию ПО? Это самый важный момент во всем цикле производства продукта. Не ответив на этот вопрос, невозможно корректно спланировать свою работу и управлять ею. Неправильная оценка размера проекта приведет к снижению качества продукта или к нарушению сроков его создания. Если же сумма на проект отпущена с запасом, то, как показывает практика, она обязательно будет потрачена полностью.
Кэтлин Питерс рекомендует разбить весь процесс оценки характеристик проекта на четыре этапа.
1. Оценка размера проекта. Чаще всего проект оценивается в строках кода, в функциональных точках (этот способ активно использует “Аргуссофт”), по числу модулей, классов, методов, функций, экранов, диалогов, файлов, таблиц в БД, отчетов и т. д.
Это самый важный этап. Здесь нельзя допустить ошибки, поскольку это непременно приведет к ошибкам во всех других оценках. Чтобы научиться правильно оценивать размеры проектов, надо накопить определенный опыт, измеряя в процессе создания ПО абсолютно все параметры работы, как количественные, так и качественные. Такой опыт - самый ценный для развития компании.
Размер новых проектов можно оценивать по аналогии со старыми, выделяя в них ключевые модули и определяя их процент в размере всего проекта.
2. Оценка рабочего времени в человеко-часах. Это возможно, если в компании поддерживается формальная технология создания ПО на протяжении всего жизненного цикла продукта - составление спецификации, проектирование, разработка, тестирование, внедрение. Кодирование при этом - самая малая, наименее важная и наименее творческая часть всей работы. Основной объем деятельности должен приходиться на ведение сопроводительной документации (что для наших компаний абсолютно непривычно), создание прототипов продукта, проектирование системы, обзоры и формальный анализ программного кода (без компиляции и использования отладчиков!).
Требуемое на проект время оценивается на основе информации об успешно завершенных аналогичных проектах (при условии, что компания документировала свою работу) с учетом производительности каждого сотрудника. Есть и другие методики определения рабочего времени (например, COCOMO), но они менее точны, чем анализ своего опыта.
3. Составление календарного плана. Он расписывается по рабочим дням и участникам проекта - сколько их, кто, что и когда будет делать. Создается специальная группа, которая будет следить за ходом выполнения плана, и в случае отклонения числовых характеристик проекта от запланированных предпримет корректирующие действия.
4. Оценивается стоимость проекта (в условных единицах). Это наименее трудоемкий этап, выполняемый с использованием данных третьего этапа.
