Расширенная каскадная модель

Этот материал объясняет понятие расширенной каскадной модели, включая типичные экзаменационные вопросы, ключевые компоненты и теги. Каждый день читайте “случайную статью” на этом сайте и расширяйте свои знания. Даже если многие темы поначалу покажутся новыми.

Суть

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

Описание в двух словах

В расширенном каскаде фазы по-прежнему идут последовательно (Требования → Проектирование → Реализация → Тестирование → Внедрение/Поддержка), но:

• Есть определенные откаты в предыдущую фазу, если критерии приемки не выполнены.
• Планирование тестирования и QA готовятся параллельно (например, план тестирования уже на фазе анализа/проектирования).
• Прототипы (UI или архитектурные спайки) применяются на ранней стадии для валидации неясных требований или технических рисков.

Ключевые термины:

• Верификация: “Правильно ли мы разработали продукт?” (относительно спецификации)
• Валидация: “Правильный ли продукт мы разработали?” (относительно деловой цели)

Популярно особенно на экзаменах IHK для специалистов-разработчиков приложений

Почему? Каскадная модель идеально подходит для небольших проектов, которые обычно выполняются в рамках обучения или стажировки. Расширенная каскадная модель менее жесткая и позволяет исправлять ошибки благодаря откатам. И я выбрал именно эту модель для своего проекта, потому что её легко объяснять и применять на практике.

Важные термины подробнее

Базовые версии

Определение: Базовая версия это зафиксированное состояние проектных артефактов на определенный момент времени. Она служит точкой отсчета для будущих изменений.

Типы базовых версий:

• Baseline требований: Утвержденные требования (техническое задание, спецификация)
• Baseline проектирования: Выпущенные документы проектирования (архитектура, модульный дизайн)
• Baseline кода: Стабильная, протестированная версия кода (Release Candidate)
• Baseline тестирования: Принятые результаты тестирования и протоколы тестов

Пример: После фазы требований создается baseline требований. Все последующие изменения должны быть официально заявлены как Change Request.

Change Request

Определение: Change Request это формальный запрос на изменение уже заданных артефактов.

Процесс Change Request:

1. Подача запроса: Кто просит что и зачем?
2. Анализ влияния: Какие последствия имеет изменение?
3. Оценка: Взвешивание затрат, выгод и рисков
4. Решение: Одобрение или отклонение Change Advisory Board (CAB)
5. Реализация: Выполнение изменения и документирование

Пример: Клиент хочет добавить новую функцию во время разработки. Это требует Change Request с анализом влияния.

Анализ влияния

Определение: Анализ влияния исследует последствия планируемого изменения для всего проекта.

Области анализа:

• Технические последствия: Какие компоненты нужно изменить?
• Временные последствия: Увеличивается ли длительность проекта?
• Финансовые последствия: Дополнительные затраты на разработку и тестирование?
• Качественные последствия: Влияет ли изменение на качество системы?
• Рисковые последствия: Возникают ли новые технические или проектные риски?

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

Отслеживаемость от требований к тестам

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

Цепь отслеживаемости:

Требование (REQ-001) → Проектирование (ARCH-015) → Код (CODE-042) → Тест (TEST-087)

Назначение отслеживаемости:

• Доказательство полноты: Каждое требование реализовано и протестировано
• Анализ влияния: При изменениях быстро определить затронутые области
• Обеспечение качества: Выявлять пробелы в покрытии
• Аудит: Для соответствия нормативным требованиям и сертификации

Пример матрицы отслеживаемости:

ID требования	Требование	ID проектирования	Компонент кода	ID тестового случая	Статус
REQ-001	Регистрация пользователя	ARCH-015	UserService.java	TEST-087	✅
REQ-002	Восстановление пароля	ARCH-016	PasswordService.java	TEST-088	✅
REQ-003	Каталог товаров	ARCH-017	ProductService.java	TEST-089	❌

Популярно на экзаменах IHK для специалистов-разработчиков приложений

Почему расширенная каскадная модель так важна на экзаменах IHK:

1. Структурированный подход

IHK проверяет, способны ли кандидаты работать систематично и структурированно. Расширенная каскадная модель обеспечивает именно эту структуру с четкими фазами и ответственностью.

2. Осознание качества

