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

Введение в проектирование ИС и жизненный цикл

Зачем нужно проектирование информационных систем

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

Проектирование ИС — это целенаправленная деятельность по преобразованию потребностей бизнеса (что нужно делать) в описания будущей системы (как это будет устроено) с последующей реализацией и внедрением.

Проектирование нужно, потому что оно:

снижает риск сделать «не то» (ошибиться в целях и требованиях)

позволяет оценивать сроки и стоимость до начала разработки

помогает обеспечить качество: надежность, безопасность, удобство, производительность

делает систему поддерживаемой и развиваемой (важно для долгоживущих ИС)

В рамках курса мы будем рассматривать проектирование как часть жизненного цикла ИС и как набор методов: от структурного анализа до проектирования данных и программного обеспечения.

Что именно проектируют в ИС

Чтобы избежать путаницы, разделим объект проектирования на несколько «слоев». На практике они взаимосвязаны, но каждый требует своих методов.

Бизнес-процессы и регламенты: как устроена работа организации, где возникает информация, кто принимает решения.

Требования: что система должна делать и при каких ограничениях.

Информационное обеспечение: какие данные нужны, как они связаны, как обеспечивается качество данных.

Программное обеспечение: компоненты, модули, интерфейсы, алгоритмы, интеграции.

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

Важно: проектирование ИС — это не только «нарисовать схему базы данных» или «придумать архитектуру». Это согласование целей, требований, данных, процессов и реализации.

Понятие жизненного цикла ИС

Жизненный цикл (ЖЦ) ИС — это последовательность стадий, через которые проходит система от замысла до вывода из эксплуатации.

ЖЦ помогает ответить на вопросы:

какие работы вообще нужно выполнить

в каком порядке их организовать

какие результаты (артефакты) должны появляться на каждом шаге

кто и что должен согласовать

В инженерной практике жизненный цикл описывают стандарты. Например, существует стандарт на процессы жизненного цикла ПО ISO/IEC/IEEE 12207.

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

Типовые стадии жизненного цикла

Названия стадий могут различаться, но смысл обычно близкий.

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

Сбор и анализ требований: фиксируется, что система должна делать и какие ограничения есть.

Проектирование: определяется, как система будет устроена (данные, функции, компоненты, интерфейсы).

Разработка (реализация): создается программный код, конфигурации, схемы БД, интеграции.

Тестирование: проверяется соответствие требованиям и отсутствие критичных дефектов.

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

Эксплуатация и сопровождение: исправления, обновления, мониторинг, развитие.

Вывод из эксплуатации: перенос данных, отключение, архивирование, закрытие рисков.

Ключевая идея: проектирование не заканчивается «на бумаге». Результаты проектирования постоянно проверяются на реализуемость, тестируемость и пригодность в эксплуатации.

Требования как основа проектирования

Требование — это формулировка нужного свойства или поведения системы.

Чтобы проектирование было управляемым, требования обычно делят на категории:

Функциональные требования: какие функции должна выполнять система (например, «оформлять заказ», «рассчитывать скидку»).

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

Ограничения: технологии, стандарты, бюджет, сроки, юридические условия.

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

Артефакты жизненного цикла

Артефакты — это результаты работ, которые можно проверить, согласовать и передать.

Примеры артефактов, которые часто встречаются в проектах ИС:

концепция и границы системы

описание требований (текстовое и/или модельное)

модели процессов и данных

архитектурное описание и проектные решения

прототипы пользовательского интерфейса

тест-план и результаты тестирования

эксплуатационная документация

Наличие артефактов не означает «много бумажной работы». Это означает управляемость: можно понять, что именно сделано, что согласовано, и почему система получилась именно такой.

Модели жизненного цикла

Модель жизненного цикла — это способ организовать стадии и обратные связи между ними.

Ниже — несколько распространенных моделей.

Каскадная модель

Смысл: стадии идут последовательно, переход на следующую — после завершения предыдущей.

Плюсы:

понятная структура работ и отчетности

удобно, когда требования стабильны

Минусы:

поздняя обратная связь от пользователей

изменения требований приводят к дорогим переделкам

Общее описание подхода к жизненному циклу можно посмотреть, например, в статье System development life cycle.

V-модель

Смысл: каждой стадии проектирования соответствует стадия проверки (верификации/валидации) на «зеркальной» ветви.

слева: требования и проектирование

справа: виды тестирования и приемка

!V-модель показывает связь проектных решений с проверками, повышая управляемость качества.

Итеративная и инкрементная модель

Смысл:

система строится частями (инкрементами)

каждый инкремент проходит мини-цикл: требования → проектирование → разработка → тестирование

Плюсы:

ранняя поставка ценности

проще управлять изменениями

Минусы:

требует дисциплины в архитектуре и управлении версиями

Спиральная модель

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

Подходит, когда:

высокие технологические риски

много неопределенности

Гибкие подходы (Agile)

Agile — это семейство подходов, где работа организована короткими итерациями, а обратная связь от пользователя и адаптация к изменениям — ключевая ценность.

Первоисточник ценностей Agile — Agile Manifesto.

Важно понимать: Agile не отменяет проектирование. Он обычно меняет его форму:

больше проектирования «по мере уточнения»

больше прототипов и быстрых проверок гипотез

сильнее роль коммуникации с бизнесом

Как выбрать модель жизненного цикла

Выбор зависит не от моды, а от условий проекта. Полезно оценить:

стабильность требований: они понятны и фиксированы или будут регулярно меняться

критичность качества: цена ошибки (финансы, безопасность, здоровье, репутация)

сложность интеграций: внешние системы, множество интерфейсов

скорость получения обратной связи: есть ли доступ к пользователям

уровень рисков: технологических и организационных

Ниже — упрощенная таблица для первичной ориентации.

| Условие проекта | Часто подходит | Почему | |---|---|---| | Требования стабильны, нужна предсказуемость | Каскадная модель | Проще планирование и согласования | | Высокие требования к качеству и проверкам | V-модель | Явная связь «проектирование ↔ тестирование» | | Нужна ранняя поставка результата | Итеративная/инкрементная | Ценность появляется частями | | Много неопределенности и рисков | Спиральная | Риски управляются с начала каждой итерации | | Требования меняются, важна скорость обратной связи | Agile | Итерации и адаптация встроены в процесс |

Как жизненный цикл связан с методологиями проектирования

Жизненный цикл отвечает на вопрос когда и в каком порядке делать работы. Методологии и технологии проектирования отвечают на вопрос как именно описывать систему.

В следующих темах курса мы будем разбирать:

структурные методы анализа и проектирования: как формально описывать функции, процессы и потоки данных

проектирование информационного обеспечения: как моделировать данные и обеспечивать их согласованность

проектирование программного обеспечения: как переходить от требований к архитектуре и компонентам

В этой вводной статье важно запомнить основу: проектирование — это не разовый этап, а управляемая деятельность внутри жизненного цикла, тесно связанная с требованиями, проверками и эксплуатацией.

Итоги

Проектирование ИС — это преобразование целей и требований в реализуемое и проверяемое решение.

Жизненный цикл описывает путь системы от идеи до вывода из эксплуатации и помогает управлять работами.

Модели жизненного цикла (каскадная, V-модель, итеративная, спиральная, Agile) различаются организацией стадий и обратной связью.

Основа качественного проектирования — корректные требования и артефакты, которые можно согласовать и проверить.

Требования к ИС: сбор, анализ и спецификация

Место требований в проектировании и жизненном цикле

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

Если требования сформулированы слабо, то на поздних стадиях жизненного цикла это приводит к:

переработкам проектных решений

конфликтам между заказчиком и командой

«непринимаемой» системе, даже если она технически работает

В любой модели жизненного цикла (каскадной, V-модели, итеративной, Agile) требования нужны для управляемости: их можно согласовать, проверить и связать с тестами и проектными артефактами.

> “Working software over comprehensive documentation” из Agile Manifesto

Важно понимать эту фразу правильно: документация не отменяется, но ее объем и форма должны быть достаточными, чтобы обеспечить общее понимание, проверяемость и поддержку решения.

