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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методы оценки — функциональные точки

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

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

Стандарты ИСО

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 Разработка программного обеспечения — Анализ функциональных точек Ml II — Руководство по методам подсчета.
NESMA — ISO / IEC 24570: 2005 Разработка программного обеспечения. Метод измерения размера функции NESMA, версия 2.1. Определения и рекомендации по подсчету для применения анализа функциональных точек.

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 Разработка программного обеспечения — Анализ функциональных точек Ml II — Руководство по методам подсчета.

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

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

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

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

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

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

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

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

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

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

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

функции

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

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

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

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

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

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

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

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

Файлы внешнего интерфейса

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

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

Существует три типа транзакционных функций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тип файла ссылка

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

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

Методы оценки — процесс подсчета FP

Процесс подсчета FP включает в себя следующие этапы —

Шаг 1 — Определите тип счета.
Шаг 2 — Определите границу счета.
Шаг 3 — Определите каждый элементарный процесс (EP), требуемый пользователем.
Шаг 4 — Определите уникальные EP.
Шаг 5 — Измерение данных функций.
Шаг 6 — Измерение транзакционных функций.
Шаг 7 — Рассчитать функциональный размер (нескорректированное количество функциональных точек).
Шаг 8 — Определить коэффициент корректировки значения (VAF).
Шаг 9 — Рассчитайте скорректированное количество точек функции.

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

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

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

Шаг 4 — Определите уникальные EP.

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

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

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

Шаг 8 — Определить коэффициент корректировки значения (VAF).

Шаг 9 — Рассчитайте скорректированное количество точек функции.

Примечание. Общие характеристики системы (GSC) не являются обязательными в ПСК 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 могут содержать бизнес-данные, данные управления и данные на основе правил. Например, телефонная коммутация производится всех трех типов — бизнес-данные, данные правил и контрольные данные. Бизнес-данные — это фактический звонок. Данные правила — это то, как вызов должен маршрутизироваться через сеть, а данные управления — это то, как коммутаторы взаимодействуют друг с другом.

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

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

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

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

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

Подсчитайте 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)
RETS	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 в приложении.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Просмотрите все, что пересекает (входит и / или выходит) границы.
Посчитайте один DET для каждого уникального идентифицируемого пользователем неповторяющегося атрибута, который пересекает (входит и / или выходит) границу во время обработки транзакционной функции.
Посчитайте только одну DET на каждую транзакционную функцию для возможности отправки ответного сообщения приложения, даже если есть несколько сообщений.
Посчитайте только одну DET на каждую транзакционную функцию для возможности инициировать действие (действия), даже если для этого есть несколько способов.
Не считайте следующие предметы как DET —
- Атрибуты, созданные внутри границы транзакционной функцией и сохраненные в ILF без выхода за границу.
- Литералы, такие как заголовки отчетов, идентификаторы экрана или панели, заголовки столбцов и заголовки атрибутов.
- Сгенерированные приложением штампы, такие как атрибуты даты и времени.
- Переменные подкачки, номера страниц и информация о позиционировании, например, «Строки с 37 по 54 из 211».
- Средства навигации, такие как возможность навигации по списку с использованием «предыдущий», «следующий», «первый», «последний» и их графические эквиваленты.

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

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

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

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

Не считайте следующие предметы как DET —

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

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

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

Переменные подкачки, номера страниц и информация о позиционировании, например, «Строки с 37 по 54 из 211».

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

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

Просмотрите все, что пересекает (входит и / или выходит) границы.
Посчитайте один DET для каждого уникального идентифицируемого пользователем неповторяющегося атрибута, который пересекает (входит и / или выходит) границу во время обработки транзакционной функции.
Посчитайте только одну DET на каждую транзакционную функцию для возможности отправки ответного сообщения приложения, даже если есть несколько сообщений.
Посчитайте только одну DET на каждую транзакционную функцию для возможности инициировать действие (действия), даже если для этого есть несколько способов.
Не считайте следующие предметы как DET —
- Атрибуты, созданные в пределах границы без пересечения границы.
- Литералы, такие как заголовки отчетов, идентификаторы экрана или панели, заголовки столбцов и заголовки атрибутов.
- Сгенерированные приложением штампы, такие как атрибуты даты и времени.
- Переменные подкачки, номера страниц и информация о позиционировании, например, «Строки с 37 по 54 из 211».
- Средства навигации, такие как возможность навигации по списку с использованием «предыдущий», «следующий», «первый», «последний» и их графические эквиваленты.

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

