Бесплатный фрагмент - Системный аналитик: первый шаг в профессию

От автора

Дорогие читатели!

Когда я только начинал свой путь в системном анализе, передо мной стояло множество вопросов. Кто такой системный аналитик на самом деле? Чем он отличается от бизнес-аналитика или разработчика? Какие инструменты и методологии использовать в работе? Как не потеряться в море технологий — от классических SQL и UML до новейших AI и low-code платформ?

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

• просто и понятно объясняет суть профессии;

• показывает место системного аналитика в IT-команде и бизнес-процессах;

• даёт практические инструменты для работы с первого дня;

• помогает сориентироваться в современных трендах — AI, low-code, data-driven подходах;

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

Именно такую книгу я и написал — «Системный аналитик: первый шаг в профессию».

Почему я решил её создать?

За годы работы я неоднократно сталкивался с тем, что:

• новички путают роли в IT и не понимают, чем конкретно занимается системный аналитик;

• учебные материалы часто перегружены теорией и не дают практических навыков;

• информация о современных трендах разрозненна — AI, low-code и data-driven подходы изучают отдельно, а не как единую экосистему;

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

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

Часть 1.
Введение в профессию

Глава 1. Кто такой системный аналитик: роль и место
в IT-проектах

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

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

Глава 2. Чем системный аналитик отличается от бизнес-аналитика, тестировщика, разработчика

1. Системный аналитик vs бизнес-аналитик:

Фокус работы:

• Бизнес-аналитик: бизнес-процессы и потребности пользователей. Отвечает на вопрос: «Что нужно бизнесу?»

• Системный аналитик: техническая реализация. Отвечает на вопрос: «Как это реализовать в системе?»

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

• БА:

— анализ бизнес-процессов («как есть» и «как должно быть»);

— выявление проблем и узких мест;

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

— создание пользовательских историй (User Stories);

— прототипирование интерфейсов (UX);

— взаимодействие с заказчиками и пользователями.

• СА:

— перевод бизнес-требований в технические спецификации;

— проектирование архитектуры системы;

— моделирование данных (ERD) и процессов (BPMN, UML);

— описание API и интеграций;

— разработка ТЗ и SRS;

— консультирование разработчиков.

Уровень технических знаний:

• БА: базовый (понимание, как работают IT-системы, основы SQL, знакомство с API).

---

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

Примеры требований:

• От БА: «Система должна позволять пользователю загружать документы в форматах PDF и DOCX».

• От СА: «API endpoint /upload принимает multipart/form-data, валидирует MIME-тип, сохраняет файл в S3-bucket, записывает метаданные в таблицу documents БД PostgreSQL».

Артефакты (результаты работы):

• БА: карта бизнес-процессов, User Stories, прототипы экранов, бизнес-требования.

• СА: ТЗ, SRS, схемы архитектуры, ERD-диаграммы, описание API (Swagger), модели данных.

2. Системный аналитик vs тестировщик:

Цель работы:

• СА: спроектировать решение, которое соответствует требованиям.

• Тестировщик: проверить, что реализованное решение соответствует требованиям и работает без ошибок.

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

• СА:

— определить, какие функции нужны и как они должны работать;

— описать критерии приёмки (Acceptance Criteria);

— спроектировать сценарии взаимодействия компонентов.

• Тестировщик:

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

— найти дефекты и ошибки;

— убедиться, что система устойчива к нагрузкам и атакам;

— автоматизировать проверки (при необходимости).

Подход к требованиям:

• СА: создаёт требования.

• Тестировщик: использует требования как основу для тест-кейсов.

Навыки:

• СА: моделирование, проектирование, знание методологий разработки.

• Тестировщик: знание техник тест-дизайна, инструментов тестирования (Postman, JMeter, Selenium), основ SQL для проверки данных.

Артефакты:

• СА: техническое задание, схемы интеграции.

• Тестировщик: тест-планы, тест-кейсы, отчёты о дефектах (Bug Reports).

Пример:

• СА описывает: «При нажатии кнопки „Оплатить“ система должна списать сумму с карты и отправить уведомление на email».

• Тестировщик проверяет:

— списывается ли сумма;

— отправляется ли email;

— что происходит при недостатке средств;

— как система реагирует на некорректный email.

3. Системный аналитик vs разработчик:

Роль в создании продукта:

• СА: проектировщик. Определяет архитектуру и правила, по которым будет строиться система.

• Разработчик: исполнитель. Пишет код, реализующий проект.

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

• СА:

— проанализировать требования и предложить оптимальное техническое решение;

— описать интерфейсы взаимодействия (API, сообщения очередей);

— смоделировать структуру данных;

— согласовать решения с архитекторами и командой.

• Разработчик:

— написать код согласно ТЗ и спецификациям;

— реализовать бизнес-логику;

— оптимизировать производительность;

— провести код-ревью.

Глубина погружения в технологии:

• СА: широкий охват (понимание стека проекта, ограничений платформ, принципов масштабирования).

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

Временной фокус:

• СА: проектирование до начала разработки.

• Разработчик: реализация во время разработки.

Артефакты:

• СА: диаграммы UML, описание API, модели данных, ТЗ.

• Разработчик: исходный код, коммиты в Git, логи сборки.

Пример:

• СА проектирует: «Микросервис авторизации должен использовать JWT-токены, хранить данные в Redis, интегрироваться с LDAP».

• Разработчик реализует: пишет код на Java/Spring Security, настраивает Redis-клиент, реализует LDAP-запросы.

Сводная таблица различий:

Важные нюансы:

1. Пересечение ролей. В небольших компаниях один специалист может совмещать роли (например, БА + СА или СА + тестировщик).

2. Последовательность работы. Часто задачи идут цепочкой:

БА → СА → Разработчик → Тестировщик

3. Общие зоны ответственности. Все участники участвуют в:

• обсуждении требований;

• анализе рисков;

• улучшении процессов (в Agile).

Глава 3. Навыки системного аналитика: технические и мягкие (hard и soft skills)

Hard skills (технические навыки)

1. Знание методологий разработки ПО:

• Agile (Scrum, Kanban);

• Waterfall;

• DevOps.

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

2. Владение нотациями моделирования:

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

• BPMN (моделирование бизнес-процессов);

• ERD (Entity-Relationship Diagrams) — проектирование баз данных;

• DFD (Data Flow Diagrams) — отображение потоков данных;

• IDEF0/IDEF3 (функциональное моделирование).

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

3. Работа с базами данных и SQL:

• написание запросов (SELECT, JOIN, подзапросы);

• понимание нормализации (1NF, 2NF, 3NF);

• проектирование схем БД.

