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

1.

Проектная
деятельность
Бабичева Надежда
Борисовна,
к.т.н., доцент кафедры ПИТиП

2.

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

3.

Анализ предметной области
Описание общего задания кейса
Представьте, что вы друзья студенты-айтишники и вам (как и
всем студентам) не хватает стипендии и хочется найти
дополнительный источник доходов. Поэтому обсудив свои умения
вы выяснили что:
Бэк - умеет заставлять людей делать то, что нужно, при этом
готов осваивать бэкэнд.
Кексик - умеет печь кексики и готов учиться делать интерфейсы
и разрабатывать пользовательский опыт взаимодействия (UI&UX).
Фронт - умеет быстро учится и давно хотел попробовать себя в
фронтэнде
Багоюзер - тестер от бога, может найти баги даже в камне.
Исходя из желаний и умений вы решили сделать чего-нибудь с
кексиками. Кексики вы печете для продажи своим сокурсникам и их
родным. При этом, на текущий момент ваша команда ни разу не
работала вместе и никто не имеет опыт разработки проекта.
3

4.

Анализ предметной области
Для того, чтобы разработать программу, приносящую реальные
выгоды определенным пользователям, необходимо сначала
выяснить, какие же задачи она должна решать для этих людей
и какими свойствами обладать.
Требования к ПО определяют, какие свойства и характеристики
оно
должно
иметь
для
удовлетворения
потребностей
пользователей и других заинтересованных лиц.
* Автор иллюстрации André Noel https://developerslife.tech/en/
4

5.

Анализ предметной области
В большинстве случаев будущие пользователи могут
перечислить набор свойств, который они хотели бы видеть, но
никто не даст гарантий, что это – исчерпывающий список. Кроме
того, часто сама формулировка этих свойств будет непонятна
большинству программистов:
• «должно использоваться и частотное, и временное уплотнение
каналов»,
• «передача клиента должна быть мягкой»,
• «для обычных швов отмечайте бригаду, а для доверительных –
конкретных сварщиков».
* Автор иллюстрации Scott Adams https://dilbert.com/
5

6.

Анализ предметной области
Чтобы ПО было действительно полезным, важно, чтобы оно
удовлетворяло реальные потребности людей и организаций,
которые часто отличаются от непосредственно выражаемых
пользователями желаний.
Для выявления этих потребностей, проводят работу,
называемую анализом предметной области или бизнесмоделированием.
В результате этой деятельности разработчики должны научиться
понимать язык, на котором говорят пользователи и заказчики,
выявить цели их деятельности, определить набор задач, решаемых
ими. Выясняют, какие задачи нужно уметь решать для достижения
этих целей, выясняют свойства результатов, которые хотелось бы
получить, а также определяют набор сущностей, с которыми
приходится иметь дело при решении этих задач.
6

7.

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

8.

Анализ предметной области
Для систематизации сбора информации о больших
организациях и дальнейшей разработки систем, поддерживающих
их деятельность, применяется схема Захмана или архитектурная
схема предприятия.
* Графические материалы взяты с ресурса https://zachman.org/ 8

9.

Анализ предметной области
В основе схемы Захмана лежит следующая идея: деятельность
даже очень большой организации можно описать, используя ответы
на простые вопросы – зачем, кто, что, как, где и когда, – и разные
уровни рассмотрения.
Обозначенные
6
вопросов
определяют
6
аспектов
рассмотрения.
• Цели организации и базовые правила, по которым она работает.
• Персонал, подразделения и другие элементы организационной
структуры, связи между ними.
• Сущности и данные, с которыми имеет дело организация.
• Выполняемые организацией и различными ее подразделениями
функции и операции над данными.
• Географическое распределение элементов организации и связи
между географически разделенными ее частями.
• Временные характеристики и ограничения на деятельность
организации, значимые для ее деятельности события.
9

10.

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

11.

Исследование проблемы объекта деятельности
Проблема – это противоречие между желаемым будущим и
текущей ситуацией. Именно она определяет цели и задачи проекта.
Для того, чтобы правильно сформулировать проблематику, нужно
ответить себе на вопросы: “Что не так? Почему? Что будет, если
это исправить?”
Чаще всего, проблема появляется, когда чего-то не хватает для
идеального развития. Подумайте, каким бы заинтересованные
стороны хотели видеть будущее. Чего не хватает, для того, чтобы
оно воплотилось?
Необходимо указать на конкретные недоработки, которые
привели к появлению проблемы.
* Графические материалы взяты с ресурса https://www.shutterstock.com/ru/ 11

