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

Содержание

• 
  Слайд 1

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

  Наталья Желнова Вера Иванова

• 
  Слайд 2

  Содержание

  Классификация нефункциональных требований Шаблоны нефункциональных требований Численные значения нефункциональных требований Связи между нефункциональными и функциональными требованиями Влияние различных категорий нефункциональных требований друг на друга Атрибуты качества продукта и нефункциональные требования Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований

• 
  Слайд 3

  Термины и определения

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

• 
  Слайд 4
  

  Типы требований Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием системы Функциональные требования Нефункциональные требования Системные требования

• 
  Слайд 5
  

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

• 
  Слайд 6
  

  Нефункциональные требования Бизнес-правила (Business Rules)–основываются на корпоративных регламентах, политиках, стандартах, законодательных актах, алгоритмах, etc. Внешние интерфейсы –описание аспектов взаимодействия с другими системами, операционной средой Атрибуты качества (Quality Attributes) – дополнительные характеристики продукта, важные для пользователей и/или разработчиков (переносимость на другие платформы, оперативная совместимость, целостность, устойчивость, etc.) Ограничения (Constraints)– условия, ограничивающие выбор возможных решений по реализации отдельных требований или их наборов Предложения по реализации – предложения, оценивающие возможность использования определенных технологических и архитектурных решений Предложения по тестированию разрабатываемого ПО – дополнения к требованиям, указывающие, каким образом то или иное требование должно быть протестировано Юридические требования– требования к лицензированию, патентной чистоте, etc.

• 
  Слайд 7
  

  Системные требования Высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений Вигерс Карл. Разработка требований к программному обеспечению 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology

• 
  Слайд 8

  Типы нефункциональных требований

  Нефункциональные требования Организационные требования Требования к реализации Стандарты Внешние требования Требования к взаимодействию Юридические требования Требования о сохранении конфиденциальности Требования по технике безопасности Требования к надежности Требования к продукту Требования к эксплуатации Требования к переносимости Требования к эффективности Требования к производительности Требования к памяти

• 
  Слайд 9

  Состав спецификаций

• 
  Слайд 10

  Модель качества ПО

  Характеристики качественного ПО Легко использовать Хорошая производительность Нет ошибок Не портит пользовательские данные при сбоях Можно использовать на разных платформах Может работать 24 часа в сутки и 7 дней в неделю Легко добавлять новые возможности Удовлетворяет потребности пользователей Хорошо документировано etc.

• 
  Слайд 11

  Создание модели качества ПО

  Определение заинтересованных лиц Определение критериев качества Нахождение решения, удовлетворяющего критериям

• 
  Слайд 12

  Модели качества программного обеспечения

  ISO 9126 ГОСТ 34 McCall’s Quality Model (1977) Boehm’s Quality Model(1978) 1061-1998 IEEE Standard for Software Quality Metrics Methodology ISO 8402:1994 Quality management and quality assurance

• 
  Слайд 13

  Модель качества ISO 9126

  Оценка качества ПО основана на трехуровневом рассмотрении: Цели (goals) — то, что мы хотим видеть в ПО Атрибуты (attributes) —свойства ПО, показывающие приближение к целям Метрики (metrics) — количественные характеристики степени наличия атрибутов Выделено 6 целей: функциональность (functionality) надежность (reliability) практичность или удобство использования (usability) эффективность (efficiency) сопровождаемость (maintainability) переносимость или мобильность (portability).

• 
  Слайд 14

  Характеристики качества ПО (ISO 9126)

• 
  Слайд 15
  
• 
  Слайд 16
  
• 
  Слайд 17

  Характеристики качества

  Функциональность –способность решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования Надежность –способность выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций Удобство использования – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя

• 
  Слайд 18
  

  Эффективность – способность обеспечивать требуемый уровень производительности в соответствии с выделенными ресурсами, временем и другими обозначенными условиями Удобство сопровождения – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов, для реализации новых требований, для облегчения дальнейшего обслуживания и адаптироваться к изменяющемуся окружению Переносимость – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/hardware) в другое

