IT-продукт и этапы его жизненного цикла

IT-продукт – это совокупность программно-аппаратных средств (программное решение, основанное на технологической базе), которое предоставляет выполнение заложенных функций, определяющих его суть. Также IT-продукт имеет себестоимость и может быть продан (внедрён) или сдан в аренду на определённый срок конечному потребителю.
Если простыми словами:
IT-продукт – это любое программное обеспечение, сайт, мобильное приложение и другая IT-система, которая разрабатывается и внедряется для выполнения определённых функций.
Жизненный цикл продукта (программного обеспечения) — этапы, через которые IT-продукт проходит от начала создания до конца разработки и внедрения в бизнес-среду. Кратко можно выделить следующие основные этапы:

1. Подготовка
2. Проектирование
3. Создание
4. Поддержка

⚠️ Внимание ⚠️
Этапы могут называться по-другому и дробиться («декомпозироваться») на более мелкие
стадии.

Классификация моделей разработки

Есть следующие модели управления разработкой продукта:

1. Waterfall Model (каскадная модель или «Водопад»).
2. V-образная модель (разработка через тестирование).
3. Спиральная модель.
4. Инкрементная модель.
5. Итеративная или итерационная модель.
6. Гибкие модели, методологии и подходы (Agile, Scrum, Kanban и другие).

Waterfall Model — каскадная модель или «Водопад»

Waterfall предполагает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом разработки ПО. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены.

Когда использовать Waterfall

• Требования известны, понятны и зафиксированы.
• Нет противоречивых требований к функциональности продукта.
• Нет проблем с доступностью программистов нужной квалификации.
• В относительно небольших проектах.

⚠️ Внимание ⚠️
Waterfall обладает как преимуществами, так и недостатками.

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

• Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, и может управлять сроками и стоимостью.
• Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».
• Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки:

• Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, её исправление дорого обойдётся. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию.
• Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
• Разработчики пишут много технической документации, что задерживает работу. Чем обширнее документация проекта, тем больше изменений нужно вносить и дольше их согласовывать.

V-образная модель (разработка через тестирование)

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

Преимущество V-образной модели в том, что количество ошибок в архитектуре ПО сводится к минимуму. А недостаток, как и у модели Waterfall, — в дороговизне исправления ошибок, допущенных при разработке архитектуры.

Спиральная модель

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

При этом есть и недостатки:

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

Agile

Agile («эджайл») переводится с английского как «гибкий». Подход включает в себя следующие практики и методологии для эффективной работы над продуктом:

• экстремальное программирование (Extreme Programming, XP);
• бережливая разработка программного обеспечения (Lean);
• фреймворк для управления проектами Scrum;
• разработка, управляемая функциональностью (Feature-driven development, FDD);
• разработка через тестирование (Test-driven development, TDD);
• методология «чистой комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методология разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
• метод управления разработкой Kanban.

Из всех перечисленных выше гибких подходов наиболее часто в IT применяют Scrum и Kanban.

Scrum

• Scrum обычно называют не методологией, а фреймворком. ○ Фреймворк — это более сформированная методология со строгими правилами.
• В Scrum все роли и процессы чётко прописаны.

Kanban

Сегодня Kanban является одной из наиболее популярных методологий разработки ПО. Если коротко, принцип Kanban состоит в следующем:

• команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта;
• каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.

В отличие от Scrum, при использовании Kanban-подхода можно взять срочные задачи в разработку сразу, не дожидаясь начала следующей итерации.