IT продукты, то есть сам результат деятельности персонала таких компаний, как наша, создаются не просто так. Существует определенная схема, по которой все делается.
И разрабатывалась эта схема (или фреймворк, если угодно) действительно «кровью и потом», а именно после потраченных впустую времени, финансов и прочих ресурсов. Дабы минимизировать их потери, как раз и появилась модель SDLC — Software Development Life Cycle или Software Development Process.
Что такое SDLC? Это, как мы уже говорили, модель создания IT продукта. Она помогает направить и оптимизировать рабочий процесс, увеличить понимание между заказчиком и исполнителем, обеспечить качественное исполнение и работу готового продукта, да и вообще это Черный Плащ, который спешит на помощь айтишникам.
SDLC включает 6 этапов:
Первые три этапа созданы для того, чтобы и клиент, и команда знали ответы на вопросы:
Анализ требований: *«Какие проблемы продукт должен решить?»*Планирование: *«Что мы будем для этого делать?»*Создание архитектуры: *«Как мы будем это делать?»*
В свою очередь, последние три регулируют аспекты реализации:
Написание кода: *Процесс создания продукта*Тестирование: *Качество продукта и отсутствие ошибок*Вывод на рынок и последующая поддержка: *Использование продукта и обратная связь с пользователями*
Цикл этот замкнутый. Все в итоге возвращается к этапу анализа требований, и опять по новой. Это значит, что продукт (например, приложение социальной сети) выходит готовым не сразу. Вспомните Instagram: какой он был в 2012 году и какой сейчас? Постепенное появление новых фишек реализовалось с помощью цикличности SDLC-фреймворка.
Цикличная модель SDLC появилась не сразу. Ранее продукты создавались по модели Waterfall (модель водопада, каскадная модель). Этапы были те же, но не было самого цикла. То есть вернуться на предыдущий было или дорого, или совсем невозможно.
Существовали также и модели, в которых зарождался принцип цикличности. Например, итеративная модель (iterative model) — разные циклы (кодинг, тестирование, релиз) по разным сегментам продукта производились одновременно. Однако, такая модель требует колоссального контроля, а также повышает риск появления недостатков в построенной архитектуре.
Отдельно стоит модель спирали (spiral model): проект проходит через 4 итерации т.е. спирали.
Единственное отличие в сути этапов каждой спирали — в конце есть анализ рисков. Эта модель хорошо подходит для проектов с определенными рисками, как например для абсолютно нового продукта. Но при этом, недостатки ее также имеют место быть: сложная система управления, вероятность неравенства разных «спиралей» по значению, а также сама сложность такого рабочего процесса.
По V-модели процесс выполняется согласно V-образной форме. Разработка каждого шага связана напрямую с тестированием. Однако, V-образный метод не подойдет для долгосрочных и комплексных проектов.
И, наконец, модель большого взрыва (Big Bang model). Она — воплощение первобытного хаоса. В ней никто не следует никаким процессам и рамкам. Она не требует планирования. Важны только изначальные ресурсы и результат. И даже заказчик не уверен, чего именно он хочет. Но такой фреймворк (если тут вообще есть «фрейм») применим только для маленьких проектов и команд. Ну и подойдет для новичков в кодинге.