Файл: Основные положения метрологии программных продуктов.pptx

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

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

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

5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

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

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

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

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

Отметим, что если во внешнем запросе ссылка на файл используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется на элемент данных (однократный учет).

После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (Function Points). Автором этой метрики - А. Альбрехт (1979).

Данные для определения ранга и оценки сложности транзакций и файлов (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4.

Табл.6

«

«

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

Для транзакций ранжирование основано на количестве ссылок на файлы и количестве типов элементов данных.

Для файлов ранжирование основано на количестве типов элементов-записей и типов элементов данных, входящих в файл.

Тип элемента- записи - это подгруппа элементов данных, распознаваемая пользователем в пределах файла.

Тип элемента данных – уникальное или рекурсивное поле, распознаваемое пользователем.

Количество функциональных указателей вычисляется по формуле:

FP= Общее количество*(0,65+0,01*Fi), (1) Где Fi – коэффициент регулировки сложности (I=1..14).

Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.12).

Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки
Вместо подсчета LOC-оценки рассматривается функциональность или полезность продукта
После вычисления FP формируются метрики производительности:

Число внешних вводов – 35;

Число внешних вводов – 35;
Ранг внешних вводов – средний, оценка сложности 4;
Число внешних выводов – 1;
Ранг внешних выводов – низкий, оценка сложности 4.
FP=35*4+1*4=144
FP=Общее количество(0,65+0,01*∑Fi);
Fi- коэффициент регулировки сложности,
Каждый коэффициент может принимать следующие значения: 0 — нет влияния, 1 — случайное, 2 — небольшое, 3 — среднее, 4 — важное, 5 — основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл. 2.11).

Функционально-ориентированные метрики

Функционально-ориентированные метрики

Достоинства функционально-ориентированных метрик:

Не зависят от языка программирования
Легко вычисляются на любой стадии проекта

Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

FP-оценки легко пересчитать в LOC-оценки. Результаты пересчета зависят от языка программирования, используемого для реализации ПО.

Метрология качества

Оценка качества

программного продукта

Стандарты ГОСТ 28806–90, ГОСТ 28195–99, СТБ ИСО/МЭК 9126–2003

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

Характеристики на первом (верхнем) уровне соответствуют основным свойствам ПС. Характеристики каждого уровня оцениваются посредством характеристик последующих.

Стандарты ГОСТ 28806–90, СТБ ИСО/МЭК 9126–2003 определяют первые два уровня иерархической модели качества. Номенклатура характеристик первого уровня обязательная, а номенклатура характеристик второго уровня (подхарактеристик) – рекомендуемой.

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

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

Функциональность (Functionality); - Надежность (Reliability); –

Удобство использования (практичность, Usability); - Эффективность (Efficiency);

–Сопровождаемость (Maintainability); –Мобильность (Portability).

Стандарт ISO/IES 9126-2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой:

- номинальная шкала отражает категории свойств оцениваемого объекта без их упорядочения;

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

интервальная шкала задает существенные свойства объекта (например, календарная дата);
относительная шкала задает некоторое значение относительно выбранной единицы;

Оценка качества программного продукта

.

.

СТБ ИСО/МЭК 9126–2003

и другая

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

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

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

Оценка качества программного продукта

Iso/iec 9126-1:2001

Модель внешнего и внутреннего качества программных средств

(характеристики и подхарактеристики).

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

Функциональность:

1. пригодность;

2. корректность;

3. способность к взаимодействию;

4. защищенность;

5. соответствие функциональности.

Надежность

:

1. завершенности (отсутствие ошибок);

2. устойчивость к ошибке;

3. восстанавливаемость;

4. соответствие надёжности.

21

стандарт ISO/IEC 9126–1:2001 классифицирует метрики качества ПС на внутренние, внешние и метрики качества в использовании. В модели внешнего и внутреннего качества метрики находятся на третьем уровне иерархии и определяют значения подхарактеристик качества. В модели качества в использовании метрики находятся на втором уровне иерархии и непосредственно определяют значения характеристик качества. Применение конкретного вида метрик определяется стадией жизненного цикла программного средства.

В стандарте ISO/IEC TR 9126–2–4 определены следующие желательные свойства метрик:

1)надежность; надежность связана со случайной ошибкой; метрика свободна от случайной ошибки, если случайные изменения не влияют на результаты метрики;

2(повторяемость; повторное использование метрики для того же продукта теми же специалистами, используя ту же спецификацию оценки (ту же окружающую среду), тот же тип пользователей и окружения, должно привести к тем же результатам с теми же допусками;

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

4) применимость; метрика должна четко указывать условия (например, наличие определенных атрибутов), которые ограничивают её употребление;

5) показательность; это способность метрики идентифицировать части или элементы программы, которые должны быть улучшены, на основании сравнения измеренных и ожидаемых результатов;

6) корректность; метрика должна обладать следующими свойствами:

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

7) значимость

эффективной по отношению к стоимости