Обеспечение качества это центральная тема на экзаменах IHK. Расширенная каскадная модель интегрирует QA-мероприятия на каждой фазе (обзоры, тесты, прототипы).

3. Требование к документации

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

4. Управление рисками

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

5. Управление изменениями

На практике изменения нужно управлять профессионально. Change Request и анализ влияния это компетенции, проверяемые IHK.

6. Прозрачность решений

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

7. Практическая значимость

Многие средние компании до сих пор работают по каскадным моделям. IHK готовит к реальным условиям работы.

Типичные сценарии экзамена IHK:

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

Расширенная каскадная модель в деталях

Ход фаз с обратными связями

    ┌─────────────────────┐
    │  1. Фаза требований │
    │                     │
    └─────────┬───────────┘
              │ Приемка
              ▼
    ┌─────────────────────┐
    │  2. Системное       │◄────────────────┐
    │      проектирование │                 │
    └─────────┬───────────┘                 │
              │ Приемка                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  3. Архитектурное   │◄────────────────┤
    │      проектирование │                 │
    └─────────┬───────────┘                 │
              │ Приемка                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  4. Модульное       │◄────────────────┤
    │      проектирование │                 │
    └─────────┬───────────┘                 │
              │ Приемка                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  5. Реализация      │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Приемка                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  6. Подготовка      │◄────────────────┤
    │      к тестированию │                 │
    └─────────┬───────────┘                 │
              │ Приемка                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  7. Тестирование    │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Приемка                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  8. Внедрение       │                 │
    └─────────────────────┘                 │
                                           │
                                           │ Контролируемые
                                           │ откаты при
                                           │ ошибках
                                           └─────────────────

Подробное описание фаз

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

Цели: полностью собрать, зафиксировать и утвердить требования

Артефакты:

• Техническое задание (видение клиента)
• Спецификация требований (видение поставщика)
• Каталог требований с идентификаторами
• Критерии приемки
• Глоссарий

Действия:

• Интервью со стейкхолдерами
• Семинары с функциональными отделами
• Анализ требований
• Приоритизация (MoSCoW)
• Техническое утверждение

Обеспечение качества:

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

Типичные возвраты: как правило, отсутствуют, так как это отправная точка

---

Фаза 2: Системный дизайн

Цели: определить границы системы, специфицировать интерфейсы

Артефакты:

• Диаграмма контекста
• Каталог интерфейсов
• Диаграммы потоков данных
• Системная архитектура (на высоком уровне)
• Технические концепции

Действия:

• Определение границ системы
• Описание внешних интерфейсов
• Моделирование потоков данных
• Спецификация нефункциональных требований
• Обоснование выбора технологий

Обеспечение качества:

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

Типичные возвраты: неясные требования → фаза анализа требований

---

Фаза 3: Архитектурный дизайн

Цели: определить детальную архитектуру, минимизировать технические риски

Артефакты:

• Диаграмма компонентов
• Диаграмма развертывания
• Модель данных (ERD)
• Каталог целей качества
• Документ архитектурных решений (ADR)

Действия:

• Разработка компонентов
• Моделирование данных
• Определение атрибутов качества
• Разработка прототипов (спайки UI, подтверждение технологий)
• Детализация концепций безопасности

Обеспечение качества:

• Рецензирование архитектуры
• Тестирование прототипов
• Бенчмарки производительности
• Обзоры безопасности

Типичные возвраты: технические неясности → системный дизайн

---

Фаза 4: Дизайн модулей

Цели: детальное проектирование всех модулей, финализация контрактов интерфейсов

Артефакты:

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

Действия:

• Проектирование классов и объектов
• Спецификация алгоритмов
• Проектирование базы данных
• Дизайн UI (экраны, макеты)
• Концепции интеграции

Обеспечение качества:

• Рецензирование дизайна
• Тестирование генерации кода
• Нормализация базы данных
• Тестирование удобства использования UI

Типичные возвраты: проблемы дизайна → архитектурный дизайн

---

Фаза 5: Реализация

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

Артефакты:

• Исходный код (версионированный)
• Модульные тесты
• Документация кода
• Скрипты сборки
• Пакеты развертывания

Действия:

• Программирование в соответствии со стандартами
• Рецензирование кода
• Статический анализ кода
• Разработка модульных тестов
• Continuous Integration

Обеспечение качества:

