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

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

404 Глава 8

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

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

(ведения) данных;

• функции (Фун) - набор функциональных примитивов средней сложности,

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

лей приложения. Матрица оценки их сложности представлена в таблице 8.32;

Таблица 8.32. Матрица оценки сложности функций

Уровень сложности Количество функциональных примитивов

Низкий 5 – 12

Средний 13 – 19

Высокий 20 – 25

• макрофункции (МаФ) - набор функций средней сложности. Их можно ас-

социировать с фрагментом приложения, с целым приложением или со всей систе-

мой потребителя. Матрица оценки их сложности представлена в таблице 8.33.

Таблица 8.33. Матрица оценки сложности макрофункций

Уровень сложности Количество функций

Низкий 2 – 3

Средний 4 – 7

Высокий 8 – 12

Все объекты EFP-метода далее связываются с тремя весовыми категориями –

«минимум», «среднее» и «максимум» (таблица 8.34).

Таблица 8.34. Веса объектов EFP-метода по уровням сложности

ЛЭД Мини-

мум

Среднее Макси-

мум

МиФ Мини-

мум

Среднее Макси-

мум

Низкий

5 6 7 Микроф. 16 18 20

Средний

8 9 10

Фун Мини-

мум

Среднее Макси-

мум

Высокий

13 14 15

Низкий

45 56 67

Слож-

ный

14 18 22

Сред-

ний

73 91 109

Сверх-

сложн.

27 39 51

Высо-

кий

106 133 160

ФПр Мини-

мум

Среднее Макси-

мум

МаФ Мини-

мум

Среднее Макси-

мум

ПрВВД

4 5 7

Низкий

151 215 280

ПрВЫВ

5 6 8

Сред-

ний

302 431 560

ПрЗАП

4 5 7

Высо-

кий

603 861 1119

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

ных в реальных проектах.

Глава 8 405

Для определения прогнозируемого размера приложения в УЕФ необходимо

определить количество объектов всех видов по каждому уровню сложности и по-

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

Не существует достаточно четкого описания метода идентификации объектов

– можно «отталкиваться» как от объектов-данных, так и от объектов-функций (де-

ловых процессов пользователя). Многое зависит от знания и опыта экспертов, вы-

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

торые рекомендации можно найти в работе Л.Сантилло и Р.Мели [14].

8.2.8. Метод Full Function Points и его разновидности

Метод Full Function Points (FFP) - наиболее интересное развитие методоло-

гии FPA. Он предложен в 1997 А.Эбреном из UQAM (университет в Квебеке, Мон-

реаль, Канада) и поддерживается Международным Консорциумом COSMIC (Com-

mon Software Measurement International Consortium) [15], [16].

Метод в большей степени ориентирован на системы реального времени (в том

числе системы телекоммуникации, системы управления процессами) и встроенные

системы (системы управления устройствами), но может использоваться и в уни-

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

ские, бухгалтерские и др., обеспечивающие обработку больших объемов данных).

Однако он не предназначен для определения размера компонентов ПО, имеющих

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

(компьютерные игры, программы музыкальных инструментов и др.).

Главное преимущество COSMIC-FFP - использование процессо-

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

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

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

процессов представляет собой упорядоченное множество подпроцессов, выпол-

няющих либо перемещение данных, либо их обработку (рисунок 8.3).

Функциональные требования

пользователей

Тип функционального

процесса

Тип

"перемещение

данных"

Тип

"манипулирование

данными"

Подпроцесс

Программное обеспечение

Рис.8.3. Модель ПО в интерпретации FFP

Модель COSMIC-FFP различает четыре типа подпроцессов перемещения

данных – вход, выход, чтение и запись. Каждый из этих подпроцессов перемещает

данные, принадлежащие только к одной группе данных (в рамках границ группы).

Подпроцессы- входы перемещают данные извне – в границы приложения пользова-

406 Глава 8

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

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

записи перемещают данные из и в хранилища (рисунок 8.4).

Входы

Выходы

Техническое

обеспечение

ввода-вывода

Чтение

Запись

Программное

обеспечение

Техническое

обеспечение

хранения

Пользователь

или

устройство

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

данными

(обработка)

Рис.8.4. Основной поток данных с позиций их функциональной обработки

Подпроцессы манипулирования данными в данной версии (2.2) метода FFP

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

ется пока не согласованной [17].

Программное обеспечение (на рисунке 8.4) включает все программные сред-

ства (и разрабатываемые, и не разрабатываемые). В зависимости от того, каких

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

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

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

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

(GUI), но не предъявляет требований к другим компонентам ПО (например, драй-

верам устройств), модель ПО может включать два слоя (рисунок 8.5).

Мышь

Клавиа-

тура

Экран

Принтер

Драйвер

ОС1

ОС2

GUI

Приложение

СУБД

ОС3

Драйвер

Жесткий

диск

Пользователь

слойслой

Рис.8.5. Пример модели ПО для определения функционального размера

Процесс измерения функционального размера ПО включает следующие ша-

ги, детально описанные в [17]:

Глава 8 407

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

ми средствами, установить границы того фрагмента (части) ПО, размер которого

будет определяться;

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

событий (осуществляющих «запуск» этих процессов из среды слоя) и группы дан-

ных;

• из идентифицированных объектов построить модель ПО в контексте тре-

бований FFP (отобразить функциональные требования на модель FFP) и выделить

слои;

• идентифицировать все подпроцессы в каждом функциональном процессе;

• оценить функциональные процессы в единицах CFSU (Cosmic Functional

Size Unit) из расчета – одна единица размера на один подпроцесс перемещения

данных:

;)()()(

)()_(

∑∑∑

∑

записьРазмерчтениеРазмервыходыРазмер

входыРазмерпроцессаьногофункционалРазмерCFSU

• Оценить объем изменений в каждом функциональном процессе по фор-

муле:

;)_(

)_(

))_((

∑

яперемещениудаленныеРазмер

яперемещениванныемодифицироРазмер

яперемещениедобавленныРазмер

процессаьногофункционалИзмененияРазмерCFSU

• оценить размер каждой части ПО (внутри слоя) и затем размер каждого

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

сов.

Очевидно, что метод COSMIC-FFP может эффективно применяться только в

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

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

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

которых не мог быть применен метод Early Function Points) Р. Мели и А. Эбрен

предложили новый метод - Early & Quick COSMIC-FFP (E&Q) [18].

Как и в методе EFP, в E&Q-методе ПО моделируется в виде иерархии функ-

ций - функциональных процессов (ФП). Они классифицируются по уровням слож-

ности – «низкий», «средний» и «высокий» в зависимости от прогнозируемого ко-

личества подпроцессов. Далее вводится понятие главный процесс (ГП) – как мно-

жество средних ФП. Уровень сложности ГП, в зависимости от количества ФП, мо-

жет также быть «низким» (6-12 ФП), «средним» (13 – 19 ФП) или «высоким» (20 -

25 ФП). По аналогии вводится макропроцесс (МП) как совокупность ГП средней

сложности. Уровни сложности МП - «низкий» (2 - 3 ГП), «средний» (4 – 7 ГП) или

«высокий» (8 -12 ГП). И, наконец, 4-й вид процессов – типовые процессы (ТП) –

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

408 Глава 8

создание, выборка, обновление, удаление. Это разновидность главных процессов.

Веса сложности указывают количество единиц CFSU, которое должно быть при-

своено процессу.

Одна из важнейших концепций COSMIC FFP – контекст измерения системы,

формируемый в результате определения Целей (назначения) измерения, Сферы

(масштаба) измерения и Угла зрения (взгляда) на измеряемый объект. Именно Угол

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

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

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

В отличие от методологий измерения размера первого поколения (FPA, Mark-

II и др.), в COSMIC FFP объекты могут рассматриваться под углом зрения не толь-

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

темой), но и разработчика. Разработчик может, например, принять решение об

использовании разных технологий реализации отдельных частей системы, что, в

свою очередь, приведет к выделению тех или иных слоев системы, о которых поль-

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

ченные по методу COSMIC FFP и другим, нужно обращать внимание на установ-

ленный Угол зрения. Например, расчеты размера бизнес-приложений по FPA и

COSMIC FFP, выполненные под углом зрения пользователей дают вполне сопоста-

вимые результаты.

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

в сфере бизнес приложений, в 2005 году появилась адаптация COSMIC FFP для

этой сферы [19]. В ней в качестве исходных элементов для анализа системы могут

служить диаграммы «сущность-связь», диаграммы классов или сценарии использо-

вания системы.

В последнее время метод COSMIC FFP получил существенную инструмен-

тальную поддержку, в частности, в CASE-средах, предлагаемых Rational Software

inc. (приложение 4).

8.3. Определение размера Web-приложений

8.3.1. Характеристика программного обеспечения для Web и подход к его

измерению

В последнее десятилетие Интернет занял прочное место во многих сферах

деятельности. По данным, опубликованным Cutter Consortium, уже к 2000 году ко-

личество Web-сайтов во «всемирной паутине» перешагнуло рубеж 196 миллионов

[20].

Темпы программной индустрии для Web значительно превысили темпы фор-

мирования основ инженерии качества ПО для Web и, прежде всего, методов изме-

рения и оценивания ПО – его размера, трудоемкости и стоимости.

Изменения, произошедшие за последние годы в практике разработки про-

граммного обеспечения, подытожены в таблице 8.35 [21].

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

предприятия и др.

Глава 8 409

Таблица 8.35. Сопоставление традиционной и Web-разработки ПО

Характеристики Традиционная разработка Web-разработка

Основные цели Разработка качественного про-

дукта с минимальными затрата-

ми

Разработка качественного про-

дукта на рынок за возможно

наиболее короткий срок

Размер команды

проекта

Средний и большой (сотни че-

ловек)

Малый (3-5 человек в команде)

Продолжитель-

ность

12-18 месяцев 3-6 месяцев

Применяемый

подход к разра-

ботке

Основан на: требованиях; вы-

пуске по фазам и/или прираще-

ниям; сценариях использования.

Документированный

Основан на: RAD, сборке из

блоков, прототипировании, RUP.

Модельно-ориентированная раз-

работка

Парадигмы и ме-

тодологии

Объектно-ориентированные ме-

тоды, генераторы, современные

языки программирования (С++ и

другие), CASE-средства

Компонентные методы, языки 4

и 5 поколения (HTML, Java и

др.), визуализация (движение,

анимация) и др.

Процессы СММ-подобные Не упорядочены

Программные

продукты

В основном новые системы, ос-

нованные на коде, с небольшим

количеством повторно исполь-

зуемых компонентов, со слож-

ными внешними интерфейсами

Относительно простые объект-

но-ориентированные системы с

большим количеством повторно

используемых компонентов, с не

сложным внешним интерфейсом

Персонал Профессиональные разработчи-

ки с достаточным опытом

Дизайнеры графики, неопытные

программисты, инженеры и др.

Технологии оце-

нивания

SLOC и FPA-подобные модели,

COCOMO и др.

До 2000 года не упорядочены

Методологии измерения, широко применяемые до 2000 года, ориентирова-

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

модели проверялись и уточнялись в течение более 20 лет; параметры моделей мно-

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

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

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

ления разработкой.

Однако очевидные отличия Web-проектов от традиционных (представленные

в таблице 8.35), обусловили сложность адаптации и применения существующих

методологий к Web-разработке.

Проблемы оценивания Web-проектов, с которыми столкнулись специалисты,

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

зуемые для оценивания.

Первые приемлемые практические решения в данной проблематике появи-

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

точного количества эмпирических данных, лежащих в основе построения необхо-

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

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

проектов.

410 Глава 8

Таблица 8.36. Проблемы оценивания Web

Область

Проблем

Традиционный подход Проблемы для Web-разработки

Процесс оце-

нивания

Использование аналогов и уроков,

извлеченных из прошлого опыта.

Общая концепция – по стандартам

ISO/IEC 14598, ISO/IEC 15539

Оценка работы исключительно на

основе мнений разработчиков

(как правило, слишком оптими-

стичных)

Оценивание

размера

Поскольку системы основаны на

требованиях, используются методы

SLOC или FPА-подобные

ПО использует множества Web-

объектов (html, xml, aпплетов и

др.). Нет согласованных методов

Оценивание

усилий

Усилия оцениваются с помощью

регрессионных моделей. Для опре-

деления соотношений между пере-

менными строятся графики данных

по проекту

Усилия оцениваются путем раз-

биения работы на отдельные за-

дачи, требующие приложения

усилий. История по проектам

практически отсутствует

Оценивание

продолжи-

тельности

Рассчитывается как кубический

