Анализ предметной области
Процесс разработки
Анализ ПО
Анализ ПО
Анализ ПО
Анализ требований
Обследование предприятия
Обследование предприятия
Обследование предприятия
Обследование предприятия
Определение требований
Уровни требований
Типы требования
Типы требования
1.1 Бизнес требования
2.1 Требования пользователей
2.2 Бизнес-правила
2.3 Атрибуты качества
3.1 Cистемные требования
3.2. Функциональные требования
Модель анализа
Процесс анализа
Анализ предметной области
Определение требований (бизнес требования)
Определение требований (бизнес требования)
Определение требований (бизнес требования)
Определение требований (бизнес требования)
Требования пользователя
Требования пользователя (пример1)
Диаграммы вариантов использования
Требования пользователя (пример2)
Диаграмма последовательности (Пример 3)
Требования пользователя
Моделирование поведения объектов
Моделирование поведения объектов
Описание алгоритмов обработки данных
Описание классов
Описание классов
Описание поведения разрабатываемой системы
Техническое задание
Техническое задание
Техническое задание
Результат анализа

Анализ предметной области

1. Анализ предметной области

Лабораторная работа
Бахвалова З.А
Институт кибернетики им. Е.И. Попова

2. Процесс разработки

Процесс разработки согласно RUP
представляет собой совокупность
следующих базовых рабочих процессов:
Анализ требований
Проектирование;
Реализация;
Тестирование.

3. Анализ ПО

Деятельность, направленная
на выявление реальных потребностей
заказчика, а также на выяснения
смысла высказанных требований,
называется анализом предметной
области

4. Анализ ПО

Анализ предметной области – это первый шаг этапа
системного анализа, с которого начинается разработка
программной системы. На этом этапе требования заказчика
уточняются, согласуются, формализуются и документируются.
Фактически на этом этапе дается ответ на вопрос: "Для чего
предназначена и что должна делать информационная система?".
Разработчики должны научиться:
понимать язык, на котором говорят заказчики;
выявить цели их деятельности;
определить набор решаемых ими задач;
определить набор сущностей, с которыми приходится иметь
дело при решении этих задач.

5. Анализ ПО

Целью этапа анализа является преобразование общих,
расплывчатых знаний об исходной предметной области
(требований заказчика) в точные определения и спецификации для
разработчиков, а также генерация функционального описания
системы.
На этом этапе определяются и специфицируются:
внешние и внутренние условия работы системы;
функциональная структура системы;
распределение функций между человеком и системой, интерфейсы;
требования к техническим, информационным и программным
компонентам системы;
требования к качеству и безопасности;
состав технической и пользовательской документации;
условия внедрения и эксплуатации.

6. Анализ требований

Обследование предприятия
◦ исследования системы управления предприятием,
◦ обследования функциональной и информационной структур,
◦ определения существующих и возможных потребителей
информации.
Определение требований:



формулируются цель и задачи проекта
происходит сбор и определение всех возможных требований,
происходит осознании контекста системы.
Анализ
◦ Процесс анализа заключается в разборе требований полученных на
предыдущем этапе, их уточнение и систематизация.

7. Обследование предприятия

Первая стадия анализа
Структурный анализ предприятия - начинается с :
исследования того, как организована система управления
предприятием,
обследования функциональной и информационной структур
системы управления,
определения существующих и возможных потребителей
информации.
По результатам обследования аналитик выстраивает обобщенную
логическую модель исходной предметной области, отображающую ее
функциональную структуру, особенности основной деятельности и
информационное пространство, в котором эта деятельность
осуществляется ( ниже).
На этом материале аналитик строит функциональную модель "Как
есть" (As Is).

8.

9. Обследование предприятия

Вторая стадия анализа
Привлекаются заинтересованные представители
заказчика, а при необходимости и независимые
эксперты.
Состоит:
в анализе модели "Как есть",
выявлении ее недостатков и узких мест,
определении путей совершенствования системы
управления на основе выделенных критериев
качества.

10. Обследование предприятия

