Лабораторная работа 1

Тема: Анализ предметной области и проектирование базовой архитектуры информационной системы
Части:

• Часть 1 — Анализ предметной области и стейкхолдеров

• Часть 2 — Формирование требований и архитектурных драйверов

• Часть 3 — Логическая архитектура (подсистемы и функциональная декомпозиция)

• Часть 4 — Информационная (данная) архитектура

Дисциплина: Проектирование архитектуры информационных систем
Продолжительность: 2 пары (3 академических часа)
Форма проведения: работа в малых подгруппах.

1. Цель лабораторной работы

Сформировать у студентов первичные навыки архитектурного проектирования ИС на ранних стадиях:

• анализ предметной области и стейкхолдеров;

• формирование функциональных и нефункциональных требований;

• выделение логических подсистем и их ответственности;

• построение концептуальной модели данных.

2. Планируемые результаты (компетенции и умения)

Студент должен уметь:

1. Определять границы информационной системы и её окружение.

2. Выделять стейкхолдеров, их цели и интересы.

3. Формулировать функциональные и нефункциональные требования, архитектурные драйверы и ограничения.

4. Проектировать логическую архитектуру (подсистемы и их взаимодействие).

5. Строить концептуальную модель данных (основные сущности, связи).

6. Оформлять результаты в виде краткого архитектурного описания: текст + диаграммы.

3. Исходные данные

Студент заранее выбирает единый кейс (или несколько на выбор) - а преподаватель утверждает его:

Примеры (страничка следующая за лабораторными работами содержит больше развернутых примеров, либо тему студент выбирает самостоятельно исходя из личных интересов или лучше опыта работы, если имеется):

• Интернет-магазин цифровых товаров.

• Система управления учебным процессом в вузе.

• CRM для небольшой сервисной компании.

• Система записи к врачу в частной клинике.

• и тд.

  
  

4. Требования к программным средствам

• текстовый редактор (Word, Google Docs, LibreOffice и т.п.);

• редактор диаграмм: Draw.io / diagrams.net, Lucidchart, PlantUML, Visual Paradigm, StarUML и др.;

• при необходимости — шаблон отчёта (смотреть ниже)

5. Структура лабораторной работы

ЧАСТЬ 1. Анализ предметной области и стейкхолдеров

Цель части:
Научиться понимать контекст ИС, определять стейкхолдеров и границы системы.

Рекомендуемое время: 30–40 минут.

Задания

1. Изучить исходное описание кейса.
   Внимательно прочитайте текст задания. При необходимости можно задать уточняющие вопросы преподавателю.

2. Выделить стейкхолдеров.
   Составьте таблицу:

   Стейкхолдер	Тип (внутр./внешн.)	Роль	Основные интересы / цели	Возможные риски / опасения

   
   
   

1. Минимум 5–7 стейкхолдеров (пользователи, заказчик, администрация, поддержка, внешние системы и т.д.).

2. Определить границы системы.

   • Опишите, что делает ИС, а какие функции остаются вне её границ (ручные процессы, сторонние сервисы).

   • Перечислите внешние системы (платёжные сервисы, почта, гос­сервисы и т.п.), если они упоминаются или логически вытекают из кейса.

3. Построить контекстную диаграмму (диаграмма окружения).

   • В центре — разрабатываемая ИС.

   • Вокруг — стейкхолдеры и внешние системы.

   • Отразить основные потоки информации (что передаётся куда: заказы, отчёты, уведомления и т.п.).

Результат ЧАСТИ 1 (в отчёт):

• Текстовое описание предметной области (5–10 предложений).

• Таблица стейкхолдеров.

• Контекстная диаграмма с краткой подписью.

ЧАСТЬ 2. Формирование требований и архитектурных драйверов

Цель части:
Выделить требования к системе и определить ключевые архитектурные драйверы (то, что влияет на архитектуру).

Рекомендуемое время: 30–40 минут.

Задания

1. Функциональные требования.
   Составьте список не менее чем из 10–15 функциональных требований.
   Можно использовать формат «пользовательских историй» или кратких сценариев:

   • «Пользователь должен иметь возможность зарегистрироваться в системе».

   • «Менеджер должен иметь возможность сформировать отчёт по продажам за период».

2. Нефункциональные требования.
   Сформулируйте не менее 5–7 нефункциональных требований по категориям:

   • производительность (время отклика, количество пользователей);

   • надёжность / доступность;

   • безопасность (аутентификация, авторизация, защита данных);

   • масштабируемость;

   • удобство сопровождения и развития и др.

3. Архитектурные ограничения.
   Перечислите ограничения, которые влияют на архитектуру, например:

   • использование определённой СУБД или стека технологий;

   • необходимость интеграции с конкретной внешней системой;

   • ограничения по бюджету, срокам, квалификации команды.

4. Формализация 2–3 сценариев качества.
   Возьмите 2–3 важных нефункциональных требования (например, производительность, доступность, безопасность) и оформите их в виде сценариев качества:

   Структура:

   • Источник стимула (кто / что инициирует ситуацию).

   • Сам стимул (событие).

   • Контекст (условия, при которых происходит событие).

   • Ожидаемая реакция системы.

   • Критерии приемлемости (конкретные, измеримые).

Результат ЧАСТИ 2 (в отчёт):

• Список функциональных требований (10–15 пунктов).

• Список нефункциональных требований (5–7 пунктов).

• Таблица архитектурных ограничений.