корень от усилий

Расчеты с помощью корня куби-

ческого дают отклонения на по-

рядок выше

Калибровка

моделей

Для калибровки моделей с целью

повышения их точности использу-

ются измерения по прошлым про-

ектам

Измерения по прошлым проектам

фиксируются как прецеденты (их

слишком мало, чтобы использо-

вать)

Анализ риска Модели оценивания используются

для анализа риска, а также для вы-

числения коэффициента отдачи от

инвестиций и анализа затрат/ выгод

Анализ риска выполняется без

применения моделей оценивания.

Коэффициент отдачи от инвести-

ций не вычисляется, анализ за-

трат/выгод не производится

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

вать по четырем категориям:

•

Web-приложения,

•

Web-интерфейсы к существующим приложениям,

•

динамические Web-сайты,

•

cтатические Web-сайты.

Web-приложения в полной мере предоставляют пользователю функциональ-

ные возможности программных приложений через Web-браузер. К Web-

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

работы в Web-среде, а также новые, ранее не существовавшие, типы приложений.

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

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

можности серверов по выполнению функций приложения, а также Web-интерфейс,

как стандартная оболочка, обрамляющая приложение. Примеры Web-приложений –

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

Hotmail (http://www.hotmail.com), расчетное приложение-форма с Web-оболочкой

(Java-апплет), предоставляющее услуги Интернет-калькулятора (“Constructive Reals

Calculator” - http://www.hpl.hp.com/personal/Hans_Boehm/crcalc/CRCalc.html) и др.

Web-интерфейсы к существующим приложениям обеспечивают для широко-

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

Глава 8 411

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

намически генерируемые HTML-страницы для взаимодействия с приложениями и

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

ществующими интерфейсами приложений. Примеры Web-интерфейсов – регистра-

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

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

мер, http://www.maxi.com.au).

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

лярно изменяемую и/или пополняемую информацию об организациях и лицах или

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

HTML-страницы и сопровождают данные в БД, подлежащие отображению на экра-

не пользователя. Примеры – сайты новостей (например, http://www.theage.com.au).

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

редко изменяемую, информацию об организациях и лицах или по определенной

проблематике. Организованы как гипертекстовые документы. Реализованы как

коллекции жестко запрограммированных HTML-страниц с гипертекстовыми ссыл-

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

сайты. Могут включать как текстовые, так и не текстовые элементы, а также

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

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

ментов, например, Microsoft FrontPage или вручную с помощью текстовых редакто-

ров. Примеры статических Web-сайтов – сайты организаций (ISO, IFPUG, Microsoft

и др.).

Все представленные категории ПО для Web обычно используют такие конст-

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

•

не текстовые (мультимедиа) элементы – графика, видео и аудио;

•

элементы с внешними источниками - публикации и отчеты, получаемые

по сети Web;

•

гипертекстовые ссылки к другим Web-сайтам.

Эффективность определения размера ПО для Web зависит от категории ПО и

назначения получаемых оценок размера.

Для оценивания размера ПО первых трех категорий может применяться кон-

цепция измерения функционального размера FSM, а полученные оценки использо-

ваться для определения трудоемкости разработки этого ПО.

FSM концептуально объединяет все представленные ранее методы определе-

ния размера ПО (раздел 8.2), полагая в основу оценивания, прежде всего, объем

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

ция которых требует затрат времени и средств.

Для статических Web-сайтов подход FSM эффективен только в следующих

случаях:

- если изменения, которые необходимо сделать в Web-сайте, касаются его

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

вующий (запрос о новом виде продукции, уточняющая информация в запросе о

продукции и др.),

- если возрастающие объемы данных или потребность в получении дина-

мически изменяемой информации требуют преобразования типа Web-сайта на ди-

намический.

412 Глава 8

Такие ситуации возникают, когда по структуре Web-сайт становится похо-

жим на информационную систему.

В большинстве же случаев FSM-подход мало эффективен для статических

Web-сайтов. Размер и трудоемкость создания таких сайтов в основном определяет-

ся количеством, размером и сложностью HTML-страниц, а не функциональностью,

предоставляемой пользователям.

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

1) размер и сложность HTML-страницы, вычисляемая исходя из

- размера страницы в «словах» или «байтах»,

- количества нетекстовых элементов на странице и элементов с внешними

источниками, с учетом типа этих элементов,

- количества и типа гиперссылок в рамках страницы и за ее пределы;

2) общее количество и тип уникальных нетекстовых элементов и элементов с

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

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

зовании указанных метрик, называемый Web Points (WP), рассматривается в п.8.3.3.

Работы же над проблемой определения функционального размера ПО для

Web остальных категорий (не статических Web-сайтов) проводятся в двух направ-

лениях:

• создание новых методов в рамках FSM-подхода, как, например метод

Web Objects, рассматриваемый в п.8.3.2.

• интерпретация правил IFPUG для Web-приложений (п.8.3.4).

8.3.2. Метод Web Objects. Определения размера Web-приложений

Для оценивания размера Web-приложений Д.Рифер в 2000 году предложил

метрику Web Objects (WO), которая основывается на оценке сложности множества

конструктивных элементов, составляющих Web-приложение [21].

Метрика использует уравнение Холстеда (см. главу 5) для оценивание разме-

ра программы по независимым от языка программирования параметрам - операн-

дам и операторам, причем под программой в данном случае понимается конструк-

тивный элемент Web-приложения:

)(log)()(log

nnNNnNS +⋅+==

где N – общее число Операндов/Операторов,

n – число разных Операндов/Операторов,

– оценка общего числа Операндов,

– оценка общего числа Операторов,

– оценка числа разных Операндов,

– оценка числа разных Операторов,

– объем (сложность) работы по созданию программы.

Д.Рифер выделил несколько типов конструктивных элементов Web-

приложения, оценки сложности которых «по Холстеду», используются в качестве

предсказателей размера (таблица 8.37).

Глава 8 413

Таблица 8.37. Предсказатели размера Web-приложения

Веса сло-

жности

№

пп

Предсказатели Примеры

Операндов (объек-

тов)

Примеры

Операторов (дейст-

вий)

С В

1 Блоки Компоненты ActiveX,

DCOM, OLE

Create, Apply, Call,

Interface, Terminate

1 2 4

2 COTS-компоненты

(включая код упа-

ковщиков)

Коммерческие про-

граммы, библиотеки

процедур

Initiate, Terminate,

Apply, Bind, Custom-

ize, Export

2 4 6

3 Графические файлы Шаблоны, рисунки,

фотографии и др.

Apply, Align, Import,

Export, Insert

2 4 6

4 Компоненты муль-

тимедиа

Текст, видео, звук,

3D-объекты, плагины,

мета-теги

Create, Cut, Paste,

Clear, Edit, Animate

1 2 4

5 Компоненты, для

которых возможен

расчет FPA-по-

добными методами

Число таблиц на сер-

вере, число таблиц на

клиенте, % реюза

Transform (входы в

выходы), Access,

Generate, Interface

- -

6 Запросы на языке

запросов

Число операторов

языка запросов

Browse, Find, Search,

Retrieve, Optimize

5 5 8

7 Повторно исполь-

зуемые компоненты

Алгоритмы, проекты,

программы и др.

Create, Aggregate,

Apply, Call, Interface,

Terminate

2 4 6

8 Скрипты и макросы

языка визуального

программирования

Агрегации, контейне-

ры, поддержка реаль-

ного времени

Create, Store, Distrib-

ute, Serialize, Edit,

Generate

1 2 3

9 Другие 2 4 6

Каждый конструктивный элемент-предсказатель любого типа представлен

множеством операндов (объектов) и операторов (действий над объектами) Приме-

ры операндов и операторов также приведены в таблице 8.37.

С каждым типом предсказателей связан вес, приписываемый в зависимости

от оцененного уровня сложности операндов и операторов Web-приложения. Значе-

ния весов получены Д.Рифером по реальным данным из 46 проектов [21].

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

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

предсказатели и составить их общий список. Если не найден подходящий тип пред-

сказателя – использовать «другой».

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

- определить множество уникальных операндов и операторов;

- оценить «вклад» операндов и операторов в сложность разработки конст-

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

(«низкий», «средний», «высокий») и установить вес по таблице 8.37;

- определить количество элементов каждого уровня сложности;

Уровень сложности: Н – «низкий», С – «средний», В – «высокий».

Размер элемента может быть учтен другим методом (см. разделы 8.1 и 8.2).