Третья стадия анализа
Создание усовершенствованной
обобщенной логической модели,
отображающей реорганизованную
предметную область или ее часть,
которая подлежит автоматизации –
функциональная модель "Как должно
быть" (As To Be).

11. Обследование предприятия

Четвертая стадия анализа
Разработка модели реорганизованной
предметной области, на которой
обязательно обозначены «границы
автоматизации»

12. Определение требований

IEEE Standard Glossary of Software Engineering Terminology (1990)
определяет требования как:
1. Условия или возможности, необходимые пользователю для решения
проблем или достижения целей;
2. Условия или возможности, которыми должна обладать система или
системные компоненты, чтобы выполнить контракт или удовлетворять
стандартам, спецификациям или другим формальным документам;
3. Документированное представление условий или возможностей для
пунктов 1 и 2.
Это определение охватывает требования как пользователей
(внешнее поведение системы), так и разработчиков (некоторые
скрытые параметры).

13. Уровни требований

Уровень1. Бизнес требования
Уровень2. Требования пользователей
Уровень3. Функциональные требования
+ нефункциональные требования к каждому уровню.

14. Типы требования

15. Типы требования

Функциональные
Нефункциональные
1 уровень
1.1 Бизнес процессы
2 уровень
2.1 Требования пользователей
2.2 Бизнес правила
2.3 Атрибуты качества
3 уровень
3.1 Системные требования
3.2 Функциональные требования
3.3 Внешний интерфейс
3.4 Ограничения

16. 1.1 Бизнес требования

1.1 Бизнес требованияФункциональные
Высокоуровневые цели, зачем нужен продукт.
Например, бизнес пользователям вовсе не
нужен объект системы Пользователь, но зато
им нужно иметь возможность поменять
стоимость товара в счете и распечатать его.
Артефакты:
документ об образе и границах проекта или
устав проекта,
рыночные требования.
Первый этап управления общими проблемами расползания границ

17. 2.1 Требования пользователей

Функциональные
Описывают цели и задачи, которые
пользователям позволит решить система.
Артефакты:
варианты использования,
сценарии,
таблицы «событие — отклик».
Пример: заказать билеты через Интернет

18. 2.2 Бизнес-правила

Нефункциональные
Включают:
корпоративные политики,
правительственные постановления,
стандарты,
алгоритмы.
Не являются требованиями к ПО, потому
что они находятся снаружи границ любой
системы ПО. Однако они часто налагают
ограничения

19. 2.3 Атрибуты качества

Нефункциональные
Дополнительное описание функций продукта,
выраженное через описание его характеристик,
важных для пользователей или разработчиков.
Характеристики:
легкость и простота использования (usability),
легкость перемещения,
целостность,
эффективность,
устойчивость к сбоям.

20. 3.1 Cистемные требования

Функциональные
Обозначают высокоуровневые требования к
продукту.
Относятся к:
программному обеспечению,
подсистемам ПО,
оборудованию,
людям.

21. 3.2. Функциональные требования

Функциональные
Это требования поведения.
Они определяют функциональность ПО,
которую необходимо создать, чтобы пользователи
смогли выполнить свои задачи в рамках бизнестребований.
Содержат положения с традиционным «должен» или
«должна»: «Система должна по электронной почте
отправлять пользователю подтверждение о заказе».

22.

Выполнение
лабораторной
работы

23.

Цель работы: формирование у студентов теоретического мышления,
позволяющего видеть процесс проектирования программного обеспечения
системным и актуальным.
Задачи: В результате изучения курса студенты должны получить
базовые представления о принципах объектно-ориентированного
программирования;
овладеть понятийным аппаратом и практическими навыками моделирования
программно-аппаратных комплексов;
научиться использовать унифицированный язык моделирования (UML –
Unified Modeling Language) для решения широкого круга задач;
получить новые возможности развивать потенциальные способности
специалиста в области разработки программного обеспечения.
Требования к уровню освоения.
В результате выполнения работы студенты должны :
продемонстрировать знание содержания курса, определенного рамками
учебной программы;
навыки объектно-ориентрованного проектирования программных продуктов;
умения разрабатывать модели к задачам из различных предметных областей
на базе языка UML.