Термины и базовые определения

Потребность (need): проблема или цель бизнеса, из-за которой вообще появляется инициатива (например, снизить время обработки заявок).

Требование (requirement): проверяемое утверждение о том, что система должна делать или каким свойством обладать.

Заинтересованная сторона (stakeholder): любой участник, на которого влияет система или кто влияет на требования (пользователи, владелец процесса, служба ИБ, администраторы, бухгалтерия).

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

Кто формирует требования и откуда они берутся

Источники требований обычно многоканальные:

пользователи и владельцы бизнес-процессов

руководство и стратегические цели

законодательство и нормативы

существующие регламенты, инструкции, отчеты

ограничения инфраструктуры и интеграций

данные и их качество в текущих системах

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

Классификация требований

Удобно разделять требования по уровням и типам, чтобы не смешивать цели бизнеса с деталями реализации.

| Тип | Что описывает | Пример формулировки | |---|---|---| | Бизнес-требования | зачем нужна система и какой эффект ожидается | «Сократить срок обработки заявки с 3 дней до 1 дня» | | Пользовательские требования | что нужно пользователю в терминах задач | «Оператор должен быстро находить заявку по телефону клиента» | | Системные требования | что должна обеспечивать система как продукт | «Система должна поддерживать поиск по номеру телефона за не более чем 2 секунды» | | Функциональные требования | функции и поведение | «Создавать заявку, назначать исполнителя, менять статус» | | Нефункциональные требования | качества и ограничения (производительность, безопасность, надежность) | «Доступность 99,5% в рабочее время», «Аудит изменений» | | Ограничения | что нельзя нарушать | «Использовать корпоративную СУБД», «Хранить данные в РФ» | | Требования к данным | состав, качества, правила, связи | «Телефон хранится в формате E.164», «У клиента может быть несколько адресов» | | Требования к интерфейсам | интеграции и протоколы | «Обмен с 1С по REST», «Импорт из CSV по шаблону» |

Нефункциональные требования часто структурируют по качественным характеристикам продукта. В качестве справочной модели можно использовать характеристики качества из ISO/IEC 25010.

Сбор требований

Сбор требований (elicitation) означает не «получить список хотелок», а организовать извлечение знаний о целях, процессах, данных и ограничениях из разных источников.

!Схема показывает, как разные источники и методы приводят к конкретным артефактам требований.

Основные техники сбора

Интервью: глубоко раскрывает детали, но зависит от качества вопросов и доступности эксперта.

Воркшопы (сессии совместной проработки): быстро согласуют понимание между подразделениями.

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

Анализ документов: регламенты, формы, отчеты, договоры, нормативы.

Прототипирование: быстрые макеты экранов и сценариев для проверки понимания.

Анкетирование: удобно для большого числа пользователей, но дает менее глубокие ответы.

Что важно зафиксировать уже на сборе

границы системы: что входит и что не входит

роли пользователей и их цели

основные сценарии и исключения

словарь терминов (глоссарий), чтобы одинаковые слова значили одно и то же

ограничения: сроки, технологии, безопасность, интеграции

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

Анализ требований превращает разрозненные ожидания и факты в согласованный, проверяемый и реализуемый набор требований.

Типовой набор задач анализа:

устранение противоречий и дубликатов

уточнение неоднозначностей (что именно означает «быстро», «удобно», «как сейчас»)

проверка реализуемости (технической, организационной, юридической)

приоритизация (что делать в первую очередь)

моделирование процессов и данных для выявления пробелов

Качества хорошего требования

Требование считается качественным, если оно пригодно для разработки и проверки.

| Критерий | Что означает на практике | Плохой пример | Улучшенный вариант | |---|---|---|---| | Однозначность | читается одинаково всеми | «Система должна быть удобной» | «Новый пользователь должен создать заявку за не более чем 3 минуты по инструкции» | | Проверяемость | можно протестировать и принять | «Система должна работать быстро» | «Поиск клиента выполняется не более чем за 2 секунды при 100 одновременных пользователях» | | Полнота | есть условия, исключения, входы/выходы | «Система сохраняет заявку» | «При сохранении обязательны: тема, клиент, канал; при ошибке показывать причину» | | Непротиворечивость | требования не конфликтуют | «Хранить 10 лет» и «Удалять через 1 год» | Единая политика хранения по классам данных | | Трассируемость | понятно, откуда требование и куда оно идет дальше | «Нужно логирование» без источника | «ИБ: журнал действий хранить 180 дней; связано с тестом T-SEC-03» |

Приоритизация

Один из простых методов приоритизации для согласования с бизнесом и командой разработки: MoSCoW.

Must: обязательно, без этого продукт не принимается.

Should: важно, но допустимо перенести, если сроки ограничены.

Could: желательно, если хватит ресурсов.

Won’t (now): не делаем сейчас.

Справочно: MoSCoW method.

Моделирование как инструмент анализа

Требования часто проверяют через модели:

модели процессов помогают увидеть шаги, роли, входы и выходы

модели данных показывают сущности, связи и правила

сценарии использования (use cases) показывают взаимодействия пользователя с системой

В следующих темах курса, где мы будем изучать структурные методы анализа и проектирования, модели станут ключевым инструментом, чтобы переводить требования в проектные решения системно, а не интуитивно.

Спецификация требований

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

Формат спецификации выбирают под жизненный цикл и культуру команды:

документная спецификация (например, SRS)

набор сценариев и требований в системе управления задачами

backlog из user stories с критериями приемки

комбинация (часто на практике)

Справочно о классическом формате: Software requirements specification.

Структура спецификации (примерный шаблон)

Ниже пример того, как можно структурировать требования, чтобы они оставались понятными и проверяемыми:

Контекст и цели

Границы системы и допущения

Роли пользователей и бизнес-процессы

Функциональные требования (по подсистемам или по сценариям)

Нефункциональные требования (качество, безопасность, надежность, производительность)

Требования к данным (справочники, атрибуты, правила качества)

Интерфейсы и интеграции

Отчетность и аналитика

Ограничения и стандарты

Приложения: глоссарий, протоколы решений, макеты

Сценарии, use case и user story

Три распространенных способа описывать функциональность:

Сценарий: текстовое описание шагов пользователя и системы.

Use case: более формальный сценарий с основным потоком и альтернативами. Справочно: Use case.

User story: краткая формулировка ценности пользователя, обычно вида «Как роль я хочу цель, чтобы ценность», плюс критерии приемки.

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

Критерии приемки

Чтобы требование можно было принять, к нему часто добавляют критерии приемки:

условия, при которых функциональность считается выполненной

примеры входных данных и ожидаемых результатов

ограничения по времени, ролям, правам доступа

Критерии приемки связывают требования с тестированием и приемкой, что особенно важно в V-модели и в проектах с высоким уровнем ответственности.

Трассируемость требований

Трассируемость означает наличие связей:

от бизнес-целей к требованиям

от требований к проектным решениям

от требований к тестам

от дефектов и изменений обратно к требованиям

!Матрица показывает, как каждое требование связано с целями, модулями и тестами.

Зачем это нужно:

чтобы изменения не ломали систему незаметно

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

чтобы доказывать, что все цели покрыты реализованной функциональностью

Управление изменениями требований

Изменения требований неизбежны: меняются процессы, закон, рынок, понимание проблемы.

Минимальный управляемый процесс выглядит так:

Регистрация запроса на изменение (что меняем и почему)

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

Решение (принять, отложить, отклонить)

Обновление версии спецификации и связей трассируемости

Это связывает требования с жизненным циклом: изменения должны быть видимыми и контролируемыми, иначе проект «плывет».

Частые ошибки в требованиях

подмена требований решениями: «сделать на микросервисах» вместо «обеспечить независимое масштабирование подсистемы X»

размытые формулировки: «быстро», «удобно», «современно», без критериев

игнорирование нефункциональных требований до конца проекта

отсутствие глоссария (термины трактуются по-разному)

несогласованные исключения и альтернативные сценарии

отсутствие владельца требования и источника

Итоги

Требования превращают потребности бизнеса в проверяемое описание будущей ИС и связывают этапы жизненного цикла.