Не считайте следующие предметы как 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 для EO —

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

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

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

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

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

Эквалайзер должен иметь минимум 1 FTR финансовые права на передачу	Типы элементов данных (DET)
	1-4	5-15	> = 16
0-1	L	L
2	L		ЧАС
> = 3		ЧАС	ЧАС

Эквалайзер должен иметь минимум 1 FTR

финансовые права на передачу

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

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

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

сложность	FP Count
Низкий	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

Функция Point Point Count состоит из двух компонентов:

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

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

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

DFP = ADD + CFP

Куда,

DFP = количество точек функции разработки

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

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

ADD = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

CFP = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

Шаг 7.4

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

AFP = ДОБАВИТЬ

Куда,

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

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

ADD = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

Шаг 7.5

Функция Point Count считает, что следующие четыре компонента функциональности —

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

EFP = ADD + CHGA + CFP + DEL

Куда,

EFP = Количество точек функции улучшения

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

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

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

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

ADD = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

CHGA = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

CFP = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

DEL = количество FP (ILF) + количество FP (EIF) + COUNT FP (EI) + количество FP (EO) + количество FP (EQ)

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

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

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

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

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

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

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

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

TDI = ∑ ¹⁴ градусов влияния

Затем рассчитайте коэффициент корректировки значения (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), это определяется

Скорректированный счетчик FP = нескорректированный счетчик FP × VAF

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

Поскольку VAF может варьироваться от 0,65 до 1,35, VAF оказывает влияние ± 35% на окончательно скорректированное количество 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

Методы оценки — точки использования

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

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

Точки использования — определение

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

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

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

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

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

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

История точек использования

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

Процесс подсчета точек использования

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

Рассчитать нескорректированные UCP
Отрегулируйте для технической сложности
Приспособиться к экологической сложности
Рассчитать скорректированные UCP

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

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

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

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

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

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

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

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

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

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

Сложность варианта использования	Вес прецедента	Количество вариантов использования	Товар
просто	5	NSUC	5 × NSUC
Средний	10	NAUC	10 × НАУК
Сложный	15	NCUC	15 × NCUC
Нескорректированный вес варианта использования (UUCW)			5 × NSUC + 10 × NAUC + 15 × NCUC

Куда,

NSUC это нет. простых случаев использования.

НАУК это нет. средних случаев использования.

NCUC это нет. комплексных вариантов использования.

Шаг 1.2 — Определите нескорректированный вес актера.

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

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

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

Шаг 1.2.1 — Классифицировать актеров как простых, средних и сложных и назначить веса актеров, как показано в следующей таблице —

Актер Сложность	пример	Актер Вес
просто	Система с определенным API	1
Средний	Система, взаимодействующая через протокол	2
Сложный	Пользователь, взаимодействующий через GUI	3

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

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

Актер Сложность	Актер Вес	Количество актеров	Товар
просто	1	NSA	1 × АНБ
Средний	2	NAA	2 × NAA
Сложный	3	NCA	3 × NCA
Масса актера без корректировки (UAW)			1 × АНБ + 2 × НАА + 3 × НКА

Куда,

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

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

NCA это нет. комплексных актеров.

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

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

Нескорректированные точки использования (UUCP) = UUCW + UAW

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

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

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

фактор	Описание	Вес
T1	Распределенная Система	2,0
T2	Время отклика или показатели производительности	1,0
T3	Эффективность конечного пользователя	1,0
T4	Комплексная внутренняя обработка	1,0
T5	Код должен быть многоразовым	1,0
T6	Прост в установке	0,5
T7	Легко использовать	0,5
T8	портативный	2,0
T9	Легко изменить	1,0
T10	параллельный	1,0
T11	Включает в себя специальные цели безопасности	1,0
T12	Предоставляет прямой доступ третьим лицам	1,0
T13	Требуются специальные средства обучения пользователей	1,0

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