• Рецензирование кода
• Статический анализ (SonarQube)
• Покрытие модульными тестами
• Соответствие стандартам кодирования

Типичные возвраты: проблемы реализации → дизайн модулей

---

Фаза 6: Подготовка тестирования

Цели: создать комплексную стратегию тестирования, развернуть среду тестирования

Артефакты:

• Концепция тестирования
• Тестовые случаи (детальные)
• Тестовые данные
• Скрипты автоматизации тестирования
• Среды тестирования

Действия:

• Определение стратегии тестирования
• Извлечение тестовых случаев (из требований)
• Подготовка тестовых данных
• Разработка автоматизации тестирования
• Настройка сред тестирования

Обеспечение качества:

• Рецензирование концепции тестирования
• Анализ покрытия тестовыми случаями
• Валидация тестовых данных
• Проверка сред тестирования

Типичные возвраты: пробелы в тестировании → реализация/дизайн модулей

---

Фаза 7: Выполнение тестирования

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

Артефакты:

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

Действия:

• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование
• Тестирование приемки
• Тестирование производительности

Обеспечение качества:

• Рецензирование тестов
• Анализ ошибок
• Регрессионное тестирование
• Проверка приемки

Типичные возвраты: системные ошибки → реализация/архитектура

---

Фаза 8: Внедрение

Цели: запустить производственную эксплуатацию, обучить пользователей, предоставить документацию

Артефакты:

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

Действия:

• Установка/развертывание
• Миграция данных
• Обучение пользователей
• Создание руководства по эксплуатации
• Построение структуры поддержки

Обеспечение качества:

• Тестирование установки
• Валидация миграции
• Обратная связь от обучения
• Проверка готовности поддержки

Типичные возвраты: проблемы эксплуатации → выполнение тестирования

Ключевые моменты для экзамена

• Последовательные фазы с контролируемыми возвратами
• Ранее интегрировать планирование тестирования (критерии приемки уже в анализе)
• Верификация/валидация на каждой фазе (рецензирования, обходы)
• Gate-решения с критериями приемки (IHK)
• Прототипирование для снижения рисков
• Трассировка (требование → дизайн → код → тест)
• Управление изменениями плюс базовые конфигурации

Основные компоненты

1. Анализ требований (техническое задание/спецификация, критерии приемки)
2. Системный дизайн (контекст, интерфейсы, модель данных)
3. Архитектурный дизайн (цели качества, решения, прототипы)
4. Дизайн модулей (детальное проектирование, контракты интерфейсов)
5. Реализация (рецензирование, статический анализ)
6. Подготовка тестирования (концепция тестирования, тестовые случаи, данные)
7. Выполнение тестирования (модульное/интеграционное/системное/приемочное)
8. Внедрение (миграция, эксплуатация, документация)
9. Контролируемые возвраты между фазами
10. Управление конфигурацией/изменениями (версионирование)

Верификация и валидация в деталях

Верификация: “Правильно ли мы создаём продукт?”

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

Методы верификации:

• Рецензирование кода: соответствует ли код стандартам кодирования?
• Модульные тесты: удовлетворяют ли функции спецификацией требования?
• Статический анализ: содержит ли код известные ошибки или антипаттерны?
• Интеграционные тесты: работают ли интерфейсы в соответствии со спецификацией?
• Рецензирование документации: полна ли и корректна ли документация?

Пример верификации:

Спецификация: "Функция пароля должна принимать 8-20 символов"
Верификация: модульный тест проверяет граничные значения 7, 8, 20, 21 символов
Результат: ✅ спецификация корректно реализована

Валидация: “Создаём ли мы правильный продукт?”

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

Методы валидации:

• Приемочные тесты: удовлетворяет ли система бизнес-требования?
• Тесты удобства использования: могут ли пользователи интуитивно работать с системой?
• Бета-тестирование: реагируют ли реальные пользователи как ожидается?
• Тесты производительности: достигает ли система требуемую производительность?
• Тесты безопасности: достаточно ли система безопасна для использования?

Пример валидации:

Требование: "Пользователи должны быстро и просто войти в систему"
Валидация: 50 пользователей-тестировщиков выполняют задачу входа (измерение: <3 секунды)
Результат: ✅ достигнута приемлемость пользователями, потребность удовлетворена

