Системный анализ для начинающих с нуля

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

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

Содержание урока

• Ожидания заказчика и исполнителя: откуда берётся разное понимание.

• Бизнес-требования, пользовательские требования и требования к системе.

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

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

• Типичные проблемы: противоречия, пропуски и неявные ожидания.

• Жизненный цикл требований и задачи аналитика.

Чему вы научитесь

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

• Отличать описание функции от требований к качеству её работы.

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

Предварительные требования

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

Для кого этот урок

Для тех, кто начинает работать с требованиями и хочет научиться отличать договорённость о результате от общего пожелания.

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

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

Содержание урока

• Стейкхолдеры: кто влияет на требования и зависит от системы.

• Классы пользователей и различия в их задачах.

• Анализ документов, кода, примеров и работы пользователей.

• Интервью, анкетирование, наблюдение, брейнштормы и воркшопы.

• Внешние и внутренние документы как источники требований.

• Проверка источников, структурирование информации и разделение уровней требований.

• Фиксация результатов обсуждений.

Чему вы научитесь

• Определять, у каких участников и в каких источниках искать требования.

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

• Организовывать собранную информацию, не теряя её источник и смысл.

Предварительные требования

Полезно предварительно разобраться в уровнях требований из урока M2L1.

Для кого этот урок

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

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

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

Содержание урока

• Зачем моделировать требования перед проектированием системы.

• Выбор нотации с учётом цели, аудитории и сложности задачи.

• Use case: акторы, цели и взаимодействие с системой.

• Графическое представление вариантов использования.

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

• Фиксация высокоуровневых целей и типичные ошибки согласования.

Чему вы научитесь

• Объяснять, какую задачу решает выбранная модель требований.

• Различать назначение диаграммы use case и подробного описания сценария.

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

Предварительные требования

Полезно знать основные уровни требований и способы их выявления.

Для кого этот урок

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

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

На уроке перейдём от бизнес- и пользовательских требований к системным. Разберём структуру спецификации требований к ПО, роль бизнес-правил, функциональных и нефункциональных требований. Затем обсудим, как проверять требования и поддерживать документацию в актуальном состоянии, когда продукт меняется.

Содержание урока

• Переход от согласованных потребностей к требованиям к системе.

• Функциональные и нефункциональные требования, бизнес-правила.

• Документирование и структура спецификации требований к ПО.

• Требования к данным, интерфейсам, качеству и локализации.

• Верификация, валидация и критерии приёмки.

• Управление версиями, изменениями, статусами и зависимостями требований.

• Ошибки, из-за которых документация перестаёт помогать команде.

Чему вы научитесь

• Ориентироваться в основных разделах спецификации требований к ПО.

• Различать проверку качества требований и проверку их соответствия реальным потребностям.

• Объяснять, как управление изменениями помогает сохранять целостность требований.

Предварительные требования

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

Для кого этот урок

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

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

Познакомимся с концептуальным, логическим и физическим уровнями моделей, а затем разберём ER-диаграммы в нотациях Чена и Мартина. На примерах посмотрим, как обозначать сущности, атрибуты и связи, читать их кратность и выбирать подходящий уровень подробности.

Содержание урока

• Назначение моделей данных и их основные виды.

• Концептуальный, логический и физический уровни.

• Сущности, атрибуты и отношения в ER-модели.

• Нотация Чена: основные элементы и примеры.

• Нотация Мартина — Crow’s Foot: чтение связей и их обязательности.

• Типичные ошибки при построении ER-диаграмм.

Чему вы научитесь

• Различать уровни моделей данных и их назначение.

• Читать основные обозначения ER-диаграмм в двух нотациях.

• Объяснять, как кратность и обязательность связей отражают правила предметной области.

Предварительные требования

Опыт работы с базами данных не нужен. Достаточно базового понимания требований и предметной области.

Для кого этот урок

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

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

Проследим преобразование учебной модели от ненормализованного состояния до третьей нормальной формы. Разберём зависимости атрибутов от ключей и друг от друга, а также ошибки, которые возникают при механическом применении правил. Главное — сохранить бизнес-смысл модели, а не гнаться за максимальным уровнем нормализации.

Содержание урока

• Задачи нормализации и качество логической ER-модели.

• Последовательный переход от 0НФ к 1НФ, 2НФ и 3НФ.

• Разделение данных и устранение лишних зависимостей.

• Первичные ключи и зависимости атрибутов.

• Разбор изменений модели на последовательных примерах.

• Ошибки нормализации и границы необходимой детализации.

Чему вы научитесь

• Объяснять, зачем нормализуют логическую модель данных.

• Различать основные шаги перехода к первым трём нормальным формам.

• Замечать избыточность и зависимости, которые требуют пересмотра структуры модели.

Предварительные требования

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

Для кого этот урок

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

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

Разберём, как он дополняет ER-модель и что стоит указывать для отдельных элементов и составных структур. На примере посмотрим, как описывать типы, длину, допустимые значения, необязательные и повторяющиеся элементы. Обсудим, как сделать словарь удобным для совместной работы.

Содержание урока

• Назначение словаря данных и его связь со спецификацией требований.

• Определения элементов данных и единая терминология.

• Типы, размеры, диапазоны и ограничения значений.

• Простые элементы, составные структуры и правила их записи.

• Пример словаря и рекомендации по его оформлению.

Чему вы научитесь

• Определять, каких сведений о данных не хватает на ER-диаграмме.

• Читать описание простых и составных элементов словаря.

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

Предварительные требования

Полезно базовое знакомство с моделями данных. Знание SQL не требуется.

Для кого этот урок

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

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

