Методы оценки - Обзор

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

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

Прошлые данные / Прошлый опыт
Доступные документы / знания
Assumptions
Выявленные риски

Четыре основных шага в оценке программного проекта:

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

Наблюдения за оценкой

Оценка не обязательно должна быть разовой задачей в проекте. Это может произойти во время -
- Приобретение проекта.
- Планирование проекта.
- Выполнение проекта по мере необходимости.
Объем проекта необходимо понять до начала процесса оценки. Было бы полезно иметь исторические данные проекта.
Метрики проекта могут предоставить историческую перспективу и ценные данные для получения количественных оценок.
Планирование требует, чтобы технические менеджеры и команда разработчиков программного обеспечения взяли на себя первоначальные обязательства, поскольку это ведет к ответственности и подотчетности.
Прошлый опыт может очень помочь.
Используйте по крайней мере два метода оценки, чтобы получить оценки и согласовать полученные значения. Обратитесь к разделу "Методы разложения" в следующем разделе, чтобы узнать о согласовании оценок.
Планы должны быть итеративными и позволять вносить корректировки по мере прохождения времени и получения дополнительных сведений.

Общий подход к оценке проекта

Широко используется подход к оценке проекта: Decomposition Technique. Техники декомпозиции используют подход «разделяй и властвуй». Оценка размера, усилий и затрат выполняется поэтапно путем разделения проекта на основные функции или связанные действия по разработке программного обеспечения.

Step 1 - Понять объем создаваемого программного обеспечения.

Step 2 - Сделайте оценку размера программного обеспечения.

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

Step 3- Сделайте оценку усилий и затрат. Вы можете получить оценку усилий и затрат, разбив проект на связанные действия по разработке программного обеспечения.

Определите последовательность действий, которые необходимо выполнить для завершения проекта.
Разделите деятельность на задачи, которые можно измерить.
Оцените усилия (в человеко-часах / днях), необходимые для выполнения каждой задачи.
Объедините оценки усилий по задачам деятельности, чтобы получить оценку деятельности.
Получите единицы затрат (т. Е. Затраты на единицу усилий) для каждого действия из базы данных.
Вычислите общие усилия и затраты для каждого действия.
Объедините смету усилий и затрат для каждого вида деятельности, чтобы получить общую смету усилий и затрат для всего проекта.

Step 4- Согласование оценок: сравните результаты, полученные на шаге 3, со значениями, полученными на шаге 2. Если оба набора оценок совпадают, то ваши числа очень надежны. В противном случае, если оценки сильно расходятся, проведите дополнительное расследование относительно того, -

Масштаб проекта недостаточно понят или неправильно истолкован.
Разбивка функций и / или действий неточная.
Исторические данные, используемые для методов оценки, не подходят для приложения, устарели или были применены неправильно.

Step 5 - Определите причину расхождения, а затем сверьте оценки.

Точность оценки

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

Важными факторами, влияющими на точность оценок, являются:

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

Ниже приведены некоторые рекомендации для получения надежных оценок.

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

См. Раздел «Рекомендации по оценке» в этой главе.

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

Проблемы с оценкой

Часто руководители проектов прибегают к оценке графиков, пропуская прикидки, чтобы оценить размер. Это может быть связано с графиком, установленным высшим руководством или командой маркетинга. Однако по какой бы то ни было причине, если это будет сделано, на более позднем этапе будет трудно оценить графики, чтобы учесть изменения в объеме.

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

Даже хорошие оценки имеют неотъемлемые допущения, риски и неопределенность, и все же они часто рассматриваются как точные.

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

Вы также можете включить неопределенность в качестве сопутствующего значения вероятности. Например, существует 90% -ная вероятность того, что проект будет завершен в определенную дату или раньше.
Организации не собирают точные данные о проектах. Поскольку точность оценок зависит от исторических данных, это будет проблемой.
Для любого проекта существует максимально короткий график, который позволит вам включить необходимый функционал и произвести качественный результат. Если есть ограничение по расписанию со стороны руководства и / или клиента, вы можете обсудить объем и функциональные возможности, которые будут доставлены.
Согласуйте с клиентом обработку перебоев в объеме, чтобы избежать превышения графика.
Неспособность учесть непредвиденные обстоятельства в окончательной оценке вызывает проблемы. Например, для встреч, организационных мероприятий.
Использование ресурсов следует рассматривать как менее 80%. Это потому, что ресурсы будут продуктивными только 80% своего времени. Если вы назначаете ресурсы с загрузкой более 80%, неизбежны задержки.