Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

414 Глава 8

- применить известную процедуру агрегирования оценок и получить оцен-

ку размера конструктивных элементов одного типа в единицах web objects (WO

i∈(1,9)):

iji

WNWO

∑

где N

– число простых, средних или сложных элементов, а W

– относитель-

ные веса, присваиваемые им в зависимости от «вклада» в сложность приложения.

Наконец, просуммировать оценки для всех типов элементов приложения.

8.3.3. Метод Web Points. Определение размера статических Web-сайтов

Метод определения размера статических Web-сайтов в единицах Web Points

(WP) был представлен Д.Клиэри на конференции IFPUG в 2000 году [22].

В качестве предсказателей размера сайта автор использует количество и

сложность HTML-страниц. Сложность каждой страницы классифицируется как

«низкая», «средняя» и «высокая» в зависимости от ее размера в «словах» и суммар-

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

текстовых элементов на странице (таблица 8.38). Диапазоны значений, указанные в

таблице, получены Д.Клиэри в результате анализа данных фирмы Charismatek и в

ходе практического применения метода могут быть откалиброваны по имеющимся

у разработчиков сайтов данным.

Таблица 8.38. Оценивание сложности HTML-страницы

Число гиперссылок Сложность

0-5 6-15 >15

0-300

Низкая Низкая Средняя

301-500

Низкая Средняя Высокая

Количе-

ство

слов

>500

Средняя Высокая Высокая

Уровням сложности приписывается вес: 4 – для «низкой», 6 – для «средней»

и 7 – для «высокой» сложности каждой HTML-страницы. Общий размер сайта в

единицах Web Points рассчитывается по формуле:

WNWP ⋅=

∑

где N – число простых, средних или сложных страниц, а W - относительные веса,

присваиваемые им в зависимости от «вклада» в сложность Web-сайта.

Метод эффективен в тех случаях, когда, во-первых, функционально Web-сайт

существенно отличается от информационной системы, а во-вторых, его изменения

в основном касаются содержимого HTML-страниц (например, добавления блока

текста или графического элемента).

8.3.4. Адаптация методов оценивания размера Web-приложений к мето-

дологии FPA

Представленные методы Web Objects, Web Points и некоторые другие, напри-

мер, Internet Points, Data Web Points [23], обладают рядом недостатков, в частности:

- измерения применимы на завершающих стадиях разработки ПО,

- методы ориентированы на Web-приложения и статические Web-сайты,

Глава 8 415

- оценки получены эмпирическим путем в условиях применения опреде-

ленных технологий реализации ПО для Web (например, реализация с помощью

html или xml) и нуждаются в калибровке.

Поскольку ISO пока не предложила стандартизованных методов, разработан-

ных в рамках концепции FSM и ориентированных на атрибуты, свойственные Web-

приложениям, многие специалисты адаптируют ранее предложенные ими методы

определения размера к методологии FPA.

Метод Web Objects (уточненная версия). В 2002 году Д.Рифер развил метод

Web Objects, взяв за основу методологию FPA. Он уточнил спектр и описания кон-

структивных элементов Web-приложений, сократил общее количество предсказа-

телей размера, специфичных для Web, до четырех и добавил их к показателям

ПФР, принятым в FPA (таблицы 8.39 и 8.40) [24].

Таблица 8.39. Предсказатели размера по методологии FPA

Веса сложно-

сти

Предска-

затели

Описание

С В

ВЛО Внутренние логические объекты, используемые Web-

приложением для хранения информации и сопровождае-

мые в нем

7 10 15

ВИО Внешние логические объекты, на которые ссылается

Web-приложение, но сопровождаемые другим программ-

ным приложением

5 7 10

ВВД Логические элементарные бизнес-процессы вне границ

приложения, направленные “внутрь” приложения с целью

ведения его ВЛО, доступа к Объектам Мультимедиа, за-

пуска Скриптов и доступа к Связям

3 4 6

ВЫВ Логические элементарные бизнес-процессы, в результате

выполнения которых данные покидают границы прило-

жения в затребованном пользователями виде (отчеты,

экраны)

