Анализ ПО

1. Анализ ПО

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

2. Анализ ПО

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

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

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

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

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

5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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