Требования к программе. Виды требований. ТЗ. ФС

СИСТЕМНОЕ И ПРИКЛАДНОЕ
ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ
Лекция 11.
Качество ПО.
Требования к программе. Виды
требований.
Техническое задание.
Функциональные спецификации.
Качество ПО
Модель качества ПО
• Показатели качества ПО
• Атрибуты показателей качества
• детализация характеристик
• Метрики качества
• методики измерения значений атрибутов
• Веса метрик в интегральной оценке
качества
• коэффициенты, отражающие приоритеты
атрибутов
3
Показатели качества
•
•
•
•
•
•
Функциональность
Надёжность
Удобство
Эффективность
Сопровождаемость
Портируемость/переносимость
4
Показатели качества:
Функциональность
Атрибуты:
• Полнота
• достаточно ли функций для решения основных задач
• Корректность (точность)
• степень достижения правильных результатов
• Интероперабельность
• способность к взаимодействию с другими продуктами
• Защищённость
• способность предотвращать несанкционированный доступ к
системе
• Согласованность
• соответствие стандартам, нормам, правилам
5
Показатели качества:
Надёжность
• Безотказность работы
• Устойчивость к ошибкам
• внешние факторы, ошибочные данные,
ошибки пользователя
• Восстанавливаемость
• способность к возобновлению прерванной
работы и восстановлению данных
• Согласованность
6
Показатели качества:
Удобство использования
• Понимаемость
• лёгкость распознавания концепций и
ограничений использования ПО
• Изучаемость
• «порог вхождения»
• Операбельность
• способность функционировать в заданных
условиях
• Согласованность
7
Показатели качества:
Эффективность
• Время реакции системы
• Эффективность по ресурсам
• количество и продолжительность
использования ресурсов
• Согласованность
8
Показатели качества:
Сопровождаемость
• Анализируемость
• лёгкость для понимания при поиске дефектов или
участков для модификации
• Изменяемость
• лёгкость внесения изменений
• Стабильность
• степень постоянства структуры (оценка
вероятности внесения изменений)
• Тестируемость
• лёгкость проверки на предмет дефектов или
необходимости модификации
• Согласованность
9
Показатели качества:
Переносимость
• Адаптивность
• простота адаптации к среде выполнения
• Простота установки
• лёгкость настройки ПО в среде
• Совместимость
• возможность запуска в заданной среде
• Заменяемость
• способность подменить собой аналогичный
продукт (совместимость по форматам)
• Согласованность
10
Требования
Требования
• Требования к ПО определяют
характеристики, необходимые для решения
поставленной задачи
• По уровням:
• Бизнес-требования
- назначение ПО: цели заказчика/потребителя
• Пользовательские требования
- набор задач, сценарии работы пользователя
• Функциональные требования
- поведение ПП, позволяющее пользователям решать свои
задачи в рамках бизнес-требований и в контексте
пользовательских требований
12
Категории требований
• Потребности
• проблемы, «закрываемые» использованием или приобретением
продукта (нужды пользователей, бизнеса, процессов)
• Функциональные требования
• Бизнес-требования, пользовательские, функциональные
• Нефункциональные требования
• Бизнес-правила: политики, регламенты, стандарты, детали
бизнес-процессов
• Внешние интерфейсы: взаимодействие с пользователем и средой
(ОС, другие системы)
• Атрибуты качества: характеристики устойчивости,
интероперабельности, портируемости и т.п.
• Ограничения: условия, сужающие выбор решений по реализации
требований (напр., производительность)
• Системные требования
• требования к системному продукту, состоящему из набора
взаимодействующих подсистем
13
Сбор требований
1. Идентификация источников
требований
•
откуда черпать информацию об
ограничениях и характеристиках
2. Извлечение требований
•
меры по получению максимально полной
системы требований
3. Анализ требований
•
обработка полученной информации
14
Сбор требований:
источники
Примеры возможных источников:
• Законодательство
• законы, указы, отраслевые правила и нормы
• Производственные нормативные документы
• регламенты, положения, уставы, приказы
• Текущая организация деятельности объекта
автоматизации
• Модели деятельности
• диаграммы бизнес-процессов
• Представления и ожидания потребителей и
пользователей системы
• напр., результаты маркетинговых исследований
• Конкурирующие продукты
15
Сбор требований:
извлечение
• Коммуникации с клиентами
• опрос пользователей
• Наблюдение за процессами
• бизнес-аналитики и инженеры изучают рутинную
работу пользователей «в естественной среде»
• Анализ нормативной документации, бизнесмоделей, конкурентных продуктов
• Мозговой штурм
• Прототипирование
• от «бумажных» скетчей до пилотных версий
16
Сбор требований:
анализ
• Обнаружение и разрешение конфликтов
между требованиями
• Определение границ и содержания
проекта (бизнес-требований)
• Детализация системных требований
для установления программных
требований
17
Спецификация требований
По уровням:
• Определение системы
• стратегические цели, требования к системе, информация о
бизнес-процессах и процедурах
• документы: “Vision”, “Concept of operations”, “Customer/User
Requirements Specification”,…
• Системные требования
• выделяют для сложных систем
• описание требований к системе в целом (взаимодействие
ПО, аппаратуры и персонала)
• документы: “System Requirements Specification”
• Требования к ПО
• документы: «Software Requirements Specification» - SRS
18
Проверка требований
• Процедуры проверки и аттестации
требований:
• Инспеции (Review)
- вычитка специалистами для контроля качества
требований
• Прототипирование
- уточнение неполных требований, проверка
архитектурных решений, оценка UI
• Аттестация (утверждение) модели
- проверка соответствия модели заданным требованиям
• Приёмочное тестирование
- все требования должны быть верифицируемы
• существует способ определить, были ли они соблюдены
19
Характеристики требований
• Согласно IEEE 29148-2011, требования всех видов
должны быть:
• Необходимы (важны)
• Свободны в реализации (не накладывают необоснованных
ограничений на дизайн)
• Недвусмысленны
• Последовательны
• Полны (не требуют дополнений)
• Атомарны (нельзя разделить на 2 и более)
• Выполнимы (технически достижимы в рамках бюджета и
проч. ограничений)
• Отслеживаемы (прослеживаются все связи с более общими
спецификациями и с реализацией требования)
• Проверяемы/верифицируемы – есть способ определить,
удовлетворяет ли система предъявленному требованию
20
Формулировка требований
(по ISO/IEC/IEEE 29148:2011)
• [Условие] [Субъект] [Действие]
[Объект]<->[Ограничение]
ПРИМЕР: Когда поступает сигнал x [Условие], Система
[Субъект] должна установить [Действие]
соответствующий сигнальный бит (флаг) [Объект] в
течение 2х секунд [Ограничение].
• [Условие][Действие или Ограничение][Значение]
ПРИМЕР: В морском режиме работы [Условие] Радарная
Система должна обнаруживать цели на удалении до
[Действие или Ограничение] 100 морских миль
[Значение].
• [Субъект] [Действие] [Значение]
ПРИМЕР: Система Заказов [Субъект] должна отображать
обрабатываемые заказы [Действие], отсортировав их
по порядку [Значение], в котором они должны быть
оплачены.
21
Требования к ПО
Примерная структура
согласно
ISO/IEC/IEEE 29148-2011
Software Requirements
Specification
Общее содержание:
1. Введение
• вводная информация о проекте (цели, задачи, обзор,
глоссарий)
2. Ссылки на документацию
• полный список документов (название, версия, дата)
• источники (местоположение документов)
3. Специфические требования
• список требований с разбивкой по категориям
4. Верификация
• раздел, параллельный 3му разделу
5. Приложения
• Сокращения и аббревиатуры
• Предположения и зависимости
-
факторы, влияющие на требования – отражают возможные изменения,
влияющие на SRS
23
SRS: Введение
Назначение
1.
•
описание области предназначения прогарммы
Область применения:
2.
•
•
•
Наименование продукта
Что программный продукт должен делать
Описание применения продукта, включая преследуемые выгоды,
намерения и цели
Как документ согласуется со спецификациями более высокого уровня
(StSR, SyRS)
•
Обзор продукта
3.
•
Позиционирование
-
•
Функции продукта
-
•
сводка основных функций
Пользовательские характеристики
-
•
«портрет пользователя» - уровень образования, опыт, тех. грамотность и т.п.
Ограничения
-
4.
системные, пользовательские, аппаратные и программные интерфейсы,
ограничения, операции, требования к адаптируемости на месте
правовые, аппаратные, интерфейсные, аудит, управение, языки, протоколы,
надёжность и критичность приложения, безопасность и секретность
Словарь терминов
24
SRS:
Специфические требования
Внешние интерфейсы
Функции
Требования к удобству использования
Требования к производительности
Логические требования к БД
Архитектурные ограничения
1.
2.
3.
4.
5.
6.
•
налагаемые стандартами, аппаратурой, ...
Атрибуты программной системы
7.
•
показатели качества
Вспомогательная информация
8.
•
примеры форматов ввода/вывода, результаты
исследований; описание решаемых проблем; специальные
инструкции
25
•
SRS: Атрибуты
программной системы
Надежность
•
•
Доступность
•
•
необходимые факторы для достижения требуемой надёжности
контрольные точки, восстановление и перезапуск.
Безопасность
•
защита от случайного или злонамеренного доступа, использования,
модификации, разрушения или разглашения. Необходимость:
-
•
Поддерживаемость (лёгкость поддержки)
•
•
Использования криптографии;
Хранения логов или истории;
Назначение некоторых функции различным модулям;
Ограничения коммуникации между некоторыми областями программы;
Проверки целостности данных для критических переменных.
некоторые требования, относящиеся к модульности, интерфейсам,
сложности и т.д.
Переносимость
•
•
•
•
•
Доля компонентов с машинно-зависимым кодом;
Доля машинно-зависимого кода;
Использование испытанного переносимого языка;
Использование особенного компилятора или подмножества языка;
Использование особенной операционной системы.
26
Техническое задание
Техническое задание
• ТЗ – базовый документ
•
•
•
•
•
общее назначение продукта
технические характеристики
требования
показатели качества
процесс выполнения проекта и приёмки
• Главная цель
• сформулировать задачу
• обосновать потребность в её решении
• максимально полно отразить требования
28
Стандарты
• ГОСТ 19.201-78 Техническое задание.
Требования к содержанию и
оформлению.
• ГОСТ 34.602-89 Техническое задание на
создание автоматизированной системы.
29
Основные разделы ТЗ
• Общие сведения о системе (программе)
• Назначение, цели и задачи системы
(программы)
• Требования к системе
• функциональные требования
• пользовательские требования
• требования к системе в целом и тд.
•
•
•
•
Требования к видам обеспечения
Требования к документированию
Стадии и этапы разработки
Порядок контроля и приемки системы
(программы)
30
Общие сведения
• Полное и сокращённое наименование
системы
• Реквизиты сторон
• Ссылки на документы, на основании
которых ведётся разработка (в т.ч.,
правовая основа)
• Сроки и финансирование
• Словарь терминов и сокращений
31
Назначение, цели и
задачи системы
Мотивация создания системы:
• какую потребность закрываем
• какие подзадачи возникают
• возможности, предоставляемые
пользователям
-
сервисы
оптимизация бизнес-процессов
безопасность
централизация обработки и хранения данных
32
Требования к системе
• Основные функциональные требования
• Декомпозиция задач:
• действующие лица
• сценарии использования
• результаты
• В составе этого раздела или в
приложении – примеры
пользовательского интерфейса
33
Требования к системе
• требования к функциональным
характеристикам
• требования к надежности
• условия эксплуатации
• требования к составу и параметрам
технических средств
• требования к информационной и
программной совместимости
• требования к маркировке и упаковке
• требования к транспортированию и хранению
• специальные требования
34
Требования к видам
обеспечения
Требования к:
• математическому
• информационному
• лингвистическому
• программному
• техническому
• и другим видам обеспечения
35
Требования к документации
• Перечень предоставляемых заказчику
документов.
• Может включать следующие документы:
•
•
•
•
•
•
•
•
•
Техническое задание
Ведомость эскизного (технического) проекта
Пояснительная записка к Техническому проекту
Описание организации информационной базы
Руководство пользователя
Руководство администратора
Программа и методика испытаний
Протокол приемочных испытаний
Акт выполненных работ
36
Стадии и этапы разработки
• Перечисляются этапы работ
• сроки
• описание
• результаты этапа
37
Порядок контроля и приёмки
• Указывается документ, на основании
которого проводятся приёмо-сдаточные
испытания.
38
Общее содержание ТЗ
• ТЗ может по необходимости
дополняться другими разделами:
• внедрение
• наполнение контентом (в случае сайта)
• и прочие работы, не подпадающие под
основные разделы
• а также может быть сокращено.
39
Функциональные
спецификации
Зачем?
• Если ТЗ – это:
• декларируемый набор функций
- описывает, что система должна делать
• если нужно – юридический документ
• требования ТЗ – для планирования работы
• то Функциональные спецификации – это:
• надо больше программистам
• хотя и не только
• описывает, как система работает
- сценарии работы пользователей с системой
- модули и их взаимодействие
• помогает понимать систему:
- а значит, разрабатывать её и поддерживать
41
Зачем описывать поведение?
• При создании продукта
• лучше представлять замысел
- прежде чем строить здание, хорошо бы продумать, где
будут окна-двери, и понадобится ли второй лифт;
- ведь чем позже вносятся изменения – тем они дороже,
- если вообще возможны.
• стремление к одинаковому видению проекта у
команды
• С прицелом на поддержку/развитие
• Проще смотреть картинки и читать линейный
текст, чем изучать код
42
Содержимое ФС
• Множество стандартов и нестандартов
• крупные методологии предписывают
определённую структуру ФС
• но структура вовсе не обязательно строгая
• Выбор (очень) зависит от контекста
• главная цель – описать систему
43
Общая схема
• Примерное содержимое ФС:
• Варианты использования
- ключевые сценарии
• Описание процессов и процедур
- детализация сценариев, компоненты
• Сложное поведение компонент
• Внутренняя структура
- детализация структуры компонент
- отношения между компонентами
- схемы БД и размещения компонент
44
Вариации
• Детали внутреннего устройства могут
выноситься в отдельный документ
• Детальная архитектура
• Также ФС может содержать:
• Чёткое разграничение целей и «антицелей»
проекта
• Списки открытых вопросов
• Специальные примечания
- маркетинговый контекст, комментарии экспертов в
предметной области
• И другое, полезное в конкретной ситуации
45
Варианты использования
• Первый шаг – отразить
пользовательские сценарии
• выделить и перечислить ключевые
взаимодействия с системой, дающие
значимый результат
• для описания подойдут
- чтобы проникнуться: пользовательские истории,
диаграммы связей (mind maps)
- чтобы быстро понять круг задач: диаграммы
прецедентов (вариантов использования) UML
46
Описание процессов и
процедур
• Расписываются сценарии:
• какие элементы взаимодействуют
• что друг у друга запрашивают
• Инструменты:
• псевдокод
• диаграммы UML: робастности,
сотрудничества, последовательности
действий, деятельности
• диаграммы Data Flow
47
Сложное поведение компонент
• Сложные алгоритмы и процедуры
• диаграммы деятельности, блок-схемы и
псевдокод
• Автоматы: смена состояний
• диаграммы состояний (UML)
48
Внутренняя структура
• Детальное описание элементов
системы:
•
•
•
•
классы (ООП) – диаграмма классов
диаграммы отношений
таблицы баз данных
схемы размещения компонент: диаграмма
развертывания (UML)
49
Ссылки
• Требования
• SWEBoK – Программные требования:
- http://swebok.sorlik.ru/1_software_requirements.html
• Техническое задание. ГОСТы:
- ГОСТ 19.201-78 http://it-gost.ru/content/view/20/41/
- ГОСТ 34.602-89 http://it-gost.ru/content/view/21/39/
- Обзорная статья «ТЗ согласно ГОСТу»: http://itgost.ru/content/view/101/51/
• Разбор процесса написания ТЗ (статьи):
- http://habrahabr.ru/post/138749/
- http://habrahabr.ru/post/140574/
• SRS
- Рекомендации IEEE 830-1998 (стандарт устарел):
• http://club.shelek.ru/viewart.php?id=344
- Актуальный стандарт ISO/IEC/IEEE 29148-2011:
• http://www.computer.org/portal/documents/82129/160549/IEEE+291482011.pdf
50
Ссылки
• Функциональные спецификации
• Стандарты на спецификацию программной архитектуры
- IEEE 1471 (устарел):
• http://en.wikipedia.org/wiki/IEEE_1471
- ISO/IEC/IEEE 42010:2011 (актуальный)
• http://en.wikipedia.org/wiki/ISO/IEC_42010
• Курс по основам UML на Intuit:
- http://www.intuit.ru/studies/courses/32/32/info
• Дополнение по Robustness Diagram (англ.):
- http://www.agilemodeling.com/artifacts/robustnessDiagram.htm
• Инструменты для UML
- Visual Paradigm (community edition – некоммерческая)
http://www.visual-paradigm.com/download/vpuml.jsp?edition=ce
- StarUML http://staruml.sourceforge.net/en/
- ArgoUML http://argouml.tigris.org/
51