ООО «Системный Подход». Нефункциональные требования(НФТ) важная часть процесса разработки ПО Атрибуты качества (ИСО/МЭК 9126-93) Классификация нефункциональных. - презентация

1 ООО «Системный Подход»

2 Нефункциональные требования(НФТ) важная часть процесса разработки ПО Атрибуты качества (ИСО/МЭК ) Классификация нефункциональных требований (FURPS+) Группы архитектурных требований Для документирования реализации и валидации НФТ сценарии эффетивный механизм. Главная проблема нефункциональных требований Нефункциональное функциональное Атрибуты качества. Сценарии Виды сценариев атрибутов качества Пример Сценария «надежность вратаря» Пример Частного сценария удобства использования системы Пример тем для общих сценариев (USABILITY) Рекомендованная литература ООО «Системный Подход»

3 Шесть характеристик, которые с минимальным дублированием описывают качество программно­го обеспечения Функциональные возможности (Functionality) Надежность (Reliability) Практичность (Usability) Эффективность (Efficiences) Сопровождаем ость (Maintainability) Мобильность (Portability) ООО «Системный Подход»

4 Набор атрибутов, относящихся к сути набора функций и их конкретным свойствам. Функциями являются те, которые реали­зуют установленные или предполагаемые потребности ООО «Системный Подход»

5 Набор атрибутов, относящихся к способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени. ООО «Системный Подход»

6 Набор атрибутов, относящихся к объему работ, требуемых для использования и индивидуальной оценки такого использования определенным или предполагаемым кругом пользователей. ООО «Системный Подход»

7 Набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях. ООО «Системный Подход»

8 Набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций). ООО «Системный Подход»

9 Набор атрибутов, относящихся к способности программного обеспечения быть перенесенным из одного окружения в другое. ООО «Системный Подход»

10 Классификация была создана Робертом Грейди (Hewlett-Packard ) Формирование требований FURPS Функциональность (Functionality) Удобство использования (Usability) Надежность (Reliability) Производительность (Performance) Сопровождаемость (Supportability) "+" в FURPS+ требования к Дизайну (Design requirements) Реализации (Implementation requirements) Интерфейсу (Interface requirements) Физическим параметрам (Physical requirements)

11 Формирование требований Существует большое количество архитектурных решений, которые удовлетворяют функциональным требованиям. Но только некоторые из них соответствуют всей совокупности требований. Басс, Клементс и Кацман выделют следующие группы архитектурных требований (атрибутов качества): Атрибуты качества системы Коммерческие атрибуты качества Атрибуты качества самой архитектуры

12 Атрибуты качества системы Availability (Доступность) Modifiability (Модифицируемость) Performance (Производительность) Security (Безопасность) Testability (Тестируемость) Usability (Практичность) Коммерческие Атрибуты Time (Сроки выхода на рынок) Cost (Стоимость и прибыль) Life Time (Срок службы системы) Target market ( Целевой рынок) Product Schedule (График развертывания продукта) Interoperability (Интеграция с существующими системами ) АК архитектуры Integrity (Целостность) Portability (переносимость) Reusability (Возможность повторного использования) Flexibility (Гибкость) Reliability (надежность ) Robustness (Живучесть) ООО «Системный Подход»

13 Записать требование легко (Гибкость, надежность …) Реализовать сложно Проверить … ООО «Системный Подход»

14 "Если про сон сказать, что это не сон а про не сон - сон, то получится сон про несон или несон про сон" ООО «Системный Подход»

15 Требование значит тестирование Тестирование значит Сценарий Сценарий значит Функция

16 Сценарий атрибута качества это вариант формализации требования связанного с соответствующим Атрибутом качества. Он состоит из следующих частей: Источник стимулов (Source of stimulus). Действующие лицо ( Актер, Агент) генерирующая входные стимулы для системы. Им может быть человек, другая программная система или аппаратное устройство. Стимул (Stimulus).Стимул это обстоятельства/вызовы которые должны быть «отработаны» системой по мере поступления в систему Среда (Environment). Стимулы возникают в определенных условиях. Например система может быть перегружена в момент возникновения стимула.. Элемент (Artifact). Стимул получает определенный элемент системы. Это может быть вся система или ее часть. Реакция (Response). Реакция это действия предпринимаемые после поступления стимула. Измерение реакции (Response measure). Реакция системы должна быть измеримой. Разработка требований

17 Общие сценарии атрибутов качества Включают в себя расширенный набор возможных элементов для соответствующего атрибута качества Общие сценарии обладают порождающими свойствами для идентификации и детализации атрибутов качества Частные сценарии атрибутов качества Состоят из конкретных элементов для каждого элемента Позволяют осуществить валидацию реализации конкретного аспекта атрибута качества ООО «Системный Подход»

18 Источник Любой Игрок : Стимул: Удар по воротам Среда Соревновате льные игры Элемент : Вратарь Реакция: Блокирование мяча Измерение Мяч должен быть не в воротах в 99% случаев атаки Разработка требований

19 Источник : Пользовате ль Стимул: Минимизац ия влияния ошибки Среда: Время выполнения Элемент : Система Реакция: Отмена выполнения текущей операции Измерение: Отмена занимает менее одной секунды Разработка требований

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

21 Л. Басс, П. Клементс, Р. Кацман Архитектура программного обеспечения на практике Software Architecture in Practice Серия: Классика Computer ScienceКлассика Computer Science ООО «Системный Подход»

22 Вопросы? Дополнительные вопросы можете задать на сайте :

23 ООО «Системный Подход» Дополнительные слайды

24 Разработка требований Положительные и отрицательные взаимосвязи характеристик качества Availability Efficiency Flexibility Integrity Interoperability Maintainability Portability Reliability Reusability Robustness Testability Usability

25 ООО «Системный Подход» Какие АК могут соответствовать этим иконкам ?

26 Формирование требований Показатель Единицы измерения Скорость Кол-во выполненных транзакций в секунду; Время реакции на действие пользователя; Время обновления экрана Размер Килобайты; Кол-во модулей памяти Простота эксплуатации Время обучения персонала; Кол-во статей в справочной системе Надежность Средняя продолжительность времени между двумя последовательными проявлениями ошибок в системе; Вероятность отказа системы; Коэффициент готовности системы Отказоустойчивость Время восстановления после сбоя; Процент событий, приводящих к сбоям; Вероятность порчи данных при сбоях Переносимость Процент машинно-зависимых операторов; Кол-во машинно-зависимых подсистем