4 5 7

ЗАП Логические элементарные бизнес-процессы, в результате

выполнения которых формируется запрос и выборка дан-

ных, покидающих границы приложения (например, про-

стой просмотр данных)

3 4 6

Калибровки в новом варианте метода выполнены Д.Рифером по 64 Web-

проектам всех категорий (в упомянутой ранее классификации).

Сначала определяется количество и сложность операндов и операторов пер-

вых трех видов конструктивных элементов Web-приложения (мультимедиа, блоков

и скриптов) и подсчитываются Web Objects с учетом весов. Используется процеду-

ра оригинального метода Web Objects 2000 года.

Далее определяется сложность Связей (xml, html и запросов). Для подсчетов

может использоваться методология, разработанная институтом SEI для учета строк

кода - SLOC [1].

Определяется количество и сложность объектов Web-приложения, присущих

традиционным программным приложениям (таблица 8.39). Может использоваться

наиболее подходящий метод, совместимый с FPA (разделы 8.1 и 8.2).

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

мер Web-приложения в условных единицах функциональности – Web Objects.

Таблица 8.40. Уточненные предсказатели размера Web-приложений

Веса Предска-

затели

Описание

Н С В

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

Объекты

мульти-

медиа

Физические объекты Web-

приложения, используемые

для вывода информации в

мультимедиа формате

4 5 7 Учитывают сложность встраивания в приложения аудио- и видео-файлов,

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

кументов (на стороне клиента и сервера).

Примеры уровней сложности: JPEG – низкий; A2b music, Microsoft-картинка

– средний; PCX Image, XIF Image, AIFF Audio – высокий.

Подсчет операторов выполняется отдельно для каждого объекта

Блоки

(включая

повторно

исполь-

зуемые)

Логические объекты, исполь-

зуемые для конструирования

Web-приложений и автомати-

зации их функций

3 4 6 Учитывают сложность разработки (приобретения) компонентов и библио-

тек, включая новые активные элементы – ActiveX, апплеты, агенты и др.,

статические элементы – COM, DCOM, OLE и др., повторно используемые

элементы – логотипы и др., и исключая стандартные библиотеки среды раз-

работки (на стороне клиента и сервера)

Каждый уникальный блок в библиотеке учитывается отдельно. Уровень

сложности устанавливается исходя из количества объектов: 1-50 – низкий,

51-250 – средний, более 250 – высокий

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

Скрипты

Логические объекты, исполь-

зуемые Web-приложением

для связи внутренних объек-

тов с блоками по определен-

ным шаблонам

2 3 4 Учитывают сложность связывания html/xml-данных и генерации отчетов

(автоматически), организации обращения к ODBC-источникам, интеграции

и анимации приложений по установленной логике (с помощью GIF), и

управления динамическим Web-контентом посредством настраиваемых пал-

лет, масок, окон и команд (на стороне клиента и сервера)

Каждый скрипт или сценарий использования учитывается отдельно. Уро-

вень сложности устанавливается исходя из количества акторов: 1-3 – низкий,

4-6 – средний, более 6 – высокий

Подсчет уникальных операторов выполняется отдельно для каждого скрипта

Связи

(линки)

Логические объекты (xml,

html и запросы), поддержи-

ваемые Web-приложением с

целью установления связей с

внешними приложениями

3 4 6 Учитывают сложность разработки средств динамического связывания при-

ложений, их интеграции, обращения к БД и другим приложениям

Подсчитываются отдельно по числу строк (а не операндов и операторов).

Может использоваться методика SEI для учета SLOC. Уровень сложности

устанавливается так: html – низкий, запросы – средний, xml – высокий

Глава 8 417

Д.Рифер уточнил также коэффициенты расширения кода с учетом современ-

ных языков и средств разработки Web-приложений [24].

Конвертирование значения показателя функционального размера в эквива-

лентное число строк исходного кода Web-приложения (SLOC) на соответствующем

языке программирования может выполняться с использованием данных, представ-

ленных в таблице 8.41.

