Урок 01.03: Жизненный цикл ПО (SDLC)

Цель урока

Детально изучить модели жизненного цикла разработки ПО (Waterfall и Agile/Scrum), разобрать каждую фазу Waterfall на конкретных примерах, а также понять, что именно делает аналитик в каждом событии Scrum: от планирования спринта до ретроспективы.

Ключевые понятия

• SDLC (Software Development Life Cycle) — жизненный цикл разработки ПО; последовательность фаз, которые проходит проект от возникновения идеи до вывода из эксплуатации
• Waterfall (каскадная модель) — модель, в которой каждая следующая фаза начинается только после полного завершения предыдущей
• Agile — философия гибкой разработки, основанная на итеративности, инкрементальности и тесном взаимодействии с заказчиком
• Scrum — фреймворк Agile, в котором работа ведётся фиксированными итерациями (спринтами) длиной 1–4 недели
• Спринт (Sprint) — зафиксированный по времени период (обычно 2 недели), в течение которого команда создаёт готовый к поставке инкремент продукта
• Backlog (бэклог) — упорядоченный по приоритету список задач/функций, которые нужно реализовать
• User Story — короткая запись требования с точки зрения пользователя (формат: «Как [роль], я хочу [цель], чтобы [причина]»)
• Increment (инкремент) — сумма всех выполненных за спринт задач + результаты предыдущих спринтов; готовый к поставке кусок продукта

---

1. Общая картина: что такое SDLC и зачем это знать аналитику

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

1. Выбор метода работы: в зависимости от модели (Waterfall / Agile) меняется глубина и формат артефактов аналитика.
2. Планирование активности: аналитик должен знать, когда и какие артефакты от него потребуются.
3. Коммуникация: аналитик объясняет заказчику, почему на фазе «Требования» нельзя начать разработку, а на фазе «Тестирование» — менять требования без change request.

Две основные модели: взгляд с высоты

Waterfall (каскад):
  Идея → [Требования] → [Проектирование] → [Разработка] → [Тестирование] → [Внедрение]
         ←—— аналитик здесь ——→

Agile (итеративный):
  Спринт 1: [Анализ] [Разработка] [Тест] → инкремент
  Спринт 2: [Анализ] [Разработка] [Тест] → инкремент
  Спринт 3: ...
         ←—— аналитик здесь В КАЖДОМ спринте ——→

---

2. Waterfall (каскадная модель): детальный разбор

2.1. Общая характеристика

Waterfall — классическая модель, пришедшая из строительства и машиностроения. Её суть: завершил фазу — передал результат дальше. Назад не возвращаемся.

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

• Проекты с фиксированным бюджетом и сроками (госзаказ, оборонка)
• Системы с высокими требованиями к безопасности (медицина, авионика, атомная энергетика)
• Проекты, где заказчик чётко знает, что хочет
• Когда жёсткая регуляторика требует полной документации до начала разработки

Недостатки (почему Waterfall критикуют):

• Позднее обнаружение ошибок (на фазе тестирования может выясниться, что требования поняты неверно)
• Сложность внесения изменений (нужен formal change request, который дорогой и долгий)
• Заказчик видит работающий продукт только в конце

2.2. Фазы Waterfall — пошаговый разбор

Фаза 1: Анализ требований (Requirements Analysis)

Что происходит: Аналитик погружается в предметную область, собирает и документирует требования.

Конкретные шаги аналитика:

Шаг	Что делает аналитик	Результат
1. Изучение предметной области	Читает регламенты, нормативные акты, интервьюирует экспертов	Понимание AS-IS
2. Идентификация стейкхолдеров	Составляет карту стейкхолдеров (включая скрытых)	Список заинтересованных лиц
3. Сбор требований	Проводит интервью, анкетирование, воркшопы	Сырой список потребностей
4. Анализ и классификация	Делит на функциональные / нефункциональные, приоритизирует	Структурированные требования
5. Документирование	Пишет SRS / ТЗ	SRS (утверждённый заказчиком)