Сравним традиционный и объектно-ориентированный подходы к проектированию, затем познакомимся с диаграммами классов и объектов UML. Разберём атрибуты, методы и основные виды связей, а на примерах увидим, как общая модель превращается в описание конкретных объектов.

Содержание урока

• Традиционный и объектно-ориентированный подходы.

• Классы и объекты: шаблон и конкретный экземпляр.

• Уровни детализации модели классов.

• UML Class Diagram: атрибуты, методы и связи.

• Ассоциация, наследование, зависимость, агрегация и композиция.

• UML Object Diagram: значения атрибутов и связи между объектами.

Чему вы научитесь

• Различать класс и объект, диаграмму классов и диаграмму объектов.

• Читать основные элементы UML Class Diagram.

• Объяснять, как диаграммы объектов дополняют общую модель системы.

Предварительные требования

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

Для кого этот урок

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

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

В этом уроке познакомимся с основными типами хранилищ и посмотрим, как в них организованы данные. Разберём файловый подход, реляционные и несколько видов нереляционных БД, а также многомерные и объектно-ориентированные базы. Это обзор для аналитика: чтобы понимать варианты хранения, не погружаясь в администрирование конкретных продуктов.

Содержание урока

• Задачи хранения данных, быстродействие и отказоустойчивость.

• Файловые хранилища и назначение разных групп файлов.

• Реляционные базы данных и табличная структура.

• NoSQL: документы, семейства столбцов, ключ-значение и графы.

• Многомерные и объектно-ориентированные базы данных.

• Примеры технологий и роль аналитика в выборе хранилища.

Чему вы научитесь

• Различать основные способы организации и хранения данных.

• Объяснять базовые отличия реляционных и нереляционных хранилищ.

• Ориентироваться в типах БД при обсуждении требований к системе.

Предварительные требования

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

Для кого этот урок

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

Как выбрать хранилище, если каждый вариант в чём-то хорош? Начать стоит не с популярного названия, а с вопросов о данных, задачах приложения и условиях, в которых будет работать система.

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

Содержание урока

• Типы данных и задачи приложения как основа выбора.

• Транзакционная обработка, аналитика и хранение документов.

• Существующая инфраструктура и совместимость компонентов.

• Наличие специалистов и возможности переиспользования решений.

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

• Компромисс между задачами бизнеса, стоимостью и архитектурой.

Чему вы научитесь

• Формулировать вопросы, с которых начинается выбор хранилища.

• Учитывать не только свойства технологии, но и ограничения организации.

• Объяснять, почему один и тот же вариант подходит не всем системам.

Предварительные требования

Полезно предварительно посмотреть урок M3L5 об основных форматах хранилищ данных.

Для кого этот урок

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

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

Пройдём пять шагов перехода от ER-модели к структуре конкретного хранилища. На одном примере разберём преобразование сущностей и атрибутов, добавление первичных и внешних ключей, служебных полей и таблиц. Проследим, как сохранить смысл исходной модели при её технической детализации.

Содержание урока

• Назначение логической и физической моделей данных.

• Преобразование сущностей в элементы хранилища.

• Поля, типы данных, длина и ограничения.

• Естественные и суррогатные первичные ключи.

• Внешние ключи и связи между таблицами.

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

Чему вы научитесь

• Различать бизнес-структуру данных и детали её хранения.

• Объяснять последовательность построения физической модели.

• Читать в модели типы полей, ограничения и связи через ключи.

Предварительные требования

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

Для кого этот урок

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

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

Обсудим, как нормализация, выбор типов и архивация влияют на объём хранилища, а индексы, денормализация и партиционирование — на скорость работы. Разберём и обратную сторону оптимизаций: выигрыш в одной операции может потребовать дополнительных ресурсов или усложнить другую.

Содержание урока

• Рост данных, ограничения инфраструктуры и стоимость хранения.

• Нормализация, выбор типов и организация таблиц.

• Архивация и правила работы со старыми данными.

• Индексы, денормализация и партиционирование.

• Запросы, кэширование, транзакции и настройки хранилища.

• Роль аналитика в определении нагрузки и требований к производительности.

Чему вы научитесь

• Различать меры по сокращению объёма данных и ускорению доступа к ним.

• Объяснять назначение основных способов оптимизации.

• Замечать компромиссы между скоростью, объёмом хранения и сложностью поддержки.

Предварительные требования

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

Для кого этот урок

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

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

Разберём, чем бизнес-процесс отличается от системного процесса и логики приложения. Отдельно обсудим уровни детализации и модели AS-IS и TO-BE. Вы увидите, почему вид модели и степень её подробности — разные характеристики, которые нужно выбирать осознанно.

Содержание урока

• Процесс: действия, участники, цель и результат.

• Текущее и целевое состояние — AS-IS и TO-BE.

• Модели бизнес-процессов, системных процессов и логики приложения.

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

• Выбор модели под задачу и аудиторию.

Чему вы научитесь

• Различать виды моделей процессов и уровни их подробности.

• Объяснять, зачем описывать и текущее, и целевое состояние.

• Подбирать степень детализации с учётом того, кто будет читать модель.

Предварительные требования

Знание графических нотаций не требуется: урок даёт основу для дальнейшего знакомства с ними.

Для кого этот урок

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

Кто начинает процесс, какое действие следует дальше и в какой момент ответственность переходит к другому участнику? BPMN позволяет показать это на одной диаграмме, не пряча логику в длинном текстовом описании.

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

Содержание урока

• Способы описания бизнес-процессов и место BPMN среди них.

• События, деятельности и шлюзы.

• Потоки последовательности, сообщения и ассоциации.

• Пулы и дорожки: участники и области ответственности.

• Данные, группы и поясняющие аннотации.

• Упрощённый пример BPMN-диаграммы.