24. Модель анализа

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

25. Процесс анализа

Процесс анализа заключается в разборе требований полученных на предыдущих
этапах их уточнение и систематизация.
1. Определение цели
2. Обучение
◦ Словарь предметной области
◦ Словарь терминов
3. Определение требований (бизнес требования)
◦ Описание производимых действий, связи между этими действиями (Нотации
IDEF0, DFD)
◦ Общие сценарии
4. Описание задач, которые пользователям позволит решить система (требования
пользователя)
◦ Описание вариантов использования системы (use cases)
Описание диаграмм
◦ Расшифровка содержания прецедентов,
5. Описание алгоритмов обработки данных (системные требования)
◦ Моделирование поведения объектов
◦ Построение модели предметной области (сущность –связь (по Чену))
◦ Описание классов
◦ Описание поведения разрабатываемой системы.

26. Анализ предметной области

Обучение
Составить «одностраничное» описание проекта
(текстовый документ 1–3стр., защищаемый артефакт),
Составить словарь
предметной области,
по методу Аббота,
Объектно-ориентированный словарь.

27.

Словарь терминов предметной области
№ Термин
Назначение
1 Накладная Документ, используемый
при передаче товара от
одного лица(поставщика)
другому(магазин),
содержит информацию о
количестве товара и его
цене
2 Товар
Предмет торговли
3 Поставщик Предприятие, лицо,
поставляющее какие-либо
товары в магазин
4 Продавец Работник магазина,
принимающий товар от
поставщиков и
составляющий отчет, также
вносящий всю информацию
о товаре в БД
5 Владелец Человек, контролирующий
магазина работу подчиненных,
поставляющий денежные
средства на поставляемый
товар.
6 Отчет
Документ, который
предоставляет
информацию о приемепередаче товара за смену.
Словарь предметной области по методу Аббота
Существительное
Накладная
Товар
Поставщик
Продавец
Владелец магазина
Отчет
Глагол
Заполнить
Вводить
Поставить
Принять/ заполнить БД/
передать/составить
Контролировать
Выводить /изменить
Объектно-ориентированный словарь
Класс
Свойство
Метод (функция)
(сущность, (состояние)
актер)
Продавец Фамилия Составление отчета
Имя
Изменение отчета
Отчество Ввод номера накладной
Ввод информации о товаре
Прием товара
Отбор товара ненадлежащего качества
Провести инвентаризацию магазина при
передаче товара другой смене
ИС
Связь с БД Вывод информации
Сохранение изменений

28. Определение требований (бизнес требования)

Диаграмма процессов на предприятии в ТЕКУЩИЙ момент
Описание контекста модели:
предмет моделирования – документооборот предприятия в процессе оказания услуг
«Сезонный шиномонтаж и шинохранение»;
область моделирования – модель охватывает процессы внутри предприятия, связанные с
оказанием услуг «Сезонный шиномонтаж и шинохранение», а также взаимодействие с
субподрядчиком (ШЦ);
цель моделирования – определить, какие процессы предприятия могут подлежать
автоматизации/улучшению;
точка зрения – директор предприятия
Контекстная
диаграмма «Оказание услуг
«Сезонный шиномонтаж и
шинохранение»

29. Определение требований (бизнес требования)

Декомпозиция основного процесса. Он разделяется на следующие работы:
обзвон клиентов и согласование времени проведения шиномонтажа;
процедура проведения шиномонтажа;
выставление счета.
Рисунок – Декомпозиция
процесса «Оказание услуг
«Сезонный шиномонтаж и
шинохранение»
Сотрудник Исполнителя обзванивает Клиентов и согласовывает время проведения ШМ.
Зачастую Клиенты сами звонят Исполнителю; время также согласовывается. Согласно Договору с
Заказчиком либо Клиент заполняет Заявку, либо Заказчик отправляет Заявку, либо обзваниваются
все клиенты, с которыми велась работа ранее.
Фирма сотрудничает с несколькими ШЦ. Согласно Договору с ШЦ на период ШМ несколько
постов используются только для Клиентов в определенные часы. Расписание, с помощью которого
сотрудник Исполнителя распределяет нагрузку на ШЦ, содержится в бумажном виде.
В зависимости от того, находится ли комплект шин клиента на хранении у фирмы, возможен
один из следующих алгоритмов действий: если комплект у Клиента, то он привозит их в пункт
проведения шиномонтажа самостоятельно; если комплект на хранении, то Исполнитель доставляет
его в ШЦ заблаговременно.