V-модель: взаимосвязь верификации и валидации

Анализ требований ←───────────────── Приемочное тестирование (валидация)
        ↓                                    ↑
Системный дизайн ←───────────────── Системное тестирование (валидация)
        ↓                                    ↑
Архитектурный дизайн ←─────── Интеграционное тестирование (верификация)
        ↓                                    ↑
Дизайн модулей ←───────────────── Модульное тестирование (верификация)
        ↓                                    ↑
Реализация ────────────────────────

Комплексный практический пример: платформа электронной торговли

Обзор проекта

Цель: разработка платформы электронной торговли с интеграцией внешних платёжных систем Команда: 8 человек (2 руководителя, 2 архитектора, 4 разработчика) Длительность: 6 месяцев Бюджет: 450.000€

Фаза 1: требования (4 недели)

Созданные артефакты:

Техническое задание (заказчик):
- 150 пользовательских историй с критериями приёмки
- 23 нефункциональных требования
- 12 интеграционных интерфейсов

Спецификация (исполнитель):
- Детальные технические описания
- Технические ограничения
- График и бюджет

Матрица отслеживания:
REQ-001 → ARCH-015 → TEST-087
REQ-045 → INTF-003 → TEST-156
...

Критерии выхода:

• ✅ Все требования приоритизированы (MoSCoW)
• ✅ Одобрение 3 заинтересованными лицами
• ✅ Матрица отслеживания завершена
• ✅ Анализ рисков выполнен

Результат: фаза одобрена, задокументированы 2 запроса на изменение

---

Фаза 2: системный дизайн (3 недели)

Созданные артефакты:

Диаграмма контекста:
- 8 внешних систем (платежи, CRM, ERP и т. д.)
- 3 роли пользователей (покупатель, администратор, партнёр)

Каталог интерфейсов:
- REST API: 47 endpoints
- SOAP: 3 унаследованных интерфейса
- Message Queue: 12 типов событий

Диаграммы потоков данных:
- Процесс заказа (7 этапов)
- Обработка платежа (4 этапа)
- Синхронизация инвентаря (ежедневно)

Решение о прототипе: разработан UI-прототип для процесса оформления заказа → положительный отзыв пользователей

Критерии выхода:

• ✅ Все внешние интерфейсы специфицированы
• ✅ Требования к производительности определены (<2s время загрузки)
• ✅ Концепция безопасности разработана
• ✅ Технологический стек определён (React, Node.js, PostgreSQL)

Обратная связь: 1 неясное требование → возврат на фазу 1

---

Фаза 3: архитектурный дизайн (3 недели)

Созданные артефакты:

Диаграмма компонентов:
- Frontend: React SPA
- Backend: 6 микросервисов
- База данных: PostgreSQL + Redis Cache
- Message Queue: RabbitMQ

Цели качества:
- Производительность: <2s время ответа
- Доступность: 99.9%
- Масштабируемость: 10.000 одновременных пользователей
- Безопасность: покрыты OWASP Top 10

ADR (Architecture Decision Records):
ADR-001: выбрана микросервисная архитектура
ADR-003: событийно-управляемая для асинхронности
ADR-007: CQRS для сложных запросов

Технические прототипы:

• интеграция платежей (spike: 3 дня)
• тест производительности (нагрузка: 5.000 пользователей)
• тест безопасности (penetration test)

Критерии выхода:

• ✅ архитектурный review пройден
• ✅ бенчмарки производительности достигнуты
• ✅ review безопасности пройден
• ✅ прототипы успешны

---

Фаза 4: дизайн модулей (2 недели)

Созданные артефакты:

Диаграммы классов:
- User Service: 12 классов
- Order Service: 18 классов
- Payment Service: 8 классов

Спецификации интерфейсов:
- Internal API: 67 методов
- External API: 47 endpoints
- Database Schema: 23 таблицы

UI Design:
- 47 вайрфреймов
- 23 High-Fidelity макета
- Адаптивный дизайн (мобильная/настольная версия)

Обеспечение качества:

• design review с senior-разработчиками
• нормализация базы данных (3NF)
• тесты UI usability с 5 пользователями

---

Фаза 5: реализация (8 недель)

Созданные артефакты:

Исходный код:
- 45.000 строк кода
- 237 unit-тестов (92% покрытие)
- 47 integration-тестов

