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

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

602 Приложение 1

Таблица 1.3. Характеристики модели с прототипированием

Характеристики Преимущества

Для анализа и моделирования проектных реше-

ний применяется прототипирование

Устраняет проблемы, связанные с не-

полнотой и нечеткостью требований

В таблице 1.4 перечислены основные риски, связанные с применением по-

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

Таблица 1.4. Риски и условия применения последовательных моделей

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

Требования не полностью понятны Требования понятны и не будут существенно

изменяться

Система слишком большая, чтобы быть

реализованной сразу

Разрабатываемая система имеет небольшой

размер и сложность

Быстрые изменения в технологии Все возможности должны быть реализованы

сразу

Частое изменение требований Новая система разрабатывается взамен старой

и нужно полностью заменить старую систему

Пользователь не может использовать

промежуточные продукты

1.3. Итерационные модели

Итерационные модели в целом можно разделить на два класса: модели с при-

ращениями (Incremental) и эволюционные (Evolutionary). В соответствии со всеми

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

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

Основное отличие между моделями - в подходах к определению требований.

1.3.1. Итерационные модели с приращениями

По моделям с приращениями (Incremental) программный продукт разрабаты-

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

ностей. При этом вначале определяются все требования к ПС, а возможно и разра-

батывается предварительный проект. Дальнейшая разработка ПС разбивается на

итерации. В каждой итерации разработка выполняется последовательно и заверша-

ется выпуском работоспособной версии программного продукта. В первой итера-

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

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

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

требований они откладываются до реализации следующей версии. В реальной жиз-

ни это допущение модели может нарушаться и допускается пересмотр требований.

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

или с перекрытием (новая итерация начинается до завершения предыдущей итера-

ции или когда первая стадия предыдущей итерации завершена примерно на 80%).

На рисунке 1.4 приведена структура модели с перекрытием итераций, а в таб-

лице 1.5 - характеристики и преимущества моделей с приращениями.

Приложение 1 603

Проект Реализация Тестирование Выпуск 1

Проект

Анализ требований и

предварительное

проектирование

Реализация Тестирование Выпуск 2

Проект Реализация Тестирование Выпуск 3

...

Рис. 1.4. Итерационная модель с перекрытием итераций

Итерационные модели с приращениями широко применяются для разработки

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

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

Таблица 1.5. Характеристики итерационных моделей с приращениями

Характеристики Преимущества

Анализ и проектирование выпол-

няются для всей системы

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

редь

Базовые функциональные требо-

вания реализуются первыми

Критические функции тестируются более тщатель-

но

Остальные требования реализу-

ются в последующих версиях

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

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

отказов из-за дефектов

Промежуточные версии пригод-

ны для использования

Завершение первой версии окончательно утвержда-

ет требования и проект

Раннее планирование и выполнение тестирования

Раннее выявление дефектов пользователями

В таблице 1.6 перечислены основные риски, связанные с применением моде-

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

Таблица 1.6. Риски и условия применения моделей с приращениями

Риски, связанные с выбором

модели

Когда лучше применять

Требования не полностью понят-

ны

Требуется быстрая реализация основных возмож-

ностей

Требования не стабильны Если проект системы можно естественным образом

разделить на независимые части

Все возможности должны быть

реализованы сразу

Быстрые изменения в технологии

1.3.2. Эволюционные модели

В отличие от моделей с приращениями, эволюционные модели применяются

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

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

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

604 Приложение 1

бранного набора требований до выпуска версии. На каждой итерации выполняется

прототипирование требований и проекта.

К наиболее известным эволюционным моделям в настоящее время относятся

спиральная модель и модель эволюционного прототипирования.

Спиральная модель (Spiral) - разработана Б.Боэмом. Отражает управляемый

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

1.5).

Анализ

риска

Анализ

риска

Анализ

риска

Анализ

риска

Прототип 1 Прототип 2 Прототип 3

Рабочий

прототип

Имитаторы, модели, эталоны

Определение целей,

альтернатив,

ограничений

Обзор состояния и

принятие решения

о разделении

проекта

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

следующих стадий

Детальный

проект

Кодиро-

вание

Автономное

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

Интегра-

ция и

тестирова-

ние

Приемочное

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

Выпуск

Разработка

проекта ПО

Верификация и

валидация проекта