Инструменты: PostgreSQL, MySQL, SQL Server.

4. Понимание API и форматов данных:

• REST (HTTP-методы, JSON);

• SOAP (XML, WSDL);

• GraphQL.

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

5. Основы программирования:

• базовые знания Python, Java, C# или JavaScript (понимание синтаксиса, алгоритмов);

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

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

• Jira (управление задачами);

• Confluence (документация);

• draw.io, Lucidchart (диаграммы);

• Figma, Balsamiq (прототипирование интерфейсов);

• Postman (тестирование API);

• Swagger/OpenAPI (документация API).

7. Понимание архитектуры ПО:

• клиент-серверная модель;

• монолиты vs микросервисы;

• очереди сообщений (RabbitMQ, Kafka);

• кэширование (Redis).

8. Основы тестирования:

• виды тестирования (функциональное, нагрузочное, регрессионное);

• разработка тест-кейсов на основе требований;

• участие в приёмочном тестировании (UAT).

9. Знание стандартов документации:

• ГОСТ 34, IEEE 830 (структура ТЗ);

• BABOK (Business Analysis Body of Knowledge).

10. Английский язык:

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

Soft skills (мягкие навыки)

1. Коммуникация:

• устная: проведение интервью, презентаций, фасилитация встреч;

---

• письменная: чёткое изложение требований в ТЗ, email-переписка;

• «перевод» между бизнесом и IT (объяснение технических деталей нетехническим специалистам и наоборот).

2. Аналитическое мышление:

• декомпозиция сложных задач;

• выявление причинно-следственных связей;

• поиск оптимальных решений с учётом ограничений.

3. Внимание к деталям:

• точность в описании требований (избегание двусмысленностей);

• проверка согласованности документации (например, соответствие Use Case и API-спецификации).

4. Управление конфликтами:

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

• аргументация технических решений.

5. Эмпатия:

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

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

6. Тайм-менеджмент и приоритизация:

• планирование задач (метод Eisenhower Matrix);

• оценка сроков реализации требований;

• работа в условиях многозадачности.

7. Гибкость и адаптивность:

• готовность к изменениям требований (Agile-среда);

• быстрое освоение новых технологий и инструментов.

8. Системное мышление:

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

• прогнозирование рисков (например, нагрузка на БД при масштабировании).

---

9. Обучаемость:

• самостоятельное изучение новых методологий (например, Low-code платформ);

• отслеживание IT-трендов (AI, Big Data, блокчейн).

10. Ответственность и проактивность:

• инициативное предложение улучшений;

• контроль выполнения задач до завершения проекта.

Как навыки соотносятся с этапами карьеры:

Практические рекомендации по развитию навыков

1. Для hard skills:

• пройдите курсы по UML/BPMN (Udemy, Coursera);

• практикуйтесь в SQL на платформах типа LeetCode или HackerRank;

• создайте учебный проект: спроектируйте API для сервиса (например, библиотеки) и опишите его в Swagger;

• изучите документацию популярных фреймворков (Spring, Django) для понимания реализации требований.

2. Для soft skills:

• тренируйте активное слушание: на встречах перефразируйте слова собеседника («Правильно ли я понял, что вам нужно…»);

• участвуйте в ролевых играх (например, «интервью с заказчиком»);

• ведите дневник рефлексии: после встреч анализируйте, что получилось, а что можно улучшить;

• читайте книги по коммуникации (например, «Как завоёвывать друзей и оказывать влияние на людей» Д. Карнеги).

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

• чек-лист «Готов ли я к задаче?»: перед началом проекта оцените, хватает ли знаний по архитектуре, нотациям, инструментам;

• обратная связь от коллег: попросите разработчика или тестировщика оценить чёткость вашего ТЗ.

Глава 4. Карьерный путь:
junior → middle → senior

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

Уровень 1: Junior системный аналитик

Опыт: 0–2 года.

Наставничество: работает под руководством middle/senior-аналитика или тимлида.

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

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

• сбор и документирование простых требований (например, «добавить поле „Дата рождения“ в форму регистрации»);

• внесение изменений в существующие процессы без изменения бизнес-логики;

• устранение локальных инцидентов (ошибок в данных, сбоев в отчётах);

• подготовка документации по шаблонам (ТЗ, Use Case);

• консультирование пользователей по функционалу системы;

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

Требуемые навыки:

• основы SQL (SELECT, JOIN, WHERE);

• базовые нотации: UML (диаграммы вариантов использования), BPMN (простые процессы);

• работа с инструментами: Jira (постановка задач), Confluence (ведение документации), draw.io (создание схем);

• понимание жизненного цикла ПО (SDLC);

• основы коммуникации: умение задавать уточняющие вопросы, фиксировать ответы.

Типичные ошибки:

• нечёткое описание требований (двусмысленности, пропуски условий);

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

• боязнь задавать вопросы наставнику.

Как перейти на следующий уровень:

• стабильно выполнять типовые задачи без ошибок;

• научиться самостоятельно находить информацию (документация, коллеги);

• начать предлагать небольшие улучшения процессов.

Уровень 2: Middle системный аналитик

Опыт: 2–5 лет.

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

Зона ответственности: модули или сервисы в рамках проекта.

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

• самостоятельное проектирование небольших систем или интеграций (например, модуль уведомлений);

• анализ и приоритизация требований (методы MoSCoW, RICE);

• разработка архитектуры решения: выбор технологий, компонентов, API;

• декомпозиция сложных задач на подзадачи для разработчиков;

• согласование изменений с бизнесом и IT-командой;

• ведение базы знаний (Confluence): актуализация документации;

• участие в собеседованиях кандидатов;

• управление скоупом проекта (объёмом работ).

Требуемые навыки:

• продвинутый SQL (подзапросы, агрегатные функции, индексы);

• глубокое понимание нотаций: UML (диаграммы последовательностей, классов), BPMN (шлюзы, параллельные процессы);

• проектирование REST API (описание endpoints, моделей запросов/ответов);

• основы проектирования БД (нормализация, связи);

• инструменты: Postman (тестирование API), Figma (прототипирование), Miro (мозговые штурмы);

• оценка трудоёмкости задач (Story Points, часы);

• фасилитация встреч (планирование спринтов, демо-презентации).

Типичные ошибки:

• недооценка рисков (например, нагрузка на БД при масштабировании);

• отсутствие коммуникации при изменениях требований;

• детализация ТЗ до уровня кода (вместо описания логики).

Как перейти на следующий уровень:

• брать сложные проекты с высокой неопределённостью;

• начать менторить junior-аналитиков;

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

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

Уровень 3: Senior системный аналитик

Опыт: 5+ лет.

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

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

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