• 
  Слайд 19

  Основные характеристики качества ПО (ISO 9126)

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

• 
  Слайд 20

  Модель качества ПО поМакКолу

  Характеристики качества: Факторы (factors), описывающие ПО с позиций пользователя и задаваемые требованиями Критерии (criteria), описывающие ПО с позиций разработчика и задаваемые как цели Метрики (metrics), используемые для количественного описания и измерения качества

• 
  Слайд 21

  Критерии качества ПО поМакКолу

  Критерии качества — числовые уровни факторов, поставленные в качестве целей при разработке: Удобство проверки на соответствие стандартам (auditability) Точность управления и вычислений (accuracy) Степень стандартности интерфейсов (communicationcommonality) Функциональная полнота (completeness) Однородность используемых правил проектирования и документации (consistency) Степень стандартности форматов данных (datacommonality) Устойчивость к ошибкам (errortolerance) Эффективность работы (executionefficiency) Расширяемость (expandability)

• 
  Слайд 22
  

  Широта области потенциального использования (generality) Независимость от аппаратной платформы (hardware independence) Полнота протоколирования ошибок и других событий (instrumentation) Модульность (modularity) Удобство работы (operability) Защищенность (security) Самодокументированность (selfdocumentation) Простота работы ( simplicity) Независимость от программной платформы (software system independence) Возможность соотнесения проекта с требованиями (traceability) Удобство обучения (training)

• 
  Слайд 23

  Критерии качества ПО поБоэму

  Дополнительные атрибуты качества по Боему: ясность (clarity), удобство внесения изменений (modifiability), документированность (documentation), способность к восстановлению функций (resilience), понятность (understandability), адекватность ( validity), функциональность (functionality), универсальность (generality), экономическая эффективность (economy)

• 
  Слайд 24

  ГОСТ 34 (с дополнениями)

  Runtime (атрибуты, относящиеся ко времени работы приложения или системы): Доступность Надежность Требования к времени хранения данных Масштабируемость Требования к удобству использования Требования к безопасности Требования к конфигурируемости Требования к производительности Ограничения

• 
  Слайд 25
  

  Design time(атрибуты, определяющие ключевые аспекты проектирования приложения или системы): Требования к повторному использованию реализации или компонентовприложения/системы Требования к расширяемости Требования к переносимости Требования к взаимодействию Требования к поддержке Требования к модульности Требования к возможности тестирования Требования к возможности и простоте локализации Требования к совместимости между версиями приложений См. Нефункциональные требования к ПО

• 
  Слайд 26

  Численные характеристики

  Доступность (отказоустойчивость) Частота недоступности системы в пределах временного интервала, который используется для определения доступности Продолжительность недоступности системы Доступность по расписанию 5 х 8 (рабочие дни, рабочие часы) 7 х 24 (все дни недели, 24 часа) 365 х 24 (все дни года, 24 часа) Доступность пять «9 » или 99,999% - стремление индустрии Например, производители серверов: Достигнутый результат – 99,998% для кластеров (10 минут недоступности в течение года) ПК – 97,5% доступности в среднем (219 часов в год)

• 
  Слайд 27
  

  Классификация по уровню требуемой непрерывности обслуживания и важности для бизнеса MissionCritical- системы, работающие в режиме «боевого дежурства». BusinessCritical– системы, критические для управления, с режимом работы 24х7х365. Рекомендованное время восстановления подобных систем после отказа менее 2 часов. BusinessOperational - обычные бизнес-приложения - системы, не требующие работы в реальном времени, с режимом работы 8х5. Рекомендованное время восстановления подобных систем после отказа 4-6 часов. OfficeProduction - не критические для управления приложения, персональные данные. Рекомендованное время восстановления подобных систем после отказа 1-2 рабочих дня.

• 
  Слайд 28
  

  Надежность и доступность Операционная мера надежности – MTTF (MeanTimeToFailure– среднее время до отказа или наработка на отказ). Измеряется в часах Частота отказов: (1/ MTTF) Среднее время на устранение отказа – MTTR (MeanTimeToRepair)