Таблица 8.41. Значения коэффициента расширения кода

Язык программирования SLOC/УЕФ

Языки программирования 1-го поколения

320

C 128

Языки программирования 2-го поколения

107

COBOL (ANSI85) 91

FORTRAN 107 107

PASCAL 91

Языки программирования 3-го поколения

C++ 53

Java для Web 32

LISP 64

ORACLE 38

Visual Basic 40

Visual C++ 34

Визуальные языки для Web (по умолчанию) 35

Объектно-ориентированные языки (по умолчанию) 29

EIFFEL 20

PERL 22

Smalltalk 20

Объектно-ориентированные языки для Web (по умолчанию) 25

Языки программирования 4-го поколения

Crystal Reports 20

Генераторы программ (по умолчанию) 16

HTML 15

SQL для web 10

Электронные таблицы (по умолчанию) 6

Excel 6

Screen Painter 6

Языки программирования 5-го поколения

XML 6

MATHCAD 5

Метод OOmFPWeb. Для оценивания размера ПО для Web на ранних стадиях

его создания О.Пастор и С.Эбрехи предложили метод OOmFPWeb, являющийся

адаптацией ранее разработанного ими метода OOmFP для расчета размера объект-

но-ориентированного ПО [25].

Метод базируется на пользовательских требованиях к Web-приложению,

представленных в Концептуальной модели приложения.

См. также п.8.4.3, где обсуждается проблема подготовки и использования эталон-

ных данных

418 Глава 8

Предполагается, что приложение разрабатывается с применением модельно-

ориентированного подхода OOWS (от Object-Oriented Web-Solutions). Подход

OOWS был предложен этими же авторами как расширение объектно-

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

кода по Концептуальной модели приложения, которая строится на ранних стадиях

ЖЦ ПО с использованием UML-диаграмм [26].

Процесс концептуального моделирования включает два вида деятельности –

проектирование информационного контента и проектирование навигации (структу-

ры Web-приложения и сценариев его использования) и завершается построением

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

Модель навигации и Модель представления (презентации) приложения, используе-

мые далее для определения размера ПО.

Все абстракции в моделях специфицируются в терминах классов, их структу-

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

Объектная модель в графической форме отображает классы, их атрибуты,

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

ханизмов агрегации и наследования). В иерархии агрегации нужно указать тип аг-

регации – ассоциация или композиция. В иерархии наследования нужно специфи-

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

ношение характеризуется с помощью соответствующего условия на атрибуты-

константы. Во втором случае специфицируется условие на атрибуты-переменные

или сервис типа «захват», который активизирует дочерний класс.

Навигационная модель получается путем дополнения Объектной модели на-

вигационной семантикой Web-приложения, базирующейся на точках зрения каждо-

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

тифицированного в Объектной модели.

Примитивы Навигационной модели:

• Навигационная карта (Navigational Map) – отражает глобальный взгляд на

Web-приложение с точки зрения определенного вида агентов. Включает:

Навигационный контекст (Navigational Context) – определяет базовые

элементы взаимодействия пользователя с ПО, включая множество Навигационных

классов и Навигационных ссылок в Объектной модели. Навигационная ссылка

(Navigational relationship) определяет ненаправленную связь между двумя навига-

ционными классами (отношение типа агрегации или наследования);

Навигационная связь (Navigational Link) – определяет попарные отноше-

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

ными контекстами;

• Навигационный класс (Navigational Class) – включает набор атрибутов и

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

• Контекстные ссылки (Context Relationships) – указывают направления на-

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

ный контекст;

• Контекстно зависимая ссылка (Contextual Dependency Relationship) –

обеспечивает предоставление дополнительной информации в текущем узле (без

указания дальнейшей навигации).

Глава 8 419

Презентационная модель охватывает требования, касающиеся представляе-

мой информации. Связывает следующие элементы построения презентации с нави-

гационными контекстами:

• Информационный макет (Information layout). Например: реестр, таблица,

дерево, «мастер-деталь» и др.;

• Критерий упорядочения (Ordering criteria), определяющий порядок выбора