• проектирование архитектуры сложных систем (микросервисы, интеграции);

• создание стандартов аналитики в компании (шаблоны ТЗ, правила моделирования);

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

• стратегическое планирование: согласование IT-решений с бизнес-целями;

• менторинг junior/middle-аналитиков (обучение, ревью документации);

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

• проведение ассессментов (оценка компетенций сотрудников);

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

Требуемые навыки:

• экспертиза в архитектуре ПО (монолиты vs микросервисы, кэширование, масштабирование);

• знание Enterprise Integration Patterns (интеграционные паттерны);

• опыт работы с Big Data, AI/ML (понимание возможностей и ограничений);

• навыки управления командой (делегирование, мотивация);

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

• стратегическое мышление (прогнозирование трендов, оценка ROI);

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

Типичные ошибки:

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

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

• сопротивление новым технологиям (консерватизм).

---

Возможности роста после senior:

• Менеджмент: руководитель аналитического отдела, product owner. Фокус на процессах, людях, бюджете.

• Экспертиза: solution architect, chief analyst. Углубление в сложные технические задачи.

• Продуктовый трек: product manager. Переход от проектирования к стратегии продукта.

• Консалтинг: независимый консультант по системной аналитике.

Критерии готовности к повышению

Используйте чек-лист для самооценки:

Практические рекомендации по развитию

1. Для junior:

• создайте учебный проект: спроектируйте API для сервиса (например, библиотеки) и опишите его в Swagger;

• решите 10–20 задач по SQL на LeetCode или HackerRank;

• нарисуйте BPMN-диаграмму для реального процесса (например, «Оформление заказа в интернет-магазине»).

2. Для middle:

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

• проведите интервью с пользователем для сбора требований;

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

3. Для senior:

• разработайте стандарт документации для команды (шаблоны ТЗ, API);

• проведите тренинг для junior-аналитиков по UML;

• изучите архитектурный паттерн (например, CQRS) и предложите его внедрение в проекте.

Глава 5. Где востребованы системные аналитики: отрасли и типы проектов

Системные аналитики востребованы везде, где внедряют или модернизируют IT-системы. Разберём ключевые отрасли и типичные проекты.

Отрасли, где нужны системные аналитики

1. Финансы и банкинг:

• Компании: банки, страховые компании, финтех-стартапы, платёжные системы.

• Задачи: автоматизация обработки транзакций, внедрение CRM/ERP, защита данных, интеграция с международными системами (SWIFT), анализ рисков.

• Примеры проектов:

— система скоринга заёмщиков;

— мобильное приложение банка с биометрией;

— платформа для онлайн-страхования.

2. Ритейл и e-commerce:

• Компании: сети супермаркетов, маркетплейсы, логистические операторы.

• Задачи: управление запасами, автоматизация складов, интеграция онлайн- и офлайн-каналов, аналитика продаж.

• Примеры проектов:

— WMS (Warehouse Management System) для сети гипермаркетов;

— CRM с персонализацией предложений;

— сервис динамического ценообразования.

3. Телеком:

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

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

• Примеры проектов:

— система тарификации услуг связи;

— приложение для самообслуживания абонентов;

— интеграция CRM с колл-центром.

4. Производство и логистика:

• Компании: заводы, транспортные компании, дистрибьюторы.

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

• Примеры проектов:

— MES (Manufacturing Execution System) для завода;

— TMS (Transportation Management System) для логистического оператора;

— система предиктивной диагностики станков.

5. Госуправление и социальные проекты:

• Организации: министерства, МФЦ, фонды, НКО.

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

• Примеры проектов:

— портал Госуслуг;

— система электронного документооборота для Минздрава;

— платформа мониторинга социальных выплат.

6. Здравоохранение:

• Организации: клиники, лаборатории, фармкомпании, страховые.

• Задачи: электронные медкарты, телемедицина, учёт лекарств.

• Примеры проектов:

— HIS (Hospital Information System);

— приложение для записи к врачу;

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

---

7. IT и разработка ПО:

• Компании: продуктовые IT-компании, аутсорсинговые студии, стартапы.

• Задачи: проектирование SaaS-решений, микросервисов, API.

• Примеры проектов:

— CRM для малого бизнеса;

— платформа аналитики данных;

— low-code конструктор бизнес-процессов.

8. Энергетика и экология:

• Компании: энергосбытовые компании, ГРЭС, экологические службы.

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

• Примеры проектов:

— система «умных» счётчиков электроэнергии;

— платформа контроля углеродного следа предприятия;

— диспетчерский центр управления энергосетью.

9. Медиа и развлечения:

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

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

• Примеры проектов:

— рекомендательная система для видеоплатформы;

— CMS для новостного портала;

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

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

1. Внедрение ERP-систем:

• Цель: централизация данных компании (финансы, HR, логистика).

• Роль СА: анализ бизнес-процессов, настройка модулей, интеграция с legacy-системами.

• Инструменты: SAP, 1C, Oracle ERP.

2. Разработка мобильных и веб-приложений:

• Цель: создание пользовательских сервисов.

• Роль СА: проектирование API, UX-прототипы, ТЗ для разработчиков.

• Пример: приложение доставки еды с оплатой картой и push-уведомлениями.

3. Автоматизация бизнес-процессов:

• Цель: сокращение ручного труда, ускорение операций.

• Роль СА: моделирование процессов (BPMN), выбор RPA-решений.

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

4. Интеграция систем:

• Цель: обмен данными между разрозненными сервисами (CRM ↔ ERP ↔ склад).

• Роль СА: описание API, маппинг данных, сценарии обработки ошибок.

• Инструменты: MuleSoft, Apache Kafka, REST/SOAP.

5. Миграция данных и модернизация:

• Цель: перенос данных в облако или новую систему без потерь.

• Роль СА: план миграции, валидация данных, откат (rollback).

• Пример: переход с локальной БД на PostgreSQL в облаке.

6. Проекты Big Data и AI:

• Цель: анализ больших данных, прогнозная аналитика, чат-боты.

• Роль СА: определение источников данных, проектирование пайплайнов, критерии качества ML-моделей.

• Инструменты: Hadoop, Spark, TensorFlow.

7. Обеспечение безопасности и соответствия стандартам:

• Цель: защита данных (GDPR, ФЗ-152), аудит систем.

• Роль СА: требования к шифрованию, ролевая модель доступа, журналы аудита.

• Пример: система двухфакторной аутентификации для банка.

8. Цифровая трансформация:

• Цель: комплексное обновление IT-ландшафта компании.

• Роль СА: стратегия миграции, приоритизация модулей, KPI эффективности.

• Пример: перевод завода на Industry 4.0 (IoT + AI).

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