CI/CD pipeline:
- Automated Builds
- Code Quality Checks (SonarQube)
- Automated Testing
- Deployment to Staging

Метрики качества:

• Code Coverage: 92%
• SonarQube Quality Gate: ✅ Passed
• Build Time: 4 минуты
• Test Execution: 8 минут

Обратная связь: 2 проблемы производительности → возврат на фазу 4

---

Фаза 6: подготовка к тестированию (2 недели)

Созданные артефакты:

Концепция тестирования:
- 4 уровня тестирования (unit/integration/system/acceptance)
- 3 тестовых окружения (dev/staging/prod)
- Автоматизация тестов: Selenium + Cypress

Тестовые случаи:
- 345 функциональных тестов
- 67 performance-тестов
- 23 security-теста
- 12 usability-тестов

Тестовые данные:
- 1.200 синтетических клиентов
- 5.000 тестовых продуктов
- 800 тестовых заказов

---

Фаза 7: выполнение тестирования (4 недели)

Результаты тестирования:

Модульные тесты: 237/237 ✅ (100%)
Integration тесты: 45/47 ✅ (96%)
Системные тесты: 89/95 ✅ (94%)
Performance тесты: 22/23 ✅ (96%)
Security тесты: 20/23 ❌ (87%)

Обнаруженные дефекты:
- Critical: 2 (уязвимости безопасности)
- Major: 8 (функциональные ошибки)
- Minor: 15 (проблемы UI)

Обратная связь:

• уязвимости безопасности → возврат на фазу 3 (архитектура)
• проблема производительности → возврат на фазу 4 (дизайн)

---

Фаза 8: развёртывание (2 недели)

Созданные артефакты:

Deployment:
- Docker контейнеры
- Kubernetes конфигурация
- Мониторинг (Prometheus + Grafana)
- Логирование (ELK Stack)

Документация:
- Руководство установки (45 страниц)
- Руководство пользователя (120 страниц)
- Руководство администратора (80 страниц)
- API документация (OpenAPI 3.0)

Обучение:
- 12 администраторских семинаров
- 45 пользовательских тренингов
- 8 справочников поддержки

Результат go-live:

• ✅ развёртывание успешно
• ✅ миграция данных завершена
• ✅ пользователи обучены
• ✅ мониторинг активен

---

Итоги проекта

Успехи:

• ✅ график соблюдён (+2 недели резерва)
• ✅ бюджет соблюдён (+5%)
• ✅ цели качества достигнуты
• ✅ приёмка пользователями: 87%

Вызовы:

• 3 крупных возврата (фазы 3, 4, 7)
• 2 запроса на изменение во время разработки
• 1 проблема безопасности в последний момент

Полученные уроки:

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

Преимущества и недостатки

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

• чёткое планирование и ответственность
• ранее обнаружение ошибок (reviews/прототипы)
• меньше дорогостоящих изменений на позднем этапе
• хорошее документирование (аудит/сертификация)

Недостатки

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

Отслеживание требований и управление ими

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

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

Пример матрицы отслеживания:

ID требования	Текст требования	Элемент дизайна	Компонент кода	Тестовый случай	Статус
REQ-001	Регистрация пользователя с проверкой email	UserRegistrationController	UserRegistrationService	TEST-001, TEST-002	✅
REQ-015	Функция сброса пароля	PasswordResetController	PasswordResetService	TEST-045, TEST-046	✅
REQ-023	Каталог продуктов с фильтрацией	ProductCatalogController	ProductService	TEST-089, TEST-090	❌
REQ-034	Функция корзины	ShoppingCartController	CartService	TEST-123, TEST-124	✅

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

• Requirements Management Tools: JIRA, Polarion, DOORS
• Test Management Tools: TestRail, Zephyr, Xray
• Excel/Google Sheets: для небольших проектов
• Custom Solutions: скрипты для отслеживания требований

Процесс отслеживания требований

1. Захват требования → REQ-XXX
2. Привязка к дизайну → ARCH-XXX
3. Связь с реализацией → CODE-XXX
4. Вывод тестовых случаев → TEST-XXX
5. Документирование приёмки → STATUS: ✅/❌
6. Анализ отклонений → Change Request

Управление изменениями и базовые версии

Определение базовых версий