30. Определение требований (бизнес требования)

Выявление проблемы и путь ее решения
После проведения анализа текущих
процессов можно сделать вывод о ….
Для решения проблемы
разрабатывается приложение, которое
позволит …..

31. Определение требований (бизнес требования)

Описание процессов отдела после внедрения предлагаемой
системы

32. Требования пользователя

Описание задач, которые пользователям позволит решить система
Сост авление расписания на шиномонт аж
Вед ение списков авт омобилей, фирм, шин
Ред акт ирование классификат оров
Учет оказанных услуг по сезонному ШМ
Менед ж ер по операциям
Учет оказанных услуг по сезонному ШХ
Ред акт ирование справочников цен на сезонные услуги
Получение д окумент а "Акт оказанных услуг по сезонному шиномонт аж у"
Главный бухгалт ер
Получение д окумент а " Акт оказанных услуг по сезонному шинохранению"
Получение Счет а
Рисунок- Диаграмма вариантов использования разрабатываемой
системы разными пользователями

33. Требования пользователя (пример1)

uc Use Case Model
Ввести данные
Посчитать
поправки
«include»
Уравнять значения
«include»
Инженер
Проанализировать
данные
Создать отчет
Диаграмма
вариантов
использования
инженера
Спецификация варианта использования «Ввод данных».
Цель: описать работу инженера с программой при вводе данных.
Активные субъекты: инженер.
Краткое описание: ввод данных, которые уже обработаны специальной программой (LGO), для последующей
обработки (вычисление поправок, уравнивание).
Основной поток событий:
Активный субъект выбирает файл, данные которого должны быть занесены в базу данных.
Программа считывает необходимые ей данные, заносит их в соответствующую таблицу БД и выводит их на экран.
Специальные требования: нет.
Предусловия: нет.
Постусловия: нет.
Дополнительные замечания: для ввода данных первичные файлы должны быть сохранены в формате *.txt.

34. Диаграммы вариантов использования

Краткий
Детальный ВИ
Название: Отправить электронное письмо.
Цель: Отправить созданное письмо с проверкой корректности его атрибутов.
Начальное состояние: Выполнен ВИ «Создать новое письмо» или ВИ «Создать
ответ на письмо».
Основной сценарий:
1. Пользователь выполняет команду отправки письма.
2. Программа проверяет, правильно ли заполнено поле «Адрес».
3. Если нет, программа сообщает об ошибке и отменяет отправку. Конец.
4. Если да, то программа проверяет, заполнено ли поле «Тема».
5. Если нет, программа выдает предупреждение, но не отменяет отправку.
6. Программа помещает письмо в папку «Исходящие» и отсылает его.
7. После отправки программа перемещает письмо в папку «Отправленные».
Сценарий обработки ошибок:
Предусловие: на шаге 6 основного сценария происходит ошибка отправки письма
(сбой сети и т. п.)
7. Программа сообщает об ошибке и предлагает сохранить текст письма в файл.
8. Если пользователь согласен сохранить текст, выполняется ВИ «Сохранить
черновик в файл».

35.

sd 1
Инженер
Форма для
выбора файла
выбрать файл()
Менеджер ввода
Таблица БД
передать данные()
закрыть()
«destroy»
выбрать
необходимые
данные()
.
вывод данных на экран()
запрос на сохранение данных()
сохранить данные()
добавить данные()
Интерфейсные классы
соответствуют
устройствам или
способам обмена
данными между
системой и ее
окружением, в том
числе пользователями.
Управляющие классы
соответствуют
алгоритмам, реализующим
какие-то значимые
преобразования данных в
системе и управляющим
обменом данными с ее
окружением в рамках
вариантов использования
Диаграмма последовательностей для варианта использования "Ввод
данных"