• Рост в финтехе и e-commerce: из-за конкуренции за удобство и скорость.

• Акцент на Big Data/AI: компании ищут аналитиков с пониманием ML-пайплайнов.

• Удалённая работа: 60–70% вакансий допускают гибридный или fully remote формат.

• Международные проекты: спрос на аналитиков с английским (B2+), особенно в стартапах и аутсорсинге.

• Кросс-отраслевые навыки: ценится опыт в смежных сферах (например, логистика + IT).

Как выбрать отрасль для старта

1. Для junior:

• IT-компании: чёткие процессы, наставничество.

• Ритейл/e-commerce: много типовых задач (автоматизация заказов, CRM).

• Банки: стабильность, но высокая бюрократия.

2. Для middle/senior:

• Финтех/стартапы: сложные проекты, быстрый рост.

• Производство/логистика: глубокие предметные знания, долгосрочные проекты.

• Госуправление: масштабные системы, но долгие согласования.

Советы:

1. Начните с отрасли, которая вам интересна (например, медицина → HIS).

---

2. Изучите специфику: термины, регламенты (ФЗ-152 для госсектора, PCI DSS для платежей).

3. Посещайте профильные конференции (например, Retail Week, Finopolis).

Часть 2.
Базовые концепции системного анализа

Глава 6. Что такое система: определение, компоненты, границы

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

Ключевые характеристики системы:

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

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

3. Цель или функция: система создаётся для достижения определённой цели (например, CRM — для управления отношениями с клиентами).

4. Взаимодействие со средой: система обменивается ресурсами, информацией или энергией с внешним миром.

5. Иерархичность: каждый элемент системы может сам быть системой (подсистемой), а сама система может быть частью более крупной системы (надсистемы).

Компоненты системы

Компоненты (элементы) — это части системы, выполняющие определённые функции. Они могут быть:

• физическими (детали механизма, серверы);

• абстрактными (алгоритмы, правила);

• живыми (сотрудники в организационной системе);

• информационными (данные, файлы).

Основные типы компонентов в IT-системах:

1. Аппаратное обеспечение: серверы, сети, устройства ввода-вывода.

2. Программное обеспечение: приложения, операционные системы, библиотеки.

3. Данные: базы данных, файлы, потоки информации.

4. Пользователи: люди или другие системы, взаимодействующие с системой.

5. Процессы: бизнес-процессы, алгоритмы обработки данных.

6. Интерфейсы: точки взаимодействия между компонентами (API, GUI, CLI).

7. Правила и политики: регламенты безопасности, бизнес-правила.

Связи между компонентами:

• Прямые связи: передача данных от одного элемента к другому (например, запрос от клиента к серверу).

• Обратные связи: механизм корректировки работы системы (например, логирование ошибок для последующего анализа):

— Отрицательные обратные связи стабилизируют систему (например, автомасштабирование серверов при нагрузке).

— Положительные обратные связи усиливают изменения (например, вирусное распространение контента в соцсетях).

Структура системы — устойчивые связи между компонентами, определяющие её поведение. Примеры структур:

• линейная (последовательная);

• иерархическая (древовидная);

• сетевая (все элементы связаны между собой).

Границы системы

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

---

Типы границ:

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

• Логические/концептуальные: определяются функционалом (например, границы CRM — управление клиентами, но не бухгалтерия).

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

Как определить границы:

1. По целям: что должна делать система? Всё, необходимое для достижения цели, входит в границы.

2. По интерфейсам: точки взаимодействия с внешней средой (API, пользовательские интерфейсы).

3. По потокам данных: откуда система получает данные и куда их передаёт.

4. По ответственности: какие процессы контролирует система, а какие — внешние системы.

Пример определения границ для интернет-магазина:

• В системе: корзина покупок, каталог товаров, платёжный шлюз, система уведомлений.

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

Классификация систем

1. По природе:

• материальные (автомобиль, завод);

• абстрактные (математическая модель, теория).

2. По взаимодействию со средой:

• открытые (обмениваются ресурсами с окружением — например, экосистема);

• закрытые (изолированы — например, герметичный химический реактор).

---

3. По динамике:

• статичные (не меняются во времени — например, мост);

• динамичные (изменяются — например, погода).

4. По сложности:

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

• сложные (много компонентов и взаимосвязей — например, интернет).

5. По управляемости:

• управляемые (можно влиять на поведение — например, автомобиль);

• самоорганизующиеся (адаптируются сами — например, нейронная сеть).

Примеры систем

1. Компьютерная система:

• компоненты: процессор, память, жёсткий диск, ОС, приложения;

• границы: корпус ПК или виртуальная среда (например, Docker-контейнер).

2. Банк:

• компоненты: отделения, клиенты, счета, транзакции, CRM;

• границы: внутренние процессы банка vs взаимодействие с ЦБ, налоговой.

3. Интернет-магазин:

• компоненты: каталог, корзина, платёжный модуль, складская система;

• границы: интеграция с внешними службами доставки и оплаты.

4. Экосистема:

• компоненты: растения, животные, почва, вода;

• границы: конкретный лес или водоём.

---

Роль системного аналитика в работе с системами

Системный аналитик должен:

• чётко определять границы системы для проекта;

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

• выявлять внешние системы и точки интеграции;

• документировать структуру системы (с помощью UML, BPMN, ERD);

• учитывать эмерджентные свойства при проектировании (например, масштабируемость);

• оценивать влияние изменений на всю систему.

Типичные ошибки:

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

• игнорирование внешних зависимостей (например, не учтена интеграция с CRM);

• недооценка обратных связей (например, отсутствие логирования ошибок);

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

Глава 7. Жизненный цикл ПО (SDLC) и роль аналитика на каждом этапе

SDLC (Software Development Life Cycle) — это структурированный процесс разработки программного обеспечения от идеи до вывода из эксплуатации. Разберём классические этапы и роль системного аналитика в каждом из них.

Этап 1. Планирование (Planning):

Цель: определить цели проекта, оценить ресурсы и ограничения.

Задачи команды:

• определение бизнес-целей и ожидаемой выгоды;

• оценка бюджета, сроков, технологий;

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

• анализ рисков и целесообразности проекта.

Роль системного аналитика:

• участие в интервью со стейкхолдерами для выявления высокоуровневых требований;

• помощь в оценке технической реализуемости идей;

• формирование документа «Видение проекта» (Vision) или концепции;

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

Результат: стратегический план проекта, устав проекта (Project Charter).

---

Этап 2. Анализ требований (Analysis / Requirements Engineering):

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

Задачи команды:

• глубокое погружение в бизнес-процессы;

• проведение интервью, опросов, наблюдений;