Базовая версия: фиксированное состояние артефактов в определённый момент времени.

Типы базовых версий:

• Requirements Baseline: утверждённые требования
• Design Baseline: утверждённые проектные документы
• Code Baseline: стабильная версия кода
• Test Baseline: принятые результаты тестирования

Процесс управления изменениями

Подать запрос на изменение
        ↓
Провести анализ влияния
        ↓
Change Advisory Board (CAB) оценивает
        ↓
Решение: Одобрено/Отклонено
        ↓
При одобрении:
  - Обновить базовую версию
  - Адаптировать прослеживаемость
  - Информировать затронутые фазы
  - Провести тестирование

Шаблон запроса на изменение:

CR-2024-001
Название: Изменение политики паролей
Обоснование: Новые требования безопасности
Воздействие:
- REQ-015: Повысить сложность пароля
- ARCH-007: Адаптировать Password Validator
- TEST-045: Добавить новые тестовые случаи
Оценка стоимости: 8 часов
Приоритет: Высокий
Одобрено: ✅

Сравнение с другими моделями разработки

Классический каскад vs. Расширенный каскад

Критерий	Классический каскад	Расширенный каскад
Обратные связи	Нет	Контролируемые возвраты
Обнаружение ошибок	Поздно (фаза тестирования)	Рано (прототипы/обзоры)
Гибкость	Очень низкая	Умеренная
Трудозатраты на планирование	Низкие	Высокие
Управление рисками	Ограниченное	Комплексное
Документация	Обширная	Очень обширная

Каскад vs. V-модель

Модель каскада:
Требования → Проектирование → Реализация → Тестирование → Внедрение
    ↓
    ↑
   (Прямой связи нет)

V-модель:
Сбор требований ←─────── Приемочное тестирование
        ↓                      ↑
Проектирование системы ←─────── Системное тестирование
        ↓                      ↑
Архитектурное проектирование ←─── Интеграционное тестирование
        ↓                      ↑
Проектирование модулей ←─────── Модульное тестирование
        ↓                      ↑
Реализация ────────────────

Каскад vs. Гибкие методологии

Аспект	Каскад	Гибкие методы (Scrum/Kanban)
Планирование	Предварительное, детальное	Итеративное, адаптивное
Изменения	Дорогие, формальные	Простые, приветствуются
Риск	Высокий (в конце)	Низкий (рано)
Прозрачность	По фазам	Постоянная
Обратная связь от клиента	В конце	Каждая итерация
Структура команды	Функциональные отделы	Кросс-функциональные

Когда подходит расширенный каскад

✅ Подходит для:

• Регулируемых отраслей (медицина, автомобилестроение, авиация)
• Критичных по безопасности систем
• Проектов со стабильными требованиями
• Государственных и муниципальных проектов
• Систем с высокими требованиями соответствия

❌ Менее подходит для:

• Нестабильных рынков
• Стартапов с частыми изменениями стратегии
• Проектов с неясными требованиями
• Небольших экспериментальных проектов
• Продуктов, ориентированных на пользователя с частыми изменениями UX

Типичные вопросы экзамена (с кратким ответом)

1. Разница между классическим и расширенным каскадом? Расширенный имеет определенные возвраты, раннее обеспечение качества и прототипирование.

2. Роль прототипов? Ранее валидировать риски (производительность, безопасность, пользовательский опыт).

3. Верификация vs. валидация? Верификация проверяет соответствие спецификации, валидация проверяет соответствие назначению.

4. Как управлять возвратами? Решение в контрольной точке, анализ влияния, запрос на изменение, повторная приемка.

5. Что такое базовая версия? Зафиксированное состояние артефактов на определенный момент времени.

6. Назначение прослеживаемости? Обеспечить реализацию и тестирование каждого требования.

7. Процесс запроса на изменение? Анализ влияния → оценка CAB → одобрение → реализация.

8. Преимущества перед классическим каскадом? Раннее обнаружение ошибок, лучший контроль рисков, выше качество.

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

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

Стратегия обучения

1. Визуализировать фазы с артефактами и критериями приемки

Метод: создайте детальный обзор фаз со всеми релевантными артефактами и критериями контрольных точек.

Практическое упражнение:

Фаза 1: Фаза требований
├── Артефакты: Техническое задание, спецификация требований, каталог требований
├── Деятельность: Интервью со stakeholder-ами, мастер-классы, приоритизация
├── Меры обеспечения качества: Обзоры требований, проверки согласованности
└── Критерии контрольной точки: ✅ Все требования приоритизированы, ✅ Одобрение заказчика

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

2. Подробно разобрать сценарий обратной связи

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

Практический пример:

Сценарий: интеграционное тестирование дает сбой
├── Обнаружение ошибки: интеграционное тестирование на этапе 7
├── Анализ ошибки: проблема производительности при доступе к БД
├── Анализ влияния: определить затронутые компоненты
├── Запрос на изменение: создать и одобрить CR-2024-001
├── Обратная связь: вернуться к этапу 4 (архитектурное проектирование)
├── Исправление: оптимизировать проектирование БД
├── Новое тестирование: добавить тесты производительности
└── Повторная приемка: этап 7 успешно пройден

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

3. Систематически сравнить модели разработки

Метод: создайте матрицу сравнения основных моделей с конкретными критериями.

Заполните матрицу сравнения:

Критерий	Классический каскад	Расширенный каскад	V-модель	Scrum
Ход фаз	Линейный	Линейный с возвратами	V-образный	Итеративный
Гибкость	Очень низкая	Умеренная	Низкая	Очень высокая
Управление рисками	Позднее	Раннее (прототипы)	Раннее	Постоянное
Документация	Обширная	Очень обширная	Обширная	Минимальная
Обратная связь клиента	В конце	На промежуточных этапах	На промежуточных этапах	Каждая итерация

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

4. Создать практическую таблицу прослеживаемости

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

Пример проекта: система регистрации пользователей

Требования:
REQ-001: Пользователь может зарегистрироваться с email и паролем
REQ-002: Пароль должен быть 8-20 символов
REQ-003: Email должен быть валидирован
REQ-004: Повторные email-адреса должны быть исключены

Проектирование:
ARCH-001: UserRegistrationController
ARCH-002: PasswordValidator
ARCH-003: EmailService
ARCH-004: UserRepository

Реализация:
CODE-001: UserRegistrationService.java
CODE-002: PasswordValidator.java
CODE-003: EmailValidator.java
CODE-004: UserRepository.java

Тестовые случаи:
TEST-001: Регистрация с корректными данными
TEST-002: Регистрация с коротким паролем
TEST-003: Регистрация с неправильным email
TEST-004: Регистрация с существующим email

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

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

Метод: смоделируйте запрос на изменение для текущего проекта.

Сценарий упражнения:

Исходная ситуация: проект находится на этапе 5 (реализация)
Запрос на изменение: добавить функцию «Social Login»

Выполнение:
1. Заполнить форму запроса на изменение
2. Провести анализ влияния:
   - Технически: необходима интеграция OAuth2
   - По времени: +2 недели на разработку
   - По стоимости: +8.000€
3. Оценить риски: безопасность OAuth2-интеграции
4. Принять решение: одобрено с дополнительными тестами безопасности
5. Обновить базовые версии и адаптировать прослеживаемость

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

6. Подготовка к экзамену

Метод: подготовься к типичным вопросам на экзамене IHK с помощью структурированных ответов.

Практика типичных экзаменационных вопросов:

• “Опишите фазы расширенной каскадной модели с основными артефактами.”
• “Объясните разницу между верификацией и валидацией на практическом примере.”
• “Как вы проводите анализ влияния при изменении требований?”
• “Какую роль играют прототипы в расширенной каскадной модели?”

Структура ответа:

1. Объясни определение/концепцию
2. Приведи практический пример
3. Укажи преимущества/недостатки
4. Подчеркни аспекты, релевантные для IHK

7. График подготовки к экзамену

Рекомендуемые этапы обучения:

Неделя 1: освоение основ

• Изучи фазы и артефакты
• Разберись в верификации и валидации
• Повтори базовые термины

Неделя 2: углубление

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

Неделя 3: применение

• Анализируй практические примеры
• Сравни с другими моделями
• Ответь на экзаменационные вопросы

Неделя 4: повторение

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

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

Основные источники

1. https://de.wikipedia.org/wiki/Wasserfallmodell
2. https://dl.acm.org/doi/10.1145/360248.360251

Типичные экзаменационные вопросы