36. Требования пользователя (пример2)

Диаграмма последовательности
Рисунок - Взаимодействие
инженера с приборами,

37. Диаграмма последовательности (Пример 3)

38. Требования пользователя

Требования к составу и функционированию системы
Требования к входным данным
Требования к выходным данным
Требования к базе данных
Требования к интерфейсу
Требования к форме ввода
Требования к форме вывода
Требования к кнопкам
Требования к системным сообщениям
Требования к надежности
Требования к эргономике
Требования к аппаратному обеспечению
Требования к программному обеспечению

39. Моделирование поведения объектов

Диаграмма состояний показывает, как объект переходит
из одного состояния в другое. И служит для моделирования
динамических аспектов системы.
Диаграмма состояний полезна при моделировании
жизненного цикла объекта.
От других диаграмм диаграмма состояний отличается
тем, что описывает процесс изменения состояний только
одного экземпляра определенного класса - одного объекта,
причем объекта реактивного, то есть объекта, поведение
которого характеризуется его реакцией на внешние
события.
Понятие жизненного цикла применимо как раз к
реактивным объектам, настоящее состояние (и поведение)
которых обусловлено их прошлым состоянием

40. Моделирование поведения объектов

41. Описание алгоритмов обработки данных

erd Entity Relationship Diagram
Высота репера
пункта
Дата
Название пункта
Приемники
1
1
B
Каталог координат и высот
*
пунктов
обновляет координаты
получает длины
L
1
H
Высота марки
пункта
*
обновляет
Высота в
обратном ходе
Высота в
прямом ходе
Тахеометр
1
получает данные
Дата
Дата
Время
*
Hr
1
Расстояние в
прямом ходе
Расстояние в
обратном ходе
Нивелир
Название
пункта
1
1
использует
значение

*
Гравиметр
СКОн
Gr
Hm
СКОm
Gm
СКОr

42. Описание классов

Диаграмма классов - это набор статических, декларативных элементов модели.
Информация с диаграммы классов напрямую отображается в исходный код
приложения.
Выделяемые классы разбиваются на три разновидности —
интерфейсные,
управляющие
классы данных.
Эти классы представляют собой набор сущностей, в терминах которых работа системы
должна представляться пользователям. Они являются понятиями, с помощью которых
достаточно удобно объяснять себе и другим происходящее внутри системы, не слишком
вдаваясь в детали.
Интерфейсные классы соответствуют устройствам или способам обмена данными
между системой и ее окружением, в том числе пользователями.
Классы данных соответствуют наборам данных, описывающих некоторые
однотипные сущности внутри системы. Эти сущности являются абстракциями
представлений пользователей о данных, с которыми работает система.
Управляющие классы соответствуют алгоритмам, реализующим какие-то значимые
преобразования данных в системе и управляющим обменом данными с ее
окружением в рамках вариантов использования.

43. Описание классов

Диаграмма классов модели документа
"Отчет"

44. Описание поведения разрабатываемой системы

45.

46. Техническое задание

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

47. Техническое задание

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

48. Техническое задание

Спецификация требований не содержит:
деталей дизайна или реализации (кроме
известных ограничений),
данных о планировании проекта,
сведений о тестировании.

49. Результат анализа

На стадии анализа требований к проектируемой
системе вводятся:
классы пользователей и соответствующие диаграммы
бизнес-транзакций;
модели (диаграммы) процессов прикладной деятельности
и соответствующие перечни функциональных задач ИС;
классы объектов предметной области и соответствующие
диаграммы "сущность-связь", отражающие
информационную модель этой предметной области;
топология расположения подразделений и пользователей,
обслуживаемых данной ИС;
параметры защиты данных, информации и самой
системы
English     Русский Правила