• систематизация требований;

• приоритизация (MoSCoW, RICE);

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

Роль системного аналитика:

• сбор и анализ функциональных требований (что система должна делать);

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

• документирование требований в SRS (Software Requirements Specification) или пользовательских историй (User Stories);

• моделирование процессов (BPMN) и данных (ERD);

• согласование требований со всеми заинтересованными сторонами.

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

Этап 3. Проектирование (Design):

Цель: разработать архитектуру и дизайн системы на основе утверждённых требований.

Задачи команды:

• выбор технологий (языки программирования, фреймворки, БД);

• проектирование архитектуры (монолит, микросервисы);

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

• создание детальных схем и моделей.

---

Роль системного аналитика:

• проектирование архитектуры решения совместно с архитектором;

• описание API (REST, SOAP, GraphQL) в Swagger/OpenAPI;

• моделирование структуры данных и связей (ERD, схемы БД);

• разработка схем интеграции между системами;

• создание прототипов интерфейсов (low-fidelity/high-fidelity);

• написание технического задания (ТЗ) для разработчиков;

• ревью проектных решений на соответствие требованиям.

Результат: архитектура системы, ТЗ, схемы интеграции, прототипы интерфейсов, описание API.

Этап 4. Разработка (Implementation / Coding):

Цель: превратить проектные решения в работающий код.

Задачи команды:

• написание кода;

• модульное тестирование (unit-testing);

• интеграция компонентов;

• настройка CI/CD-пайплайнов.

Роль системного аналитика:

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

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

• участие в код-ревью (оценка соответствия кода ТЗ);

• актуализация документации при изменениях;

• решение возникающих вопросов между бизнесом и разработчиками.

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

Этап 5. Тестирование (Testing):

Цель: проверить качество продукта, выявить и устранить ошибки.

Виды тестирования:

• юнит-тестирование (модульное);

• интеграционное;

• системное;

• приёмочное (UAT);

• нагрузочное;

• безопасности.

Роль системного аналитика:

• разработка тест-кейсов на основе требований;

• участие в приёмочном тестировании (UAT) с заказчиками;

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

• фиксация расхождений и передача на доработку;

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

Результат: отчёт о тестировании, исправленные ошибки, верифицированная система.

Этап 6. Внедрение (Deployment):

Цель: запустить ПО в промышленной среде.

Задачи команды:

• настройка оборудования и инфраструктуры;

• миграция данных;

• развёртывание на серверах;

• обучение пользователей.

Роль системного аналитика:

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

• участие в миграции данных (проверка корректности переноса);

• консультирование службы поддержки;

• сбор первых отзывов пользователей;

• фиксация проблем внедрения для оперативного решения.

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

Этап 7. Поддержка и обслуживание (Maintenance):

Цель: обеспечить стабильную работу ПО, вносить улучшения.

Задачи команды:

• исправление ошибок;

• обновления и патчи безопасности;

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

• добавление новой функциональности.

Роль системного аналитика:

• анализ запросов на изменения (Change Requests);

• оценка влияния изменений на систему;

• документирование обновлений;

• приоритизация задач для доработки;

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

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

Этап 8. Вывод из эксплуатации (Retirement):

Цель: корректно завершить жизненный цикл ПО.

Задачи команды:

• планирование миграции на новую систему;

• архивирование данных;

• уведомление пользователей;

• отключение сервисов.

Роль системного аналитика:

• анализ данных для архивации;

• составление плана миграции данных;

• документирование процесса вывода из эксплуатации;

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

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

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

1. Waterfall (каскадная модель):

• аналитик работает последовательно на каждом этапе;

• требования фиксируются до начала разработки;

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

2. Agile (гибкие методологии, Scrum, Kanban):

• аналитик участвует в планировании спринтов;

• требования уточняются итеративно;

• фокус на быстрой поставке ценности;

• постоянное взаимодействие с командой и заказчиком.

3. DevOps:

• аналитик учитывает требования к CI/CD, мониторингу, инфраструктуре;

• участвует в автоматизации процессов;

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

Типичные ошибки аналитика в SDLC:

• На этапе анализа: неполный сбор требований, игнорирование нефункциональных требований.

• На этапе проектирования: слишком детальное ТЗ (до уровня кода) или, наоборот, слишком абстрактное.

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

• В тестировании: недостаточное участие в UAT, неучёт сценариев пользователей.

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

Глава 8. Методологии разработки: Waterfall, Agile (Scrum, Kanban), DevOps

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

1. Waterfall (каскадная модель):

История: предложена в 1970 году Уинстоном Ройсом.

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

Этапы:

1. Сбор и анализ требований.

2. Проектирование.

3. Разработка.

4. Тестирование.

5. Внедрение.

6. Поддержка.

Принципы:

• жёсткое планирование до начала работ;

• полная документация на каждом этапе;

• изменения вносятся через формальные процедуры;

• заказчик получает продукт только в конце цикла.

Преимущества:

• предсказуемость сроков и бюджета;

• чёткие требования на старте;

• подробная документация;

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

Недостатки:

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

• высокий риск при неточных требованиях;

• длительное ожидание результата;

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

Где применяется:

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

• медицинская и авиационная техника (сертификация);

• крупные банковские системы;

• проекты с чёткими стандартами (ГОСТ, ISO).

2. Agile (гибкая разработка):

История: манифест Agile создан в 2001 году.

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

Основные принципы (из Agile-манифеста):

• люди и взаимодействие важнее процессов и инструментов;

• работающее ПО важнее исчерпывающей документации;

• сотрудничество с заказчиком важнее согласования условий контракта;

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

Подходы в рамках Agile: Scrum, Kanban, XP, Lean.

1) Scrum:

Ключевые роли:

• Product Owner (владелец продукта) — определяет приоритеты;

• Scrum Master — фасилитатор процесса;

• команда разработки (5–9 человек).

Цикл (спринт): 2–4 недели.

События:

• планирование спринта (выбор задач из бэклога);

• ежедневные стендапы (15 минут);

• обзор спринта (демонстрация результата);

• ретроспектива (анализ улучшений).

Артефакты:

• Product Backlog (приоритизированный список функций);

• Sprint Backlog (задачи текущего спринта);

• Increment (готовый к использованию функционал).

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

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

2) Kanban:

Суть: визуализация рабочего процесса и ограничение незавершённой работы (WIP — Work In Progress).

Инструменты: доска с колонками (например, «Запланировано» → «В работе» → «Готово»).

Правила:

• визуализировать поток задач;

• ограничить количество задач в работе;

• управлять потоком (ускорять узкие места);

• делать процессы явными;

• непрерывно улучшать.

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