12.

Исследование проблемы объекта деятельности
Во время формулировки проблемы, часто допускаются ошибки:
• Подмена вопросом. Например: “Как научить пользователей
финансовой грамотности?”
• Подмена задачей. Например: “Разработать мобильное
приложение для контроля финансов”.
• Подмена конкретной проблемы, которую вы собираетесь
решить, огромной областью, в которую она входит. Например:
“Существует проблема недостаточной финансовой грамотности
пожилого населения страны…”
Итак, при формулировке проблемы, которую решает ваш
проект, самое важное – определить несоответствия, которые
вы собираетесь устранить; желательно также понять, почему они
появились и что будет, когда они исчезнут.
12

13.

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

14.

Сбор исходных данных
Задача сбора исходных данных является наиважнейшей в
процессе проектирования ПО. Именно от точности и полноты
собранных
данных
зависит
качество
и
эффективность
проектируемого объекта [1]. Поэтому, сбор данных требует
специального внимания и выполнения определенных принципов.
Первым принципом является полнота сбора данных. Важно
учесть все факторы, которые могут оказать влияние на
проектируемый объект.
Вторым принципом является точность сбора данных.
Результат проектирования будет достоверным только в том случае,
если данные собраны с высокой степенью точности.
* Графические материалы взяты с ресурса https://www.shutterstock.com/ru/ 14

15.

Сбор исходных данных
Требования к программной системе исходят из различных
источников, обычно называемых заинтересованными сторонами.
Это отдельные лица или группы, заинтересованные в успешном
завершении работы системы.
* Графические материалы взяты с ресурса https://www.shutterstock.com/ru/ 15

16.

Сбор исходных данных
Вот основные источники требований:
Конечные пользователи (End Users): это лица, которые будут
непосредственно использовать систему.
Заинтересованные стороны бизнеса (Business Stakeholders):
в эту группу входят менеджеры, руководители и другие лица,
принимающие
решения
в
организации,
внедряющей
программное обеспечение.
Клиенты (Customers): Потребители особенно важны в контексте
B2B, где организация, покупающая программное обеспечение,
может отличаться от той, которая его использует.
Владельцы продукта или бизнес-аналитики (Product Owners
or Business Analysts). В контексте гибкой разработки владелец
продукта играет центральную роль в сборе, интерпретации и
приоритизации требований на основе их понимания
потребностей пользователей и бизнес-целей.
16

17.

Сбор исходных данных
• Специализированные эксперты (Subject Matter Experts SME):
это лица, обладающие специальными знаниями в определенной
области, связанной с системой, например эксперты по правовым
вопросам или данным.
• Регулирующие органы (Regulatory Bodies): если программная
система работает в регулируемой области (например,
здравоохранение или финансы), к ней будут предъявляться
требования, продиктованные соответствующими законами,
правилами и стандартами.
• Системные или программные архитекторы (System or
Software Architects). Эти технические заинтересованные лица
могут определять определенные нефункциональные требования
на основе системных ограничений или лучших технических
практик, таких как требования к производительности,
требования безопасности и требования к ремонтопригодности.
17

18.

Сбор исходных данных
• Существующие системы или системная документация
(Existing Systems or System Documentation): если новую систему
необходимо интегрировать с существующей системой или
заменить ее, сама существующая система вместе со всей
сопутствующей документацией может быть источником
требований.
• Другие источники требований тоже могут быть. Все зависит от
предметной области.
18

19.

Сбор исходных данных
Сбор требований (Requirements Gathering), также известный как
выявление (Requirements Elicitation) требований, включает в себя
выявление и документирование потребностей и ожиданий
заинтересованных сторон для определения четких, кратких и
действенных требований.
Вот некоторые из методов сбора требований:
1. Анализ заинтересованных сторон (Stakeholder Analysis):
Суть в определении всех лиц или групп, которые
заинтересованы в проекте или будут затронуты его
результатами.
2. Интервью (Interviews). Проведение индивидуальных интервью
– отличный способ собрать подробную информацию. Можно
проводить как структурированные интервью (с заранее
определенными вопросами), так и неструктурированные (более
открытые и исследовательские) или их комбинацию.
19

20.