ПО

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

требований

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

ЖЦ

План

разработки

План

интеграции и

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

Требования

к ПО

Анализ

концепции

Валидация

требований

Оценка

альтернатив,

идентификация и

разрешение рисков

Общая

стоимость

Развитие

проекта

Разработка и

проверка продукта

следующего уровня

Рис. 1.5. Спиральная модель ЖЦ

На каждом витке спирали (стадии) выполняются следующие действия:

Определяются цели стадии. Рассматриваются альтернативные решения

для достижения этих целей.

Проводится оценивание этих решений. Идентифицируются риски завер-

шения стадии и выполняется их анализ. Принимаются решения о продолжении или

завершении стадии.

Разрабатываются рабочие продукты стадии и план для следующей ста-

дии.

Последний виток спирали может иметь структуру каскадной модели.

Виды рассматриваемых рисков - риски, касающиеся технических аспектов

разработки, финансовые риски (соотношение эффективость/затраты и ресурсы), а

также риски эксплуатации.

Приложение 1 605

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

когда проблемы проекта недостаточно понятны.

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

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

при которых ее лучше применять.

Таблице 1.7. Характеристики спиральной модели

Характеристики Преимущества

Первый прототип моделирует концепцию. Резуль-

татом является план требований. Перед переходом

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

анализ риска.

Неопределенности в требованиях

пользователя, требованиях к ПО и

проекте моделируются до их реа-

лизации в коде

Второй прототип моделирует требования к ПО.

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

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

няется анализ риска.

Минимизируются ошибки, связан-

ные с отсутствующими, недоста-

точно подробными или противоре-

чивыми требованиями

Третий прототип моделирует проект. В результате

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

прототип. Перед переходом к следующей стадии

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

Прототип сохраняется как физиче-

ская модель потребностей пользо-

вателя

Последний прототип (рабочий) используется как

основа для детального проектирования, кодирова-

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

Промежуточные версии пригодны

для использования

Таблица 1.8. Риски и условия применения спиральной модели

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

Все возможности должны быть реали-

зованы сразу

Проект крупный, сложный и требования не

могут быть определены сразу

Проект нельзя естественным образом

разделить на независимые части

Новая технология и требуется ее освоение

Проект можно естественным образом разде-

лить на независимые части

Пользователи не могут четко сформулировать

требования

Требуется ранняя демонстрация возможностей

Дальнейшим развитием этой модели является Win-Win Spiral Model, которая

основана на привлечении к разработке разных категорий участников проекта и оп-

ределении условий успеха (выигрыша) системы или подсистемы, которые обсуж-

даются на каждой итерации. Возможные альтернативные решения должны оцени-

ваться по отношению к целям и ограничениям проекта.

Модель эволюционного прототипирования. Эта модель основана на приме-

нении эволюционного прототипирования в рамках всего ЖЦ разработки (а не толь-

ко для моделирования требований). В литературе она часто называется моделью

быстрой разработки приложений (RAD от Rapid Application Development). Моде-

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

606 Приложение 1

Анализ применимости модели.

Изучение возможности применения модели для проекта.

Обследование заказчика.

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

Итерация разработки функционального прототипа.

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

ных требований и стратегии реализации системы.

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

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

циональным требованиям.

На шагах 3 и 4 разработчики выполняют определение прототипов, согласование сроков раз-

работки, построение и проверку прототипов. Эти шаги выполняются итеративно и включают

три итерации: начальное ознакомление, уточнение и согласование.

Реализация.

Установка системы в среде заказчика, разработка документации и обучение.

Эта модель применяется для разработки не критических бизнес-приложений,

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

менение предполагает тесное взаимодействие разработчика и пользователя. Разра-

ботка приложений обычно выполняется в среде мощных CASE-средств.

Структура модели представлена на рисунке 1.6, а таблице 1.9 перечислены

основные характеристики и преимущества модели. В таблице 1.10 перечислены

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

лучше применять.

Анализ

применимости

модели

Обследование

заказчика

Итерация

разработки

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

прототипа

Реализация

Итерация

проектирования

и построения

Рис. 1.6. Модель эволюционного прототипирования

Таблица 1.9. Характеристики модели

Характеристики Преимущества

Гибкость. Возможность быстро реагировать на из-

менения и расширения требований

