Проектирование информационных систем Требования к информационным системам Лекция

Проектирование информационных систем Требования к информационным системам Лекция 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