Шаг 2.2 — Для каждого из 13 факторов оцените проект и оцените его от 0 (не имеет значения) до 5 (очень важно).

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

Влияние фактора = ударный вес × номинальное значение

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

фактор	Описание	Вес (Вт)
T1	Распределенная Система	2,0
T2	Время отклика или показатели производительности	1,0
T3	Эффективность конечного пользователя	1,0
T4	Комплексная внутренняя обработка	1,0
T5	Код должен быть многоразовым	1,0
T6	Прост в установке	0,5
T7	Легко использовать	0,5
T8	портативный	2,0
T9	Легко изменить	1,0
T10	параллельный	1,0
T11	Включает в себя специальные цели безопасности	1,0
T12	Предоставляет прямой доступ третьим лицам	1,0
T13	Требуются специальные средства обучения пользователей	1,0
Общий технический фактор (TFactor)

Шаг 2.5 — Рассчитать коэффициент технической сложности (TCF) как —

TCF = 0,6 + (0,01 × TFactor)

Шаг 3: приспособиться к экологической сложности

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

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

Шаг 3.2 — Для каждого из 8 факторов оцените проект и оцените его от 0 (не имеет значения) до 5 (очень важно).

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

Влияние фактора = ударный вес × номинальное значение

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

фактор	Описание	Вес (Вт)
F1	Знаком с моделью проекта, которая используется	1,5
F2	Опыт применения	0,5
F3	Объектно-ориентированный опыт	1,0
F4	Возможность ведущего аналитика	0,5
F5	мотивация	1,0
F6	Стабильные требования	2,0
F7	Частичная занятость	-1,0
F8	Сложный язык программирования	-1,0
Общий фактор окружающей среды (EFactor)

Шаг 3.5 — Рассчитать фактор окружающей среды (EF) как —

1,4 + (-0,03 × EFactor)

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

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

UCP = UUCP × TCF × EF

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

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

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

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

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

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

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

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

Недостатки точек использования

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

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

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

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

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

Методы оценки — широкополосный Delphi

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

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

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

Широкополосная техника Delphi

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

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

Встреча Kickoff
Оценочная встреча

Широкополосная техника Delphi — Шаги

Шаг 1 — Выберите команду оценки и модератора.

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

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

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

Шаг 5 — Вся оценочная команда собирается на оценочную встречу.

Шаг 5.1 — В начале собрания по оценке Модератор собирает начальные оценки от каждого из членов команды.

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

Шаг 5.3 — Каждый член команды читает вслух подробный список задач, которые он / она сделал, идентифицируя любые сделанные предположения и поднимая любые вопросы или проблемы. Оценки задания не разглашаются.

Отдельные подробные списки задач при объединении способствуют более полному списку задач.

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

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

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

Шаг 5.6 — Модератор собирает измененные оценки от всех членов команды и отображает их в строке 2 раунда.

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

Шаг 5.7. Затем команда обсуждает изменения, которые они сделали, и предположения.

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

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

Шаг 5.9 — Модератор снова собирает измененные оценки от всех участников и выводит их на график в 3 раунде.

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

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

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

Шаг 6 — Менеджер проекта затем собирает результаты оценки.

Шаг 6.1 — Он собирает отдельные списки задач и соответствующие оценки в единый основной список задач.

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

Шаг 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]

Трехточечные этапы оценки

Шаг 1 — Прибытие на WBS.

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

Шаг 3 — Рассчитать среднее из трех значений.

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

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

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

Шаг 5 — Рассчитайте стандартное отклонение задачи.

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

Шаг 6 — Повторите шаги 2, 3, 4 для всех задач в СПП.

Шаг 7 — Рассчитайте трехточечную оценку проекта.

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

Шаг 8 — Рассчитайте стандартное отклонение проекта.

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

Преобразовать оценки проекта в уровни доверия