Сбор исходных данных
Вот некоторые из методов сбора требований:
3. Фокус-группы (Focus Groups): Фокус-группы позволяют
проводить интерактивные обсуждения и выявить различные
точки зрения на требования.
4. Опросы/анкеты (Surveys/Questionnaires): Когда вам нужно
собрать информацию от большой группы людей, опросы и
анкеты - ваш выбор. Они должны быть хорошо продуманы.
5. Анализ документации (Document Analysis): Просмотрите
существующую документацию, связанную с проектом, такую
как предыдущие отчеты по проекту, диаграммы процессов
(Process Diagrams), диаграммы последовательности (Sequence
Diagrams), мануалы, правила регуляторов и прочее.
20

21.

Сбор исходных данных
Вот некоторые из методов сбора требований:
6. Наблюдение/стажировка
(Observation/Job
Shadowing):
Понаблюдайте
за
конечными
пользователями
в
их
естественной среде, чтобы понять их потребности и проблемы.
7. Семинары (Workshops): Семинары включают в себя
организацию встреч ключевых заинтересованных сторон, для
совместного определения и согласования требований.
Квалифицированный фасилитатор (координатор) может вести
эти сессии, чтобы они были продуктивными и не отклонялись
от намеченного курса.
8. Прототипирование (Prototyping): Можно разработать прототип
(предварительную
версию
продукта),
чтобы
помочь
заинтересованным сторонам визуализировать конечный
результат.
21

22.

Сбор исходных данных
Вот некоторые из методов сбора требований:
9. Моделирование целей (Goal Modeling). Используется, чтобы
понять, каких целей ваши пользователи хотят достичь с
помощью системы. Эти цели послужат основой для
спецификации вашего продукта, определяя функциональные
возможности
будущей
системы
и
ограничения
производительности.
10. Варианты использования (Use Cases): Описывают, как
различные участники будут взаимодействовать с системой для
достижения своих целей. Это поможет вам определить
функциональные требования к системе. Каждый вариант
использования,
скорее
всего,
станет
разделом
или
подразделом спецификации вашего продукта, описывающим
конкретную функциональность системы.
22

23.

Сбор исходных данных
Вот некоторые из методов сбора требований:
11. Персонажи
(Personas):
на
этом
этапе
создаются
вымышленные персонажи, представляющие разные группы
пользователей. Эти персонажи будут направлять разработку
пользовательских историй, которые обеспечивают более
подробное представление о функциональных требованиях
системы.
12. Пользовательские истории (User Stories). В Agile-проектах
пользовательские
истории
обычно
используются
для
представления требований с точки зрения пользователя.
Каждая пользовательская история описывает, кому нужна
конкретная функция, что это за функция и для чего.
23

24.

Сбор исходных данных
Пользовательские истории (User Story)
Пользовательские истории – это простой способ регистрации
пользовательских требований по всему проекту, часто написанный
с точки зрения конечного пользователя.
Вот пример:
Я, как «Клиент»,
Хочу иметь возможность "искать книги по названию, автору или
номеру издания ISBN"
для того, чтобы «я мог быстро найти книгу, которую ищу».
24

25.

Сбор исходных данных
Варианты использования (Use Cases)
Вариант
использования
описывает,
как
пользователь
взаимодействует с системой для достижения цели. Он более
подробен, чем пользовательская история, и включает в себя шаги,
которые должен предпринять пользователь.
Вариант использования (Use
Case)
Поиск книги
Действующее лицо (Actor)
Клиент
Предварительные
(Preconditions)
«Клиент находится
магазина».
условия
на
главной
странице
книжного
онлайн-
Основной поток (Basic Flow)
1. «Клиент переходит к строке поиска»;
2. «Клиент вводит название книги, автора или ISBN в строку
поиска»;
3. «Система извлекает и отображает список книг, соответствующих
критериям поиска»;
4. «Клиент выбирает книгу из списка, чтобы просмотреть более
подробную информацию»;
Постусловия (Postconditions)
«Клиент просматривает сведения о выбранной книге».
Исключения (Exceptions)
«Если совпадений не найдено, система показывает сообщение
«Результаты не найдены».
25

26.

Сбор исходных данных
Также
по
составлению
всех
вариантов
использования
составляется диаграмма вариантов использования в нотации UML
* Графические материалы взяты с ресурса
26
https://www.microsoft.com/ru-ru/microsoft-365/business-insights-ideas/resources/guide-to-uml-diagramming-and-database-modeling

27.

Использованные источники
[1] Старшинов Владислав, От идеи к развертыванию: искусство
современной разработки программного обеспечения. / В.
Старшинов // Личный блог на портале habr.com. - 2023. - URL:
https://habr.com/ru/articles/752418/ (дата обращения 16.09.2023)
27