Роль аналитика: Максимальная. Это «звездный час» аналитика. Он — главное действующее лицо.

Пример: Для системы «Электронный документооборот» аналитик за 3 недели:

• Изучает 5 внутренних регламентов
• Проводит 10 интервью с начальниками отделов
• Собирает 78 требований
• Пишет SRS на 60 страниц
• Согласует с заказчиком (подпись — переход к фазе 2)

Ключевой вопрос: «Что должна делать система?»

Фаза 2: Проектирование (Design / System Architecture)

Что происходит: На основе SRS архитектор и аналитик проектируют, как система будет устроена технически.

Конкретные шаги аналитика:

Шаг	Что делает аналитик	Результат
1. Функциональная декомпозиция	Разбивает систему на модули	Диаграмма компонентов
2. Проектирование API	Описывает эндпоинты, форматы данных	API-контракты (OpenAPI)
3. Проектирование БД	Строит ER-диаграмму, Data Dictionary	Модель данных
4. Моделирование процессов	Строит BPMN / UML диаграммы	Модели процессов
5. Прототипирование UI	Совместно с UI/UX-дизайнером	Wireframes / мокапы
6. Спецификация интерфейсов	Описывает форматы ввода/вывода	Interface specs

Роль аналитика: Высокая, но совместно с архитектором. Аналитик отвечает за то, чтобы дизайн соответствовал требованиям. Архитектор — за техническую реализуемость.

Пример: Для того же ЭДО аналитик:

• Выделяет модули: «Авторизация», «Загрузка документов», «Маршрутизация», «Подписание ЭЦП», «Архив»
• Описывает API: POST /api/v1/documents — загрузка, POST /api/v1/documents/{id}/sign — подписание
• Рисует Sequence Diagram для сценария «Подписание документа»

Артефакты: Software Design Document (SDD), API-спецификации, ER-диаграмма, UML-диаграммы.

Ключевой вопрос: «Как технически устроена система?»

Фаза 3: Разработка (Implementation / Coding)

Что происходит: Разработчики пишут код на основе SRS и SDD.

Роль аналитика: Поддерживающая (средняя активность).

• Отвечает на уточняющие вопросы разработчиков
• Уточняет детали требований (но НЕ меняет их без change request)
• Участвует в код-ревью только в части соответствия требованиям (не технической)

Конкретные ситуации:

Ситуация	Реакция аналитика
Разработчик: «В SRS сказано "отправить уведомление", но не указан канал (email/SMS/push)»	Аналитик смотрит в SRS, если там действительно нет — уточняет у заказчика и выдаёт дополнение к SRS
Разработчик: «Это требование технически нереализуемо в указанные сроки»	Аналитик обсуждает с архитектором, вместе предлагают альтернативу, согласуют с заказчиком
Разработчик: «Я сделал, проверьте, соответствует ли это требованию FR-012»	Аналитик проводит informal review

Ключевой вопрос: «Я правильно понял требование?»

Фаза 4: Тестирование (Testing)

Что происходит: QA-инженеры проверяют, что система соответствует SRS.

Роль аналитика: Контрольная (средняя активность).

• Ревью тест-кейсов: проверяет, что тесты покрывают все требования из SRS
• Участвует в приёмочном тестировании (UAT — User Acceptance Testing): помогает заказчику проверить, что система делает то, что нужно
• Фиксирует несоответствия и баги (deviation from requirements)

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

Пример: QA написал тест-кейс: «Пользователь загружает документ формата PDF — система сохраняет». Аналитик проверяет: в требовании FR-023 сказано «поддерживаются форматы PDF, DOCX, PNG». Аналитик добавляет тест-кейсы для DOCX и PNG, а также негативный сценарий — загрузка EXE.

Ключевой вопрос: «Система соответствует спецификации?»

Фаза 5: Внедрение (Deployment / Implementation)

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

Роль аналитика: Поддерживающая.