Сбор требований использует разные техники и обязательно фиксирует контекст, роли, ограничения и термины.

Анализ требований устраняет противоречия, повышает проверяемость, расставляет приоритеты и выявляет пробелы.

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

Управление изменениями и трассируемость защищают проект от неконтролируемого роста объема работ и снижения качества.

Методологии и технологии проектирования ИС

Как эта тема связана с жизненным циклом и требованиями

В предыдущих темах курса мы разобрали:

жизненный цикл ИС — как организуются работы от идеи до эксплуатации

требования — как фиксируется то, что система должна делать и какими свойствами обладать

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

Проще говоря:

жизненный цикл задает когда и в какой последовательности выполняются работы

требования задают что нужно

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

!Связь жизненного цикла, требований и методов проектирования

Термины: методология, метод, технология, нотация, инструмент

Чтобы не смешивать понятия, договоримся о терминах.

Методология — система принципов и правил, которая определяет подход к проектированию: какие модели строим, какие артефакты получаем, как согласуем решения, как управляем изменениями.

Метод — конкретный способ выполнения работы внутри методологии (например, декомпозиция функций, построение диаграммы потоков данных).

Технология проектирования — практическая организация работ: набор методов, ролей, шаблонов документов, процедур контроля качества и часто инструментов (например, CASE-средства, репозитории моделей).

Нотация — формальный язык записи моделей (например, DFD, IDEF0, ER-диаграммы, UML).

Инструмент — программное средство, которое помогает создавать и хранить модели, вести трассируемость, генерировать документацию.

Важно: одну и ту же методологию можно реализовывать разными технологиями (по-разному организовать процесс и инструменты), а одну нотацию использовать в разных методологиях.

Зачем вообще нужны методологии проектирования

Методологии проектирования применяют не ради «красивых схем», а ради управляемости и качества.

Они помогают:

снижать неоднозначность требований за счет моделей и согласованных терминов

выявлять пробелы и противоречия (например, «процесс есть, а данные для него не определены»)

обеспечивать трассируемость: требование → модель → проектное решение → тест

разделять уровни проектирования: бизнес-уровень, логический уровень, технический уровень

упрощать коммуникацию между бизнесом, аналитиками, архитекторами, разработчиками и тестировщиками

Классы методологий проектирования ИС

На практике полезно различать несколько «семейств» методологий. Они часто комбинируются.

Структурные методологии анализа и проектирования

Структурный подход исторически один из самых распространенных в проектировании ИС, особенно для систем учета и обработки данных.

Его ключевые идеи:

функциональная декомпозиция: сложную систему разбивают на функции и подпроцессы

явное моделирование потоков данных между функциями

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

Типовые нотации структурного подхода:

диаграммы потоков данных DFD (Data flow diagram)

функциональные модели IDEF0 (IDEF0)

модель «сущность–связь» ER (Entity%E2%80%93relationship_model)

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

Объектно-ориентированные методологии

Объектно-ориентированный подход фокусируется на:

сущностях предметной области как «объектах» со структурой и поведением

взаимодействиях между объектами и компонентами

моделировании сценариев использования

Наиболее распространенная нотация — UML (Unified Modeling Language).

UML часто применяют ближе к проектированию программного обеспечения (архитектура, компоненты, взаимодействия), но он также используется и на аналитическом уровне (use case, диаграммы деятельности).

Процессные методологии моделирования бизнеса

Если значимая часть требований завязана на регламенты, роли и бизнес-процессы, удобны нотации процессного моделирования.

Самая распространенная нотация — BPMN (Business Process Model and Notation).

BPMN помогает:

согласовать «как работает бизнес» до автоматизации

выделить точки контроля, исключения и события

определить роли и ответственность

Архитектурные методологии и корпоративная архитектура

Для крупных организаций проектирование ИС часто ведут не только на уровне одной системы, а в контексте ландшафта приложений и данных.

Используются подходы корпоративной архитектуры, например:

TOGAF (The Open Group Architecture Framework)

фреймворк Zachman (Zachman Framework)

Они помогают увязать:

бизнес-цели

процессы

данные

приложения

технологии и инфраструктуру

И снизить риск локальной оптимизации, когда отдельная система «хороша сама по себе», но плохо стыкуется с остальными.

Уровни проектирования: от концепции к реализации

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

Концептуальный уровень

Цель: зафиксировать смысл и границы, не углубляясь в технические детали.

Типовые результаты:

контекст системы и внешние взаимодействия

основные бизнес-сущности и термины (глоссарий)

верхнеуровневые процессы и роли

Логический уровень

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

Типовые результаты:

модели процессов и функций

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

сценарии использования и бизнес-правила

Физический уровень

Цель: привязать решение к конкретным технологиям и ограничениям.

Типовые результаты:

схема базы данных с типами, индексами, ограничениями

интерфейсы интеграции (форматы, протоколы, контракты)

архитектурные решения по развертыванию и масштабированию

Практическое правило: чем раньше вы уходите в физический уровень, тем выше риск «подменить требования решением».

Технологии проектирования: как организуют работу на практике

Под технологией проектирования в проектной деятельности часто понимают воспроизводимую «производственную линию»: роли, шаги, артефакты, проверки качества, инструменты.

Артефактный подход

Удобно мыслить через артефакты, которые должны появиться и быть согласованы.

Типовой набор артефактов между требованиями и реализацией:

модель бизнес-процессов или функциональная модель

модель данных

спецификация интерфейсов

архитектурное описание (компоненты, ответственности, взаимодействия)

прототипы пользовательского интерфейса

решения по безопасности и журналированию

Этот подход хорошо сочетается и с каскадной моделью, и с итеративной: просто артефакты могут выпускаться по частям.

CASE-средства и репозитории моделей

CASE (Computer-Aided Software Engineering) — инструменты, поддерживающие проектирование и управление артефактами.

Что они обычно дают:

единое хранилище моделей и версий

шаблоны диаграмм и проверку связности

генерацию документации

иногда генерацию каркасов кода или схем БД

Даже без тяжелых CASE-средств важен принцип: модели и требования должны быть не «в разрозненных файлах», а в управляемой структуре с версиями и ответственными.

Трассируемость «требование → модель → тест»

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

В технологии проектирования трассируемость обычно реализуют через:

идентификаторы требований

ссылки из диаграмм и спецификаций на требования

связь требований с тест-кейсами и критериями приемки

Это особенно критично в V-модели, где каждой стадии проектирования соответствует вид проверки.

Как выбирать методологию и нотации под проект

Нет универсального набора «правильных» диаграмм. Выбор зависит от целей, рисков и контекста.

Факторы выбора

стабильность требований и частота изменений

сложность предметной области и число исключений

количество интеграций и внешних интерфейсов

критичность качества и требований безопасности

размер команды и распределенность участников

требования заказчика к документации и приемке

Практическая матрица выбора

| Ситуация | Что обычно полезно | Почему | |---|---|---| | Нужно согласовать работу подразделений и регламент | BPMN | Хорошо показывает роли, события, альтернативы | | Нужно строго описать функции и потоки информации | DFD | Явно показывает входы/выходы и хранилища данных | | Нужно описать «что такое данные» и их связи | ER-модель | Хорошая основа для логической модели БД | | Нужны сценарии взаимодействия с системой | Use case (UML) | Связывает роли, цели и варианты поведения | | Нужна архитектура ПО и границы компонентов | UML (компоненты/последовательности) | Помогает проектировать взаимодействия и зависимости | | Нужно увязать систему с ландшафтом ИТ | TOGAF-подходы | Снижает риск несостыковок на уровне предприятия |

Типовой «сквозной» пример набора моделей

Рассмотрим упрощенную ситуацию: требуется ИС для обработки заявок клиентов.

Рациональная последовательность проектирования может выглядеть так:

Зафиксировать контекст и границы: кто внешние участники, какие внешние системы, какие основные интеграции.

Описать ключевой процесс обработки заявки: роли, шаги, исключения.

Построить модель потоков данных или функций: какие данные на входе/выходе каждого шага.

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