• 2–3 сценария качества в формализованной форме.

ЧАСТЬ 3. Логическая архитектура (подсистемы и функциональная декомпозиция)

Цель части:
Спроектировать логическую структуру системы: подсистемы, их ответственность и взаимодействие.

Рекомендуемое время: 40–45 минут.

Задания

1. Функциональная декомпозиция.
   На основе требований сгруппируйте функции в логические блоки (подсистемы).
   Примеры подсистем:

   • «Управление пользователями и ролями»;

   • «Управление каталогом товаров»;

   • «Управление заказами»;

   • «Оплаты и расчёты»;

   • «Отчётность и аналитика»;

   • «Интеграция с внешними системами» и др.

   Минимум 5–7 подсистем.

2. Определить ответственность подсистем.
   Для каждой подсистемы заполните таблицу:

   | Подсистема | Ответственность | Основные операции / функции | Основные данные, которыми оперирует |

3. Определить взаимодействие подсистем.

   • Опишите, какая подсистема обращается к какой и по какому поводу.

   • Можно указать тип взаимодействия на уровне идей (синхронный запрос, асинхронное сообщение и т.п., пока без технических деталей).

4. Построить диаграмму логической архитектуры.
   Возможные варианты:

   • UML диаграмма пакетов / компонентов;

   • C4 диаграмма уровня Container (основные контейнеры / сервисы и связи).

   На диаграмме должны быть:

   • все подсистемы;

   • стрелки / связи между ними;

   • подписи связей (какой тип информации передаётся, за что отвечает связь).

Результат ЧАСТИ 3 (в отчёт):

• Таблица подсистем и их ответственности.

• Диаграмма логической архитектуры (подсистем / контейнеров) с кратким текстовым пояснением (5–10 предложений).

ЧАСТЬ 4. Информационная (данная) архитектура

Цель части:
Спроектировать концептуальную модель данных, согласованную с логической архитектурой.

Рекомендуемое время: 40–45 минут.

Задания

1. Выделить ключевые сущности предметной области.
   На основе требований и подсистем определите 8–15 сущностей, например:

   • Пользователь, Роль;

   • Клиент;

   • Товар / Услуга;

   • Заказ, Позиция заказа;

   • Платёж;

   • Отчёт и т.п.

2. Определить атрибуты и связи.
   Для каждой сущности определите:

   • ключевые атрибуты (ID, наименование, дата, сумма, статус и т.д.);

   • типы связей между сущностями (1:1, 1:N, M:N).

3. Построить ER-диаграмму (концептуальная модель данных).
   Используйте удобную нотацию (Crow’s Foot, UML Class).
   На диаграмме должны быть:

   • сущности (в виде прямоугольников) с основными атрибутами;

   • связи с указанием кратности.

4. Связать сущности с подсистемами.
   Для каждой сущности укажите, какая подсистема является основным «владельцем» данных (где эти данные создаются и хранятся как «источник истины»).

   Таблица:

   | Сущность | Описание | Основная подсистема-владелец | Другие подсистемы, использующие данные |

5. Проанализировать риски по данным.
   Кратко (5–7 предложений) опишите возможные проблемы:

   • избыточность и дублирование данных;

   • проблемы целостности;

   • потенциальные «узкие места» по производительности (например, очень нагруженные сущности).

Результат ЧАСТИ 4 (в отчёт):

• ER-диаграмма (концептуальная модель данных).

• Таблица «сущности — подсистемы».

• Краткий текстовый анализ рисков по данным.

6. Структура итогового отчёта по Лабораторной работе 1

Рекомендуемая структура отчёта:

1. Титульный лист (по шаблону вуза).

2. Цель и задачи работы.

3. Краткое описание предметной области и кейса.

4. Часть 1. Анализ стейкхолдеров и контекста системы

   • описание предметной области;

   • таблица стейкхолдеров;

   • контекстная диаграмма.

5. Часть 2. Требования и архитектурные драйверы

   • функциональные требования;

   • нефункциональные требования;

   • архитектурные ограничения;

   • сценарии качества.

6. Часть 3. Логическая архитектура

   • таблица подсистем и ответственности;

   • диаграмма логической архитектуры;

   • текстовое пояснение.

7. Часть 4. Информационная архитектура

   • перечень сущностей и атрибутов;

   • ER-диаграмма;

   • таблица «сущности — подсистемы»;

   • анализ рисков.

8. Ответы на контрольные вопросы.

9. Выводы по работе.

7. Контрольные вопросы (примерный перечень)

1. Что такое стейкхолдер информационной системы? Приведите примеры.

2. Для чего нужно определять границы системы и её окружение на ранних этапах?

3. Чем функциональные требования отличаются от нефункциональных?

4. Что такое архитектурный драйвер? Приведите два примера для вашего кейса.

5. Зачем выполнять функциональную декомпозицию системы?

6. В чём отличие логической архитектуры от физической (технологической)?

7. Что такое концептуальная модель данных? Чем она отличается от логической модели БД?

8. Почему важно понимать, какая подсистема является владельцем данных?

8. Критерии оценивания

• Полнота анализа стейкхолдеров и контекста — до 20%.

• Качество и реалистичность требований и сценариев качества — до 25%.

• Обоснованность логической архитектуры и корректность диаграммы подсистем — до 25%.

• Корректность модели данных (ER-диаграммы) и связи с подсистемами — до 20%.

• Оформление отчёта, выводы, ответы на вопросы — до 10%.