• Составляет инструкции для пользователей (user manual)
• Проводит обучение пользователей (тренинги)
• Помогает службе поддержки (Helpdesk) — пишет FAQ
• Участвует в опытно-промышленной эксплуатации (ОПЭ)
• Фиксирует первые замечания пользователей для следующей версии

Пример: Аналитик проводит 5 тренингов для операторов ЭДО, записывает видеоинструкцию «Как подписать документ ЭЦП», передаёт в Helpdesk список типовых вопросов и ответов.

Ключевой вопрос: «Пользователи могут работать с системой?»

Фаза 6: Сопровождение (Maintenance)

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

Роль аналитика: Минимальная / эпизодическая.

• Анализирует запросы на доработку (change requests)
• Оценивает влияние изменений на существующую архитектуру
• Если изменения значительны — цикл может начаться заново (новая версия → новый Waterfall)

Ключевой вопрос: «Что нужно улучшить в следующей версии?»

2.3. Схема прохождения Waterfall с указанием загрузки аналитика

Фаза:       Требования → Проектирование → Разработка → Тестирование → Внедрение → Сопровождение
Загрузка СА: ██████████    ████████        ████         ██████        ████        ██
             (100%)        (80%)           (30%)        (50%)         (30%)       (10%)
             
Артефакты:   SRS           SDD + диаграммы  —            Отчёт по UAT   Инструкции  Change log

---

3. Agile / Scrum: роль аналитика в деталях

3.1. Философия Agile vs Waterfall для аналитика

Аспект	Waterfall	Agile
Требования	Полный SRS в начале, изменения — формальный change request	Бэклог живёт и evolves; требования уточняются каждый спринт
Документация	Подробная, каждый шаг зафиксирован	Минимально необходимая (just enough); упор на работающий продукт
Контакт с заказчиком	В начале и в конце проекта	Постоянный (в конце каждого спринта — демо)
Ошибки	Обнаруживаются поздно, дорогие	Обнаруживаются рано, дешёвые
Роль аналитика	«Архитектор требований»: спроектировал — передал	«Связной»: постоянно уточняет, переприоритизирует

Важный нюанс: Agile не отменяет аналитика. Он меняет характер его работы. В Agile аналитик не пишет 100-страничный SRS до старта разработки, а постоянно взаимодействует с командой и заказчиком, вытягивая и уточняя требования ровно настолько, насколько нужно для следующего спринта (just-in-time requirements).

3.2. Структура Scrum-команды: роль аналитика

В Scrum нет роли «аналитик» как отдельной позиции в Scrum Guide. Аналитик может быть:

• Членом Development Team — если нанимается как универсал (часто в небольших командах)
• Отдельной ролью рядом с командой — если аналитик работает с Product Owner и командой (часто в крупных компаниях)

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

Роль в Scrum	Функция	Что делает аналитик
Product Owner	Владелец продукта: отвечает за ценность и приоритеты	Аналитик помогает PO: собирает требования, детализирует User Stories, оценивает технические риски
Scrum Master	Обеспечивает соблюдение Scrum, устраняет блокеры	Аналитик НЕ выполняет роль SM (хотя может помогать с фасилитацией)
Development Team	Разработчики, тестировщики, аналитик	Аналитик — полноценный член команды, отвечает за качество требований

3.3. События Scrum: что делает аналитик?

1. Backlog Refinement (Grooming) — уточнение бэклога

Что это: Регулярная встреча (обычно 1 раз в спринт, 1–2 часа), на которой команда и PO уточняют, оценивают и приоритизируют задачи из бэклога для будущих спринтов.

Цель для аналитика: Подготовить User Stories до состояния «Ready» (готово к разработке), то есть так, чтобы команда могла взять задачу в спринт и начать работать без дополнительных вопросов.

Пошаговый процесс работы аналитика в Grooming:

ДО GRooming (подготовка):
  1. Собрать обратную связь от пользователей / заказчика
  2. Написать черновики User Stories
  3. Проставить acceptance criteria (критерии приёмки)
  4. Приложить ссылки на прототипы / диаграммы
  5. Проставить предварительный приоритет (совместно с PO)

НА GRooming:
  1. Презентовать Story команде (2–3 минуты)
  2. Ответить на вопросы: «А что если...?», «А как быть с...?»
  3. Зафиксировать уточнения прямо в карточке задачи
  4. Помочь команде оценить сложность (Story Points):
     — объяснить технические нюансы
     — указать зависимости от других Stories
     — предупредить о рисках
  5. Договориться о критериях готовности (Definition of Ready)

ПОСЛЕ GRooming:
  1. Дополнить требования на основе вопросов команды
  2. Согласовать изменения с PO
  3. Обновить диаграммы / прототипы, если нужно
  4. Переместить Story в топ бэклога (status: Ready)

Конкретный пример диалога аналитика на Grooming:

Аналитик: «У нас есть Story: "Как пользователь, я хочу отфильтровать список заказов по дате, чтобы быстро найти нужный". Acceptance Criteria: 1) Поле выбора даты "с" и "по"; 2) По умолчанию — последние 7 дней; 3) Результаты обновляются без перезагрузки страницы.»

Разработчик: «А что, если пользователь выберет дату "по" раньше, чем дату "с"?»

Аналитик: «Хороший вопрос. Давайте добавим: если дата "по" раньше, чем "с" — показывать предупреждение и не применять фильтр. Я обновлю критерии.»

Определение Ready (DoR — Definition of Ready): Чек-лист, по которому команда определяет, что Story готова к спринту:

• Заголовок и описание понятны команде
• Acceptance Criteria сформулированы
• Прототип / ссылка на дизайн приложены (если нужен UI)
• Зависимости от других задач известны
• Технические риски оценены
• Story оценина в Story Points
• PO подтвердил приоритет

---

2. Sprint Planning — планирование спринта

Что это: Встреча в начале спринта (обычно 2–4 часа для 2-недельного спринта), на которой команда решает, какие задачи войдут в спринт и как они будут реализованы.

Участвуют: Вся Scrum-команда (PO, SM, Development Team, аналитик).

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

Два этапа планирования:

Этап	Что происходит	Что делает аналитик
Часть 1: Что мы делаем? (What)	PO представляет цели спринта (Sprint Goal) и топ-приоритет Stories из бэклога	Аналитик помогает PO: напоминает контекст, объясняет бизнес-ценность каждой Story
Часть 2: Как мы это сделаем? (How)	Команда разбивает Stories на задачи (tasks), оценивает часы	Аналитик отвечает на технические вопросы по требованиям, уточняет Acceptance Criteria, помогает не забыть граничные случаи (edge cases)

Что аналитик делает ДО планирования:

• Проверяет, что все Stories в топе бэклога имеют статус Ready
• Готовит ответы на возможные вопросы разработчиков
• Согласует с PO, какие Stories обязательно должны войти в спринт

Что аналитик делает ВО ВРЕМЯ планирования:

Действие	Пример
Переформулирует бизнес-язык в технический	PO: «Нужна аналитика по заказам». Аналитик: «Конкретно: таблица с колонками "Дата, Сумма, Статус" + график по дням. Данные из PostgreSQL, агрегация через SQL»
Уточняет границы Story	«Эта Story включает бэкенд API, НО не включает отображение на фронтенде — это следующая Story»
Выявляет зависимости	«Story A требует, чтобы была готова Story B (таблица users), поэтому A не может быть в этом спринте, если B не готова»
Помогает декомпозировать крупные Stories	«Давайте разобьём "Корзина покупок" на: 1) Добавление товара, 2) Удаление, 3) Пересчёт суммы»
Фиксирует технические решения	«Договорились, что для фильтрации используем server-side pagination, а не client-side»

Результат для аналитика:

• Sprint Backlog (список задач спринта) с чёткими требованиями
• Возможно, несколько новых уточняющих записей в Stories
• Понимание, что нужно подготовить к следующему уточнению бэклога

---

3. Daily Scrum (стендап) — ежедневная синхронизация

Что это: 15-минутная ежедневная встреча, где каждый отвечает на 3 вопроса: «Что сделал вчера? Что буду делать сегодня? Есть ли блокеры?»

Роль аналитика:

• Кратко отчитывается по своей работе (уточнение требований, подготовка бэклога, анализ)
• Фиксирует блокеры, связанные с неясными требованиями
• Если разработчик говорит: «Я не уверен, как должна работать эта функция» — аналитик берёт в работу уточнение

Важно: Это НЕ встреча для детального обсуждения требований. Если требуется глубокая дискуссия — аналитик назначает отдельную встречу (after-scrum).

---

4. Sprint Review (Демо) — показ результатов

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

Роль аналитика:

• Готовит сценарий демонстрации (checklist: что показываем, какие данные используем)
• Помогает разработчику показать ровно то, что соответствует Acceptance Criteria
• Фиксирует feedback от стейкхолдеров («А можно ещё вот так?») — эти пожелания уходят в бэклог

Пример: Аналитик перед демо проверяет: «Показываем сценарий "Успешная регистрация", потом "Ошибка при неверном email". Заказчик настаивает, чтобы был ещё "Восстановление пароля" — но это не делали в этом спринте, объясняем, что это в бэклоге на следующий спринт».

---

5. Sprint Retrospective — ретроспектива

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

Роль аналитика:

На ретроспективе аналитик говорит о качестве требований и взаимодействии:

Типичная проблема (голос аналитика)	Действие на ретро
«В этом спринте трижды менялись требования в середине задачи — это привело к переделкам»	Предложить: «Давайте договоримся, что после Sprint Planning требования не меняются; если change — выносим в следующий спринт»
«Разработчики начали задавать вопросы по Story, которую я не успел подготовить — пришлось ждать ответа 2 дня»	Предложить: «Усилим Definition of Ready: без утверждённых Acceptance Criteria Story не берём в спринт»
«Заказчик на демо сказал, что функционал ему не нужен — потратили спринт впустую»	Предложить: «Усилим контакт с заказчиком до спринта — показывать прототипы до разработки»
«Тестировщики нашли баги из-за неполных требований (не описали граничные случаи)»	Действие: «На Grooming будем уделять 5 минут на brainstorm граничных случаев для каждой Story»
«Взаимодействие с PO было хорошим: он сразу отвечал на вопросы»	Закрепить: продолжать в том же духе

Формат: Аналитик участвует как равноправный член команды. Его голос важен, потому что он видит «узкие места» на стыке бизнеса и разработки.

Action Items (конкретные улучшения), которые может предложить аналитик:

1. Добавить в Definition of Ready пункт: «Прототип утверждён дизайнером»
2. Завести в бэклоге технический долг: «Документировать нефункциональные требования»
3. Договориться с PO: ответ на вопрос команды — не дольше 4 часов
4. Проводить ad-hoc встречу «Требования» перед планированием спринта

---

3.4. Сравнительная таблица: что аналитик делает в Waterfall vs Agile

Действие аналитика	Waterfall	Agile
Сбор требований	Единоразово, в начале (недели-месяцы)	Постоянно, each sprint
Документирование	Полный SRS (100+ страниц)	User Stories + Acceptance Criteria (лёгкие артефакты)
Уточнение требований	Через change request (формально, долго)	На Grooming / Planning (неформально, быстро)
Участие в тестировании	Ревью тест-плана, UAT в конце	Помощь в написании тест-кейсов в каждом спринте
Контакт с заказчиком	Фаза требований + UAT	Каждый Sprint Review (раз в 2 недели)
Реагирование на изменения	Сложно, дорого	Просто, дёшево (early sprint)

---

4. Другие модели SDLC (краткий обзор)

4.1. Iterative (итеративная модель)

Суть: Проект делится на итерации (обычно 2–4 недели), но в отличие от Agile:

• Требования фиксируются в начале
• В каждой итерации — полный цикл: анализ → дизайн → разработка → тест
• Заказчик видит результат после каждой итерации

Роль аналитика: Как в Waterfall, но «размазанная» по итерациям. В каждой итерации — свой мини-SRS для части функционала.

4.2. Spiral (спиральная модель)

Суть: Каждый виток спирали — это анализ рисков + prototip + разработка + планирование следующего витка.

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

4.3. V-Model

Суть: Каждой фазе разработки соответствует фаза тестирования того же уровня. V-Model — «зеркальный» Waterfall.

Требования ←→ Acceptance Testing
Проектирование ←→ Integration Testing
Детальный дизайн ←→ Unit Testing
        Разработка

Роль аналитика: Как в Waterfall, плюс активное участие в написании Acceptance Criteria на уровне требований.

4.4. DevOps-цикл (Continuous Delivery)

Суть: Разработка, тестирование, развёртывание и мониторинг слиты в непрерывный процесс.

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

---

5. Как аналитику выбрать модель для проекта: чек-лист

Вопрос	Если ДА → склоняемся к
Требования известны и стабильны?	Waterfall / V-Model
Бюджет и сроки строго фиксированы?	Waterfall (но с рисками)
Есть регулятор, требующий полную документацию до старта?	Waterfall
Заказчик готов к постоянному взаимодействию?	Agile
Требования могут меняться в процессе?	Agile
Проект высокорисковый (новая технология, инновация)?	Spiral / Agile
Нужен быстрый выход на рынок (MVP)?	Agile
Команда распределённая?	Agile (Scrum of Scrums)

---

Вопросы для самопроверки

1. Назовите все 6 фаз Waterfall. На какой фазе загрузка аналитика максимальна?
2. Что такое SRS и SDD? В чём разница?
3. В чём отличие подхода к требованиям в Waterfall и Agile?
4. Что такое Definition of Ready (DoR)? Какие пункты вы бы в него включили?
5. Опишите, что делает аналитик на каждом из трёх событий Scrum: Backlog Refinement, Sprint Planning, Sprint Retrospective.
6. Почему в Agile аналитик не может «один раз написать требования и забыть»?
7. Какую модель SDLC вы выберете для:
   • (а) системы управления ядерным реактором;
   • (б) мобильного приложения для заказа пиццы;
   • (в) внутреннего портала для документооборота небольшой компании? Обоснуйте.

---

Практическое задание

Кейс: Вам нужно разработать систему бронирования переговорных комнат в офисе на 300 человек.

Часть 1. Предположите, что проект идёт по Waterfall. Напишите:

• Какие артефакты вы создадите на фазе «Требования» (2–3 предложения о каждом)
• Какие артефакты — на фазе «Проектирование»

Часть 2. Предположите, что проект идёт по Agile (Scrum). Напишите:

• Как будет выглядеть ваш Backlog Refinement (что вы подготовите, как пройдёт встреча)
• Какие вопросы вы зададите на Retrospective, если в спринте разработчики 3 раза подходили с вопросом «А как на самом деле должна работать эта функция?»

Формат: свободная форма (документ / таблица).

---

Дополнительные материалы

• Scrum Guide (последняя версия) — bible для Scrum: https://scrumguides.org/
• Книга: «Scrum и XP: заметки с передовой» — Henrik Kniberg (коротко, практично, бесплатно)
• Книга: «Software Requirements» — Karl Wiegers (детально про требования в разных моделях)
• Стандарт: ISO/IEC/IEEE 12207 — процессы жизненного цикла ПО
• Статья (Agile vs Waterfall): «Agile vs Waterfall: Choosing the Right Methodology for Your Project» (Barry Boehm, 2003 — классика)
• Шаблон: DoR / DoD (Definition of Ready / Definition of Done) — примеры в открытом доступе