Чему вы научитесь

• Узнавать основные элементы BPMN и объяснять их назначение.

• Читать последовательность действий и ветвления в простой диаграмме.

• Различать порядок выполнения шагов и обмен сообщениями между участниками.

Предварительные требования

Полезно знакомство с понятием процесса и уровнями его описания из урока M4L1.

Для кого этот урок

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

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

Для таких задач познакомимся с UML Activity Diagram — диаграммой деятельности. Сравним её назначение с BPMN, разберём основные элементы и посмотрим упрощённый пример. Урок поможет понимать, как на схеме передаётся поведение системы шаг за шагом.

Содержание урока

• Назначение Activity Diagram и сравнение с BPMN.

• Действия, активности, потоки управления и объектные потоки.

• Начало, завершение, условия и объединение ветвей.

• Параллельное выполнение и синхронизация.

• Сигналы, таймеры, распределение ответственности и области прерывания.

• Чтение упрощённого примера диаграммы.

Чему вы научитесь

• Объяснять, для каких задач используют диаграмму деятельности.

• Читать основные обозначения и логику простой Activity Diagram.

• Различать альтернативные и параллельные пути выполнения.

Предварительные требования

Полезно базовое понимание моделей процессов. Знакомство с BPMN облегчит сравнение нотаций.

Для кого этот урок

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

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

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

Содержание урока

• Назначение UML State Machine Diagram.

• Простые и составные состояния.

• Переходы, условия и внутренние действия.

• Триггеры, эффекты и действия при входе и выходе.

• Начальные и конечные состояния, основные псевдосостояния.

• Упрощённый пример статусной модели.

Чему вы научитесь

• Отличать описание процесса от описания жизненного цикла объекта.

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

• Выделять события и ограничения, которые нужно уточнить при описании статусной модели.

Предварительные требования

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

Для кого этот урок

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

Откуда система получает данные, что с ними делает и куда передаёт результат? Эти вопросы требуют другого взгляда, чем описание действий пользователя или шагов бизнес-процесса.

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

Содержание урока

• Назначение модели потоков данных.

• Внешние сущности, процессы, хранилища и потоки.

• Контекстное, логическое и физическое представления.

• Уровни детализации: 0, 1, 2 и глубже.

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

Чему вы научитесь

• Объяснять, что показывает модель потоков данных.

• Различать уровень абстракции и глубину детализации модели.

• Выделять источники, получателей, обработку и хранение данных.

Предварительные требования

Достаточно базового представления о системе, её границах и процессах.

Для кого этот урок

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

Продолжим тему потоков данных и сосредоточимся на самой диаграмме DFD. Её основу составляют всего четыре вида элементов, но вместе они позволяют показать, как информация проходит через систему.

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

Содержание урока

• Назначение Data Flow Diagram.

• Внешние сущности как источники и получатели данных.

• Процессы, преобразующие входные данные в выходные.

• Хранилища для временного и постоянного сохранения информации.

• Потоки данных и связи между элементами.

• Упрощённый пример DFD.

Чему вы научитесь

• Узнавать четыре основных типа элементов DFD.

• Прослеживать движение данных по простой диаграмме.

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

Предварительные требования

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

Для кого этот урок

Для аналитиков, которым нужно читать DFD и объяснять обмен данными между частями системы.

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

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

Содержание урока

• Различия между логической и физической моделями потоков данных.

• Анализ исходной модели и определение технической архитектуры.

• Детализация хранилищ, процессов и каналов передачи.

• Инфраструктура, производительность и масштабирование.

• Безопасность, надёжность и другие нефункциональные требования.

• Тестирование, проверка соответствия и документирование физической модели.

Чему вы научитесь

• Объяснять, какие технические детали появляются при переходе к физической модели.

• Ориентироваться в последовательности её подготовки.

• Выделять ограничения и нефункциональные требования, влияющие на движение данных.

Предварительные требования

Полезно знать основные элементы DFD и различать логические и физические модели.

Для кого этот урок

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

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

Разберём понятия UI и UX, признаки хорошего интерфейса и типичные причины пользовательских затруднений. Посмотрим, кто участвует в создании экранов и за что отвечает системный аналитик: сценарии, данные, проверки и состояния. Урок покажет, почему работа над интерфейсом начинается с понимания пользователя и требований.

Содержание урока

• UI и UX: различия и связь между ними.

• Пользователи, их задачи и контекст работы.

• Признаки качественного интерфейса и частые проблемы.

• Роли аналитика, дизайнера, разработчика и тестировщика.

• Сценарии, поля, проверки и состояния экранов.

• Путь от потребности до интерфейса и основные UI/UX-артефакты.

Чему вы научитесь

• Различать визуальную сторону интерфейса и пользовательский опыт.

• Замечать решения, которые затрудняют выполнение пользовательской задачи.

• Объяснять, какие вопросы интерфейса должен прорабатывать аналитик.

Предварительные требования

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

Для кого этот урок

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

Готовый макет — результат нескольких шагов, каждый из которых отвечает на свой вопрос. Кто будет пользоваться системой? Какие экраны нужны? Как они связаны? Что должно происходить после каждого действия?

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

Содержание урока

• Общая последовательность проектирования интерфейса.

• Подготовка: цели, пользователи, сценарии и ограничения.

• Структура экранов и навигация.

• Lo-Fi, визуальная концепция и Hi-Fi-прототипы.

• Дизайн-система, адаптация и передача решения в разработку.

• Проверка интерфейса и уточнение решений.

• Инструменты проектирования и ошибки на стыке этапов.

Чему вы научитесь

• Ориентироваться в этапах создания UI и их результатах.

• Объяснять, почему структуру и сценарии прорабатывают до визуальных деталей.

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

Предварительные требования

Полезно знакомство с понятиями UI и UX. Владение графическими редакторами не требуется.

Для кого этот урок

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

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

Разберём восемь базовых принципов проектирования UI: от простоты и последовательности до обратной связи и предотвращения ошибок. Посмотрим на них глазами аналитика: какие вопросы задавать при описании экранов, согласовании сценариев и обсуждении прототипов. Для этого не нужно быть дизайнером — нужно понимать, что происходит с пользователем.

Содержание урока

• Простота и понятный пользователю язык.

• Последовательность и предсказуемость поведения.

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

• Предотвращение ошибок и проверки ввода.

• Видимость важных элементов и сокращение лишних шагов.

• Применение принципов при работе с требованиями и прототипами.

Чему вы научитесь

• Объяснять основные признаки понятного интерфейса.

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

• Задавать конкретные вопросы об удобстве сценариев и поведении элементов.

Предварительные требования

Достаточно базового представления об UI/UX и пользовательских задачах.

Для кого этот урок

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

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

На примере оплаты разберём состав пользовательского сценария и отличие User Scenario от формального use case. Проследим, как из действий пользователя появляются экраны и элементы интерфейса. Особое внимание уделим альтернативным и негативным сценариям, которые легко пропустить, если описывать только успешный путь.

Содержание урока

• Пользовательский сценарий: участник, цель, действия и результат.

• Отличие User Scenario от Use Case.

• Основной путь — Happy Path.

• Альтернативные действия и сценарии ошибок.

• Связь сценариев с экранами, User Flow, CJM и прототипами.

• Разбор сценария онлайн-оплаты.

Чему вы научитесь

• Выделять цель пользователя и основные части сценария.

• Различать успешный, альтернативный и негативный пути.

• Объяснять, как сценарий определяет состав и поведение интерфейса.

Предварительные требования

Полезно понимать основы UI/UX и назначение пользовательских требований.

Для кого этот урок

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

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

Познакомимся с Customer Journey Map — CJM. На примере онлайн-оплаты разберём этапы пути, действия, мысли, эмоции и проблемные места. Обсудим, как аналитик использует такую карту, чтобы находить возможности для улучшения и превращать наблюдения в требования к системе.

Содержание урока

• Назначение CJM и отличие от пользовательского сценария.

• Этапы пути, действия, ожидания и эмоции.

• Болевые точки: где и почему возникают трудности.

• Возможности улучшения пользовательского опыта.

• Роль аналитика и связь CJM с другими UI/UX-артефактами.

• Пример карты для онлайн-оплаты.

Чему вы научитесь

• Читать основные части карты пользовательского пути.

• Отличать описание действий от анализа пользовательского опыта.

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

Предварительные требования

Полезно предварительно познакомиться с пользовательскими сценариями из урока M5L4.

Для кого этот урок

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

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

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

Содержание урока

• Назначение Sitemap и момент её появления в проекте.

• Разделы, страницы, связи и иерархия.

• Понятная навигация и точки входа пользователя.

• Типичные ошибки в структуре продукта.

• Участие аналитика в определении экранов и переходов.

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

Чему вы научитесь

• Читать структуру продукта по карте сайта.

• Различать описание навигации и внешний вид экранов.

• Замечать избыточную вложенность и другие проблемы организации разделов.

Предварительные требования

Полезно понимать, что такое пользовательский сценарий. Знание инструментов дизайна не нужно.

Для кого этот урок

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

Проверить идею интерфейса можно раньше, чем появятся фирменные цвета и аккуратные иконки. Для этого достаточно показать состав экрана, основные действия и переходы — в простом Lo-Fi-прототипе.

Разберём, чем такой черновик отличается от Hi-Fi и какие вопросы помогает решить. Посмотрим, как требования, сценарии и карта сайта становятся основой прототипа, а также какие ошибки возникают при его подготовке. Главная задача здесь — быстро обсудить и проверить логику, не тратя время на преждевременную визуальную детализацию.

Содержание урока

• Назначение Lo-Fi и отличие от Hi-Fi.

• Wireframe и набор связанных экранов.

• Структура, навигация и пользовательский поток.

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

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

• Роль аналитика и частые ошибки при подготовке Lo-Fi.

Чему вы научитесь

• Объяснять, какие задачи решает черновой прототип.

• Определять, что стоит показать в Lo-Fi, а что можно пока не детализировать.

• Использовать сценарии и карту сайта как ориентиры при обсуждении прототипа.

Предварительные требования

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

Для кого этот урок

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

На черновой схеме можно проверить логику, но не всегда понятно, как человек воспримет будущий интерфейс. Hi-Fi-прототип приближает его к реальному продукту: добавляет компоненты, тексты, визуальный стиль и интерактивность.

Посмотрим, что меняется при переходе от Lo-Fi к Hi-Fi и какие вопросы теперь можно проверять. Обсудим навигацию, читаемость, состояния элементов и соответствие требованиям. Разберём, что аналитик должен уточнить вместе с дизайнером, прежде чем макеты станут основой для разработки.

Содержание урока

• Назначение Hi-Fi и отличие от чернового прототипа.

• Компоненты, контент и визуальные детали.

• Переходы, кликабельные элементы и интерактивные сценарии.

• Проверка восприятия интерфейса и пользовательских ошибок.

• Состояния загрузки, ошибок, пустых данных и успешного результата.

• Проверка требований и передача макетов в разработку.

Чему вы научитесь

• Различать задачи Lo-Fi- и Hi-Fi-прототипирования.

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

• Замечать, когда красивый макет не раскрывает поведение системы.

Предварительные требования

Полезно посмотреть урок о Lo-Fi-прототипах и понимать основные пользовательские сценарии.

Для кого этот урок

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

Если одинаковые кнопки на разных экранах выглядят и работают по-разному, пользователю приходится заново разбираться с интерфейсом. Команда тоже тратит время на повторное обсуждение уже решённых вопросов.

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

Содержание урока

• Назначение дизайн-системы и её развитие вместе с продуктом.

• Принципы, стили, компоненты и паттерны.

• Повторное использование элементов интерфейса.

• Состояния компонентов и правила их поведения.

• Примеры: Material Design, Apple Human Interface Guidelines и Fluent Design.

• Взаимодействие аналитика, дизайнера и разработчиков.

Чему вы научитесь

• Объяснять, из чего состоит дизайн-система и зачем она команде.

• Учитывать состояния и поведение компонентов при описании требований.

• Замечать ситуации, в которых новое решение дублирует уже существующее.

Предварительные требования

Полезно базовое знакомство с UI и прототипами.

Для кого этот урок

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

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

Познакомимся с юзабилити-, коридорным и A/B-тестированием. Обсудим, что проверять на Lo-Fi, Hi-Fi и в готовом продукте, какие задачи давать пользователю и какие показатели отслеживать. Разберём роль аналитика в подготовке сценариев и превращении результатов проверки в уточнённые требования.

Содержание урока

• Цели тестирования UI/UX на разных этапах.

• Проверка навигации, форм, сценариев и текстов.

• Юзабилити-тестирование и наблюдение за пользователем.

• Коридорные проверки и A/B-тестирование.

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

• Подготовка сценариев, анализ результатов и частые ошибки проверки.

Чему вы научитесь

• Различать назначение основных методов тестирования UI/UX.

• Формулировать, какую пользовательскую задачу и результат нужно проверить.

• Объяснять, как наблюдения и метрики помогают уточнять требования к интерфейсу.

Предварительные требования

Полезно понимать пользовательские сценарии и различия между Lo-Fi и Hi-Fi. Опыт профессионального тестирования не требуется.

Для кого этот урок

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

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

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

Содержание урока

• Архитектура: компоненты, взаимодействия, инфраструктура и требования.

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

• UML, C4 и текстовая документация.

• Архитектурные стили и шаблоны проектирования.

• Примеры подходов и выбор инструмента описания.

• Участие системного аналитика в архитектурной работе.

Чему вы научитесь

• Объяснять назначение основных архитектурных представлений.

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

• Понимать, какие требования и сведения аналитик передаёт для принятия архитектурных решений.

Предварительные требования

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

Для кого этот урок

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

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

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

Содержание урока

• Функциональные, технические и пользовательские компоненты.

• Логические модули и подсистемы.

• Серверы, сети и клиентские устройства.

• Данные, хранилища и интеграционные механизмы.

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

• Интерфейсы, зависимости и границы ответственности.

Чему вы научитесь

• Различать основные группы компонентов системы.

• Объяснять, за что отвечают отдельные части решения.

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

Предварительные требования

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

Для кого этот урок

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

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

Разберём роли клиента и сервера, распределение логики и данных, а также двух-, трёх- и многоуровневые варианты организации системы. Посмотрим на преимущества подхода и его ограничения: зависимость от доступности сервера, рост нагрузки и необходимость масштабирования. Свяжем эти вопросы с требованиями, которые прорабатывает аналитик.

Содержание урока

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

• Разделение ответственности и централизованное управление данными.

• Двухуровневая, трёхуровневая и многоуровневая архитектура.

• Преимущества и ограничения подхода.

• Примеры веб-, мобильных и корпоративных систем.

• Требования к скорости, безопасности и взаимодействию сторон.

Чему вы научитесь

• Определять роли клиента и сервера в простой схеме взаимодействия.

• Различать основные варианты клиент-серверной архитектуры.

• Объяснять, как распределение ответственности влияет на требования к системе.

Предварительные требования

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

Для кого этот урок

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

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

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

Содержание урока

• Аппаратные, программные, сетевые компоненты и инфраструктура данных.

• Одноуровневая, многоуровневая и распределённая организация.

• Масштабируемость, отказоустойчивость, производительность и безопасность.

• Физические и облачные серверы.

• Виртуализация, контейнеризация и примеры реализации.

• Роль аналитика в формировании требований к серверной части.

Чему вы научитесь

• Ориентироваться в основных элементах серверной архитектуры.

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

• Выделять требования к серверной части, которые важно уточнить заранее.

Предварительные требования

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

Для кого этот урок

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

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

Разберём основные компоненты мобильного приложения и требования к ним. Познакомимся с MVC, MVVM и Clean Architecture, особенностями iOS и Android, локальными и удалёнными данными. Обсудим, какие вопросы производительности, безопасности и взаимодействия с backend должен учитывать аналитик.

Содержание урока

• Компоненты мобильного приложения и их ответственность.

• Производительность, энергоэффективность и другие требования.

• Варианты организации приложения и архитектурные паттерны.

• Особенности iOS, Android и кроссплатформенных решений.

• Локальное хранение, удалённые данные и кэширование.

• Безопасность и взаимодействие между слоями приложения.

Чему вы научитесь

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

• Объяснять назначение основных архитектурных паттернов на обзорном уровне.

• Учитывать особенности мобильной платформы при обсуждении требований.

Предварительные требования

Полезно знакомство с клиент-серверной архитектурой. Знание Swift, Kotlin и мобильной разработки не требуется.

Для кого этот урок

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

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

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

Содержание урока

• Принцип разделения ответственности.

• Презентационный слой, бизнес-логика и слой данных.

• Интерфейсы и зависимости между слоями.

• Преимущества для разработки, тестирования и сопровождения.

• Примеры организации и инструменты реализации.

• Задачи аналитика при описании многослойной системы.

Чему вы научитесь

• Различать назначение типовых слоёв приложения.

• Объяснять, зачем отделять бизнес-логику от интерфейса и хранения данных.

• Прослеживать взаимодействие слоёв на простой архитектурной схеме.

Предварительные требования

Полезно понимать основные компоненты системы и принцип клиент-серверной архитектуры.

Для кого этот урок

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

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

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

Содержание урока

• Сервис как единица бизнес-функциональности.

• Переиспользование, слабая связанность и скрытие деталей реализации.

• Поставщики, потребители, реестр сервисов и коммуникационная шина.

• Примеры SOA в банковских и корпоративных системах.

• Преимущества, ограничения и инструменты реализации.

• Границы сервисов, взаимодействия и документация.

Чему вы научитесь

• Объяснять основные принципы сервис-ориентированной архитектуры.

• Различать роли компонентов SOA.

• Выделять вопросы о сервисных границах и взаимодействии, которые важно согласовать.

Предварительные требования

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

Для кого этот урок

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

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

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

Содержание урока

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

• API Gateway, коммуникации и хранилища данных.

• Сравнение микросервисов, монолита и SOA.

• Независимое развитие и масштабирование: возможности и цена.

• Контейнеризация, оркестрация, очереди и мониторинг.

• Границы сервисов, контракты и задачи аналитика.

Чему вы научитесь

• Объяснять основные особенности микросервисной архитектуры.

• Сопоставлять её преимущества со сложностью распределённого взаимодействия.

• Выделять вопросы об ответственности, данных и интерфейсах сервисов.

Предварительные требования

Полезно предварительно познакомиться с клиент-серверным и сервис-ориентированным подходами.

Для кого этот урок

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

Система, которая хорошо работает с небольшой нагрузкой, может столкнуться с трудностями при росте числа пользователей и объёма данных. Возможности её расширения во многом зависят от выбранной архитектуры.

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

Содержание урока

• Вертикальное и горизонтальное масштабирование.

• Влияние архитектурного стиля на возможности роста.

• Масштабирование монолита, клиент-серверных и многослойных систем.

• Независимое расширение микросервисов и событийная обработка.

• Балансировщики, очереди, кэширование и облачные инструменты.

• Оценка будущей нагрузки и роль аналитика.

Чему вы научитесь

• Различать основные способы масштабирования.

• Объяснять, как организация системы влияет на распределение нагрузки.

• Формулировать вопросы о росте данных и пользователей для архитектурного обсуждения.

Предварительные требования

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

Для кого этот урок

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

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

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

Содержание урока

• Назначение диаграммы компонентов UML.

• Компоненты, интерфейсы и зависимости.

• Декомпозиция, документирование и интеграция систем.

• Примеры применения и чтение диаграммы.

• Преимущества, ограничения и инструменты построения.

• Участие аналитика в описании структуры и связей.

Чему вы научитесь

• Читать основные элементы диаграммы компонентов.

• Выделять модули, точки взаимодействия и зависимости.

• Определять, на какие архитектурные вопросы отвечает эта диаграмма, а на какие — нет.

Предварительные требования

Полезно понимать, что такое компонент, интерфейс и архитектура системы.

Для кого этот урок

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

Структура приложения ещё не показывает, где оно работает. Для этого нужен другой взгляд: на серверы, устройства, размещённое ПО и сетевые связи между ними.

Познакомимся с диаграммой развёртывания UML. Разберём основные обозначения и пример размещения компонентов, обсудим пользу схемы для планирования инфраструктуры, обновлений и диагностики. Уточним, какие сведения аналитик согласовывает с DevOps-инженерами и почему такую документацию важно обновлять вместе с системой.

Содержание урока

• Назначение диаграммы развёртывания.

• Узлы, размещённые программные компоненты и каналы связи.

• Представление распределённой инфраструктуры.

• Использование при планировании, обновлении и поиске проблем.

• Пример диаграммы, инструменты и ограничения.

• Согласование инфраструктурных сведений и актуализация документации.

Чему вы научитесь

• Читать базовую схему размещения ПО и связей между узлами.

• Отличать физическое развёртывание от логической структуры приложения.

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

Предварительные требования

Полезно знать основные компоненты системы и назначение диаграммы компонентов. Опыт работы DevOps-инженером не требуется.

Для кого этот урок

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

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

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

Содержание урока

• Интеграция как обмен данными между системами.

• Пример взаимодействий при покупке в интернет-магазине.

• Причины использования внешних сервисов.

• Инициатор обмена, сообщения и правила обработки данных.

• Интеграционный ландшафт продукта.

• Вопросы аналитика и типичные ошибки при описании взаимодействий.

Чему вы научитесь

• Узнавать интеграции за привычными пользовательскими действиями.

• Определять участников обмена и его назначение.

• Перечислять основные вопросы, которые нужно выяснить до детализации API.

Предварительные требования

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

Для кого этот урок

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

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

Разберём роли клиента и сервера, назначение IP-адресов, доменных имён и портов. Посмотрим, чем различаются внутренняя сеть, DMZ и Интернет, и проследим обращение на примере мобильного банка. Урок даёт сетевую базу для аналитика без погружения в настройку оборудования.

Содержание урока

• Компьютерная сеть и участники обмена.

• Роли клиента и сервера.

• IP-адреса, доменные имена и порты.

• Последовательность обращения к серверу.

• Внутренняя сеть, DMZ и внешняя доступность.

• Схема взаимодействия мобильного приложения, backend и платёжного шлюза.

Чему вы научитесь

• Различать адрес узла и порт работающего на нём сервиса.

• Прослеживать простую схему сетевого взаимодействия.

• Уточнять, через какую сеть идёт обмен и какие ограничения доступа действуют.

Предварительные требования

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

Для кого этот урок

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

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

Разберём запрос и ответ по частям: метод, URL, заголовки, тело и статус. Познакомимся с распространёнными HTTP-методами и кодами ответов, а затем соберём общую картину взаимодействия. Уделим внимание ошибкам: аналитику важно описывать не только успешный результат.

Содержание урока

• Назначение HTTP и модель «запрос — ответ».

• Структура запроса: метод, адрес, заголовки и тело.

• Методы GET, POST, PUT и DELETE.

• URL и адресация ресурсов.

• Структура ответа и распространённые коды статусов.

• Пример обращения и задачи аналитика при описании контракта.

Чему вы научитесь

• Различать основные части HTTP-запроса и ответа.

• Объяснять назначение распространённых методов и статусов.

• Выделять данные и сценарии ошибок, которые нужно зафиксировать в требованиях к взаимодействию.

Предварительные требования

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

Для кого этот урок

Для аналитиков, которые начинают разбираться в HTTP и готовятся работать с API.

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

Сравним синхронное и асинхронное взаимодействие, разберём Push, Pull, Polling, Callback и Webhook. Посмотрим, как получить итог операции и какие ограничения учитывать при выборе подхода. Обсудим длительность обработки, нагрузку, надёжность и сценарии ожидания результата.

Содержание урока

• Синхронный обмен: ожидание ответа, преимущества и ограничения.

• Асинхронная обработка и отдельное получение результата.

• Push и Pull: кто инициирует передачу информации.

• Polling и его влияние на число запросов.

• Callback и Webhook.

• Критерии выбора режима и ошибки при описании ожидания и сбоев.

Чему вы научитесь

• Различать синхронное и асинхронное взаимодействие.

• Объяснять разницу между запросом результата и уведомлением о нём.

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

Предварительные требования

Полезно знать основы HTTP и модель «запрос — ответ».

Для кого этот урок

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

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

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

Содержание урока

• Назначение спецификации API: кто её создаёт и использует.

• Операции, адреса, параметры и заголовки запросов.

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

• Успешные ответы, ошибки и примеры сообщений.

• Авторизация, ограничения и обязательность полей.

• Согласование контракта и типичные пропуски в документации.

Чему вы научитесь

• Ориентироваться в основных разделах спецификации API.

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

• Замечать пропуски, которые могут вызвать разное понимание контракта у команд.

Предварительные требования

Полезно понимать HTTP-запросы, ответы и основные режимы взаимодействия систем.

Для кого этот урок

Для начинающих аналитиков, которые готовятся читать, обсуждать и оформлять API-контракты.

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

Познакомимся с JSON и XML и разберём простые примеры сообщений. Посмотрим, как читать поля, вложенные структуры и массивы, как фиксировать типы данных и обязательность полей. Урок поможет увереннее разбираться в содержимом запросов и ответов без необходимости писать программный код.

Содержание урока

• Сообщение как структурированный набор данных.

• Зачем системам общие правила представления информации.

• JSON: поля, значения, объекты и массивы.

• XML: элементы и теги.

• Сравнение форматов и обзор других вариантов обмена.

• Типы данных, вложенность, обязательность полей и пример денежного перевода.

Чему вы научитесь

• Читать простые сообщения в JSON и XML.

• Различать отдельный объект и список объектов.

• Определять, какие характеристики полей нужно отразить в описании сообщения.

Предварительные требования

Достаточно базового понимания интеграций. Знание языков программирования не требуется.

Для кого этот урок

Для аналитиков, которые начинают работать со структурами сообщений и хотят понимать данные в API-контрактах.

Системы могут решать похожие задачи обмена данными, но организовывать взаимодействие по-разному. В одном проекте встречаются SOAP-сервисы, в другом — REST API, а иногда несколько подходов используются одновременно.

Познакомимся с SOAP, REST и GraphQL: как в них описывают операции, формируют запросы и получают данные. Кратко рассмотрим другие варианты взаимодействия. Урок поможет не путать API-подход с форматом сообщения и учитывать ограничения существующих систем, а не выбирать технологию только по её популярности.

Содержание урока

• Разные подходы к организации API.

• SOAP и формализованные контракты.

• REST и взаимодействие через HTTP.

• GraphQL и выбор нужных клиенту данных.

• Краткий обзор gRPC, WebSocket и обмена через сообщения и события.

• Сочетание нескольких подходов в одном проекте и вопросы аналитика.

Чему вы научитесь

• Объяснять базовые различия между SOAP, REST и GraphQL.

• Отличать формат данных от способа организации API.

• Учитывать особенности используемого подхода при обсуждении интеграции.

Предварительные требования

Полезно знать основы HTTP и форматов JSON и XML.

Для кого этот урок

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

Когда API меняется, его текстовое описание легко отстаёт от реализации. Машиночитаемая спецификация помогает работать с контрактом более последовательно и использовать его не только для чтения документации.

Разберём, что описывает OpenAPI и чем он отличается от инструментов Swagger. Посмотрим на операции, параметры, ответы, ошибки и схемы данных, а также на возможности Swagger UI. Проследим, как единый контракт связывает работу аналитика, разработчика и тестировщика.

Содержание урока

• Проблемы поддержки API-документации.

• OpenAPI как стандарт описания контракта.

• Swagger и интерактивная документация Swagger UI.

• Операции, параметры, запросы, ответы и ошибки.

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

• Работа команды с единым контрактом и поддержание его актуальности.

Чему вы научитесь

• Различать OpenAPI, Swagger и Swagger UI.

• Ориентироваться в основных частях спецификации.

• Объяснять, как контракт используется при согласовании, разработке и проверке API.

Предварительные требования

Полезно предварительно познакомиться с HTTP, спецификацией API и структурами сообщений.

Для кого этот урок

Для аналитиков, которые хотят понимать современную API-документацию и своё участие в её подготовке и поддержке.

Готовый код ещё не означает, что проект можно закрывать. Нужно проверить соответствие результата требованиям, подготовить документацию, обучить пользователей и договориться, кто будет поддерживать систему после передачи.

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

Содержание урока

• Цели завершающего этапа и проверка достигнутого результата.

• Сопоставление реализации с требованиями и ожиданиями.

• Финальные проверки качества и устранение критических дефектов.

• Комплект документации и передача знаний.

• Обучение пользователей и организация поддержки.

• Оценка эффективности, приёмка и закрытие проекта.

Чему вы научитесь

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

• Связывать эти задачи с нужными документами и результатами проверок.

• Объяснять роль аналитика в подготовке приёмки и передаче знаний.

Предварительные требования

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

Для кого этот урок

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

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

Познакомимся с ролью ГОСТ и национальных стандартов СТ РК в проектной документации. Разберём организационные, технические и эксплуатационные документы: от технико-экономического обоснования до пользовательских руководств. Обсудим, почему состав комплекта зависит от проекта, заказчика и установленных требований.

Содержание урока

• ГОСТ и СТ РК в контексте IT-проектов.

• Организационная, техническая и эксплуатационная документация.

• Технико-экономическое обоснование и техническое задание.

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

• Программа и методика испытаний.

• Руководства, регламенты и определение состава документации.

Чему вы научитесь

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

• Объяснять, чем отличаются ТЗ, спецификация требований и программа испытаний.

• Уточнять состав документации с учётом условий конкретного проекта.

Предварительные требования

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

Для кого этот урок

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

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

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

Содержание урока

• Миграция данных, приложений и инфраструктуры.

• Анализ исходной системы и ограничений.

• Big Bang, поэтапный и гибридный переход.

• Ресурсы, зависимости, сроки и риски миграции.

• Резервное копирование, проверки и стратегия отката.

• Документы миграции и оценка результата переноса.

Чему вы научитесь

• Различать виды миграции и основные стратегии перехода.

• Перечислять ключевые разделы плана миграции.

• Определять, какие проверки и меры снижения рисков следует обсудить с командой.

Предварительные требования

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

Для кого этот урок

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

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

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

Содержание урока

• Задачи обучения при внедрении системы.

• Анализ ролей, потребностей и уровня подготовки пользователей.

• Очные занятия, вебинары, онлайн-курсы, видео и инструкции.

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

• Оценка эффективности обучения.

• База знаний и поддержка после занятий.

Чему вы научитесь

• Учитывать различия между группами пользователей при планировании обучения.

• Подбирать форматы и материалы под их рабочие задачи.

• Перечислять способы проверки того, помогло ли обучение освоить систему.

Предварительные требования

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

Для кого этот урок

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

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

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

Содержание урока

• Назначение руководства и его целевая аудитория.

• Введение, общие сведения и подготовка к работе.

• Описание функций, интерфейса и навигации.

• Пошаговые инструкции для типовых сценариев.

• Частые проблемы, возможные причины и способы решения.

• Дополнительные материалы и обращение в поддержку.

Чему вы научитесь

• Ориентироваться в структуре пользовательского руководства.

• Организовывать описание вокруг задач и последовательности действий пользователя.

• Определять, какие пояснения, иллюстрации и сведения о поддержке стоит добавить.

Предварительные требования

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

Для кого этот урок

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

После запуска у системы появляются реальные нагрузки, обращения пользователей, ошибки и новые потребности. Чтобы она продолжала работать, нужны понятное распределение ответственности, мониторинг и управляемые обновления.

Разберём виды поддержки и уровни L1, L2 и L3: кто принимает обращение, кто разбирается в причинах и когда подключаются разработчики. Посмотрим на каналы связи, инструменты наблюдения и показатели качества поддержки. Обсудим, как аналитик помогает разбирать проблемы и поддерживать документацию в актуальном состоянии.

Содержание урока

• Техническая, функциональная и административная поддержка.

• Уровни L1, L2 и L3 и распределение задач.

• Каналы обращений, тикет-системы и база знаний.

• Мониторинг производительности и анализ ошибок.

• Плановые, критические и крупные обновления.

• Метрики поддержки и участие аналитика в сопровождении.

Чему вы научитесь

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

• Объяснять, как связаны обращения, мониторинг и работа над улучшениями.

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

Предварительные требования

Полезно базовое понимание жизненного цикла продукта. Опыт работы в службе поддержки не требуется.

Для кого этот урок

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

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

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

Содержание урока

• Цели оценки и выбор критериев успеха.

• Сбор данных и сравнение с плановыми показателями.

• Финансовые, операционные и качественные метрики.

• Сроки, ресурсы и удовлетворённость пользователей.

• Анализ проблем и причин отклонений.

• Итоговый отчёт, рекомендации и извлечённые уроки.

Чему вы научитесь

• Отличать завершение работ от достижения целей проекта.

• Подбирать группы показателей для оценки разных сторон результата.

• Понимать, какие выводы и рекомендации должны попасть в итоговый отчёт.

Предварительные требования

Достаточно общего представления о целях проекта и жизненном цикле продукта. Углублённые знания финансового анализа не нужны.

Для кого этот урок

Для аналитиков, которые хотят связывать результаты разработки с пользой для бизнеса и учитывать опыт завершённых проектов.