Модели разработки
Зачем нужно
Модель разработки (SDLC model) определяет КАК организован процесс создания ПО: какие фазы, в каком порядке, как обрабатывать изменения. Выбор модели влияет на скорость, качество и стоимость проекта. На собеседовании это один из стандартных вопросов.
Где используется
- Планирование проектов — выбор подходящего процесса
- Собеседования — знание моделей обязательно
- Командная работа — понимание текущего процесса
- RS School — Agile/Scrum используется в командных проектах
Waterfall (Каскадная модель)
┌──────────────┐
│ Requirements │
└──────┬───────┘
▼
┌──────────────┐
│ Design │
└──────┬───────┘
▼
┌──────────────┐
│Implementation│
└──────┬───────┘
▼
┌──────────────┐
│ Testing │
└──────┬───────┘
▼
┌──────────────┐
│ Deployment │
└──────┬───────┘
▼
┌──────────────┐
│ Maintenance │
└──────────────┘
| Плюсы | Минусы |
|---|---|
| Простая и понятная | Нет гибкости к изменениям |
| Чёткие фазы и документация | Результат видим только в конце |
| Легко планировать сроки | Поздняя обратная связь |
| Подходит для фиксированных требований | Высокий риск несоответствия |
Когда использовать: требования полностью известны и не изменятся (госзаказ, встроенные системы).
V-Model (V-образная модель)
Requirements ──────────────────────── Acceptance Testing
\ /
System Design ────────────── System Testing
\ /
Architecture ───────── Integration Testing
\ /
Module Design ──── Unit Testing
\ /
Implementation
Каждая фаза разработки имеет соответствующую фазу тестирования.
| Плюсы | Минусы |
|---|---|
| Тестирование планируется рано | Такая же негибкость как Waterfall |
| Чёткая связь требования → тест | Нет прототипирования |
| Высокое качество | Дорого при изменениях |
Когда использовать: проекты с высокими требованиями к качеству (медицина, авиация).
Spiral (Спиральная модель)
Planning
/ \
Evaluation Risk Analysis
\ /
Development
& Testing
Каждый виток спирали — новая итерация с анализом рисков.
| Плюсы | Минусы |
|---|---|
| Управление рисками | Сложная и дорогая |
| Итеративность | Нужен опыт в оценке рисков |
| Гибкость | Много документации |
Когда использовать: крупные дорогие проекты с высокими рисками.
Iterative (Итеративная модель)
Итерация 1: [Req] → [Design] → [Code] → [Test] → Версия 1.0
Итерация 2: [Req] → [Design] → [Code] → [Test] → Версия 2.0
Итерация 3: [Req] → [Design] → [Code] → [Test] → Версия 3.0
Каждая итерация — мини-Waterfall. Продукт развивается инкрементально.
| Плюсы | Минусы |
|---|---|
| Раннее получение работающего ПО | Может быть сложно определить scope итерации |
| Возможность вносить изменения | Архитектура может не выдержать изменений |
| Постоянная обратная связь | Требует опытного управления |
Agile
User Story → Sprint (2-4 недели) → Increment → Feedback → Repeat
Sprint 1: [Plan] → [Dev] → [Test] → [Review] → [Retro] → Инкремент
Sprint 2: [Plan] → [Dev] → [Test] → [Review] → [Retro] → Инкремент
Sprint 3: [Plan] → [Dev] → [Test] → [Review] → [Retro] → Инкремент
Agile Manifesto (ценности)
Люди и взаимодействие > Процессы и инструменты
Работающий продукт > Исчерпывающая документация
Сотрудничество с заказчиком > Согласование условий контракта
Готовность к изменениям > Следование первоначальному плану
| Плюсы | Минусы |
|---|---|
| Гибкость к изменениям | Сложно оценить полную стоимость |
| Быстрая обратная связь | Требует вовлечённости заказчика |
| Работающий продукт каждый спринт | Может не подойти для больших команд |
| Мотивация команды | Менее формализованная документация |
Когда использовать: большинство современных проектов, особенно веб-разработка.
Сравнительная таблица
| Параметр | Waterfall | V-Model | Iterative | Agile |
|---|---|---|---|---|
| Гибкость | Низкая | Низкая | Средняя | Высокая |
| Обратная связь | В конце | В конце | Каждую итерацию | Каждый спринт |
| Документация | Полная | Полная | Средняя | Минимальная |
| Риски | Высокие | Средние | Средние | Низкие |
| Изменения | Дорого | Дорого | Возможны | Приветствуются |
| Тестирование | Фаза в конце | Параллельно | Каждую итерацию | Непрерывно |
| Когда использовать | Фикс. требования | Критичное качество | Средние проекты | Большинство проектов |
Когда какую модель выбрать
Требования чёткие и не изменятся?
├── Да → Waterfall / V-Model
└── Нет
├── Проект большой и рискованный? → Spiral
├── Нужна частая обратная связь? → Agile
└── Инкрементальное развитие? → Iterative
Частые ошибки
| Ошибка | Проблема | Решение |
|---|---|---|
| Waterfall для стартапа | Требования постоянно меняются | Используй Agile |
| Agile без дисциплины | Хаос вместо гибкости | Следуй практикам Scrum/Kanban |
| Нет тестирования в итерации | Баги накапливаются | Тестируй каждую итерацию |
| Путают Agile и отсутствие процесса | «Мы Agile = мы ничего не планируем» | Agile = адаптивный ПРОЦЕСС |
| Жёсткий Waterfall для веб-проекта | Медленная доставка | Перейди на итеративный подход |
Практика
- Определи, какая модель используется в твоём текущем проекте
- Сравни Waterfall и Agile для разработки интернет-магазина
- Составь аргументы ЗА и ПРОТИВ Agile для конкретного проекта
- Нарисуй V-Model для простого веб-приложения
- Подготовь ответ на вопрос «Какие модели разработки вы знаете?»
Связанные темы
- Agile и Scrum — подробнее о Scrum
- Kanban — альтернатива Scrum
- QA термины — терминология тестирования
- Жизненный цикл тестирования — STLC