Раннее выявление дефектов в ин-

терфейсе

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

техническими (качества)

Быстрая демонстрация функцио-

нальных возможностей

Приложение 1 607

Таблица 1.10. Риски и условия применения модели

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

От разработчика требуется хорошее владение

CASE- методами и инструментами

Пользователи не могут четко

сформулировать требования

Разрабатываемое приложение должно быть не кри-

тичным

Требуется ранняя демонстрация

возможностей

Требуется наличие мощных CASE-средств

608

Приложение 2. ПРИМЕРЫ МЕТРИК В ЭТАЛОННОЙ

МОДЕЛИ КАЧЕСТВА

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

таблице 2.2 - внешние метрики качества для характеристики «функциональность».

Таблица 2.1. Внутренние метрики характеристики «функциональность»

Название Описание

Функциональная пригодность

Функцио-

нальная адек-

ватность

X = 1 – A/B

А – число функций, определение (описание) которых не отвечает по-

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

В – число проверенных функций

Источники данных:

Спецификация требований, проект, код, отчет о проверке. Виды провер-

ки описаны в главе 5.

Интерпретация значений:

0<=X<=1 (ближе к 1 – лучше)

Полнота

функцио-

нальной реа-

лизации

X = 1 – A/B

А – число обнаруженных пропущенных функций

В – число функций, описанных в спецификации требований

Источники данных и интерпретация значений: здесь и далее - те же

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

Корректность

функцио-

нальной реа-

лизации

X = 1 – A/B

А – число обнаруженных некорректно реализованных или пропущенных

функций

В – число функций, описанных в спецификации требований

Стабильность

функцио-

нальной спе-

цификации

X = 1 – A/B

А – число функций, которые изменялись в ходе ЖЦ разработки

В – число функций, описанных в спецификации требований

Точность

Тщательность

реализации-

функций

X = A/B

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

к точности были полностью реализованы

В – число функций, для которых требования к точности были установ-

лены в спецификации требований

Точность вы-

числения

данных

X = A/B

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

ется специфицированный уровень точности вычислений

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

уровень точности вычислений

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

Способность

к обмену

данными

(основанному

на формате)

X = A/B

А – число форматов интерфейсных данных, реализация которых кор-

ректна по отношению к специфицированным требованиям

В – число форматов данных (предназначенных для обменов), установ-

ленных в спецификациях требований

Приложение 2 609

Название Описание

Согласован-

ность интер-

фейса

(протокол)

X = A/B

А – число протоколов интерфейса, реализующих формат, установлен-

ный в спецификации требований

В – число протоколов интерфейса, которые должны быть реализованы в

соответствии со спецификацией требований

Защищенность

Наблюдае-

мость

доступа

X = A/B

А – число видов доступа, обеспечивающих вход в систему способом,

предусмотренным в спецификации требований

В – число видов доступа, предусмотренных в спецификации требований

Контроли-

руемость дос-

тупа

X = A/B

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

операций, реализованных корректно по отношению к спецификации

требований

В – число требований к контролю доступа, установленных в специфика-

ции требований

Степень пре-

дупреждения

повреждений

X = A/B

А – число обработчиков для предупреждения повреждения данных,

реализованных корректно по отношению к спецификации требова-

ний

В – число способов выполнения работы/доступа, идентифицированных

в требованиях как такие, которые могут привести к повреждению/

разрушению данных

Примечание: с учетом необходимых уровней защиты

Шифрование

данных

X = A/B

А – число предусмотренных обработчиков шифрования/дешифрования

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

цификации требований

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

применено шифрование/дешифрование, как того требует специфика-

ция

Примечание: шифрование – для данных в открытых базах данных, дан-

ных в общедоступных коммуникациях

Соответствие нормам и правилам, касающимся обеспечения функциональности ПС

Функцио-

нальное соот-

ветствие

X = A/B

А – число корректно реализованных элементов, к которым предъявля-

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

мам и правилам (стандартам, соглашениям), выявленных при про-

верке

В – общее число элементов, по отношению к которым установлены

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

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

стандартам

интерфейса

X = A/B

А – число корректно реализованных интерфейсов по отношению к при-

нятым нормам и правилам для системы

В – общее число интерфейсов, требующих согласования с принятыми

для системы нормами и правилами

Приложение 2

610