Минусы: нет жёстких сроков, требует дисциплины в ограничении WIP.

Сравнение Scrum и Kanban:

3. DevOps:

История: концепция появилась в 2009 году.

Суть: объединение разработки (Dev) и эксплуатации (Ops) для непрерывной поставки ПО.

Цели:

• сократить время выхода на рынок;

• повысить стабильность и надёжность систем;

• автоматизировать процессы;

• обеспечить непрерывную обратную связь.

Ключевые практики:

• CI/CD (Continuous Integration / Continuous Delivery):

— CI — автоматическая сборка и тестирование кода при каждом коммите;

— CD — автоматизированное развёртывание в продакшн.

• Infrastructure as Code (IaC) — управление инфраструктурой через код (Terraform, Ansible).

• Мониторинг и логирование (Prometheus, Grafana, ELK Stack).

• Автоматизация тестирования (юнит-, интеграционные, нагрузочные тесты).

• Культура сотрудничества между командами Dev и Ops.

Инструменты:

• CI/CD: Jenkins, GitLab CI, GitHub Actions;

• контейнеризация: Docker, Kubernetes;

• оркестрация: Kubernetes, OpenShift;

• мониторинг: Prometheus, Grafana;

• IaC: Terraform, Ansible.

Преимущества:

• частые релизы (до нескольких раз в день);

• быстрое исправление ошибок;

• снижение рисков при развёртывании;

• прозрачность процессов.

Недостатки:

• требует значительных инвестиций в автоматизацию;

---

• сложная настройка инструментов;

• культурная трансформация команд.

Сравнение методологий:

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

1. Waterfall:

• требования стабильны и чётко определены;

• проект крупный, с жёсткими стандартами;

• бюджет и сроки фиксированы;

• низкая терпимость к изменениям (например, гособоронзаказ).

2. Agile (Scrum):

• требования могут меняться;

• нужен быстрый результат (MVP);

---

• есть доступ к заказчику/стейкхолдерам;

• команда готова к итеративной работе.

3. Agile (Kanban):

• непрерывный поток задач (поддержка, обслуживание);

• нет чёткого бэклога;

• приоритет — скорость выполнения отдельных задач.

4. DevOps:

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

• есть ресурсы на автоматизацию;

• важна стабильность и отказоустойчивость;

• команда готова к культуре сотрудничества Dev+Ops.

Гибридные подходы

На практике часто используют комбинации:

• Waterfall + Agile: Waterfall для проектирования, Agile для разработки.

• Scrum + DevOps: Scrum для планирования, DevOps для CI/CD.

• Kanban + DevOps: непрерывная поставка с визуализацией потока.

Пример:

Банк разрабатывает новую систему:

• Waterfall — для согласования требований с регуляторами;

• Agile — для итеративной разработки функционала;

• DevOps — для автоматизации тестирования и развёртывания.

Глава 9. Архитектура ПО: клиент-серверная, микросервисы, монолиты

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

1. Клиент-серверная архитектура:

Суть: разделение системы на две части:

• Клиент — интерфейс для взаимодействия с пользователем (браузер, мобильное приложение, десктоп-программа).

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

Виды:

• Двухзвенная (двухуровневая): клиент напрямую обращается к серверу (например, веб-сайт → веб-сервер).

• Трёхзвенная: добавляется промежуточный слой (сервер приложений) между клиентом и БД.

• Многоуровневая: несколько специализированных серверов (аутентификации, кэширования, аналитики).

Компоненты:

• клиентское приложение (GUI, логика отображения);

• сервер приложений (бизнес-логика);

• сервер БД (хранение данных);

• сеть (передача запросов/ответов).

Примеры:

• интернет-банк (мобильное приложение + сервер банка);

• онлайн-магазин (веб-сайт + сервер с каталогом товаров);

• корпоративная CRM (десктоп-клиент + центральный сервер).

---

Преимущества:

• чёткое разделение ролей;

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

• простота разработки для небольших систем;

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

Недостатки:

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

• сложность масштабирования при высокой нагрузке;

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

Когда выбирать:

• небольшие и средние проекты;

• приложения с централизованными данными;

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

2. Монолитная архитектура:

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

Структура (по слоям):

• Презентационный слой (UI/UX, взаимодействие с пользователем).

• Бизнес-логика (правила обработки данных, алгоритмы).

• Доступ к данным (работа с БД, кэширование).

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

Примеры:

• бухгалтерское ПО для малого бизнеса;

• система учёта товаров на складе;

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

Преимущества:

• простота разработки и тестирования (всё в одном месте);

• единый технологический стек (не нужно согласовывать языки/фреймворки);

• низкая стоимость развёртывания;

• естественная согласованность данных (единая БД).

---

Недостатки:

• сложность внесения изменений (риск сломать другие модули);

• ограниченная масштабируемость (масштабируется весь монолит);

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

• долгий цикл релизов (полное обновление системы);

• трудности параллельной разработки (конфликты кода).

Когда выбирать:

• MVP или стартап (быстрый запуск);

• небольшие команды разработки;

• проекты с чёткими и стабильными требованиями;

• системы без высокой нагрузки.

3. Микросервисная архитектура:

Суть: система разбивается на независимые сервисы, каждый из которых выполняет одну бизнес-функцию и имеет собственную БД. Сервисы взаимодействуют через API (REST, gRPC, сообщения).

Ключевые принципы:

• Автономность: каждый сервис развёртывается и обновляется независимо.

• Децентрализованное управление данными: у каждого сервиса своя БД (паттерн Database per Service).

• Лёгковесное взаимодействие: асинхронные сообщения или REST-запросы.

• Оркестрация: управление сервисами через API Gateway или Service Mesh.

Компоненты:

• микросервисы (авторизация, каталог товаров, платежи и т. д.);

• API Gateway (единая точка входа для клиентов);

• Service Registry (реестр сервисов);

• Message Broker (очереди сообщений — Kafka, RabbitMQ);

• инструменты оркестрации (Kubernetes, Docker Swarm).

Примеры (интернет-магазин):

• сервис пользователей (регистрация, профили);

• сервис каталога (товары, категории);

• сервис заказов (оформление, статусы);

• платёжный сервис;

• сервис уведомлений (email/SMS).

Преимущества:

• независимое масштабирование (нагруженные сервисы масштабируются отдельно);

• изоляция сбоев (падение одного сервиса не останавливает всю систему);

• технологическая гибкость (разные языки/фреймворки для разных сервисов);

• параллельная разработка (команды работают автономно);

• частые релизы (обновление одного сервиса без остановки системы).

Недостатки:

• высокая сложность проектирования и развёртывания;