Уточнить сценарии использования: создание заявки, поиск, смена статуса, закрытие, отмена.

Спроектировать интерфейсы интеграции и архитектурные компоненты.

Ценность такой цепочки в том, что каждый следующий артефакт проверяет предыдущий:

процесс без данных быстро выявляет пробелы

данные без процессов выявляют «мертвые сущности»

архитектура без сценариев повышает риск неверного разбиения на компоненты

Частые ошибки при выборе методологий и технологий

выбор нотации «потому что принято», без связи с задачами проекта

смешивание уровней: попытка сразу рисовать физическую БД, когда не определены сущности и правила

модели ради моделей: диаграммы есть, но они не связаны с требованиями и приемкой

отсутствие глоссария: одинаковые термины на схемах означают разное

несогласованность моделей: процесс говорит одно, модель данных — другое

Итоги

Методологии и технологии проектирования определяют, как переводить требования в согласованные модели и проектные решения.

Структурные методы (DFD, IDEF0, ER) сильны там, где важны функции, потоки данных и строгая декомпозиция.

UML и BPMN дополняют структурный подход: UML удобен для проектирования ПО и сценариев, BPMN — для процессов.

Проектирование полезно вести по уровням: концептуальный → логический → физический, чтобы не подменять требования техническими решениями.

Критичны управляемые артефакты, инструменты хранения и трассируемость «требование → модель → тест».

Структурный анализ: контекст, DFD и словарь данных

Место структурного анализа в курсе

В предыдущих темах мы:

разобрали жизненный цикл ИС и роль проектирования

научились собирать, анализировать и специфицировать требования

рассмотрели методологии проектирования и место структурных методов среди них

Теперь переходим к практике структурного анализа — дисциплинированному способу описать будущую ИС через:

границы системы и взаимодействия с внешним миром (контекст)

функции и перемещение информации между ними (DFD — диаграммы потоков данных)

точные определения данных (словарь данных)

Главная ценность структурного анализа: он помогает превратить текстовые требования в проверяемые модели, в которых легче увидеть пропуски, противоречия и лишние допущения.

Справочно о нотации: Data-flow diagram.

Что такое структурный анализ

Структурный анализ — это подход, в котором систему описывают как набор функций (процессов), преобразующих входные данные в выходные, и как потоки данных между этими функциями.

Ключевые идеи:

функциональная декомпозиция: от общего к частному (система → крупные функции → подпроцессы)

явные потоки данных: что именно передается между процессами и внешними участниками

явные хранилища данных: где информация хранится и откуда берется

Важно: DFD моделирует движение и преобразование информации, а не последовательность действий по времени. Для «времени» и событий чаще удобнее BPMN, но в структурном подходе акцент именно на данных и функциях.

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

Зачем нужна контекстная диаграмма

Контекстная диаграмма — это самый верхний уровень представления системы. На ней показывают:

систему как единый процесс

внешние сущности (актеры, подразделения, внешние системы)

основные потоки данных между внешним миром и системой

Контекстная диаграмма отвечает на вопросы:

где граница системы

кто и что обменивается данными с системой

какие интеграции и каналы обмена принципиально важны

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

!Пример контекстной диаграммы: границы системы и основные внешние взаимодействия

Как построить контекст

Выписать внешние сущности.

Уточнить, какие данные каждая сущность передает в систему и получает из системы.

Договориться о названиях потоков на уровне смысла, не углубляясь в формат.

Проверить границы: все, что внутри — ответственность системы; все, что снаружи — внешние участники или внешние ИС.

Частые ошибки в контексте

путать внешнюю сущность и роль внутри системы (например, «Оператор» должен быть снаружи, а не «внутри ИС»)

показывать на контексте внутренние хранилища данных (на этом уровне они обычно не нужны)

рисовать слишком много потоков с низкоуровневыми деталями (форматы, поля, технические параметры)

DFD: диаграммы потоков данных

Базовые элементы DFD

DFD использует ограниченный набор сущностей.

Процесс: преобразует данные (например, «Зарегистрировать заявку»).

Поток данных: информация, которая передается (например, «Данные заявки»).

Хранилище данных: место долговременного хранения (например, «Заявки», «Клиенты»).

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

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

Уровни DFD и декомпозиция

DFD строят по уровням.

Контекстный уровень: система как один процесс.

Уровень 0: крупные процессы системы и основные хранилища.

Уровень 1 и ниже: детализация выбранного процесса до подпроцессов.

Декомпозиция останавливается, когда процесс становится достаточно понятным для реализации и тестирования (то есть известны входы/выходы, правила обработки и взаимодействие с хранилищами).

Правило балансировки

Балансировка (balancing) означает: при детализации процесса на следующий уровень сохраняются его внешние входы и выходы.

То есть:

если процесс на уровне 0 получает поток A и отдает поток B, то на уровне 1, где этот процесс раскрыт подпроцессами, суммарно должны присутствовать те же внешние потоки A и B

нельзя «потерять» вход или выход при детализации

Балансировка — один из самых полезных способов автоматически находить ошибки анализа: потерянные интеграции, забытые входы, «магически появившиеся» данные.

Правила качества DFD

процесс должен иметь хотя бы один вход и хотя бы один выход

поток данных должен иметь источник и получатель

нельзя передавать данные напрямую из внешней сущности во внешнюю сущность, минуя систему (иначе это не взаимодействие с системой)

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

Именование: как сделать диаграммы читаемыми

процессы называются глагольной фразой: «Проверить оплату», «Рассчитать скидку»

хранилища называют существительным во множественном числе: «Заявки», «Клиенты»

потоки называют как состав данных: «Данные заявки», «Статус оплаты»

Пример: DFD для системы обработки заявок

Ниже — пример логики DFD уровня 0. Он показывает, какие крупные функции есть в системе и где лежат данные.

!Пример DFD уровня 0: основные процессы, хранилища и потоки

Пример детализации одного процесса (например, 2.0 «Обработать заявку») на уровень 1 может включать подпроцессы:

принять в работу

назначить исполнителя

изменить статус

закрыть заявку

При этом по правилу балансировки все внешние входы/выходы процесса 2.0 должны «сохраниться» на его диаграмме уровня 1.

Словарь данных

Зачем нужен словарь данных

Словарь данных (data dictionary) — это спецификация смыслов и структуры данных, которые встречаются в DFD.

Он нужен, чтобы:

устранить неоднозначность потоков (что именно входит в «Данные заявки»)

зафиксировать единые определения терминов и атрибутов

обеспечить согласованность моделей (DFD, требования, будущая ER-модель)

упростить проектирование БД, интерфейсов и тестов

Справочно: Data dictionary.

Что описывают в словаре данных

Обычно в словаре фиксируют определения для:

потоков данных

структур сообщений (составных данных)

элементов данных (отдельных полей)

хранилищ данных

при необходимости: бизнес-правил валидации данных (в связке с требованиями)

Минимальный шаблон записи

Ниже пример минимально достаточного набора полей для описания элемента или структуры данных.

| Поле | Что означает | Пример | |---|---|---| | Идентификатор | уникальный код для трассируемости | DD-FLOW-01 | | Название | короткое имя | Данные заявки | | Описание | смысл в предметной области | Набор данных, вводимых при регистрации заявки | | Состав | перечень полей или вложенных структур | Номер, Дата, Клиент, Тема, Канал, Приоритет | | Формат/тип | типы, ограничения длины | строка до 200, дата, справочник | | Источник/получатель | откуда приходит и куда уходит | Клиент → 1.0 | | Правила | проверки и ограничения | Тема обязательна; Канал из справочника |

Пример фрагмента словаря данных

| Идентификатор | Название | Состав | Правила | |---|---|---| | DD-FLOW-01 | Данные заявки | Телефон, Тема, Описание, Канал, Желаемая дата | Телефон обязателен; Канал ∈ {сайт, телефон, офис} | | DD-ELEM-03 | Телефон | — | Хранить в международном формате, без пробелов; уникальность не требуется | | DD-STORE-01 | Заявки | Номер заявки, Дата, Клиент, Статус, Исполнитель | Номер заявки уникален |