• 
  Слайд 29
  

  Связь между уровнем дефектов и значениями MTTF

• 
  Слайд 30
  

  Надежность и доступность (промышленные средние) Среднее число ошибок в бизнес - системах, найденное в течение первого года эксплуатации: США 4,44/KLOC Япония 1,96/KLOC Среднее число ошибок в ПО CMMI уровень 1 7,38/KLOC CMMI уровень 3 1,30/KLOC Число ошибок в системах высокой доступности (99,9%+) Должно быть ниже 0,01/KLOC

• 
  Слайд 31
  

  Производительность Transaction Processing Performance Council Число операций в секунду: Ед. измерения: MIPS – миллионы инструкций в секунду Число транзакций в секунду TPC-App для серверов приложений и веб-сервисов TPC-C для операций многих пользователей с базой данных TPC-E – новый OLTP тест. Эмулирует брокерскую компанию с клиентами, которые генерируют торговые транзакции. Компания взаимодействует с финансовыми рынками TPC-H для поддержки принятия решений. Набор произвольных бизнес-запросов и параллельная модификация данных

• 
  Слайд 32
  

  Производительность При заданных параметрах системы Число серверов Процессоры Память Дисковая подсистема Сеть При заданном объеме базы данных Число записей того или иного сорта, например, число позиций на складе или число счетов в банковской системе или число полисов в страховой системе При меняющемся числе параллельно работающих пользователей Например, 1 – 10 – 100 – 1000 – 10000 Время отклика системы на воздействие Он-лайнзапросы Пакетные запросы (отчеты)

• 
  Слайд 33
  

  Производительность Необходимо учитывать разные архитектуры Клиент – сервер Клиент – сервер приложений – сервер базы данных Клиент – сервер интерфейса – сервер приложений – сервербазы данных Как осуществляется балансировка загрузки Автоматически, средствами сервера приложений, операционной системы, базы данных Алгоритмами приложения

• 
  Слайд 34
  

  Безопасность Внешние метрики безопасности:

• 
  Слайд 35
  

  Безопасность Внешние метрики безопасности:

• 
  Слайд 36
  

  Безопасность Внутренние метрики безопасности:

• 
  Слайд 37
  

  Безопасность Внутренние метрики безопасности:

• 
  Слайд 38
  

  Безопасность Метрики безопасности качества в использовании: :

• 
  Слайд 39
  

  Безопасность Метрики безопасности качества в использовании: :

• 
  Слайд 40
  

  Если точное значение определить невозможно Используйте оценочные значения (границы интервалов, за которые нельзя выходить) Оценки по порядку величины Например, 1 – 10 – 100 – 1000 – 10000 Уточняйте требования бизнес-уровня Пользуйтесь экспертизой ведущих производителей ПО Benchmark tests Техническая документация (MSDN)

• 
  Слайд 41

  Атрибуты качества: проблемы

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

• 
  Слайд 42

  Атрибуты качества: рабочие группы

  Рабочая группа по определению атрибутов качества: Создание такой группы – это дополнительный способ выявления основных характеристик систем ПО, смысл которого в привлечении заинтересованных лиц (владельцы проекта). Основные особенности рабочей группы по характеристикам качества: системно-ориентирована сфокусирована на заинтересованных лицах созывается до того, как завершено проектирование архитектуры ПО Результат включает в себя: исходные сценарии сценарии характеристик качества с приоритетами уточненные сценарии Может использоваться для: уточнения требований планирования прототипов для уменьшения рисков проектирования архитектуры

• 
  Слайд 43
  

  Определить список заинтересованных лиц (ЗЛ), с которыми можно провести техническое интервью: Представители бизнес-пользователей Архитекторы ПО Ведущие специалисты по тестированию Менеджеры и аналитики зависимых систем Составить опросник с архитектурными требованиями: Несколько вопросов для каждого требования Указать приоритет Собрать ответы ЗЛ, проанализировать их на непротиворечивость.

• 
  Слайд 44
  

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

• 
  Слайд 45

  Атрибуты качества: компромиссы

• 
  Слайд 46

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

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