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

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

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

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

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

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

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

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

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

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

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

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

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

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. Клиент-серверная архитектура:

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

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

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

Виды:

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