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

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

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

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

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

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

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

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

    • Приобретение проекта.
    • Планирование проекта.
    • Выполнение проекта по мере необходимости.
  • Масштаб проекта должен быть понят до начала процесса оценки. Будет полезно иметь исторические данные проекта.

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

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

  • Опыт прошлого может очень помочь.

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

  • Планы должны быть итеративными и позволять вносить коррективы с течением времени и узнавать больше деталей.

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

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

Шаг 1 - Понимание объема программного обеспечения, которое будет построено.

Шаг 2 - Генерация оценки размера программного обеспечения.

  • Начните с определения объема.

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

  • Рассчитать размер каждой функции.

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

  • Объедините оценки функций, чтобы получить общую оценку для всего проекта.

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

  • Определите последовательность действий, которые необходимо выполнить для завершения проекта.

  • Разделите деятельность на задачи, которые можно измерить.

  • Оцените усилия (в человеко-часах / днях), необходимые для выполнения каждой задачи.

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

  • Получите единицы затрат (т. Е. Затраты / единичные усилия) для каждого действия из базы данных.

  • Вычислите общее усилие и стоимость для каждого действия.

  • Объедините оценки усилий и затрат для каждого вида деятельности, чтобы получить общую оценку усилий и затрат для всего проекта.

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

  • Масштаб проекта недостаточно понят или неверно истолкован.

  • Распределение функций и / или действий не является точным.

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

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

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

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

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

  • Точность всех входных данных оценки.

  • Точность любого сметного расчета.

  • Насколько близко исторические данные или отраслевые данные, использованные для калибровки модели, соответствуют оцениваемому проекту.

  • Предсказуемость процесса разработки программного обеспечения вашей организации.

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

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

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

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

Обратитесь к разделу «Рекомендации по оценке» в этой главе.

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

Вопросы оценки

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

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

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

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

  • Вы также можете включить неопределенность в качестве сопутствующего значения вероятности. Например, существует 90% вероятность того, что проект будет завершен в определенную дату или раньше.

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

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

  • Договоритесь с клиентом о том, как обрабатывать перепады объема, чтобы избежать превышения графика.

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

  • Использование ресурсов следует рассматривать как менее 80%. Это потому, что ресурсы будут продуктивными только на 80% своего времени. Если вы назначаете ресурсы более чем на 80%, это может привести к проскальзыванию.

Руководство по оценке

При оценке проекта следует учитывать следующие рекомендации:

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

  • Предположим, что ресурсы будут продуктивными только для 80 процентов их времени. Следовательно, при оценке принимайте коэффициент использования ресурсов менее 80%.

  • Ресурсы, работающие над несколькими проектами, занимают больше времени для выполнения задач из-за потери времени на переключение между ними.

  • Включите время управления в любой оценке.

  • Всегда создавайте непредвиденные обстоятельства для решения проблем, встреч и других неожиданных событий.

  • Дайте достаточно времени, чтобы сделать правильную оценку проекта. Срочные оценки являются неточными оценками высокого риска. Для крупных девелоперских проектов шаг оценки должен рассматриваться как мини-проект.

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

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

  • Используйте несколько разных людей, чтобы оценить и использовать несколько разных методов оценки.

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

  • Пересмотреть проект несколько раз в течение его жизненного цикла.