4 14feb13 ПрИС-требования.ppt
- Количество слайдов: 39
Проектирование информационных систем Требования к информационным системам Лекция 4
Основные виды деятельности программной инженерии Формирование видения Бизнес-анализ Анализ требований Разработка архитектуры Детальное проектирование Реализация Тестирование Управление проектом Управление средой Управление конфигурацией Управление требованиями Усовершенствование Экспертиза (испытание) Документирование Обучение Внедрение Эксплуатация Сопровождение
Основные виды деятельности программной инженерии Формирование видения Бизнес-анализ Анализ требований Разработка архитектуры Детальное проектирование Реализация Тестирование Управление проектом Управление средой Управление конфигурацией Управление требованиями Усовершенствование Экспертиза (испытание) Документирование Обучение Внедрение Эксплуатация Сопровождение
Основные виды деятельности программной инженерии Формирование видения Бизнес-анализ Анализ требований Разработка архитектуры Детальное проектирование Реализация Тестирование Управление проектом Управление средой Управление конфигурацией Управление требованиями Усовершенствование Экспертиза (испытание) Документирование Обучение Внедрение Эксплуатация Сопровождение
Анализ требований и бизнес-анализ Предприятие (организационная система, ОС) Представляет исходные данные для Помогает осуществить Моделирует АИС Процесс анализа требований Анализ ПО (бизнес-анализ) Определяет © Ю. A. Маглинец Анализ требований 5
Требования – понятие и классификация Часть 1 Понятие и классиификация требований. © Ю. A. Маглинец 6
Требование к АИС • Требование – это условие или возможность, которой должна соответствовать система • Требования – это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы Понятие и классиификация требований. © Ю. A. Маглинец 7
Определение IEEE 1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей; 2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам; 3. Документированное представление условий или возможностей для пунктов 1 и 2 Понятие и классиификация требований. © Ю. A. Маглинец 8
Как и кем используются требования? – Специалист по АТ – постановка задачи, определение рамок проекта – Представитель заказчика – постановка задачи, определение рамок проекта, контроль работы исполнителя, приёмка результатов работы – Архитектор системы – разработка архитектуры, проектирование подсистем – Программист – разработка программного кода – Тестировщик – составление тест-плана, тестовых сценариев – Менеджер проекта – планирование и контроль исполнения работ Процесс анализа требований © Ю. A. Маглинец 9
Классификация по предмету Виды требований Требования к продукту Понятие и классиификация требований. Требования к проекту © Ю. A. Маглинец 10
Классификация по уровню Бизнестребования Требования пользователей Функциональные требования Понятие и классиификация требований. Требования пользователей Функциональные требования © Ю. A. Маглинец Функциональные требования 11
Пример бизнес-требования система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза Понятие и классиификация требований. © Ю. A. Маглинец 12
Классификация по уровню Бизнестребования Требования пользователей Функциональные требования Понятие и классиификация требований. Требования пользователей Функциональные требования © Ю. A. Маглинец Функциональные требования 13
Пример требования пользователя • система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение Введение © Ю. A. Маглинец 14
Классификация по уровню Бизнестребования Требования пользователей Функциональные требования Понятие и классиификация требований. Требования пользователей Функциональные требования © Ю. A. Маглинец Функциональные требования 15
Пример функциональных требований (или просто функций) по работе с электронным заказом: • заказ может быть • создан, • отредактирован, • удалён и • перемещён с участка на участок Введение © Ю. A. Маглинец 16
Конфликты между требованиями разных уровней Введение © Ю. A. Маглинец 17
Классификация 3 Виды требований Требования к программному обеспечению Системные требования Понятие и классиификация требований. © Ю. A. Маглинец 18
Классификация К. Вигерса Виды требований Функциональные требования Нефункциональные требования Характеристики продукта Внешние интерфейсы Атрибуты качества Ограничения Понятие и классиификация требований. © Ю. A. Маглинец 19
Модель FURPS+ (R. Grady, Hewlett-Packard, 1992) Виды требований Атрибуты качества Ограничения Применимость Надёжность Проектирования Разработки Производительность Пригодность к сопровождению На интерфейсы Физические Понятие и классиификация требований. © Ю. A. Маглинец 21
Модель FURPS • • • Functionality, функциональность Usability, удобство использования Reliability, надежность Performance, производительность Supportability, пригодность к эксплуатации (поддержке) Введение © Ю. A. Маглинец 22
Модель FURPS+ (ограничения) • Ограничения проектирования, design • Ограничения разработки, implementation • Ограничения на интерфейсы, interface • Физические ограничения, physical Введение © Ю. A. Маглинец 23
FURPS+ Функциональность (1) • Журналирование, аuditing — инструменты отслеживания действий пользователей и системы путем записи в журнал безопасности конкретных типов событий. • Лицензирование, licensing — средства для отслеживания, приобретения, установки и контроля над использованием лицензий. • Локализация, localization — средства поддержки различных естественных языков. • Почта, mail — службы отправки и получения Введение © Ю. A. Маглинец 24
FURPS+ Функциональность (2) • Почта, mail — службы отправки и получения сообщений • Помощь, online help — возможность оказывать поддержку пользователей в реальном времени • Печать, printing — средства для печати документов. • Отчетность, reporting — инструменты создания и получения отчетов. Введение © Ю. A. Маглинец 25
FURPS+ Функциональность (3) • Безопасность, security — средства защиты доступа к определенным ресурсам информации. • Управление системой, system management — инструменты, позволяющие управлять приложениями в распределенной среде. • Технологический процесс, workflow — поддержка документооборота, включая процессы проверки, визирования и утверждения. Введение © Ю. A. Маглинец 26
FURPS+ Удобство использования • эстетика и логичность пользовательского интерфейса, • учет человеческого фактора, • эксплуатационная документация, ее состав (руководства пользователей, администраторов и др. ), отраслевые и гос. стандарты оформления, • квалификация пользователей и их обучение, • справочная информация в системе. Введение © Ю. A. Маглинец 27
FURPS+ Надежность (1) • сбои: – допустимая частота/периодичность сбоев, – среднее время сбоев и их серьезность, – возможность восстановления системы после сбоев, в т. ч. возможность предварительного резервного копирования данных, Введение © Ю. A. Маглинец 28
FURPS+ Надежность(2) • предсказуемость поведения, • время готовности системы к работе, режим работы или время доступности системы (например, «Система должна быть доступна 24 часа в сутки 7 дней в неделю» ), • точность вычислений. Введение © Ю. A. Маглинец 29
FURPS+ Производительность (1) • скорость работы, время отклика системы, • пропускная способность, включая общее и допустимое количество одновременно работающих пользователей, количество пользовательских запросов, число обращений системы к БД и объем запрашиваемых/передаваемых данных в единицу времени, Введение © Ю. A. Маглинец 30
FURPS+ Производительность(2) • время, необходимое на восстановление — скорость восстановления, • время, необходимое для запуска и завершения работы — скорость запуска и завершения, • потребление ресурсов. Введение © Ю. A. Маглинец 31
FURPS+ Пригодность к поддержке – возможности: (1) • тестирования, • расширения — наращивания дополнительного функционала системы, • масштабирования — тиражирования, например, в филиалах/подразделениях организации, • адаптации/приспособления к использованию в заданной среде, в т. ч. путем предварительной настройки, Введение © Ю. A. Маглинец 32
FURPS+ Пригодность к поддержке – возможности: (2) • конфигурирования — оперативной, регулярной настройки, переопределения параметров, • совместимости, • сопровождения, поддержки работоспособности: исправление ошибок, обновление данных, частота архивации и резервного копирования, Введение © Ю. A. Маглинец 33
FURPS+ Пригодность к поддержке – возможности: (3) • сервисного обслуживания и ремонта, их удобство, • установки, • локализации (например, «Продукт будет поддерживать несколько естественных языков» ), • портативность, • соответствие международным стандартам. Введение © Ю. A. Маглинец 34
FURPS+ Ограничения проектирования – ограничения на технологии (например, «Хранение необходимо реализовать с помощью реляционной БД» ), – процесс ( «RUP» ), – средства разработки ( «диаграммы должны создаваться в MS Visio, документация — в MS Word» ), – прочие. Введение © Ю. A. Маглинец 35
FURPS+ Ограничения реализации – стандарты разработки, – стандарты качества ПО, в т. ч. кода, – языки программирования, – средства разработки ( «В качестве СУБД должна быть использована Oracle 10 g» ), – ресурсные ограничения, – лицензионные ограничения, – ограничения на техническое (аппаратное) обеспечение, – прочие. Введение © Ю. A. Маглинец 36
FURPS+ Ограничения интерфейсов – форматы данных, – протоколы взаимодействия, – внешние системы, – прочие. Введение © Ю. A. Маглинец 37
FURPS+ Физические ограничения, • накладываемые на технические (аппаратные) средства и окружение системы: – форма, – размер, – вес, – температурный режим, – влажность, – ограничения на вибрацию, Введение прочие. © Ю. A. Маглинец – 38
Документы IEEE • IEEE 1362 “Concept of Operations Document”. • IEEE 1233 «Guide for Developing System Requirements Specifications» . • IEEE Standard 830 -1998, «IEEE Recommended Practice for Software Requirements Specifications» • IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610. 12 -1990 • IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004. Понятие и классиификация требований. © Ю. A. Маглинец 39
ГОСТ РФ • ГОСТ 34. 601 -90. Информационная технология. Автоматизированные системы. Стадии создания. • ГОСТ 34. 602 -89. Информационная технология. Техническое задание на создание автоматизированной системы • ГОСТ 19. 201 -78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению. Понятие и классиификация требований. © Ю. A. Маглинец 40
4 14feb13 ПрИС-требования.ppt