Таблица 2.2. Внешние метрики характеристики «функциональность»

Название Описание

Функциональная пригодность

Функцио-

нальная адек-

ватность

X = 1 – A/B

А – число функций, реализация которых не отвечает задачам ПС

В – число оцениваемых функций ПС

Источники данных: Спецификация требований, отчет об оценивании

Интерпретация значений: 0<=X<=1 (ближе к 1 – лучше)

Полнота

функцио-

нальной реа-

лизации

X = 1 – A/B

А – число пропущенных функций, обнаруженных при оценивании ПС

В – число функций, описанных в спецификации требований

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

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

тестированию (см. главу 6)

Источники данных и интерпретация значений: здесь и далее - те же

Корректность

функцио-

нальной реа-

лизации

X = 1 – A/B

А – число некорректно реализованных и пропущенных функций, обна-

руженных при оценивании ПС

В – число функций, описанных в спецификации требований

Стабильность

функцио-

нальной спе-

цификации

X = 1 – A/B

А – число функций, которые изменялись с момента ввода ПС в действие

В – число функций, описанных в спецификации требований

Точность

Ожидаемая

точность реа-

лизации

функций

X = A/Т

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

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

Т – время тестирования (использования) ПС

Примечание: Выполняется путем прогона тестов и сравнения ожидае-

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

Источники данных: Спецификация требований, руководство пользо-

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

Интерпретация значений: 0<=X (ближе к 0 – лучше)

Тщательность

реализации

функций

X = A/Т

А – зафиксированное пользователями число случаев неправильного

выполнения функций по отношению к спецификации требований

Т – время использования ПС

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

Интерпретация значений: 0<=X (ближе к 0 – лучше)

Точность вы-

числения

данных

X = A/Т

А – зафиксированное пользователями число результатов вычислений, не

отвечающих требованиям уровня точности

Т – время использования ПС

Источники данных и интерпретация значений: те же

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

Способность

к обмену

данными

X = A/B

А – число форматов интерфейсных данных, успешно участвующих в

обменах с другим ПО или системами при тестировании

Приложение 2 611

Название Описание

(основанно-

му на форма-

те данных)

В – общее число форматов данных, которые должны участвовать в об-

менах

Примечание: выполняется путем прогона тестов для проверки транзак-

ций данных

Источники данных: Спецификация требований, руководство пользо-

вателя, отчет о тестировании.

Интерпретация значений: 0<=X<=1 (ближе к 1 – лучше)

Способность

к обмену

данными

(основанному

на успешных

попытках

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

X = 1 - A/B

А – зафиксированное пользователем число случаев отказа функций при

попытках обмена данными с другим ПО или системами

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

Y = A/T

Т – период времени использования ПС

Источники данных: те же

Интерпретация значений: 0<=X<=1 (ближе к 1 – лучше),

0<=Y (ближе к 0 – лучше)

Защищенность

Наблюдае-

мость

доступа

X = A/B

А – число «доступов пользователя к системе или данным», зафиксиро-

ванных в базе данных истории доступов.

В – число «доступов пользователя к системе или данным», произведен-

ных в ходе оценивания

Примечание: выполняется путем прогона тестов, имитирующих атаки на

ПС, внесение вирусов и др.

Источники данных: тестовые спецификации, отчет о тестировании

Интерпретация значений: 0<=X<=1 (ближе к 1 – лучше)

Контроли-

руемость дос-

тупа

X = A/B

А – число обнаруженных различных типов нелегальных операций

В – число типов нелегальных операций, требования к контролю которых

установлены в спецификации

Источники данных: тестовые спецификации, отчет о тестировании,

отчет о проблемах при эксплуатации

Интерпретация значений: 0<=X<=1 (ближе к 1 – лучше)

Частота по-

вреждения

данных

a) Х = 1 - А/N

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

восстановить, вторичные последствия утраты данных и др.)

N – число тестовых ситуаций, в которых предпринимались попытки по-

вредить данные

б) Y = 1 - B/N

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

в) Z = A/T или B/T

Т – период времени функционирования (в течение периода тестирова-

ния)

Источники данных: те же

Интерпретация значений: 0<=X<=1 (ближе к 1 – лучше),

0<=X<=1 (ближе к 1 – лучше), 0<=Z (ближе к 0 – лучше)