ИЗВИНИ

ИЗВИНИ
Разработчик(и)	Галорат
Стабильная версия	8.4 / 2020
Операционная система	Microsoft Windows
Тип	Программное обеспечение для управления проектами
Лицензия	Лицензионное соглашение
Веб-сайт	Домашняя страница SEER-SEM

SEER for Software (SEER-SEM) — это приложение для управления проектами, используемое для оценки ресурсов, необходимых для разработки программного обеспечения.

История

Модель System Development Corporation 1966 года, основанная на регрессиях. ^[1]

1980 года Статья Дона Райфера и Дэна Галората , побудившая к созданию модели JPL Softcost. Эта модель, ранний пример оценки программного обеспечения, позволяет автоматически выполнять анализ рисков. Позже компания Reifer Consultants сделала Softcost коммерческим продуктом. ^[2]

1984 Компьютерная экономика JS-2 и Галорат разработали систему-3 на основе модели Дженсена. ^[3]

Вдохновленная Дженсеном система-3 и другие системы моделирования, такие как COCOMO Барри Боэма и ранние работы Doty Associates, можно рассматривать как прямые и косвенные участники программного пакета, который будет разработан Галоратом в конце 1980-х годов.

В 1988 году компания Galorath Incorporated начала работу над первоначальной версией SEER-SEM. ^[4]

Группа моделей

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

Размеры. Насколько велик оцениваемый программный проект (строки кода, функциональные точки, варианты использования и т. д.)
Технология. Какова возможная продуктивность разработчиков (возможности, инструменты, практики и т. д.)
Расчет усилий и расписания. Какое количество усилий и времени потребуется для завершения проекта?
Расчет ограниченных усилий/графика. Как меняется ожидаемый результат проекта при применении графиков и кадровых ограничений?
Деятельность и распределение труда. Как следует распределять работы и труд в смете?
Расчет стоимости. Сколько будет стоить проект с учетом ожидаемых усилий, продолжительности и распределения рабочей силы?
Расчет дефектов. Учитывая тип продукта, продолжительность проекта и другую информацию, каково ожидаемое объективное качество поставляемого программного обеспечения?
Расчет затрат на техническое обслуживание. Сколько усилий потребуется для адекватного обслуживания и обновления эксплуатируемой системы программного обеспечения?
Прогресс. Как продвигается проект и чем он закончится. И как перепланировать.
Срок действия. Достижимо ли такое развитие на основе задействованной технологии?

Определение размера программного обеспечения

Размер программного обеспечения является ключевым фактором для любой модели оценки и для большинства параметрических моделей программного обеспечения . Поддерживаемые метрики определения размера включают строки исходного кода (SLOC), функциональные точки , определение размера на основе функций (FBS) и ряд других показателей. Для внутреннего использования они переводятся в эффективный размер ( $S_{e}$ ). $S_{e}$ является формой общей валюты внутри модели и позволяет смешивать новый, повторно используемый и даже готовый коммерческий код для комплексного анализа процесса разработки программного обеспечения. Общий расчет для $S_{e}$ является:

S_{e}=({\text{new size}})+({\text{existing size}})\times (0.4\times {\text{redesign}}+0.25\times {\text{reimpl}}+0.35\times {\text{retest}})

Как указано, $S_{e}$ увеличивается прямо пропорционально количеству разрабатываемого нового программного обеспечения. $S_{e}$ увеличивается на меньшую величину, поскольку уже существующий код повторно используется в проекте. Степень этого увеличения определяется объемом доработок (перепроектирование, повторная реализация и повторное тестирование), необходимых для повторного использования кода.

Выбор размера на основе функций

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

В SEER-SEM все показатели размера переводятся в $S_{e}$ , в том числе введенные с помощью FBS. Это не простое преобразование, т. е. не языковая корректировка, как это делается с помощью столь высмеиваемого метода обратного эффекта . Скорее, модель включает в себя такие факторы, как этап оценки, операционную среду, тип приложения и сложность приложения. Все эти соображения существенно влияют на соотношение между функциональным размером и $S_{e}$ . После перевода FBS в функциональные точки он преобразуется в $S_{e}$ как:

S_{e}=L_{x}*(AdjFactor*UFP)^{\frac {Entropy}{1.2}}

где,

$L_{x}$ является фактором расширения, зависящим от языка.
$AdjFactor$ является результатом расчетов с учетом других факторов, упомянутых выше. Энтропия колеблется от 1,04 до 1,2 в зависимости от типа разрабатываемого программного обеспечения.

Расчет усилий и продолжительности

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

K=D^{0.4}\cdot \left({\frac {S_{e}}{C_{te}}}\right)^{E}

где,

$S_{e}$ эффективный размер, введенный ранее
$C_{te}$ Эффективная технология – это комплексный показатель, отражающий факторы, связанные с эффективностью или производительностью, с которой может осуществляться разработка. Обширный набор параметров людей, процессов и продуктов влияет на рейтинг эффективных технологий. Более высокий рейтинг означает, что разработка будет более продуктивной.
$D$ — сложность укомплектования персоналом — оценка внутренней сложности проекта с точки зрения скорости, с которой в проект добавляется персонал.
$E$ — энтропия. В былые времена энтропия была зафиксирована на уровне 1,2. Затем он увеличился до 1,04–1,2 в зависимости от характеристик проекта, при этом более мелкие проекты, ориентированные на ИТ, имели тенденцию к более низкому значению. В настоящее время энтропия составляет от 1,0 до 1,2 в зависимости от атрибутов проекта. SEER допустит энтропию меньше 1,0, если также будет соблюдаться такое обстоятельство.

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

t_{d}=D^{-0.2}\cdot \left({\frac {S_{e}}{C_{te}}}\right)^{0.4}

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

Ссылки

^ Б. Мазель. Роль компьютерного моделирования в корпоративном управлении: обзор , стр. 8, декабрь 1975 г.,
^ Дэн Галорат, почему SEER начался 18 августа 2008 г.
^ Дэн Галорат, почему SEER начался 18 августа 2008 г.
^ Галорат, Д. и Эванс М. (2006) Определение размера программного обеспечения, оценка и управление рисками ISBN 0-8493-3593-0 Страница xxii

Внешние ссылки

[1] Б. Мазель. Роль компьютерного моделирования в корпоративном управлении: обзор , стр. 8, декабрь 1975 г.,

[2] Дэн Галорат, почему SEER начался 18 августа 2008 г.

[3] Дэн Галорат, почему SEER начался 18 августа 2008 г.

[4] Галорат, Д. и Эванс М. (2006) Определение размера программного обеспечения, оценка и управление рисками ISBN 0-8493-3593-0 Страница xxii

[1]

[2]

[3]

[4]