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

Глава 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):

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