Важно: словарь данных — это не обязательно «огромный документ». На практике он может быть таблицей в репозитории требований, wiki-страницей или сущностями в CASE-инструменте. Критично не место хранения, а единые определения и версионность.

Как связать контекст, DFD и словарь данных с требованиями

Связь с требованиями лучше делать явной.

Для каждого крупного процесса DFD уровня 0 зафиксировать, какие требования он реализует.

Для каждого потока данных в DFD иметь запись в словаре данных.

Для каждого хранилища данных понимать, какие требования к данным и хранению к нему относятся (сроки хранения, аудит, права доступа).

Так появляется трассируемость из темы про требования: требование → процесс/поток/хранилище → проектирование БД и интерфейсов → тесты.

Проверки согласованности (что полезно сделать до проектирования БД и ПО)

Ниже — практичные проверки, которые обычно дают быстрый эффект.

Проверка балансировки между уровнями.

Проверка «нет магии»: данные не возникают без источника.

Проверка полноты: все внешние сущности из контекста участвуют в DFD уровня 0.

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

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

Итоги

Контекстная диаграмма фиксирует границы системы и основные внешние взаимодействия.

DFD описывает функции, потоки данных, хранилища и внешние сущности и поддерживает декомпозицию по уровням.

Правило балансировки защищает от потери входов/выходов при детализации.

Словарь данных делает потоки и хранилища однозначными и связывает структурные модели с требованиями, будущей БД, интерфейсами и тестами.

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

Структурное проектирование: ER-модели и нормализация

Как эта тема связана с предыдущими

В структурном анализе мы описывали систему через функции и потоки данных: строили контекст, DFD и уточняли состав потоков и хранилищ в словаре данных. Следующий логичный шаг структурного подхода — перейти от описания движения информации к описанию структуры хранения информации.

Здесь появляются два ключевых инструмента:

ER-модель (модель сущность–связь) — показывает, какие данные существуют в предметной области и как они связаны.

Нормализация — помогает сделать структуру данных устойчивой: уменьшить дублирование и избежать типовых ошибок при обновлениях.

ER-моделирование особенно полезно, когда система является данно-ориентированной: учет, заявки, заказы, финансы, склад, кадры.

Справочно:

Entity–relationship model

Database normalization

Что такое ER-модель

ER-модель — это логическое представление данных предметной области через:

сущности (что мы храним)

атрибуты (какие свойства храним)

связи (как сущности связаны между собой)

ограничения (уникальность, обязательность, кардинальности)

Важно: ER-модель отвечает на вопрос что хранить и как это связано, но не привязана к конкретной СУБД и типам данных на уровне VARCHAR(200) или индексов. Это логический уровень проектирования из предыдущей темы про методологии.

Термины ER-моделирования

Сущность

Сущность — объект предметной области, про который нужно хранить данные.

Примеры:

Клиент

Заявка

Сотрудник

Платеж

Практическое правило: если объект имеет самостоятельный смысл, жизненный цикл и набор атрибутов, он часто становится сущностью.

Атрибут

Атрибут — свойство сущности.

Примеры атрибутов сущности Клиент:

ФИО

Телефон

Email

Дата регистрации

Атрибуты должны соответствовать словарю данных: если в словаре определено поле Телефон и его правила (формат, обязательность), эти правила должны быть согласованы с моделью.

Связь

Связь — ассоциация между сущностями.

Примеры:

Клиент создает Заявку

Сотрудник обрабатывает Заявку

Заявка имеет Историю изменений

Связи часто соответствуют потокам и операциям из DFD: если в DFD есть процесс «Зарегистрировать заявку» и хранилище «Заявки», в ER-модели почти наверняка будет сущность Заявка и связь с инициатором (например, Клиент).

Кардинальность и обязательность

Связь обычно характеризуют двумя свойствами:

кардинальность: сколько объектов может быть связано

обязательность: обязательно ли наличие связи

Типовые кардинальности:

1:1: один к одному

1:N: один ко многим

M:N: многие ко многим

Пример смысла:

Клиент → Заявка: часто 1:N (у клиента может быть много заявок)

Заявка → Клиент: часто N:1 (каждая заявка относится к одному клиенту)

Обязательность описывает, может ли запись существовать без связи.

если заявка не может быть без клиента, то связь обязательная

если заявка может быть без назначенного исполнителя (пока не взяли в работу), то связь с исполнителем необязательная

Идентификатор и ключи

Чтобы ссылаться на конкретный объект сущности, используют идентификатор.

В реляционной модели идентификатор обычно реализуют как первичный ключ.

Типы ключей, которые важно различать:

естественный ключ — реальный атрибут предметной области (например, ИНН, Email, Номер договора)

суррогатный ключ — технический идентификатор (например, ClientId как целое число или UUID)

Практическая рекомендация:

естественный ключ хорош, когда он действительно стабилен и гарантированно уникален

суррогатный ключ удобен для связей и миграций, но не отменяет уникальные ограничения на бизнес-поля (например, ИНН может быть уникальным даже при наличии ClientId)

Как перейти от DFD и словаря данных к ER-модели

ER-модель не рисуется «из воздуха». Самый надежный путь — извлечь сущности и правила из уже сделанных артефактов.

Источники для ER-модели

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

DFD уровня 0 и ниже: показывает, какие данные создаются, читаются, обновляются, используются

словарь данных: дает точные определения полей, структур и бизнес-правил

требования: уточняют обязательность, сроки хранения, аудит, права

Практический алгоритм построения ER-модели

Выписать кандидатов в сущности.

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

Определить идентификаторы и уникальные бизнес-ограничения.

Найти связи между сущностями и их кардинальности.

Отдельно разобрать связи M:N и сложные случаи.

Проверить модель через сценарии и процессы из DFD.

Согласовать термины с глоссарием и словарем данных.

Сложные места, где часто ошибаются

Связь многие-ко-многим

Связь M:N означает, что:

одному объекту сущности A соответствует много объектов сущности B

и одновременно одному объекту сущности B соответствует много объектов сущности A

Пример:

Заявка может иметь несколько Тегов

один Тег может быть у многих Заявок

В реляционных БД связь M:N обычно реализуют через промежуточную сущность (ассоциативную таблицу), например ЗаявкаТег.

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

Повторяющиеся группы и множественные значения

Если у Клиента может быть несколько телефонов, то атрибут Телефон1, Телефон2, Телефон3 — плохой признак. Обычно нужна отдельная сущность Контакт или Телефон клиента.

Это напрямую связано с нормализацией: повторяющиеся группы усложняют валидацию, поиск и изменения.

Справочники и статусы

Статусы, каналы, типы заявок часто полезно выделять в отдельные сущности-справочники:

чтобы ограничить допустимые значения

чтобы хранить дополнительные атрибуты (порядок, описание, признак конечного статуса)

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

Сквозной пример: ER-модель для системы обработки заявок

Возьмем пример, который уже встречался в DFD: система обработки заявок клиентов.

Кандидаты в сущности

Клиент

Заявка

Сотрудник

СтатусЗаявки (справочник)

ИсторияСтатусаЗаявки (событийная сущность)

Пример связей

Клиент 1:N Заявка

Сотрудник 1:N Заявка (если в каждый момент времени у заявки один ответственный)

Заявка 1:N ИсторияСтатусаЗаявки

СтатусЗаявки 1:N ИсторияСтатусаЗаявки

!Пример логической ER-модели для заявок с ключевыми сущностями и кардинальностями

Проверка модели через требования и DFD

Полезные вопросы для самопроверки модели на согласованность с DFD и требованиями:

какой процесс создает Заявку и какие поля обязательны при создании

кто имеет право менять статус и нужно ли журналирование

может ли заявка быть без исполнителя и до какого момента

требуется ли хранить историю изменения полей, а не только статуса

Нормализация: зачем она нужна

Нормализация — набор правил, которые помогают организовать данные так, чтобы:

не дублировать одно и то же в разных местах

избежать аномалий добавления, обновления и удаления

сделать данные согласованными и поддерживаемыми

Типовые проблемы ненормализованной структуры:

аномалия обновления: один и тот же телефон клиента хранится в 50 строках, обновили в 49

аномалия вставки: нельзя добавить нового клиента, пока нет заявки

аномалия удаления: удалили последнюю заявку клиента и «потеряли» данные клиента

Справочно: Database normalization

Нормальные формы простыми словами

Ниже — практическая интерпретация. На реальных проектах часто достаточно уверенно держаться до третьей нормальной формы.

Первая нормальная форма

Первая нормальная форма (1NF) означает:

в ячейке хранится одно значение

нет списков в одном поле

нет повторяющихся групп типа Телефон1, Телефон2

Пример нарушения 1NF:

поле Телефоны со значением +79990000000; +79991111111

Обычно это исправляется выделением отдельной сущности.

Вторая нормальная форма

Вторая нормальная форма (2NF) важна, когда первичный ключ составной. Смысл:

неключевые атрибуты должны зависеть от всего ключа, а не от его части

На практике в прикладных ИС составные ключи часто встречаются в таблицах связей (например, ЗаявкаТег), и там особенно важно не «прилеплять» атрибуты, которые относятся только к заявке или только к тегу.

Третья нормальная форма

Третья нормальная форма (3NF) в практической формулировке:

неключевые атрибуты должны зависеть только от ключа и не зависеть от других неключевых атрибутов

Пример типовой ошибки:

в таблице Заявка хранить ClientEmail и ClientName вместе с ClientId

Здесь ClientEmail и ClientName логически зависят от клиента, а не от заявки. Правильнее хранить эти данные в Клиент, а в Заявка — ссылку ClientId.

Справочно: Third normal form

BCNF как усиление 3NF

Иногда 3NF недостаточно, и применяют нормальную форму Бойса–Кодда (BCNF).

Практически это требуется реже, но полезно знать, что:

BCNF строже и сильнее защищает от некоторых редких аномалий, связанных с зависимостями и уникальностями

Справочно: Boyce%E2%80%93Codd normal form

Пример нормализации: от «все в одной таблице» к устойчивой структуре

Исходная (проблемная) таблица

Представим, что кто-то предложил хранить заявки так:

| TicketId | TicketDate | TicketTheme | ClientName | ClientPhone | EmployeeName | StatusName | |---|---|---|---|---|---|---| | 101 | 2026-01-10 | Не работает интернет | Иванов И.И. | +79990000000 | Петров П.П. | В работе | | 102 | 2026-01-11 | Плохой сигнал | Иванов И.И. | +79990000000 | Сидоров С.С. | Новая |

Проблемы:

данные клиента дублируются во всех заявках

нельзя гарантировать единообразие имени сотрудника

смена телефона клиента требует обновления множества строк

Нормализованный вариант (идея результата)

Разделяем на сущности и связи:

Клиент(ClientId, Name, Phone, ...)

Сотрудник(EmployeeId, Name, ...)

Статус(StatusId, Code, Name, ...)

Заявка(TicketId, TicketDate, Theme, ClientId, AssigneeId, CurrentStatusId, ...)

!Иллюстрация, как нормализация убирает дублирование и вводит ссылки

Что это дает

изменение телефона клиента делается в одном месте

справочник статусов становится управляемым

легче обеспечить целостность: заявка не может ссылаться на несуществующего клиента

проще делать аналитику: сколько заявок по статусам, по исполнителям, по клиентам

Когда нормализацию специально ослабляют

Иногда в системах сознательно делают денормализацию — добавляют производные поля или дублируют данные.

Причины:

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

необходимость хранить «снимок на момент» (например, адрес клиента на дату заказа)

упрощение интеграций или витрин данных

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

Чек-лист качества ER-модели перед переходом к физической схеме

у каждой сущности определен идентификатор и уникальности

атрибуты согласованы со словарем данных

связи имеют кардинальность и обязательность

связи M:N преобразованы в ассоциативные сущности там, где это нужно

нет повторяющихся групп и списков в одном атрибуте

модель проверена сценариями: создание, изменение, поиск, закрытие, аудит

Итоги

ER-модель переводит результаты структурного анализа в логическую структуру данных: сущности, атрибуты, связи и ограничения.

DFD и словарь данных — надежная основа для построения ER-модели и проверки ее полноты.

Нормализация уменьшает дублирование и защищает от аномалий вставки, обновления и удаления.

В большинстве прикладных ИС хорошая цель — уверенная структура на уровне 3NF, а денормализация допускается как контролируемое исключение.

Проектирование программного обеспечения: архитектура и интерфейсы

Место темы в курсе

В предыдущих темах мы последовательно построили основу проектирования ИС:

определили роль проектирования в жизненном цикле

научились формулировать и специфицировать требования

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

выполнили структурный анализ через контекст, DFD и словарь данных

спроектировали информационное обеспечение через ER-модель и нормализацию

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

Эта тема отвечает на два ключевых вопроса:

архитектура: как разложить систему на части и распределить ответственность

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

Базовые понятия: что именно мы проектируем

Архитектура программного обеспечения

Архитектура ПО описывает ключевые решения о структуре системы:

какие компоненты существуют

как они взаимодействуют

где проходят границы ответственности

какие принципы обеспечивают нефункциональные требования

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

Справочно: Software architecture.

Компонент, модуль, сервис

Чтобы не путаться, полезно договориться о терминах.

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

Компонент: более крупная единица разбиения с явным интерфейсом и ответственностью (например, подсистема биллинга).

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

Практическое правило: если вы не можете коротко сказать, за что отвечает часть системы, значит граница выбрана плохо.

Интерфейс и контракт

Интерфейс описывает, как одна часть системы может быть использована другой частью.

Контракт усиливает интерфейс, добавляя проверяемые условия:

какие входные данные допустимы

какие выходные данные гарантируются

какие ошибки возможны

какие ограничения действуют (права, лимиты, время ответа)

Для внешних интеграций контракт обычно оформляют как спецификацию API, например через OpenAPI Specification.

От каких артефактов зависит архитектура

Архитектура и интерфейсы не проектируются изолированно. Они опираются на уже созданные артефакты.

Требования

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

DFD и декомпозиция процессов

Словарь данных

ER-модель и ограничения данных

Типовая ошибка: начинать архитектуру с выбора технологий (например, "микросервисы"), не привязав это к требованиям, потокам данных и качественным характеристикам.

От требований к архитектуре: качества, которые задают форму решения

Функциональные требования отвечают на вопрос что делать. Но архитектуру сильнее всего формируют нефункциональные требования.

Частые архитектурно значимые требования:

производительность и задержки

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

доступность и отказоустойчивость

безопасность и аудит

сопровождаемость и скорость изменений

интеграции и совместимость

Чтобы не оставлять эти свойства «в воздухе», удобно фиксировать для них измеримые критерии (например, целевое время ответа и ожидаемую нагрузку) и связывать их с проектными решениями.

Справочно о модели качества: ISO/IEC 25010.

Архитектурные представления и документация

Архитектуру важно описывать так, чтобы разные участники видели систему на нужном уровне.

Модель C4 как удобная структура описания

Практичный способ описывать архитектуру по уровням детализации дает C4 model:

контекст: кто и как взаимодействует с системой

контейнеры: крупные исполняемые части (приложение, БД, брокер сообщений)

компоненты: крупные части внутри контейнера

код: детали реализации (обычно уже на уровне разработки)

Справочно: C4 model.

!Пример того, как описывать архитектуру от контекста к контейнерам

Архитектурные решения как управляемые записи

Сильная практика для управляемости архитектуры: фиксировать ключевые решения как ADR.

что решили

почему

какие альтернативы рассматривали

какие последствия у решения

Справочно: Architecture decision record.

Декомпозиция: как выделять компоненты

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

Ниже несколько способов, которые часто комбинируют.

Декомпозиция по бизнес-возможностям

Компоненты выделяют вокруг крупных бизнес-функций, которые видны в DFD уровня 0.

Пример для системы заявок:

управление заявками

управление клиентами

справочники и статусы

уведомления

отчетность

Связь с DFD полезна как проверка: почти каждый крупный процесс DFD должен «приземляться» в компонент или модуль.

!Иллюстрация перехода от структурного анализа к архитектурной декомпозиции

Декомпозиция по данным и ответственности

ER-модель подсказывает, где у данных единый жизненный цикл и владелец.

Примеры:

данные Клиента управляются компонентом клиентского учета

данные Заявки управляются компонентом обработки заявок

справочники статусов управляются отдельным компонентом или общим справочником

Практическое правило: если два компонента постоянно спорят, кто «главный» за сущность, значит границы ответственности выбраны плохо.

Слоистая структура внутри приложения

Даже если система развертывается как один продукт, внутри полезно разделять слои ответственности.

Типовой вариант:

слой представления: UI, API-контроллеры

прикладной слой: сценарии, оркестрация операций

доменный слой: бизнес-правила

инфраструктурный слой: доступ к БД, внешним сервисам, очередям

Это не «единственно верно», но помогает не смешивать в одном месте интерфейсы, бизнес-логику и доступ к данным.

Справочно: Layered architecture.

Выбор архитектурного стиля: монолит, модульный монолит, микросервисы

Выбор стиля влияет на скорость разработки, операционную сложность и устойчивость к изменениям.

Сравнение подходов

| Подход | Суть | Когда часто разумно | Основной риск | |---|---|---|---| | Монолит | одно приложение, единое развертывание | небольшая команда, быстрое развитие, умеренные интеграции | разрастание в «комок» без модульности | | Модульный монолит | один деплой, но строгие внутренние границы модулей | нужна простота эксплуатации, но важна управляемость изменений | границы модулей формальны, а зависимости «протекают» | | Микросервисы | независимые сервисы, сетевые интерфейсы | много команд, разные темпы развития частей, высокая нагрузка на отдельные модули | сложность эксплуатации, распределенные ошибки |

Справочно о микросервисах: Microservices.

Практические критерии выбора

Сколько независимых команд будет развивать систему

Насколько различаются требования к масштабированию частей системы

Насколько критична независимая поставка изменений

Есть ли зрелая эксплуатация: мониторинг, логирование, CI/CD

Если уверенности нет, модульный монолит часто безопаснее как стартовая точка.

Проектирование интерфейсов

Интерфейсы делятся на внутренние и внешние.

внутренние интерфейсы отделяют модули внутри приложения

внешние интерфейсы соединяют систему с внешними системами и клиентами

Внешние API: что должно быть в контракте

Минимально полезный контракт внешнего API должен определять:

операции и ресурсы

форматы запросов и ответов

коды ошибок и структуру ошибок

правила аутентификации и авторизации

ограничения: лимиты, таймауты, размеры сообщений

версионирование и совместимость

Для REST-подхода часто ориентируются на понятия ресурса и стандартные методы.

Справочно: Representational state transfer.

Идемпотентность и повторные запросы

В интеграциях всегда возможны повторы запросов из-за сетевых сбоев.

Идемпотентная операция дает один и тот же результат при повторном выполнении с теми же параметрами.

Практический смысл:

GET обычно идемпотентен

PUT часто проектируют идемпотентным

POST часто неидемпотентен, поэтому полезен идемпотентный ключ (например, Idempotency-Key), если это важно для бизнеса

Версионирование API

Изменения контрактов неизбежны, поэтому нужно заранее выбрать правила.

Частые варианты:

версия в URL: /api/v1/...

версия в заголовке

совместимые изменения без смены версии: добавление полей при соблюдении обратной совместимости

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

Асинхронные интерфейсы и события

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

Плюсы асинхронности:

сглаживание нагрузки

меньше связность по времени

возможность ретраев и гарантированной доставки

Минусы:

сложнее отладка и трассировка

нужно проектировать обработку повторов и порядок сообщений

Для документирования событийных контрактов применяют спецификации, например AsyncAPI.

Интеграционные решения: как выбрать стиль взаимодействия

Ниже упрощенная матрица для выбора.

| Ситуация | Часто подходит | Почему | |---|---|---| | нужен мгновенный ответ пользователю | синхронный API | можно сразу показать результат | | внешний сервис нестабилен | очередь и обработка в фоне | система меньше зависит от доступности внешнего сервиса | | важна гарантированная доставка | брокер сообщений | легче обеспечить повторы и подтверждения | | много потребителей изменений | события домена | один источник публикует, многие подписываются |

Независимо от стиля, интерфейс должен быть связан со словарем данных: термины и поля должны иметь единые определения.

Данные и границы: транзакции, согласованность, владение

На этапе архитектуры важно решить, как компоненты делят данные.

Владелец данных

Владелец данных определяет:

кто имеет право изменять сущность

кто отвечает за целостность

кто публикует изменения наружу

Если все компоненты напрямую пишут в одну и ту же таблицу, границы ответственности размываются и система становится хрупкой.

Согласованность между компонентами

В распределенных решениях транзакции «через сеть» становятся дорогими и сложными.

Практичные подходы:

предпочитать локальные транзакции внутри компонента

синхронизировать состояние через события

проектировать компенсации для бизнес-ошибок, если требуется цепочка действий

Справочно о подходе с компенсациями: Saga pattern.

Трассируемость: как связать требования, модели и интерфейсы

Чтобы архитектура не превратилась в набор «красивых картинок», нужно сохранить трассируемость.

Управляемая цепочка выглядит так:

Требование

Процесс DFD

Компонент или модуль

Интерфейс и контракт

Тест (в том числе интеграционный)

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

Минимальный комплект артефактов результата

Набор зависит от масштаба проекта, но как минимум обычно полезны:

диаграмма контекста и контейнеров архитектуры

описание основных компонентов и их ответственности

список внешних интерфейсов с ссылками на спецификации

словарь основных сообщений и ошибок, согласованный со словарем данных

перечень ключевых архитектурных решений (ADR)

Частые ошибки в проектировании архитектуры и интерфейсов

подмена требований технологией: выбор стиля без обоснования качественными требованиями

отсутствие явного владельца данных и «общая база для всех» без правил

неописанные ошибки API и отсутствие стандартного формата ошибок

игнорирование повторов сообщений и запросов в интеграциях

контракты не связаны со словарем данных, термины расходятся

отсутствие версионирования и стратегии совместимости

Итоги

Архитектура ПО определяет структуру системы, границы ответственности и способы удовлетворить нефункциональные требования.

DFD и ER-модель дают надежные подсказки для декомпозиции на компоненты и определения владения данными.

Интерфейсы должны быть оформлены как контракты: форматы, ошибки, безопасность, ограничения, совместимость.

Выбор стиля (монолит, модульный монолит, микросервисы) должен быть обоснован контекстом проекта и зрелостью эксплуатации.

Трассируемость "требование → процесс → компонент → интерфейс → тест" делает архитектуру управляемой при изменениях.

Документирование проекта ИС и контроль качества

Зачем документировать проект ИС

Проектирование информационной системы (ИС) в предыдущих темах курса шло по цепочке:

требования

структурный анализ: контекст, DFD, словарь данных

структурное проектирование: ER-модель и нормализация

проектирование ПО: архитектура и интерфейсы

Чтобы все эти результаты превратились в управляемый проект, нужны два «сквозных» механизма:

документирование: фиксирует решения, термины, модели и договоренности так, чтобы ими могли пользоваться разработка, тестирование, внедрение и сопровождение

контроль качества: гарантирует, что артефакты непротиворечивы, проверяемы и действительно соответствуют требованиям

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

Полезные ориентиры по процессам жизненного цикла и работам по обеспечению качества дает стандарт ISO/IEC/IEEE 12207.

Основные понятия

Артефакт проекта — любой результат работы, который можно сохранить, согласовать, версионировать и проверить: документ, диаграмма, таблица, спецификация API, протокол решения.

Версия — зафиксированное состояние артефакта во времени.

Базовая линия (baseline) — утвержденная версия набора артефактов, относительно которой оцениваются изменения.

Верификация — проверка того, что артефакт сделан правильно относительно спецификаций и стандартов.

Валидация — проверка того, что мы делаем то, что нужно бизнесу и пользователям.

Связка простая:

верификация отвечает на вопрос «соответствует ли реализация и проектирование спецификациям»

валидация отвечает на вопрос «закрывает ли решение реальную потребность»

Принципы хорошей документации

Документация как часть коммуникации

Документация нужна, чтобы:

закреплять единое понимание терминов и границ системы

снижать риск «устных договоренностей», которые не доживают до разработки или тестирования

обеспечить трассируемость: требование → модель → решение → тест

ускорять ввод новых участников в проект

Достаточность, а не максимальный объем

Типовая ошибка — измерять качество документации количеством страниц.

Правильнее измерять:

проверяемость: можно ли по артефактам построить тесты и принять результат

однозначность: не требует ли документ постоянных устных пояснений

актуальность: синхронизированы ли документы с текущей версией системы

Единые термины и единое «место правды»

Если термин Клиент в требованиях означает одно, а в словаре данных или ER-модели другое, система неизбежно будет собрана «с перекосом». Поэтому важно:

иметь глоссарий терминов

иметь словарь данных, связанный с интерфейсами и БД

избегать дублирования описаний без явной синхронизации

Какие документы обычно нужны в проекте ИС

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

Документы уровня целей и контекста

Концепция и границы системы: что входит в ИС и что не входит, кто пользователи, какие внешние системы.

Контекстная диаграмма: внешние сущности и ключевые потоки данных.

Документы требований

Спецификация требований: функциональные, нефункциональные, ограничения.

Критерии приемки: условия, при которых функциональность считается выполненной.

Матрица трассируемости: связь требований с моделями, интерфейсами и тестами.

Ориентир по структуре и качеству требований: ISO/IEC/IEEE 29148.

Документы анализа и данных

DFD: процессы, потоки, хранилища.

Словарь данных: определения потоков, структур, полей, правил.

ER-модель: сущности, атрибуты, связи, ограничения.

Правила данных: обязательность, уникальности, сроки хранения, аудит, требования к качеству данных.

Документы архитектуры и интерфейсов

Архитектурное описание: компоненты, ответственность, взаимодействия, ключевые нефункциональные решения.

Решения архитектуры (ADR): записи о том, что выбрано и почему.

Спецификации интеграций: внешние и внутренние контракты.

Для API де-факто стандартом описания REST-контрактов является OpenAPI Specification.

Документы качества, тестирования и эксплуатации

План тестирования и стратегия тестов: виды тестов, уровни, ответственность.

Тест-кейсы и результаты прогонов.

Набор нефункциональных проверок: нагрузка, безопасность, отказоустойчивость.

Эксплуатационная документация: развертывание, мониторинг, резервное копирование, реагирование на инциденты.

Как связать документы в единую систему артефактов

Главная проблема документации не в том, что ее «мало», а в том, что она существует разрозненно и не связана.

Ниже — минимальная схема связности:

Требования имеют идентификаторы: REQ-...

Процессы DFD связаны с требованиями: DFD-PROC-... → REQ-...

Потоки и поля в словаре данных имеют идентификаторы: DD-...

ER-сущности и атрибуты ссылаются на словарь данных: ENTITY.Client.phone → DD-ELEM-Телефон

Интерфейсы API используют те же поля и смыслы: API.CreateClient.phone → DD-ELEM-Телефон

Тесты ссылаются на требования и контракты: TEST-... → REQ-... → API-...

!Иллюстрация показывает, как документы и модели связываются в трассируемую цепочку от целей до тестов и эксплуатации

Матрица трассируемости: как выглядит на практике

Матрица трассируемости может быть таблицей в wiki, в системе управления требованиями или в трекере задач. Важно не место, а наличие устойчивых ссылок.

Пример упрощенной матрицы:

| Требование | Процесс DFD | Данные (словарь/ER) | Интерфейс | Тест | |---|---|---|---|---| | REQ-01 Создание заявки | DFD-P-01 Зарегистрировать заявку | DD-FLOW-01 Данные заявки; ER.Ticket | API POST /tickets | TEST-FT-01 | | REQ-07 Аудит смены статуса | DFD-P-04 Изменить статус | ER.TicketStatusHistory | API POST /tickets/{id}/status | TEST-SEC-03 |

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

Контроль качества документации и моделей

Контроль качества применим не только к коду, но и к требованиям, моделям и спецификациям.

Качество требований

Требования должны быть:

однозначными

проверяемыми

непротиворечивыми

трассируемыми

Если требование нельзя проверить тестом или приемкой, оно не защищает проект от споров.

Качество DFD и структурного анализа

Проверки, которые обычно дают быстрый эффект:

балансировка уровней DFD

отсутствие «магии»: у каждого потока есть источник

корректность связей: нет потоков «внешняя сущность → внешняя сущность» в обход системы

согласованность терминов потоков со словарем данных

Качество ER-модели и данных

Проверки перед переходом к физической схеме:

определены идентификаторы и уникальности

проработаны связи и кардинальности

нет повторяющихся групп и множественных значений в одном поле

правила обязательности согласованы со сценариями

Качество архитектуры и интерфейсов

Минимальные критерии качества интерфейсного контракта:

описаны входы и выходы

описаны ошибки и их формат

описаны права доступа

описаны ограничения: таймауты, лимиты, размеры сообщений

определено версионирование и совместимость

Процесс контроля качества: что делают и когда

Ревью и инспекции

Ревью — основной дешевый способ поймать ошибки до разработки.

Типы ревью:

ревью требований с бизнесом и пользователями

ревью моделей (DFD, ER) с аналитиками и архитекторами

ревью API-контрактов с интеграторами и командой тестирования

ревью архитектурных решений (ADR) с ответственными за эксплуатацию и безопасность

Практическое правило: каждое ревью должно заканчиваться либо утверждением версии, либо списком замечаний, либо решением о переработке.

Контроль изменений и версии артефактов

Чтобы документация не устаревала сразу после согласования, нужен управляемый процесс:

Запрос на изменение: что меняем и почему.

Анализ влияния: какие требования, модели, интерфейсы и тесты затронуты.

Решение: принять, отложить, отклонить.

Обновление версии артефактов и матрицы трассируемости.

Качество через гейты (точки контроля)

Удобная практика — определять «гейты», то есть минимальные критерии качества для перехода к следующей стадии.

Пример логики гейтов:

нельзя начинать детальное проектирование данных, пока не согласованы границы и контекст

нельзя фиксировать API-контракт, пока не согласован словарь данных по ключевым сообщениям

нельзя выпускать релиз, пока не выполнены обязательные тесты и приемка

!Схема показывает, как контроль качества встроить в жизненный цикл через точки допуска

Метрики и чек-листы качества

Метрики не обязаны быть сложными. Цель — сделать качество наблюдаемым.

Примеры практичных показателей:

доля требований с критериями приемки

доля требований, имеющих связь с тестом

число замечаний на ревью по категориям: термины, противоречия, неполнота

доля API-методов со стандартизированным форматом ошибок

Чек-листы полезны как «страховка от забывания». Например:

чек-лист качества требования

чек-лист качества DFD

чек-лист качества ER-модели

чек-лист качества API-контракта

Частые ошибки в документировании и контроле качества

документация существует, но не имеет владельцев и не версионируется

нет единого словаря терминов, поэтому модели и API расходятся по смыслу

требования не проверяемы, нет критериев приемки

матрица трассируемости отсутствует, влияние изменений не видно

ревью делается формально, без фиксации решений и замечаний

эксплуатационные требования (мониторинг, резервное копирование, аудит) появляются слишком поздно

Итоги

Документация в проекте ИС нужна для управляемости: согласование, проверяемость, трассируемость и сопровождение.

Артефакты курса (требования, DFD, словарь данных, ER-модель, архитектура, интерфейсы) должны быть связаны в единую систему.

Контроль качества включает верификацию и валидацию, ревью, управление изменениями и точки контроля качества.

Матрица трассируемости делает изменения управляемыми и связывает требования с моделями, интерфейсами и тестами.

Чем раньше встроен контроль качества артефактов, тем дешевле исправления и тем выше шанс получить принимаемую систему.