Трехточечная оценка (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) учитывает три значения: наиболее оптимистичная оценка (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

Шаг (1) — Прибытие на WBS.

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

Шаг (3) — Рассчитать среднее значение PERT для трех значений.

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

Шаг (4) — Рассчитайте стандартное отклонение задачи.

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

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

Шаг (7) — Рассчитать оценку PERT проекта.

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

Шаг (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.

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

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

Это простой средний

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

Это средневзвешенное значение

Методы оценки — аналог

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

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

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

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

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

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

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

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

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

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

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

Шаг 1 — Определите домен текущего проекта.
Шаг 2 — Определите технологию текущего проекта.
Шаг 3 — Посмотрите в базе данных организации, доступны ли аналогичные данные проекта. Если доступно, перейдите к шагу (4). В противном случае перейдите к шагу (6).
Шаг 4 — Сравните текущий проект с идентифицированными данными прошлого проекта.
Шаг 5 — Получите оценку продолжительности и стоимости текущего проекта. На этом заканчивается аналогичная оценка проекта.
Шаг 6 — Посмотрите в базе данных организации, имеют ли какие-либо прошлые проекты те же модули, что и в текущем проекте.
Шаг 7 — Посмотрите в базе данных организации, если какие-либо прошлые проекты имели действия, аналогичные тем, что были в текущем проекте.
Шаг 8 — Соберите все и используйте экспертную оценку, чтобы получить оценку продолжительности и стоимости текущего проекта.

Шаг 1 — Определите домен текущего проекта.

Шаг 2 — Определите технологию текущего проекта.

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

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

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

Шаг 6 — Посмотрите в базе данных организации, имеют ли какие-либо прошлые проекты те же модули, что и в текущем проекте.

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

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

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

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

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

Методика проста, а время, затрачиваемое на оценку, значительно меньше.

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

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

Методы оценки — WBS

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

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

Представление WBS

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

Схема (с отступом)
Древовидная структура (организационная структура)

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

Контурный вид

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

Разработка программного обеспечения

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

Разработка программного обеспечения

Объем

Анализ / Требования к программному обеспечению

дизайн

развитие

тестирование

Повышение квалификации

развертывание

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

Древовидная структура

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

Типы WBS

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

Функциональная СПП — В функциональной СПП система разбивается на основании функций в разрабатываемом приложении. Это полезно при оценке размера системы.
Действие WBS — В действии WBS система разбивается на основе действий в системе. Действия далее разбиты на задачи. Это полезно при оценке усилий и графика в системе.

Функциональная СПП — В функциональной СПП система разбивается на основании функций в разрабатываемом приложении. Это полезно при оценке размера системы.

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

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

Шаг 1 — Начните с функционального WBS.

Шаг 2 — Рассмотрим листовые узлы.

Шаг 3 — Используйте либо аналогию, либо широкополосный Delphi, чтобы получить оценки размера.

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

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

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

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

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

При планировании задач необходимо принимать во внимание определенные вещи:

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

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

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

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

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

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

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

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

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

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

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

Финиш на старт (FS)
От финиша до финиша (FF)

Финиш на старт (FS)

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

От финиша до финиша (FF)

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

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

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

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

Основные этапы

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

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

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

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

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

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

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

WBS приводит к более точным оценкам стоимости и графика.

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

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

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

Методы оценки — планирование покера

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

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

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

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

Планирование Техники Оценки Покера

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

Планирование Покер играется с колодой карт. Поскольку используется последовательность Фибоначчи, карты имеют номера — 1, 2, 3, 5, 8, 13, 21, 34 и т. Д. Эти числа представляют «Очки истории». У каждого оценщика есть колода карт. Числа на карточках должны быть достаточно большими, чтобы их могли видеть все члены команды, когда один из членов команды держит карточку.
Один из членов команды выбран модератором. Модератор читает описание пользовательской истории, для которой делается оценка. Если у оценщиков есть какие-либо вопросы, владелец продукта отвечает на них.
Каждый оценщик в личном порядке выбирает карту, представляющую его или ее оценку. Карты не показываются, пока все оценщики не сделают выбор. В это время все карточки одновременно переворачиваются и удерживаются, чтобы все члены команды могли видеть каждую оценку.
В первом туре очень вероятно, что оценки меняются. Высокие и низкие оценки объясняют причину их оценок. Следует позаботиться о том, чтобы все дискуссии были предназначены только для понимания и ничего не принималось лично. Модератор должен обеспечить то же самое.
Команда может обсудить историю и их оценки в течение еще нескольких минут.
Модератор может делать заметки по обсуждению, которые будут полезны при разработке конкретной истории. После обсуждения каждый оценщик переоценивает, снова выбирая карточку. Карты снова остаются закрытыми, пока все не подсчитают, в какой момент они одновременно переворачиваются.

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

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

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

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

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

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

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

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

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

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

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

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

Методы оценки — Тестирование

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

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

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

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

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

Процент метода развития усилий

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

Оценка проектов тестирования

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

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

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

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

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

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

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

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

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

Оценка теста = (O + (4 × M) + E) / 6

Куда,

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

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

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

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

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

Метод точки использования

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

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

Шаг 1 — Посчитай нет. актеров. Актеры включают в себя положительные, отрицательные и исключительные.

Шаг 2 — Рассчитайте нескорректированный вес актера как

Нескорректированный вес актера = всего нет. актеров

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

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

Нескорректированные веса вариантов использования = общее число случаев использования

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

Нескорректированные баллы варианта использования = (Нескорректированный вес актера + Нескорректированные веса прецедента)

Шаг 6 — Определить технический / экологический фактор (TEF). Если недоступно, примите это как 0.50.

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

Скорректированная точка варианта использования = нескорректированные точки варианта использования × [0,65 + (0,01 × TEF]

Шаг 8 — Рассчитайте общее усилие как

Общее усилие = скорректированный вариант использования × 2

Структура разбивки работ

Шаг 1 — Создайте WBS, разбив тестовый проект на маленькие кусочки.

Шаг 2 — Разделите модули на подмодули.

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

Шаг 4 — Разделите функциональности на подфункции.

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

Шаг 6 — Определите количество задач, которые ваша команда должна выполнить.

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

Шаг 8 — Оцените продолжительность каждого задания.

Широкополосная техника Delphi

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

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

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

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

При тестировании оценка основывается на документе спецификации требований или на ранее созданном прототипе приложения. Для расчета FP для проекта требуются некоторые основные компоненты. Они —

Функциональные точки нескорректированных данных — i) внутренние файлы, ii) внешние интерфейсы
Функциональные точки нескорректированной транзакции — i) пользовательские входы, ii) пользовательские выходы и iii) пользовательские запросы
Основная формула Каперса Джонса —

Количество тестовых случаев = (количество функциональных точек) × 1,2
Всего фактических усилий (TAE) —

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

Функциональные точки нескорректированных данных — i) внутренние файлы, ii) внешние интерфейсы

Функциональные точки нескорректированной транзакции — i) пользовательские входы, ii) пользовательские выходы и iii) пользовательские запросы

Основная формула Каперса Джонса —

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

Всего фактических усилий (TAE) —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методы оценки — функциональные точки

Стандарты ИСО

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

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

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

функции

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

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

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

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

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

Тип файла ссылка

Методы оценки — процесс подсчета FP

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

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

Функция подсчета точек

Функция Количество очков

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

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

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

Шаг 5: Измерьте функции данных

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

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

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

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

Шаг 6: Измерение транзакционных функций

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

Внешний вход

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

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

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

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

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

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

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

Шаг 7.1

Шаг 7.2

Шаг 7.3

Шаг 7.4

Шаг 7.5

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

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

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

Репозитории ФП

Методы оценки — точки использования

Точки использования — определение

История точек использования

Процесс подсчета точек использования

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

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

Шаг 3: приспособиться к экологической сложности

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

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

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

Недостатки точек использования

Методы оценки — широкополосный Delphi

Широкополосная техника Delphi

Широкополосная техника Delphi — Шаги

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

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

Недостатки

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

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

Трехточечные этапы оценки

Преобразовать оценки проекта в уровни доверия

Методы оценки — PERT

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

Шаги оценки PERT

Преобразовать оценки проекта в уровни доверия

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

Методы оценки — аналог

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

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