взгляда на запрошенную информацию (упорядочение по возрастанию/убыванию);

• Организация информации (Information organization), а именно:

Кардинальность (насыщенность) страницы (Рage cardinality) – число

прецедентов (instances), приходящихся на один «логический блок». Может быть

постоянной (статической) или переменной (динамической);

Режим доступа (Access mode). Доступ к логическим блокам может быть

последовательным или случайным (прямым).

Процесс оценивания размера Web-приложения основан на отображении

концепции FPA на примитивы Концептуальной модели.

Отображение включает следующие шаги:

Шаг 1. Концептуальная модель анализируется с целью определения границ

приложения и сферы измерения (отдельно измеряемых фрагментов приложения,

например, отдельных Web-сервисов, сценариев для каждого агента и др.).

Шаг 2. Концептуальная модель анализируется с целью определения кандида-

тов в логические объекты-данные и функции.

Выделяются следующие типы объектов измерения:

• классы, реализующие навигацию (кандидаты в ВЛО),

• взгляды на объекты-данные вне рассматриваемого приложения (кандидаты

в ВИО);

• сервисы (методы навигационного класса) (кандидаты в ВВД),

• контекстные (гипертекстовые) ссылки между навигационными классами

(кандидаты в ЗАП),

• навигационные контексты (кандидаты в ВЫВ или ЗАП).

В качестве ВЛО учитывается каждый класс, ассоциируемый с агентом. Класс

инкапсулирует множество элементов данных (атрибутов), представляющих состоя-

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

на классы существующей (внешней) системы. В качестве ВВД учитывается каждый

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

зируется для (по требованию) агента. В качестве ЗАП учитывается каждый навига-

ционный контекст, определенный в Модели навигации. Контекстная информация

выбирается без внешнего вмешательства в поведение системы.

Шаг 3. Определяется сложность каждого идентифицированного объекта (для

каждого навигационного класса) в терминах уровней сложности (низкий, средний,

высокий).

Так же, как и в FPA, сложность структур данных и функций устанавливается

по количеству выделенных ПДО, СОФ, ЭДО и ЭДФ, правила учета (отображения)

которых представлены в таблице 8.42. Для классификации объектов по сложности

используются таблицы методологии FPA (см. раздел 8.1).

420 Глава 8

Таблица 8.42. Правила отображения объектов

Фактор

сложности

Правила отображения

По одному ЭДО для каждого атрибута (данных) класса

По одному ЭДО для каждого атрибута в функции идентификации класса

или взгляда, на который есть однозначная агрегированная ссылка

ЭДО для

классов

По одному ЭДО для каждого атрибута в функции идентификации супер-

класса данного класса

Одна ПДО для класса

ПДО для

классов

По одной ПДО для каждой многозначной ссылки типа агрегации (классов

или взглядов)

По одному ЭДО для каждого атрибута (данных) взгляда (не производного)

ЭДО для

взглядов

По одному ЭДО для каждого атрибута в идентификационной функции, на

которую ссылается класса с помощью однозначной ссылки типа агрегации

Одна ПДО для взгляда

ПДО для

взглядов

По одной ПДО для каждой многозначной ссылки типа агрегации с классом

По одному ЭДО для каждого аргумента сервиса, связанного с данными

Один ЭДО для способности приложения посылать сообщения

ЭДО для

сервисов

Один ЭДО для действия в ходе выполнения сервиса (Accept/Cancel)

Один СОФ для класса, в котором определен сервис

По одному СОФ для каждого нового класса, на который есть ссылка в ар-

гументе сервиса, связанном с объектом

Если определены ограничения целостности, учитывается один СОФ для

нового класса, на который есть ссылка в формуле

Если сервис представляет собой транзакцию, учитывается по одному СОФ

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

Если определена специализация по условию, учитывается по одному СОФ

для каждого нового класса, к которому указан доступ в формуле специали-

зации

Если определена специализация по событию (событие захвата / освобож-

дения (carrier/liberator)), учитывается по одному СОФ для каждого нового

класса, для которого событие состоит в захвате/освобождении

По одному СОФ для каждого нового класса, на который есть ссылка в

формуле контрольного условия, установленного в Диаграмме переходов

состояний

.По одному СОФ для каждого нового класса, на который есть ссылка в

формуле триггера, установленного в Диаграмме взаимодействия

СОФ для

сервисов

По одному СОФ для нового класса, на который есть ссылка в формуле

предусловия, установленного в Диаграмме перехода состояний

По одному ЭДО для каждого атрибута навигационных классов

По одному ЭДО для каждой контекстно зависимой ссылки

По два ЭДО для каждой контекстной ссылки

По одному ЭДО для каждого сервиса, определенного в навигационных

классах

По одному ЭДО для каждой сервисной связи, ассоциированной с сервисом

По одному ЭДО для каждого атрибута, определенного в формуле фильтра

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

По одному ЭДО для каждого атрибута, определенного в формуле фильтра

доступа к информации

ЭДО для

навигаци-

онных

контек-

стов

По одному ЭДО для каждого атрибута, определенного в формуле индекса

Глава 8 421

Фактор

сложности

Правила отображения

По четыре ЭДО для каждого режима последовательного доступа к блокам

данных (предыдущий, следующий, первый, последний, по номеру)

По пять ЭДО для каждого режима случайного доступа к блокам данных

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

По одному ЭДО для кардинальности страницы (динамической)

По одному ЭДО для каждого критерия упорядочения контекста навигации

По одному ЭДО для каждой возможности указать выполняемое действие

По одному ЭДО для способности приложения отображать сообщения

(ошибки, диагностика и др.)

По одному СОФ для каждого навигационного класса

По одному СОФ для каждого нового класса, на который есть ссылка в

формуле фильтра популяции

По одному СОФ для каждого нового класса, на который есть ссылка в

формуле фильтра доступа к информации

СОФ для

навигаци-

онных

контек-

стов

По одному СОФ для каждого нового класса, на который есть ссылка в

формуле индекса

Шаг 4. Уровням сложности приписываются веса (в соответствии с FPA) и

рассчитывается функциональный размер (отдельно данных и функций) Web-

приложения в единицах OOmFPWeb, а затем и суммарный размер приложения по

формулам

∑∑

views

classo

OOmFPOOmFPOOmFP

∑∑

serviceф

OOmFPWebOOmFPOOmFPWeb

Web

фo

OOmFPWebOOmFPWebOOmFPWeb +=

где OOmFP

– количество единиц размера объектов-данных, OOmFP

class

классов, OOmFP

views

- взглядов, OOmFPWeb

- функций, OOmFPWeb

service

- серви-

сов, OOmFPWeb

– навигационных контекстов.

Шаг 5. Значения в единицах OOmFPWeb уточняются с учетом общесистем-

ных нефункциональных требования к приложению.

8.4. Стандартизация методологии измерения размера

8.4.1. Базовый стандарт по измерению объема функциональности

Со времени опубликования методологии FPA появилось множество методов,

основанных на концепции определения объема (размера) функциональности ПО.

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

несовместимости этих методов, что снизило привлекательность каждого из них и

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

функционального размера.

В конце 1992 года сообщества специалистов по измерению ПО из Австралии,

Великобритании, Нидерландов и США создали рабочую группу WG12 при ISO/IEC

JTC1/SC7, которая предложила проект стандарта, призванного устранить несовмес-

422 Глава 8

тимость методов и создать более строгую методологию измерения функционально-

го размера – FSM (Functional Size Measurement). По мере выполнения этого проекта

к нему подключались специалисты из ASMA (Australian Software Metrics Associa-

tion), NESMA (Netherlands Software Metrics Association), UKSMA (UK Software Met-

rics Association), IFPUG и других организаций и сообществ.

Теперь это проект международного стандарта ISO/IEC 14143 «Information

technology - Software measurement - Functional size measurement», который включает

шесть частей, находящихся на разных стадиях разработки и согласования:

1. Часть 1. Определение концепции (в 1998 году принят как стандарт ISO/IEC

14143-1:1998) [27].

2. Часть 2. Оценивание соответствия методов определения размера про-

граммных средств стандарту ISO/IEC 14143-1:1998 (в 2002 году принят как стан-

дарт ISO/IEC 14143-2:2002) [28].

3. Часть 3. Верификация метода измерения размера (объема) функциональ-

ных возможностей (в 2003 году утвержден как технический отчет ISO/IEC TR

14143-3:2003) [29].

4. Часть 4. Эталонная модель измерения размера (объема) функциональных

возможностей (в 2002 году утвержден как технический отчет ISO/IEC TR 14143-

4:2003) [30].

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

меняться метод определения размера (в 2004 году утвержден как технический отчет

ISO/IEC TR 14143-5:2004) [31].

6. Часть 6. Руководство по использованию серии стандартов ISO/IEC 14143 и

связанных с ними международных стандартов (в 2006 году утвержден как стандарт

ISO/IEC 14143-1:2006) [32].

В части 1 стандарта описаны общие основные особенности методов изме-

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

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

Назначение этой части стандарта - обеспечить однозначную интерпретацию прин-

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

что главными потребителями части 1 стандарта будут лица, которые привлекаются

к разработке методов измерения функционального размера и нуждаются в знании

основных характеристик этих методов, а также те, кто хочет проверить, отвечает ли

конкретный метод определения размера ПС основным концепциям FSM.

Часть 2 стандарта предоставляет схему для оценивания степени соответ-

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

требованиям части 1 этого стандарта. Схема включает требования к составу и ква-

лификации экспертных групп, входным документам для выполнения оценивания,

процедурам оценивания и к оформлению результатов. Выполнение оценивания по

этой схеме гарантирует объективность, беспристрастность, последовательность и

повторяемость оценок.

Часть 3 стандарта нужна, прежде всего, тем, кто хочет выбрать метод

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

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

области. Для этого метод-кандидат на использование должен быть протестирован

(верифицирован) путем сопоставления результатов вычислений этим методом и

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

Глава 8 423

ности метода: проверяемость метода, повторяемость результатов, воспроизводи-

мость процедур, точность оценок, конвертируемость меры в другую меру разме-

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

теля, применимость в рамках определенной функциональной области.

Потребители различных методов измерения функционального размера ино-

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

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

глашения о стандартных эталонных наборах требований пользователя (RUR, Ref-

erence User Requirements), применительно к которым могли бы рассматриваться

претензии потребителей.

Цель части 4 стандарта - дать потребителям ориентиры, относительно ко-

торых можно было бы оценить эффективность методов FSM для различных классов

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

стандарта:

• разработчики метода FSM будут иметь возможность проверить его соот-

ветствие функциональные области, в которой он может эффективно использовать-

ся, и отшлифовать метод на эталонных RUR;

• оценщики методов FSM будут располагать эталонными объектами, по

отношению к которым FSM может быть применен и сопоставлен;

• пользователи прекратят неправомерное использование непригодных для

их классов ПС методов измерения размера;

• менеджеры проектов смогут использовать улучшенные эталонные дан-

ные для контрольного тестирования качества ПС и продуктивности проекта.

Эталонные требования пользователя включают функциональные требования

пользователя (FUR, от Functional User Requirements), требования к качеству (QR, от

Quality Requirements) и технические требования (TR, от Technical Requirements).

Стандарт содержит примеры эталонных требований пока только для двух

крупных классов ПС – деловых (офисных) информационных систем и систем ре-

ального времени/управления.

Схема использования эталонной модели FSM показана на рисунке 8.6.

Оцениваемый

метод

Коллекция

эталонных

требований

пользователя (RUR)

Эталонные методы

определения размера

Измерение размера

в соответствии с

оцениваемым методом

Измерение размера

в соответствии с

эталонным методом (ми)

Результаты

Эталонные

результаты

Оценивание

метода

Рис.8.6. Оценивание метода FSM по эталонам

Цель части 5 стандарта – определить подход к классификации функцио-

нальных требований потребителя для применения в FSM. Используя эту часть

стандарта: