Методы оценки - Краткое руководство

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

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

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

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

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

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

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

  • Приобретение проекта.
  • Планирование проекта.
  • Выполнение проекта по мере необходимости.

• До начала процесса оценки необходимо понять объем проекта. Было бы полезно иметь исторические данные проекта.

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

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

• Прошлый опыт может очень помочь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Разбивка функций и / или действий неточная.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по оценке

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

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

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

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

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

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

• Выделите достаточно времени для правильной оценки проекта. Срочные оценки - это неточные оценки с высоким уровнем риска. Для крупных девелоперских проектов этап оценки действительно следует рассматривать как мини-проект.

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

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

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

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

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

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

Для определения размера программного обеспечения на основе FP появилось несколько признанных стандартов и / или общедоступных спецификаций. По состоянию на 2013 год это -

Стандарты ISO

• COSMIC- ISO / IEC 19761: 2011 Программная инженерия. Метод измерения функционального размера.

• FiSMA - ISO / IEC 29881: 2008 Информационные технологии - Программное обеспечение и системная инженерия - Метод измерения функционального размера FiSMA 1.1.

• IFPUG - ISO / IEC 20926: 2009 Разработка программного обеспечения и систем - Измерение программного обеспечения - Метод измерения функционального размера IFPUG.

• Mark-II - ISO / IEC 20968: 2002 Разработка программного обеспечения - Анализ функциональных точек MI II - Руководство по методам подсчета.

• NESMA - ISO / IEC 24570: 2005 Разработка программного обеспечения - Метод измерения размера функции NESMA версия 2.1 - Определения и рекомендации по подсчету для применения анализа функциональных точек.

Спецификация группы управления объектами для автоматизированной функциональной точки

Object Management Group (OMG), некоммерческий консорциум стандартов компьютерной индустрии с открытым членством, принял спецификацию Automated Function Point (AFP) под руководством Консорциума по качеству программного обеспечения ИТ. Он обеспечивает стандарт для автоматизации подсчета FP в соответствии с рекомендациями Международной группы пользователей функциональных точек (IFPUG).

Function Point Analysis (FPA) techniqueколичественно оценивает функции, содержащиеся в программном обеспечении, в терминах, значимых для пользователей программного обеспечения. FP учитывают количество разрабатываемых функций на основе спецификации требований.

Function Points (FP) Countingрегулируется стандартным набором правил, процессов и рекомендаций, определенных Международной группой пользователей функциональных точек (IFPUG). Они опубликованы в Руководстве по практике подсчета (CPM).

История анализа функциональных точек

Концепция функциональных точек была введена Аланом Альбрехтом из IBM в 1979 году. В 1984 году Альбрехт усовершенствовал этот метод. Первые рекомендации по функциональным точкам были опубликованы в 1984 году. Международная группа пользователей функциональных точек (IFPUG) - это всемирная организация пользователей программного обеспечения для анализа функциональных точек в США. ВInternational Function Point Users Group (IFPUG)- это некоммерческая организация, управляемая членами, основанная в 1986 году. IFPUG владеет анализом функциональных точек (FPA), как определено в стандарте ISO 20296: 2009, который определяет определения, правила и шаги для применения метода измерения функционального размера (FSM) IFPUG. IFPUG поддерживает Руководство по методам подсчета функциональных точек (CPM). CPM 2.0 был выпущен в 1987 году, и с тех пор было сделано несколько итераций. Версия 4.3 CPM была выпущена в 2010 году.

Версия 4.3.1 CPM с внесенными редакционными изменениями ISO была выпущена в 2010 году. Стандарт ISO (IFPUG FSM) - Измерение функциональных размеров, который является частью CPM 4.3.1, представляет собой метод измерения программного обеспечения с точки зрения предоставляемых им функций. CPM - это международно признанный стандарт ISO / IEC 14143-1 «Информационные технологии - Измерение программного обеспечения».

Элементарный процесс (EP)

Элементарный процесс - это наименьшая единица функционального требования пользователя, которая:

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

Функции

Есть два типа функций -

• Функции данных
• Функции транзакции

Функции данных

Есть два типа функций данных -

• Внутренние логические файлы
• Файлы внешнего интерфейса

Функции данных состоят из внутренних и внешних ресурсов, которые влияют на систему.

Internal Logical Files

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

External Interface Files

Файл внешнего интерфейса (EIF) - это идентифицируемая пользователем группа логически связанных данных или управляющей информации, которая используется приложением только для справочных целей. Данные находятся полностью за пределами приложения и поддерживаются в ILF другим приложением. EIF имеет неотъемлемое значение, заключающееся в том, что он поддерживается извне, и для получения данных из файла необходимо разработать интерфейс. (См. Рисунок 1)

Функции транзакции

Есть три типа транзакционных функций.

• Внешние входы
• Внешние выходы
• Внешние запросы

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

External Inputs

Внешний ввод (EI) - это функция транзакции, в которой данные поступают «внутрь» приложения из-за границы внутрь. Эти данные поступают за пределы приложения.

• Данные могут поступать с экрана ввода данных или из другого приложения.
• EI - это то, как приложение получает информацию.
• Данные могут быть либо контрольной, либо деловой.
• Данные могут использоваться для поддержки одного или нескольких внутренних логических файлов.
• Если данные являются управляющей информацией, обновлять внутренний логический файл не нужно. (См. Рисунок 1)

External Outputs

Внешний вывод (EO) - это функция транзакции, при которой данные «выходят» из системы. Кроме того, EO может обновлять ILF. Данные создают отчеты или выходные файлы, отправляемые в другие приложения. (См. Рисунок 1)

External Inquiries

Внешний запрос (EQ) - это функция транзакции с компонентами ввода и вывода, которые приводят к извлечению данных. (См. Рисунок 1)

Определение RET, DET, FTR

Тип элемента записи

Тип элемента записи (RET) - это самая большая идентифицируемая пользователем подгруппа элементов внутри ILF или EIF. Лучше всего посмотреть на логические группы данных, чтобы помочь их идентифицировать.

Тип элемента данных

Тип элемента данных (DET) - это подгруппа данных в FTR. Они уникальны и идентифицируются пользователем.

Указанный тип файла

Ссылка на тип файла (FTR) - это самая большая подгруппа, идентифицируемая пользователем, в EI, EO или EQ, на которую делается ссылка.

Функции транзакции EI, EO, EQ измеряются путем подсчета FTR и DET, которые они содержат, в соответствии с правилами подсчета. Аналогичным образом, функции данных ILF и EIF измеряются путем подсчета DET и RET, которые они содержат, согласно правилам подсчета. Измерения функций транзакций и функций данных используются при подсчете FP, что приводит к функциональному размеру или функциональным точкам.

Процесс подсчета FP включает следующие шаги -

• Step 1 - Определите тип подсчета.

• Step 2 - Определите границу счета.

• Step 3 - Определите каждый элементарный процесс (EP), необходимый пользователю.

• Step 4 - Определите уникальные EP.

• Step 5 - Функции измерения данных.

• Step 6 - Измерьте транзакционные функции.

• Step 7 - Расчет функционального размера (нескорректированное количество функциональных баллов).

• Step 8 - Определите коэффициент корректировки значения (VAF).

• Step 9 - Рассчитайте количество скорректированных функциональных точек.

Note- Общие характеристики системы (GSC) сделаны необязательными в CPM 4.3.1 и перенесены в Приложение. Следовательно, шаги 8 и 9 можно пропустить.

Шаг 1. Определите тип подсчета

Есть три типа подсчета функциональных баллов:

• Подсчет очков функции развития
• Подсчет точек функции приложения
• Подсчет очков улучшенной функции

Подсчет очков функции развития

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

Подсчет точек функции приложения

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

Подсчет очков улучшенной функции

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

Шаг 2: Определите границу счета

Граница указывает границу между измеряемым приложением и внешними приложениями или доменом пользователя. (См. Рисунок 1)

Чтобы определить границу, поймите -

• Цель подсчета функциональных баллов
• Объем измеряемого приложения
• Как и какие приложения хранят какие данные
• Сферы деятельности, поддерживающие приложения

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

Составьте и / или разложите функциональные требования пользователя на наименьшую единицу деятельности, которая удовлетворяет всем следующим критериям:

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

Например, функциональное требование пользователя - «Ведение информации о сотрудниках» можно разделить на более мелкие действия, такие как добавление сотрудника, изменение сотрудника, удаление сотрудника и запрос о сотруднике.

Каждая идентифицированная таким образом единица деятельности представляет собой элементарный процесс (EP).

Шаг 4: Определите уникальные элементарные процессы

Сравнивая два уже определенных EP, считайте их одним EP (тем же EP), если они -

• Требуется такой же набор DET.
• Требуется такой же набор FTR.
• Требуется тот же набор логики обработки для завершения EP.

Не разделяйте EP с несколькими формами логики обработки на несколько Eps.

Например, если вы определили «Добавить сотрудника» как EP, его не следует разделять на два EP, чтобы учесть тот факт, что сотрудник может иметь или не иметь иждивенцев. EP по-прежнему является «Добавить сотрудника», и есть различия в логике обработки и DET для учета иждивенцев.

Шаг 5. Измерение функций данных

Классифицируйте каждую функцию данных как ILF или EIF.

Функция данных должна быть классифицирована как -

• Внутренний логический файл (ILF), если он поддерживается измеряемым приложением.

• Файл внешнего интерфейса (EIF), если он указан, но не поддерживается измеряемым приложением.

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

Рассмотрим следующую документацию для подсчета ILF и EIF -

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

Шаг 5.1: Подсчитайте DET для каждой функции данных

Примените следующие правила для подсчета DET для ILF / EIF:

• Подсчитайте DET для каждого уникального идентифицируемого пользователя, неповторяющегося поля, поддерживаемого или извлекаемого из ILF или EIF посредством выполнения EP.

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

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

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

Шаг 5.2: Подсчитайте RET для каждой функции данных

Примените следующие правила для подсчета RET для ILF / EIF:

• Подсчитайте один RET для каждой функции данных.
• Подсчитайте один дополнительный RET для каждой из следующих дополнительных логических подгрупп DET.
  • Ассоциативная сущность с неключевыми атрибутами.
  • Подтип (кроме первого подтипа).
  • Атрибутивная сущность в отношениях, отличных от обязательных 1: 1.

Шаг 5.3: Определите функциональную сложность для каждой функции данных

RETS	Типы элементов данных (DET)
	1-19	20-50	>50
1	L	L	А
От 2 до 5	L	А	ЧАС
> 5	А	ЧАС	ЧАС

Функциональная сложность: L = Низкий; A = Среднее; H = Высокий

Шаг 5.4: Измерьте функциональный размер для каждой функции данных

Функциональная сложность	Количество FP для ILF	Количество FP для EIF
Низкий	7	5
В среднем	10	7
Высоко	15	10

Шаг 6. Измерьте транзакционные функции

Чтобы измерить транзакционные функции, выполните следующие действия:

Шаг 6.1: классифицируйте каждую транзакционную функцию

Транзакционные функции следует классифицировать как внешний ввод, внешний вывод или внешний запрос.

Внешний вход

Внешний ввод (EI) - это элементарный процесс, который обрабатывает данные или управляющую информацию, поступающую извне. Основное назначение EI - поддерживать одну или несколько ILF и / или изменять поведение системы.

Должны применяться все следующие правила -

• Данные или управляющая информация поступает из-за пределов приложения.

• По крайней мере, один ILF поддерживается, если данные, входящие в границу, не являются управляющей информацией, изменяющей поведение системы.

• Для идентифицированного EP должно применяться одно из трех утверждений:

  • Логика обработки отличается от логики обработки, выполняемой другими EI для приложения.

  • Набор идентифицированных элементов данных отличается от наборов, определенных для других EI в приложении.

  • Упомянутые файлы ILF или EIF отличаются от файлов, на которые ссылаются другие EI в приложении.

Внешний выход

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

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

Логика обработки должна -

• Содержат хотя бы одну математическую формулу или расчет.
• Создавать производные данные.
• Поддерживайте один или несколько ILF.
• Измените поведение системы.

Должны применяться все следующие правила -

• Отправляет данные или управляющую информацию за пределы границы приложения.
• Для идентифицированного EP должно применяться одно из трех утверждений:
  • Логика обработки отличается от логики обработки, выполняемой другими ОР для приложения.
  • Набор идентифицированных элементов данных отличается от других ОР в приложении.
  • Упомянутые ILF или EIF отличаются от файлов, на которые ссылаются другие EO в приложении.

Кроме того, должно применяться одно из следующих правил -

• Логика обработки содержит по крайней мере одну математическую формулу или расчет.
• Логика обработки поддерживает по крайней мере один ILF.
• Логика обработки изменяет поведение системы.

Внешний запрос

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

Логика обработки не содержит математических формул или вычислений и не создает производных данных. Во время обработки не поддерживается ни ILF, ни поведение системы.

Должны применяться все следующие правила -

• Отправляет данные или управляющую информацию за пределы границы приложения.
• Для идентифицированного EP должно применяться одно из трех утверждений:
  • Логика обработки отличается от логики обработки, выполняемой другими эквалайзерами приложения.
  • Набор идентифицированных элементов данных отличается от других EQ в приложении.
  • Упомянутые ILF или EIF отличаются от файлов, на которые ссылаются другие EQ в приложении.

Кроме того, должны применяться все следующие правила:

• Логика обработки извлекает данные или управляющую информацию из ILF или EIF.
• Логика обработки не содержит математических формул или вычислений.
• Логика обработки не меняет поведения системы.
• Логика обработки не поддерживает ILF.

Шаг 6.2: Подсчитайте DET для каждой транзакционной функции

Примените следующие правила для подсчета DET для EI -

• Проверьте все, что пересекает (входит и / или выходит) за границу.

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

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

• Подсчитайте только одно DET для каждой транзакционной функции для возможности инициировать действие (я), даже если есть несколько способов сделать это.

• Не считайте следующие элементы как DET -

  • Атрибуты, сгенерированные внутри границы транзакционной функцией и сохраненные в ILF без выхода за границу.

  • Литералы, такие как заголовки отчетов, идентификаторы экрана или панели, заголовки столбцов и заголовки атрибутов.

  • Приложение генерирует штампы, такие как атрибуты даты и времени.

  • Переменные пейджинга, номера страниц и информация о местоположении, например, «Строки с 37 по 54 из 211».

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

Примените следующие правила для подсчета DET для EO / EQ:

• Проверьте все, что пересекает (входит и / или выходит) за границу.

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

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

• Подсчитайте только одно DET для каждой транзакционной функции для возможности инициировать действие (я), даже если есть несколько способов сделать это.

• Не считайте следующие элементы как DET -

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

  • Литералы, такие как заголовки отчетов, идентификаторы экрана или панели, заголовки столбцов и заголовки атрибутов.

  • Приложение генерирует штампы, такие как атрибуты даты и времени.

  • Переменные пейджинга, номера страниц и информация о местоположении, например, «Строки с 37 по 54 из 211».

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

Шаг 6.3: Подсчитайте FTR для каждой транзакционной функции

Примените следующие правила для подсчета FTR для EI:

• Подсчитайте FTR для каждой поддерживаемой ILF.
• Подсчитайте FTR для каждого чтения ILF или EIF во время обработки EI.
• Подсчитайте только один FTR для каждого ILF, который поддерживается и читается.

Примените следующее правило для подсчета FTR для EO / EQ:

• Подсчитайте FTR для каждого чтения ILF или EIF во время обработки EP.

Кроме того, примените следующие правила для подсчета FTR для ОР:

• Подсчитайте FTR для каждого ILF, поддерживаемого во время обработки EP.
• Подсчитайте только один FTR для каждого ILF, который поддерживается и читается EP.

Шаг 6.4: Определите функциональную сложность для каждой транзакционной функции

FTRs	Типы элементов данных (DET)
	1-4	5-15	>=16
0-1	L	L	А
2	L	А	ЧАС
> = 3	А	ЧАС	ЧАС

Функциональная сложность: L = Низкий; A = Среднее; H = Высокий

Определите функциональную сложность для каждого EO / EQ, за исключением того, что EQ должен иметь минимум 1 FTR -

EQ должен иметь минимум 1 FTR FTRs	Типы элементов данных (DET)
	1-4	5-15	> = 16
0-1	L	L	А
2	L	А	ЧАС
> = 3	А	ЧАС	ЧАС

Функциональная сложность: L = Низкий; A = Среднее; H = Высокий

Шаг 6.5: Измерьте функциональный размер для каждой транзакционной функции

Измерьте функциональный размер каждого EI по его функциональной сложности.

Сложность	Количество FP
Низкий	3
В среднем	4
Высоко	6

Измерьте функциональный размер каждого EO / EQ по его функциональной сложности.

Сложность	Количество FP для EO	Количество FP для эквалайзера
Низкий	4	3
В среднем	5	4
Высоко	6	6

Шаг 7: Расчет функционального размера (нескорректированное количество функциональных точек)

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

Шаг 7.1

Вспомните, что вы нашли на шаге 1. Определите тип счета.

Шаг 7.2

Рассчитайте функциональный размер или количество функциональных баллов в зависимости от типа.

• Для подсчета очков функции развития перейдите к шагу 7.3.
• Чтобы узнать количество точек функции приложения, перейдите к шагу 7.4.
• Для подсчета очков функции улучшения перейдите к шагу 7.5.

Шаг 7.3

Подсчет очков функции разработки состоит из двух функциональных компонентов:

• Функциональность приложения включена в требования пользователя к проекту.

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

DFP = ADD + CFP

Где,

DFP = Подсчет очков функции развития

ADD = Размер функций, предоставляемых пользователю проектом разработки

CFP = Размер функции преобразования

ADD = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)

CFP = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)

Шаг 7.4

Вычислить количество точек функции приложения

AFP = ADD

Где,

AFP = Количество точек функции приложения

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

ADD = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)

Шаг 7.5

Функция подсчета очков расширенной функции учитывает следующие четыре компонента функциональности:

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

EFP = ADD + CHGA + CFP + DEL

Где,

EFP = Счетчик очков улучшенной функции

ADD = Размер функций, добавляемых проектом улучшения

CHGA = Размер функций, изменяемых проектом улучшения

CFP = Размер функции преобразования

DEL = Размер функций, удаляемых проектом улучшения

ADD = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)

CHGA = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)

CFP = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)

DEL = Счетчик FP (ILFs) + Счетчик FP (EIFs) + Счетчик FP (EIs) + Счетчик FP (EOs) + Счетчик FP (EQs)

Шаг 8: Определите коэффициент корректировки значения

GSC сделаны необязательными в CPM 4.3.1 и перенесены в Приложение. Следовательно, шаги 8 и 9 можно пропустить.

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

Общая характеристика системы	Краткое описание
Передача данных	Сколько имеется средств связи для передачи или обмена информацией с приложением или системой?
Распределенная обработка данных	Как обрабатываются распределенные данные и функции обработки?
Спектакль	Потребовалось ли пользователю время отклика или пропускная способность?
Широко используемая конфигурация	Насколько активно используется текущая аппаратная платформа, на которой будет выполняться приложение?
Скорость транзакции	Как часто транзакции выполняются ежедневно, еженедельно, ежемесячно и т. Д.?
Он-лайн ввод данных	Какой процент информации вводится онлайн?
Эффективность конечного пользователя	Было ли приложение разработано для повышения эффективности конечного пользователя?
Онлайн-обновление	Сколько ILF обновляется с помощью онлайн-транзакции?
Комплексная обработка	Есть ли в приложении обширная логическая или математическая обработка?
Возможность повторного использования	Было ли приложение разработано для удовлетворения потребностей одного или нескольких пользователей?
Легкость установки	Насколько сложна переоборудование и установка?
Удобство работы	Насколько эффективны и / или автоматизированы процедуры запуска, резервного копирования и восстановления?
Несколько сайтов	Было ли приложение специально разработано, разработано и поддержано для установки на нескольких сайтах для нескольких организаций?
Содействовать изменениям	Было ли приложение специально разработано, разработано и поддержано для облегчения изменений?

Диапазон степени влияния - от нуля до пяти, от отсутствия влияния до сильного влияния.

Рейтинг	Степень влияния
0	Нет или не влияет
1	Случайное влияние
2	Умеренное влияние
3	Среднее влияние
4	Значительное влияние
5	Сильное влияние во всем

Определите степень влияния для каждого из 14 GSC.

Сумма значений 14 GSC, полученных таким образом, называется общей степенью влияния (TDI).

TDI = ∑¹⁴ Degrees of Influence

Затем рассчитайте коэффициент корректировки значения (VAF) как

VAF = (TDI × 0.01) + 0.65

Каждый GSC может варьироваться от 0 до 5, TDI может варьироваться от (0 × 14) до (5 × 14), то есть от 0 (когда все GSC низкие) до 70 (когда все GSC высокие), то есть 0 ≤ TDI ≤ 70. Следовательно, VAF может варьироваться в диапазоне от 0,65 (когда все GSC низкие) до 1,35 (когда все GSC высокие), то есть 0,65 ≤ VAF ≤ 1,35.

Шаг 9: Расчет количества скорректированных функциональных точек

Согласно подходу FPA, который использует VAF (версии CPM до V4.3.1), это определяется следующим образом:

Adjusted FP Count = Unadjusted FP Count × VAF

Где нескорректированное количество FP - это функциональный размер, рассчитанный на шаге 7.

Поскольку VAF может изменяться от 0,65 до 1,35, VAF оказывает влияние ± 35% на окончательное скорректированное количество FP.

Преимущества функциональных очков

Функциональные точки полезны -

• Измеряя размер решения, а не размер проблемы.

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

• Поскольку это не зависит от технологии.

• Поскольку он не зависит от языков программирования.

• При оценке тестовых проектов.

• При оценке общей стоимости проекта, графика и усилий.

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

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

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

Репозитории FP

Международная группа по стандартам бенчмаркинга программного обеспечения (ISBSG) растет и поддерживает два репозитория для ИТ-данных.

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

В репозитории проектов развития и усовершенствования находится более 6000 проектов.

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

Лицензию на репозиторий ISBSG можно приобрести по адресу: http://www.isbsg.com/

ISBSG предлагает 10% скидку членам IFPUG для покупок в Интернете при использовании кода скидки «IFPUGMembers».

Обновления выпуска данных программного проекта ISBSG можно найти по адресу: http://www.ifpug.org/isbsg/

COSMIC и IFPUG совместно разработали Глоссарий терминов для нефункционального программного обеспечения и требований проекта. Его можно скачать с - cosmic-sizing.org

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

Варианты использования - это способ зафиксировать функциональные требования системы. Пользователь системы именуется «Актер». Варианты использования в основном имеют текстовую форму.

Рекомендации по использованию - Определение

Use-Case Points (UCP)- это метод оценки программного обеспечения, используемый для измерения размера программного обеспечения с вариантами использования. Концепция UCP похожа на FP.

Количество UCP в проекте основано на следующем:

• Количество и сложность вариантов использования в системе.
• Количество и сложность участников системы.

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

  • Среда, в которой будет развиваться проект (например, язык, мотивация команды и т. Д.)

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

История точек прецедентов

Метод оценки точки прецедента был введен Густавом Карнером в 1993 году. Позднее лицензия на эту работу была предоставлена ​​Rational Software, которая объединилась с IBM.

Процесс подсчета баллов прецедента

Процесс подсчета очков прецедента состоит из следующих этапов:

• Рассчитать нескорректированные UCP
• С учетом технической сложности
• Сделайте поправку на сложность окружающей среды
• Рассчитать скорректированные UCP

Шаг 1. Рассчитайте нескорректированные точки варианта использования.

Сначала вы рассчитываете нескорректированные точки варианта использования, выполнив следующие шаги:

• Определите нескорректированный вес варианта использования
• Определите нескорректированный вес актера
• Расчет нескорректированных точек прецедента

Step 1.1 - Определите нескорректированный вес варианта использования.

Step 1.1.1 - Найдите количество транзакций в каждом сценарии использования.

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

Step 1.1.2- Классифицируйте каждый вариант использования как простой, средний или сложный в зависимости от количества транзакций в варианте использования. Кроме того, назначьте вес варианта использования, как показано в следующей таблице -

Сложность варианта использования	Количество транзакций	Вес варианта использования
просто	≤3	5
В среднем	От 4 до 7	10
Сложный	> 7	15

Step 1.1.3- Повторите для каждого варианта использования и получите все веса вариантов использования. Неадаптированный вес варианта использования (UUCW) - это сумма всех весов варианта использования.

Step 1.1.4 - Найдите нескорректированный вес варианта использования (UUCW), используя следующую таблицу -

Сложность варианта использования	Вес варианта использования	Количество вариантов использования	Продукт
просто	5	NSUC	5 × NSUC
В среднем	10	NAUC	10 × NAUC
Сложный	15	NCUC	15 × NCUC
Unadjusted Use-Case Weight (UUCW)			5 × NSUC + 10 × NAUC + 15 × NCUC

Where,

NSUC is the no. of Simple Use-Cases.

NAUC is the no. of Average Use-Cases.

NCUC is the no. of Complex Use-Cases.

Step 1.2 − Determine Unadjusted Actor Weight.

An Actor in a Use-Case might be a person, another program, etc. Some actors, such as a system with defined API, have very simple needs and increase the complexity of a Use-Case only slightly.

Some actors, such as a system interacting through a protocol have more needs and increase the complexity of a Use-Case to a certain extent.

Other Actors, such as a user interacting through GUI have a significant impact on the complexity of a Use-Case. Based on these differences, you can classify actors as Simple, Average and Complex.

Step 1.2.1 − Classify Actors as Simple, Average and Complex and assign Actor Weights as shown in the following table −

Actor Complexity	Example	Actor Weight
Simple	A System with defined API	1
Average	A System interacting through a Protocol	2
Complex	A User interacting through GUI	3

Step 1.2.2- Повторите для каждого актера и получите все веса актеров. Неадаптированный вес актера (UAW) - это сумма всех весов актера.

Step 1.2.3 - Найдите нескорректированный вес актера (UAW), используя следующую таблицу -

Актерская сложность	Вес актера	Количество Актеров	Продукт
просто	1	АНБ	1 × АНБ
В среднем	2	NAA	2 × NAA
Сложный	3	NCA	3 × NCA
Unadjusted Actor Weight (UAW)			1 × NSA + 2 × NAA + 3 × NCA

Где,

АНБ - это нет. простых актеров.

NAA - это нет. средних актеров.

NCA - нет. сложных актеров.

Step 1.3 - Расчет нескорректированных точек варианта использования.

Неадаптированный вес варианта использования (UUCW) и нескорректированный вес участника (UAW) вместе дают нескорректированный размер системы, называемый нескорректированными точками варианта использования.

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

Следующие шаги - настроить нескорректированные точки варианта использования (UUCP) для технической сложности и сложности среды.

Шаг 2: внесите поправку на техническую сложность

Step 2.1 - Рассмотрите 13 факторов, которые способствуют влиянию технической сложности проекта на точки прецедентов и их соответствующие веса, как указано в следующей таблице -

Фактор	Описание	Вес
Т1	Распределенная система	2.0
Т2	Время отклика или целевые показатели производительности	1.0
Т3	Эффективность конечного пользователя	1.0
Т4	Комплексная внутренняя обработка	1.0
T5	Код должен быть многоразовым	1.0
T6	Легко установить	.5
T7	Легко использовать	.5
T8	Портативный	2.0
T9	Легко изменить	1.0
T10	Одновременный	1.0
T11	Включает особые цели безопасности	1.0
T12	Обеспечивает прямой доступ для третьих лиц	1.0
T13	Требуются специальные средства обучения пользователей	1.0

Многие из этих факторов представляют собой нефункциональные требования проекта.

Step 2.2 - Для каждого из 13 факторов оцените проект и поставьте балл от 0 (неактуально) до 5 (очень важно).

Step 2.3 - Рассчитайте влияние фактора на основе ударной нагрузки фактора и номинального значения для проекта как

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)- Рассчитайте сумму воздействия всех факторов. Это дает общий технический коэффициент (TFactor), как указано в таблице ниже -

Фактор	Описание	Вес (Вт)	Номинальное значение (от 0 до 5) (RV)	Удар (I = W × RV)
Т1	Распределенная система	2.0
Т2	Время отклика или целевые показатели производительности	1.0
Т3	Эффективность конечного пользователя	1.0
Т4	Комплексная внутренняя обработка	1.0
T5	Код должен быть многоразовым	1.0
T6	Легко установить	.5
T7	Легко использовать	.5
T8	Портативный	2.0
T9	Легко изменить	1.0
T10	Одновременный	1.0
T11	Включает особые цели безопасности	1.0
T12	Обеспечивает прямой доступ для третьих лиц	1.0
T13	Требуются специальные средства обучения пользователей	1.0
Total Technical Factor (TFactor)

Step 2.5 - Рассчитайте коэффициент технической сложности (TCF) как -

TCF = 0.6 + (0.01 × TFactor)

Шаг 3: адаптация к сложности окружающей среды

Step 3.1 - Рассмотрите 8 факторов окружающей среды, которые могут повлиять на выполнение проекта, и их соответствующие веса, как указано в следующей таблице -

Фактор	Описание	Вес
F1	Знаком с используемой моделью проекта	1.5
F2	Опыт применения	.5
F3	Объектно-ориентированный опыт	1.0
F4	Возможности ведущего аналитика	.5
F5	Мотивация	1.0
F6	Стабильные требования	2.0
F7	Персонал, занятый неполный рабочий день	-1,0
F8	Сложный язык программирования	-1,0

Step 3.2 - По каждому из 8 факторов оцените проект и поставьте балл от 0 (нерелевантно) до 5 (очень важно).

Step 3.3 - Рассчитайте влияние фактора на основе ударной нагрузки фактора и номинального значения для проекта как

Impact of the Factor = Impact Weight × Rated Value

Step 3.4- Рассчитайте сумму воздействия всех факторов. Это дает общий коэффициент окружающей среды (EFactor), как указано в следующей таблице -

Фактор	Описание	Вес (Вт)	Номинальное значение (от 0 до 5) (RV)	Удар (I = W × RV)
F1	Знаком с используемой моделью проекта	1.5
F2	Опыт применения	.5
F3	Объектно-ориентированный опыт	1.0
F4	Возможности ведущего аналитика	.5
F5	Мотивация	1.0
F6	Стабильные требования	2.0
F7	Персонал, занятый неполный рабочий день	-1,0
F8	Сложный язык программирования	-1,0
Total Environment Factor (EFactor)

Step 3.5 - Рассчитайте фактор окружающей среды (EF) как -

1.4 + (-0.03 × EFactor)

Шаг 4. Рассчитайте скорректированные точки варианта использования (UCP)

Рассчитайте скорректированные точки варианта использования (UCP) как -

UCP = UUCP × TCF × EF

Преимущества и недостатки точек прецедента

Преимущества точек прецедента

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

• UCP (оценка размера) не зависит от размера, навыков и опыта команды, реализующей проект.

• Оценки на основе UCP оказываются близкими к фактическим, когда оценка выполняется опытными людьми.

• UCP прост в использовании и не требует дополнительного анализа.

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

Недостатки точек прецедента

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

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

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

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

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

Считается, что в ходе этого процесса диапазон ответов сократится, и группа будет сходиться к «правильному» ответу. Наконец, процесс останавливается после заранее определенного критерия остановки (например, количества раундов, достижения консенсуса и стабильности результатов), и средние или средние оценки финальных раундов определяют результаты.

Метод Delphi был разработан в 1950-1960-х годах в корпорации RAND.

Широкополосный метод Delphi

В 1970-х годах Барри Бём и Джон А. Фаркуар создали широкополосный вариант метода Дельфи. Термин «широкополосный» используется потому, что, по сравнению с методом Delphi, метод широкополосного использования Delphi предполагает большее взаимодействие и более тесную связь между участниками.

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

• Стартовое совещание
• Оценка встречи

Широкополосный метод Delphi - шаги

Step 1 - Выберите команду оценки и модератора.

Step 2- Модератор проводит стартовую встречу, на которой команде предоставляется спецификация проблемы и список задач высокого уровня, любые предположения или ограничения проекта. Команда обсуждает проблему и вопросы оценки, если таковые имеются. Они также принимают решение о единицах оценки. Модератор руководит всем обсуждением, контролирует время и после стартовой встречи, готовит структурированный документ, содержащий спецификацию проблемы, список задач высокого уровня, предположения и единицы оценки, которые были приняты. Затем он отправляет копии этого документа для следующего шага.

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

Step 4- Модератор вызывает группу оценки на встречу по оценке. Если кто-либо из членов группы оценки отвечает, что оценки не готовы, модератор дает больше времени и повторно отправляет приглашение на собрание.

Step 5 - Вся команда по оценке собирается на оценочную встречу.

Step 5.1 - В начале оценочной встречи модератор собирает первоначальные оценки от каждого члена команды.

Step 5.2- Затем он рисует диаграмму на доске. Он отображает общую оценку проекта каждого участника знаком X в строке 1 раунда, не раскрывая соответствующих имен. Команда оценки получает представление о диапазоне оценок, который изначально может быть большим.

Step 5.3- Каждый член команды зачитывает вслух подробный список задач, которые он / она сделал, определяя любые сделанные предположения и поднимая любые вопросы или проблемы. Смета задачи не разглашается.

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

Step 5.4 - Затем группа обсуждает любые сомнения / проблемы по поводу поставленных задач, сделанных предположений и проблем с оценками.

Step 5.5- Затем каждый член команды пересматривает свой список задач и предположения и при необходимости вносит изменения. Оценки задач также могут потребовать корректировок на основе обсуждения, которые отмечены как + N Hrs. для дополнительных усилий и –N Hrs. с меньшими усилиями.

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

Step 5.6 - Модератор собирает измененные оценки от всех членов команды и наносит их на линию 2 раунда.

В этом раунде диапазон будет уже по сравнению с предыдущим, поскольку он больше основан на консенсусе.

Step 5.7 - Затем группа обсуждает сделанные изменения задачи и предположения.

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

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

Step 5.9 - Модератор снова собирает измененные оценки от всех участников и наносит их на линию 3 раунда.

Опять же, в этом раунде диапазон будет уже по сравнению с предыдущим.

Step 5.10 - Шаги 5.7, 5.8, 5.9 повторяются до тех пор, пока не будет выполнен один из следующих критериев:

• Результаты сведены к достаточно узкому диапазону.
• Все члены команды не хотят менять свои последние оценки.
• Отведенное для оценки время встречи истекло.

Step 6 - Затем менеджер проекта собирает результаты оценочной встречи.

Step 6.1 - Он объединяет отдельные списки задач и соответствующие оценки в единый главный список задач.

Step 6.2 - Он также объединяет отдельные списки предположений.

Step 6.3 - Затем он просматривает окончательный список задач с группой оценки.

Преимущества и недостатки широкополосной техники Delphi

Преимущества

• Широкополосный метод Delphi - это основанный на консенсусе метод оценки усилий.
• Полезно при оценке времени на выполнение задачи.
• Участие опытных людей и их индивидуальная оценка приведет к достоверным результатам.
• Люди, которые будут выполнять эту работу, делают оценки, таким образом делая достоверные оценки.
• Сохраняющаяся анонимность позволяет каждому уверенно выражать свои результаты.
• Очень простой прием.
• Предположения документируются, обсуждаются и согласовываются.

Недостатки

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

Трехточечная оценка рассматривает три значения:

• самая оптимистичная оценка (O),
• наиболее вероятная оценка (M), и
• пессимистическая оценка (наименее вероятная оценка (L)).

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

Трехточечная оценка (E) основана на простом среднем и соответствует треугольному распределению.

E = (O + M + L) / 3

Среднеквадратичное отклонение

При треугольном распределении

Среднее = (O + M + L) / 3

Стандартное отклонение = √ [((O - E) ² + (M - E) ² + (L - E) ² ) / 2]

Шаги трехточечной оценки

Step 1 - Прибытие в WBS.

Step 2 - Для каждой задачи найдите три значения - наиболее оптимистическую оценку (O), наиболее вероятную оценку (M) и пессимистическую оценку (L).

Step 3 - Рассчитайте среднее из трех значений.

Mean = (O + M + L) / 3

Step 4- Рассчитайте трехбалльную оценку задачи. Трехточечная оценка - это среднее значение. Следовательно,

E = Mean = (O + M + L) / 3

Step 5 - Рассчитайте стандартное отклонение задачи.

Standard Deviation (SD) = √ [((O − E)² + (M − E)² + (L - E)²)/2]

Step 6 - Повторите шаги 2, 3, 4 для всех задач в WBS.

Step 7 - Рассчитайте трехбалльную оценку проекта.

E (Project) = ∑ E (Task)

Step 8 - Рассчитайте стандартное отклонение проекта.

SD (Project) = √ (∑SD (Task)²)

Преобразуйте оценки проекта в уровни уверенности

Рассчитанные таким образом трехточечная оценка (E) и стандартное отклонение (SD) используются для преобразования оценок проекта в «уровни достоверности».

Преобразование основано на том, что -

• Уровень уверенности в E +/– SD составляет примерно 68%.
• Уровень уверенности в значении E +/– 1,645 × SD составляет примерно 90%.
• Уровень уверенности в значении E +/– 2 × SD составляет примерно 95%.
• Уровень уверенности в значении E +/– 3 × SD составляет приблизительно 99,7%.

Обычно 95% уровень достоверности, т. Е. Значение E + 2 × SD, используется для всех оценок проекта и задач.

Метод оценки и анализа проекта (PERT) рассматривает три значения: наиболее оптимистичную оценку (O), наиболее вероятную оценку (M) и пессимистическую оценку (наименее вероятную оценку (L)). В отрасли возникла некоторая путаница в отношении трехточечной оценки и PERT. Однако техники разные. Вы увидите различия, когда изучите эти две техники. Кроме того, в конце этой главы собраны и представлены различия.

PERT основан на трех значениях - наиболее оптимистической оценке (O), наиболее вероятной оценке (M) и пессимистической оценке (наименее вероятная оценка (L)). Наиболее вероятная оценка имеет в 4 раза больший вес, чем две другие оценки (оптимистическая и пессимистическая).

Оценка PERT (E) основана на средневзвешенном значении и соответствует бета-распределению.

E = (O + 4 × M + L)/6

PERT часто используется вместе с методом критического пути (CPM). CPM рассказывает о задачах, которые критичны в проекте. Если есть задержка с этими задачами, проект задерживается.

Среднеквадратичное отклонение

Стандартное отклонение (SD) измеряет изменчивость или неопределенность оценки.

В бета-версии

Среднее = (O + 4 × M + L) / 6

Стандартное отклонение (SD) = (L - O) / 6

Шаги оценки PERT

Step (1) - Прибытие в WBS.

Step (2) - Для каждой задачи найдите три значения: наиболее оптимистическую оценку (O), наиболее вероятную оценку (M) и пессимистическую оценку (L).

Step (3) - PERT Среднее = (O + 4 × M + L) / 6

PERT Среднее = (O + 4 × M + L) / 3

Step (4) - Рассчитайте стандартное отклонение задачи.

Стандартное отклонение (SD) = (L - O) / 6

Step (6) - Повторите шаги 2, 3, 4 для всех задач в WBS.

Step (7) - Рассчитайте оценку PERT проекта.

E (Проект) = ∑ E (Задача)

Step (8) - Рассчитайте стандартное отклонение проекта.

SD (Проект) = √ (ΣSD (Задача) ² )

Преобразуйте оценки проекта в уровни уверенности

Рассчитанные таким образом оценка PERT (E) и стандартное отклонение (SD) используются для преобразования оценок проекта в уровни достоверности.

Преобразование основано на том, что

• Уровень уверенности в E +/– SD составляет примерно 68%.
• Уровень уверенности в значении E +/– 1,645 × SD составляет примерно 90%.
• Уровень уверенности в значении E +/– 2 × SD составляет примерно 95%.
• Уровень уверенности в значении E +/– 3 × SD составляет примерно 99,7%.

Обычно уровень достоверности 95%, т. Е. Значение E + 2 × SD, используется для всех оценок проекта и задач.

Различия между трехточечной оценкой и PERT

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

Трехточечная оценка	ПЕРТ
Простое среднее	Средневзвешенное
Следует треугольному распределению	Следит за бета-распространением
Используется для небольших повторяющихся проектов	Используется для крупных неповторяющихся проектов, обычно проектов НИОКР. Используется вместе с методом критического пути (CPM)
E = Среднее = (O + M + L) / 3 Это простое среднее	E = Среднее = (O + 4 × M + L) / 6 Это средневзвешенное значение
SD = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2]	SD = (L - O) / 6

Analogous Estimationиспользует аналогичную информацию о прошлом проекте для оценки продолжительности или стоимости вашего текущего проекта, отсюда и слово «аналогия». Вы можете использовать аналогичную оценку, когда имеется ограниченная информация о вашем текущем проекте.

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

В таких случаях лучшим решением будет аналогичная оценка. Возможно, он не идеален, но точен, поскольку основан на прошлых данных. Аналогичная оценка - это простой в применении метод. Успешность проекта может достигать 60% по сравнению с первоначальными оценками.

Аналогичная оценка - определение

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

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

Требования к аналогичной оценке

Для аналогичной оценки требуется следующее:

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

Аналогичные шаги оценки

Менеджер проекта и команда должны совместно провести аналогичную оценку.

• Step 1 - Определите домен текущего проекта.

• Step 2 - Определите технологию текущего проекта.

• Step 3- Посмотрите в базе данных организации, есть ли данные о похожих проектах. Если возможно, перейдите к Шагу (4). В противном случае переходите к шагу (6).

• Step 4 - Сравните текущий проект с идентифицированными данными прошлого проекта.

• Step 5- Получите оценку продолжительности и стоимости текущего проекта. На этом аналогичная оценка проекта заканчивается.

• Step 6 - Посмотрите в базе данных организации, есть ли у каких-либо прошлых проектов модули, аналогичные модулям в текущем проекте.

• Step 7 - Посмотрите в базе данных организации, есть ли в прошлых проектах деятельность, аналогичная текущим проектам.

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

Преимущества аналогичной оценки

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

• Техника проста, а времени на оценку уходит меньше.

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

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

Иерархическая структура работ (WBS) в управлении проектами и системном проектировании представляет собой разложение проекта на более мелкие компоненты, ориентированное на конечный результат. WBS - это ключевой результат проекта, который организует работу группы по управляемым разделам. Свод знаний по управлению проектами (PMBOK) определяет WBS как «иерархическую декомпозицию, ориентированную на конечный результат, работы, выполняемой командой проекта».

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

Представительство WBS

WBS представлен в виде иерархического списка рабочих операций проекта. Есть два формата WBS -

• Контурное представление (формат с отступом)
• Просмотр древовидной структуры (организационная диаграмма)

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

Общий вид

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

• Software Development

• Scope

  • Определить объем проекта
  • Надежное спонсорство проекта
  • Определите предварительные ресурсы
  • Безопасность основных ресурсов
  • Объем завершен

• Analysis/Software Requirements

  • Провести анализ потребностей
  • Проект предварительных спецификаций программного обеспечения
  • Разработать предварительный бюджет
  • Изучите спецификации / бюджет программного обеспечения с командой
  • Учитывать отзывы о спецификациях программного обеспечения
  • Разработайте график доставки
  • Получите одобрение для продолжения (концепция, сроки и бюджет)
  • Обеспечьте необходимые ресурсы
  • Анализ завершен

• Design

  • Изучите предварительные спецификации программного обеспечения
  • Разработать функциональные спецификации
  • Получить разрешение на продолжение
  • Дизайн завершен

• Development

  • Ознакомьтесь с функциональными характеристиками
  • Определение параметров модульной / многоуровневой конструкции
  • Разработать код
  • Тестирование разработчика (первичная отладка)
  • Разработка завершена

• Testing

  • Разработка планов модульного тестирования с использованием спецификаций продукта
  • Разработка планов тестирования интеграции с использованием спецификаций продукта

• Training

  • Разработка спецификаций обучения для конечных пользователей
  • Определите методику проведения обучения (онлайн, в классе и т. Д.)
  • Разработать учебные материалы
  • Завершить подготовку учебных материалов
  • Разработать механизм проведения обучения
  • Учебные материалы завершены

• Deployment

  • Определить окончательную стратегию развертывания
  • Разработать методологию развертывания
  • Ресурсы безопасного развертывания
  • Обучить вспомогательный персонал
  • Развернуть программное обеспечение
  • Развертывание завершено

Давайте теперь посмотрим на представление древовидной структуры.

Просмотр древовидной структуры

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

Типы WBS

Есть два типа WBS -

• Functional WBS- В функциональном WBS система разбита на функции в разрабатываемом приложении. Это полезно при оценке размера системы.

• Activity WBS- В WBS активности система не работает в зависимости от действий в системе. Действия далее разбиваются на задачи. Это полезно при оценке усилий и графика в системе.

Оценить размер

Step 1 - Начните с функциональной WBS.

Step 2 - Рассмотрим листовые узлы.

Step 3 - Используйте Analogy или Wideband Delphi для получения оценок размера.

Оценить усилия

Step 1- Используйте технику Wideband Delphi для построения WBS. Мы предлагаем, чтобы задачи не превышали 8 часов. Если задача большей продолжительности, разделите ее.

Step 2 - Используйте широкополосную технику Delphi или трехточечную оценку, чтобы получить оценки трудозатрат для задач.

Планирование

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

При планировании задач следует учитывать некоторые вещи -

• Precedence - Говорят, что задача, которая должна быть выполнена раньше другой, имеет приоритет над другой задачей.

• Concurrence - Параллельные задачи - это те, которые могут выполняться одновременно (параллельно).

• Critical Path - Конкретный набор последовательных задач, от которых зависит дата завершения проекта.

  • У всех проектов есть критический путь.
  • Ускорение некритических задач напрямую не сокращает график.

Метод критического пути

Метод критического пути (CPM) - это процесс определения и оптимизации критического пути. Задачи некритического пути могут начинаться раньше или позже, не влияя на дату завершения.

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

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

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

Отношения зависимости задач

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

• От конца до начала (FS)
• Окончание до конца (FF)

От конца до начала (FS)

В отношении зависимости задачи «От конца к началу» (FS) задача B не может начаться, пока задача A не будет завершена.

Окончание до конца (FF)

В отношении зависимости задачи «От конца до конца» (FF) задача B не может завершиться, пока не будет завершена задача A.

Диаграмма Ганта

Диаграмма Ганта - это тип гистограммы, адаптированный Каролем Адамецки в 1896 году и независимо Генри Ганттом в 1910-х годах, который иллюстрирует график проекта. Диаграммы Ганта иллюстрируют даты начала и окончания конечных элементов и сводных элементов проекта.

Вы можете перенести формат структуры, показанный на рисунке 2, в Microsoft Project, чтобы получить представление диаграммы Ганта.

Вехи

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

Например, на приведенной выше диаграмме Ганта завершение проектирования и завершение разработки показаны в виде вех, представленных в форме ромба.

Вехи могут быть привязаны к условиям контракта.

Преимущества оценки с использованием WBS

WBS значительно упрощает процесс оценки проекта. Он предлагает следующие преимущества перед другими методами оценки:

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

• WBS позволяет получить более точные оценки затрат и сроков.

• Менеджер проекта получает командное участие для завершения WBS. Такое участие команды порождает энтузиазм и ответственность в проекте.

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

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

Планирование оценки покера

Planning Poker - это основанный на консенсусе метод оценки, который в основном используется для оценки усилий или относительного размера пользовательских историй в Scrum.

Planning Poker сочетает в себе три метода оценки - широкополосную технику Delphi, оценку по аналогам и оценку с использованием WBS.

Планирование покера было впервые определено и названо Джеймсом Греннингом в 2002 году, а затем популяризировано Майком Коном в его книге «Гибкое оценивание и планирование», чья деятельность компании обозначила этот термин.

Планирование техники оценки в покере

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

• В Planning Poker используется колода карт. Поскольку используется последовательность Фибоначчи, на картах есть числа - 1, 2, 3, 5, 8, 13, 21, 34 и т. Д. Эти числа представляют собой «Сюжетные точки». У каждого оценщика есть колода карт. Цифры на карточках должны быть достаточно большими, чтобы их могли видеть все члены команды, когда один из членов команды держит карточку.

• Один из членов команды выбирается модератором. Модератор читает описание пользовательской истории, для которой проводится оценка. Если у оценщиков есть вопросы, product owner на них отвечает.

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

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

• Команда может обсудить историю и свои оценки еще несколько минут.

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

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

Преимущества планирования оценки покера

Планирование покера сочетает в себе три метода оценки:

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

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

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

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

В основном это связано с тем, что обычно test effort estimation является частью development estimation. Только в случае методов оценки, использующих WBS, таких как Wideband Delphi, Трехточечная оценка, PERT и WBS, вы можете получить значения для оценок действий тестирования.

Если вы получили оценки в виде функциональных баллов (FP), то согласно Caper Jones,

Number of Test Cases = (Number of Function Points) × 1.2

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

Процент метода разработки

Требуемые усилия по тестированию прямо пропорциональны усилиям по разработке или в процентах. Усилия по разработке можно оценить с помощью строк кода (LOC) или функциональных точек (FP). Затем процент усилий по тестированию получается из базы данных организации. Полученный таким образом процент используется для оценки трудозатрат на тестирование.

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

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

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

• Командные навыки
• Базовые знания
• Сложность приложения
• Исторические данные
• Циклы ошибок для проекта
• Доступность ресурсов
• Вариации производительности
• Системная среда и время простоя

Тестирование методов оценки

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

• Методика оценки тестирования программного обеспечения PERT
• Метод UCP
• WBS
• Широкополосный метод Delphi
• Функциональная точка / Анализ точки тестирования
• Процентное распределение
• Методика оценки тестирования на основе опыта

Методика оценки тестирования программного обеспечения PERT

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

Формула, используемая в этой технике:

Test Estimate = (O + (4 × M) + E)/6

Где,

O = Оптимистическая оценка (лучший сценарий, при котором ничего не пойдет не так и все условия оптимальны).

M = Скорее всего, оценка (скорее всего, продолжительность и может быть какая-то проблема, но большинство вещей пойдет правильно).

L = Пессимистическая оценка (наихудший сценарий, когда все идет не так).

Стандартное отклонение для метода рассчитывается как -

Standard Deviation (SD) = (E − O)/6

Метод точки прецедента

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

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

Step 1- Считай нет. актеров. Актеры бывают положительными, отрицательными и исключительными.

Step 2 - Рассчитайте нескорректированные веса актеров как

Unadjusted Actor Weights = Total no. of Actors

Step 3 - Подсчитайте количество вариантов использования.

Step 4 - Рассчитайте нескорректированные веса вариантов использования как

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 - Рассчитайте нескорректированные точки варианта использования как

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6- Определите технический / экологический фактор (TEF). Если недоступен, примите значение 0,50.

Step 7 - Рассчитайте скорректированную точку варианта использования как

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 - Рассчитайте общее усилие как

Total Effort = Adjusted Use-Case Point × 2

Иерархическая структура работ

Step 1 - Создайте WBS, разбив тестовый проект на небольшие части.

Step 2 - Разделите модули на подмодули.

Step 3 Разделите подмодули на функциональные возможности.

Step 4 - Разделите функциональные возможности на подфункции.

Step 5 - Просмотрите все требования к тестированию, чтобы убедиться, что они добавлены в WBS.

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

Step 7 - Оцените усилия для каждой задачи.

Step 8 - Оцените продолжительность каждой задачи.

Широкополосный метод Delphi

В методе Wideband Delphi WBS распределяется между командой, состоящей из 3-7 членов, для повторной оценки задач. Окончательная оценка является результатом обобщенных оценок, основанных на консенсусе команды.

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

Функциональная точка / анализ точки проверки

FP указывают на функциональность программного приложения с точки зрения пользователя и используются в качестве метода для оценки размера программного проекта.

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

• Unadjusted Data Function Points - i) внутренние файлы, ii) внешние интерфейсы

• Unadjusted Transaction Function Points - i) вводимые пользователем данные; ii) выводы пользователя; iii) запросы пользователей

• Capers Jones basic formula -

  Количество тестовых примеров = (количество функциональных точек) × 1,2

• Total Actual Effort (TAE) -

  (Количество тестовых случаев) × (процент усилий по разработке / 100)

Процентное распределение

В этом методе всем этапам жизненного цикла разработки программного обеспечения (SDLC) назначаются усилия в%. Это может быть основано на прошлых данных из аналогичных проектов. Например -

Фаза	% усилий
Управление проектом	7%
Требования	9%
дизайн	16%
Кодирование	26%
Тестирование (все фазы тестирования)	27%
Документация	9%
Установка и обучение	6%

Затем% усилий для тестирования (все фазы тестирования) распределяется на все фазы тестирования -

Все этапы тестирования	% усилий
Компонентное тестирование	16
Независимое тестирование	84
Total	100

Независимое тестирование	% усилий
Интеграционное тестирование	24
Системное тестирование	52
Приемочное тестирование	24
Total	100

Системное тестирование	% усилий
Функциональное тестирование системы	65
Нефункциональное тестирование системы	35 год
Total	100

Планирование тестирования и архитектура дизайна	50%
Фаза обзора	50%

Методика оценки тестирования на основе опыта

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