• накладные расходы на сетевое взаимодействие между сервисами;

• проблемы с согласованностью данных (CAP-теорема);

• необходимость DevOps-инфраструктуры (CI/CD, мониторинг);

• рост операционных затрат (ресурсы на оркестрацию, логирование).

Когда выбирать:

• крупные и сложные системы;

• высоконагруженные проекты (миллионы пользователей);

• команды с разделением на специализированные группы;

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

---

Сравнение архитектур:

Гибридные подходы

На практике часто комбинируют архитектуры:

1. Монолит + микросервисы:

• ядро системы — монолит;

• нагруженные модули (платежи, аналитика) выделены в микросервисы.

2. Клиент-сервер + микросервисы:

• клиент обращается к API Gateway, который маршрутизирует запросы к микросервисам.

---

3. Модульный монолит:

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

Пример гибрида:

• Соцсеть:

— монолит — лента новостей и личные сообщения (частые изменения);

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

— клиент-сервер — мобильное приложение.

Как выбрать архитектуру:

1. Для стартапа/MVP: начните с монолита или клиент-сервера для быстрого запуска. Проектируйте с учётом возможной декомпозиции.

2. Для среднего бизнеса:

• стабильные требования → монолит;

• растущая нагрузка → модульный монолит или гибрид.

3. Для крупных систем:

• высокая нагрузка → микросервисы;

• критичность отказоустойчивости → микросервисы с резервным копированием.

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

• размер команды;

• бюджет на инфраструктуру;

• требования к масштабируемости;

• частота изменений функциональности;

• уровень экспертизы DevOps.

Глава 10. Основы баз данных: таблицы, связи, SQL
(базовый уровень)

1. Что такое база данных:

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

Реляционная БД — тип БД, где данные хранятся в таблицах, связанных между собой. Примеры: MySQL, PostgreSQL, Oracle, SQL Server.

2. Таблицы и их структура:

Таблица — основной объект реляционной БД. Состоит из:

• строк (записей) — содержат конкретные данные;

• столбцов (полей) — определяют типы данных.

Пример таблицы Users:

Типы данных в столбцах:

• числовые: INT, FLOAT;

• текстовые: VARCHAR (n), TEXT;

• дата/время: DATE, DATETIME;

• логические: BOOLEAN.

3. Ключи в базах данных:

Первичный ключ (Primary Key, PK) — уникальный идентификатор записи в таблице:

• гарантирует уникальность каждой строки;

• не может быть NULL;

• в таблице только один первичный ключ.

Внешний ключ (Foreign Key, FK) — столбец, ссылающийся на первичный ключ другой таблицы. Создаёт связь между таблицами.

Составной ключ — первичный ключ из нескольких столбцов.

4. Связи между таблицами:

• Один-к-одному (One-to-One):

— одна запись в таблице А связана с одной записью в таблице Б.

Пример: пользователь и его паспорт.

• Один-ко-многим (One-to-Many):

— одна запись в таблице А связана со многими записями в таблице Б.

Пример: автор (1) → книги (много).

• Многие-ко-многим (Many-to-Many):

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

— требует промежуточной таблицы.

Пример: студенты ↔ курсы.

Реализация связи многие-ко-многим:

• таблица Students: student_id (PK), name;

• таблица Courses: course_id (PK), title;

• промежуточная таблица Student_Courses: student_id (FK), course_id (FK).

5. SQL:

Базовый синтаксис:

SQL (Structured Query Language) — язык для работы с реляционными БД.

---

Основные команды (CRUD):

• CREATE — создание объектов:

sql

CREATE TABLE Users (

user_id INT PRIMARY KEY,

name VARCHAR (100),

email VARCHAR (255)

);

• INSERT — добавление данных:

sql

INSERT INTO Users (user_id, name, email)

VALUES (3, «Мария», 'maria@mail.com’);

• SELECT — выборка данных:

sql

— Все данные из таблицы:

SELECT * FROM Users;

— Конкретные столбцы:

SELECT name, email FROM Users;

— С условием:

SELECT * FROM Users WHERE user_id = 1;

• UPDATE — обновление данных:

sql

UPDATE Users

SET email = 'ivan_new@mail.com’

WHERE user_id = 2;

• DELETE — удаление данных:

sql

DELETE FROM Users

WHERE user_id = 3.

6. Операторы фильтрации и сортировки:

• WHERE — фильтрация по условию:

sql

SELECT * FROM Users WHERE registration_date> «2023-02-01»;

• AND/OR — комбинирование условий:

sql

SELECT * FROM Users

WHERE registration_date> «2023-01-01»

AND name LIKE «А%»;

• ORDER BY — сортировка:

sql

SELECT * FROM Users ORDER BY name ASC; — по возрастанию

SELECT * FROM Users ORDER BY registration_date DESC; — по убыванию;

• LIMIT — ограничение количества строк:

sql

SELECT * FROM Users LIMIT 5; — первые 5 записей.

7. Объединение таблиц (JOIN):

JOIN — операция для выборки данных из нескольких связанных таблиц.

Виды JOIN:

• INNER JOIN — возвращает только совпадающие строки:

sql

SELECT Users.name, Orders.amount

FROM Users

INNER JOIN Orders ON Users.user_id = Orders.user_id;

• LEFT JOIN — все строки из левой таблицы + совпадающие из правой:

sql

SELECT Users.name, Orders. order_id

FROM Users

LEFT JOIN Orders ON Users.user_id = Orders.user_id;

• RIGHT JOIN — все строки из правой таблицы + совпадающие из левой;

• FULL JOIN — все строки из обеих таблиц (если есть совпадения).

8. Агрегатные функции:

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

• COUNT () — количество строк;

• SUM () — сумма значений;

• AVG () — среднее значение;

• MAX () /MIN () — максимум/минимум.

Пример:

sql

SELECT COUNT (*) AS total_users FROM Users;

SELECT AVG (amount) AS avg_order FROM Orders;

GROUP BY — группировка данных:

sql

SELECT user_id, SUM (amount) AS total_spent

FROM Orders

GROUP BY user_id;

9. Практический пример:

Задача: создать базу данных интернет-магазина с таблицами:

• Customers (клиенты);

• Products (товары);

• Orders (заказы).

Создание таблиц:

sql

CREATE TABLE Customers (

customer_id INT PRIMARY KEY,

---

name VARCHAR (100)

);

CREATE TABLE Products (

product_id INT PRIMARY KEY,

title VARCHAR (200),

price DECIMAL (10, 2)

);

CREATE TABLE Orders (

order_id INT PRIMARY KEY,

customer_id INT,

product_id INT,

quantity INT,

FOREIGN KEY (customer_id) REFERENCES Customers (customer_id),

FOREIGN KEY (product_id) REFERENCES Products (product_id)

);

Запрос: показать заказы с именами клиентов и названиями товаров:

sql

SELECT

Customers.name,

Products. title,

Orders. quantity,

(Products.price * Orders. quantity) AS total_amount

FROM Orders

JOIN Customers ON Orders.customer_id = Customers.customer_id

JOIN Products ON Orders.product_id = Products.product_id;

10. Основные принципы проектирования БД:

• Нормализация — устранение избыточности данных:

— разбиение на связанные таблицы;

— минимизация дублирования информации.

• Целостность данных — обеспечение корректности связей:

— ограничения внешних ключей (ON DELETE CASCADE, ON UPDATE CASCADE);

— проверка значений (NOT NULL, UNIQUE).

• Индексы — ускорение запросов:

— создаются на столбцах, используемых в WHERE/JOIN;

— пример: CREATE INDEX idx_email ON Users (email).

Глава 11. API: REST, SOAP, GraphQL (концептуально)

API (Application Programming Interface) — это набор правил и инструментов для взаимодействия между программами. Разберём три ключевых подхода к построению API: REST, SOAP и GraphQL.

1. REST (Representational State Transfer):

REST — архитектурный стиль для построения распределённых систем (впервые описан Роем Филдингом в 2000 году).

Ключевые принципы:

• Клиент-серверная архитектура: чёткое разделение клиента и сервера.

• Отсутствие состояния (Stateless): каждый запрос содержит всю необходимую информацию; сервер не хранит данные о состоянии клиента.

• Кэширование: ответы могут быть закэшированы для повышения производительности.

• Единообразный интерфейс: стандартизированные методы HTTP (GET, POST, PUT, DELETE и др.).

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

• Код по требованию (опционально): сервер может передавать исполняемый код (например, JavaScript).

• HATEOAS (Hypermedia as the Engine of Application State): ответы содержат ссылки на связанные ресурсы.

Основные HTTP-методы:

• GET — получение данных;

• POST — создание нового ресурса;

• PUT/PATCH — обновление существующего ресурса;

• DELETE — удаление ресурса.

Формат данных: чаще JSON, иногда XML.

Пример запроса (получение списка пользователей):

http

GET /api/users HTTP/1.1

Host: example.com

Accept: application/json

Ответ:

json

[

{

«id»: 1,

«name»: «Анна»,

«email»: "anna@mail.com»

}

]

Преимущества REST:

• простота и интуитивность;

• широкое распространение;

• поддержка кэширования на уровне HTTP;

• гибкость форматов данных;

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

Недостатки REST:

• избыточная выборка данных (over-fetching): клиент получает больше информации, чем нужно;

• недостаточная выборка (under-fetching): требуется несколько запросов для получения связанных данных;

• нет единой структуры — разные разработчики реализуют REST по-разному;

• версионирование API (REST часто требует версий: v1, v2 и т. д.).

Где применяется REST:

• публичные API (Twitter, GitHub, Stripe);

• мобильные приложения;

---

• веб-сервисы с простой структурой данных;

• микросервисы.

2. SOAP (Simple Object Access Protocol):

SOAP — протокол обмена структурированными сообщениями в распределённых системах (основан на XML).

Ключевые особенности:

• строго формализованный стандарт (спецификации WSDL, WS-Security, WS-ReliableMessaging);

• использует XML для запросов и ответов;

• поддерживает различные транспортные протоколы (HTTP, SMTP, TCP);

• имеет встроенную обработку ошибок (код ошибки + описание);

• обеспечивает высокий уровень безопасности (интеграция с WS-Security).

Структура SOAP-сообщения:

• Envelope — корневой элемент;

• Header — опциональный заголовок (аутентификация, транзакции);

• Body — основное содержимое запроса/ответа;

• Fault — информация об ошибках.

Пример SOAP-запроса:

xml

<soap: Envelope xmlns: soap="http://www.w3.org/2003/05/soap-envelope">

<soap: Header>

<auth: Credentials xmlns: auth="http://example.com/auth">

<auth: Username> user </auth: Username>

<auth: Password> pass </auth: Password>

</auth: Credentials>

</soap: Header>

<soap: Body>

<GetUserDetails xmlns="http://example.com/api">

<UserID> 123 </UserID>

</GetUserDetails>

</soap: Body>

</soap: Envelope>

Преимущества SOAP:

• независимость от языка и платформы;

• встроенная безопасность (шифрование на уровне сообщений);

• надёжность (поддержка транзакций);

• строгая типизация и валидация через WSDL;

• работа с разными транспортными протоколами.

Недостатки SOAP:

• тяжеловесность (большие XML-файлы);

• сложность реализации и настройки;

• низкая производительность из-за накладных расходов на XML;

• жёсткая структура (трудно вносить изменения).

Где применяется SOAP:

• корпоративные системы (банки, страховые компании);

• биллинговые системы;

• системы бронирования (авиабилеты, отели);

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

3. GraphQL:

GraphQL — язык запросов для API, разработанный в 2012 году Facebook (принадлежит компании Meta, которая признана экстремистской организацией и запрещена в РФ). Позволяет клиенту точно указать, какие данные ему нужны.

Ключевые концепции:

• единая точка входа (endpoint);

• схема данных (Schema) — описание типов, полей и связей;

• запросы (Queries) — получение данных;

• мутации (Mutations) — изменение данных;

• подписки (Subscriptions) — real-time обновления.

Пример GraphQL-запроса (получение имени и email пользователя):

graphql

query {

user (id: 1) {

name

email

}

}

Ответ:

json

{

«data»: {

«user»: {

«name»: «Анна»,

«email»: "anna@mail.com»

}

}

}

Пример мутации (создание пользователя):

graphql

mutation {

createUser (name: «Иван», email: "ivan@mail.com») {

id

name

}

}

Преимущества GraphQL:

• клиент запрашивает только нужные поля (нет over/under-fetching);

• единая версия API (схема эволюционирует без версионирования);

• строгая типизация (SDL — Schema Definition Language);

• подробная информация об ошибках;

• гибкая авторизация (можно выборочно раскрывать поля);

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

Недостатки GraphQL:

• сложность проектирования схемы для больших систем;

• риск перегрузки сервера из-за сложных вложенных запросов;

• проблема N+1 (множество запросов к БД из-за вложенности);

• требуется дополнительная оптимизация (DataLoader);

• менее распространён, чем REST.

Где применяется GraphQL:

• сложные системы с множеством связанных сущностей;

• мобильные приложения (экономия трафика);

• микросервисные архитектуры (единая точка входа);

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

Сравнительная таблица: