- Суть
- Этапы SDLC
- SDLC и STLC в одном рисунке
- Классический SDLC: плюсы и минусы
- Методологии SDLC
- Как выбрать методологию разработки — таблица и сравнения
Что такое STLC
SDLC (Software Development Life Cycle) — последовательность этапов разработки тем или иным способом, с применением тех или иных подходов. После возникновения бизнес-идеи и сбора требований они будут реализованы в функциях приложения, которые удовлетворят потребности клиентов. Разработчик (и тестировщик) должен понимать особенности разных моделей SDLC, и почему выбрана та или иная модель.
Этапы SDLC
В общем виде SDLC состоит из 6 этапов:
- Планирование
- Анализ
- Дизайн
- Разработка и тестирование
- Имплементация
- Поддержка (обслуживание)
Планирование
Самая первая фаза (этап) начинается со сбора требований и последующего планирования, сообразно полученным требованиям. Некоторые считают этот этап самым важным, определяющим, особенно с точки зрения проджект-менеджера и стейкхолдеров.
На этом этапе находят ответы на вопросы:
- Как будет использоваться приложение?
- Какие данные будут вводиться в него («подаваться на вход»)?
- Что собой будет представлять вывод?
- Кто будет пользователями этого приложения?
Анализ
Как только требования стали известны, настало время анализировать их, на валидность и применимость, возможность практического осуществления. Команда решает, возможно ли добавить те или иные требования в этот продукт. Далее создается документ Спецификаций требований, служащий основой при переходе к следующему этапу:
Дизайн
Дизайн требований, описанных и уточненных на предыдущих этапах. Подбираются инструменты, программные и аппаратные, описывается общая архитектура приложения. Спецификации системного дизайна, подготовленные на этом этапе, служат указаниями для следующего, четвертого, этапа. А на текущем, третьем этапе, при активном участии QA-департамента создается стратегия тестирования, в которой описывается, что будет тестироваться, и как.
Разработка и тестирование
В некоторых командах принято осуществлять разработку и тестирование одновременно в одном этапе, в других командах принято разделять на два этапа. После того как создана документация по системе, разработка разбивается на модули (юниты), и начинается собственно написание кода.
Для команды разработчиков данный этап является самым важным. Он также является самым длительным этапом в SDLC. После написания кода (или параллельно с) выполняется тестирование продукта: функциональное и нефункциональное, приемочное, модульное и интеграционное, системное, производительности, юзабельности и пр.
Имплементация
Также известна как «фаза деплоя», наступает после успешного завершения тестирования. Сосредоточена на доставке продукта конечным пользователям, установке его на клиентские системы (устройства).
После этого наступает время бета-тестирования. Найденные баги, а также пожелания насчет совершенствования продукта передаются разработчикам. После того как их учтут, проводится финальное развертывание приложения.
Поддержка и обслуживание
На этом, последнем, этапе, после релиза (выпуска) продукта он поддерживается (обслуживается) командой — устраняются проблемы, возникающие у пользователей.
SDLC и STLC
Преимущества и недостатки разработки по классическому SDLC-циклу
| Преимущества | Недостатки |
|---|---|
| Создается много полезной документации | Не очень хорошо, если очень много итераций и/или регулярные ревью кода |
| Хорошо описываемые исчерпывающие этапы | Бывает сложно оценить затраты и время |
| Легкое обслуживание и поддержка | Негибкий процесс, если часто изменяются требования |
| Эффективная разработка и соблюдение стандартов | При этом возможно превышение затрат и времени |
| Легко ставить цели и оценивать процесс со стороны | Бывает ограниченная возможность автоматизировать документацию и стандарты |
| Легко мониторить крупные проекты | Мало параллельных процессов |
| Хороший контроль процессов | Но для этого нужно хорошо описать проект в самом начале |
| Контроль пользовательского ввода | Но не во всех проектах бывает возможен |
Методологии SDLC (модели)
Методологии выбирают исходя из контекста проекта и бизнес-требований. Далее рассмотрим самые распространенные SDLC-модели, их достоинства и недостатки.
Модель водопада (каскадная)
Представляет собой линейный процесс последовательной имплементации продукта, идущий «сверху вниз», как каскад, или водопад. Это значит, что каждый этап разработки начинается только после завершения предыдущего. Не предполагается возвращение на предыдущие этапы, чтобы отработать изменения в требованиях. Водопадная модель исторически самая первая из возникших, и все еще применяется в разработке.
Применение
В проектах, не предполагающих изменение требований после начала разработки, в частности это проекты, инициированные RFP-запросом (документированный запрос организации, заинтересованной в приложении), и проекты, в которых клиент очень ясно и подробно изложил требования.
Преимущества
- Легко объяснять клиентам процесс разработки и текущее состояние проекта
- Упорядоченный подход
- Все стадии и активности известны и подробно описываются
- Легко планировать проект
- Верификация на каждом этапе обеспечивает раннее обнаружение дефектов и ошибок в требованиях
- На каждом этапа есть соответствующая документация
Недостатки
- Предполагается, что требования «заморожены», то есть не будут изменяться в процессе
- Очень сложно вернуться на любой этап после его завершения
- Негибкий процесс
- Трудное и дорогое масштабирование и приспособление проекта к изменениям
- Требует наличия детализированного плана
- Достаточно дорогая модель в плане ресурсов и «человеко-часов»
V-модель
Является расширением каскадной модели. Вместо линейного продвижения проекта, процесс как бы «располовинивается» после этапа имплементации и создания кода, визуально формируя специфическую V-образную модель. Разница между стандартной водопадной и V-моделью состоит в очень раннем планировании тестирования в V-модели.
V-моделью называется еще и потому, что как бы своим названием указывает на V-алидацию и V-ерификацию.
Применение
- Когда требования к продукту четко описаны, известны и понятны
- Когда пользуются техниками разработки и инструментами, хорошо изученными командой
Преимущества
- Простая и легкая методика
- На каждом этапе документируется
- Превосходит каскадную модель тем что тестирование начинается раньше
- Хорошо работает если с требованиями все ОК
- Верификация и валидация продукта на ранних этапах
Недостатки
- Не очень гибкая, если нужна гибкость — то Agile
- Трудности с масштабированием
- Продукт разрабатывается на этапе имплементации, и не создаются так называемые ранние работающие прототипы
- Нет четкого пути отработки проблем с тестированием (sic!)
- Достаточно дорогая модель, большие и негибкие затраты времени и труда
- Нужен большой детализированный и четко соблюдаемый план
Модель прототипирования
Предполагает создание прототипов — неполных версий разрабатываемого приложения. Эта активность обычно направлена на визуализацию неких компонентов приложения, представляющих интерес, с целью прояснить/уточнить для команды пользовательские требования. Также прототипирование помогает снизить количество излишних итераций (этапов) в каскадной модели, трудных в имплементации из-за негибкости, присущей этой модели. После создания финального прототипа требования «замораживаются».
Существуют разновидности прототипной модели:
- Быстрое прототипирование — прототипы затем не становятся частью финальной версии продукта
- Эволюционное прототипирование — прототипы «развиваются» до финальной системы, включаются в нее как основа, путем последовательного включения в систему результатов пользовательского фидбэка.
- Инкрементальное прототипирование — продукт создается как последовательность отдельных прототипов, которые в конце интегрируются в единое целое.
- Экстремальное прототипирование — в основном в веб-разработке. Она разбивается на три фазы. На первой делают статический прототип, состоящий из HTML-страниц. На второй работают с уровнем сервисов, программируя поведение. На третьей имплементируют сервисы.
Применение
Как отдельная методология или как дополнение к любой другой SDLC-модели. Особенно полезна при разработке системы с множеством пользовательских взаимодействий. И обратно, если в системе нет большого количества взаимодействий с пользователем (например специализированная система для вычислений), ей не нужны прототипы.
Преимущества
- Уменьшение затрат времени и ресурсов (если на создание прототипов не уходит слишком много времени)
- Улучшение качества взаимодействий с пользователем
Недостатки
- Мало возможностей для анализа
- Прототипы не всегда понятны пользователям, и недооценка прототипа (делают поспешный вывод о несовершенстве системы вообще)
- Иногда неполное понимание разработчиками целей пользователей
- Иногда большие затраты времени на создание и поддержку прототипов
- Поэтому имплементация прототипов в готовый продукт может затягиваться
Спиральная модель разработки (SDM)
Комбинация этапов дизайна и прототипирования — пытаясь сочетать преимущества подходов «снизу вверх» и «сверху вниз». В общем виде гибрид прототипной и каскадной моделей. Предназначена для больших, дорогих, сложных проектов. Этапы в целом взяты из водопадной модели, идут в том же порядке, но отделяются этапами планирования, оценки рисков, и создания прототипов (симуляций).
Применение
В больших проектах и системах с множеством встраиваемых этапов/сегментов.
Преимущества
- Оценка предстоящих затрат бюджета и усилий более реалистична по мере развития проекта, поскольку проблемы определяются раньше
- Раннее включение разработчиков в процессы
- Хороший контроль рисков
Недостатки
- Высокая стоимость финального продукта
- Нужны специальные скиллы оценки рисков
- Высокая специфичность проекта определяет трудность применения наработок в следующих проектах (нет реюзабельности)
Итеративная и инкрементальная модели
Тоже создавалась как развитие водопадной модели. Начинается с планирования, завершается деплоем, и между ними циклические операции. Базовая идея такого подхода — создание системы последовательными циклами (итерациями) и небольшими «порциями» (инкрементально), что позволяет разработчикам изучать продукт на ранних стадиях и вносить корректировки. Можно представить эти модели как мини-водопады, или мини-V-модели:
Применение
В приложениях, которые могут модифицироваться на расширение/сужение функциональности, и в больших системах, состоящих из множества маленьких сегментов, например ERP-системах. Например, начинают с модуля бюджета как первой итерации, и продолжают разработкой складского модуля и так далее.
Преимущества
- Создание бизнес-ценности в продукте на раннем этапе
- Экономное использование ресурсов, контролируемыми небольшими «порциями»
- Гибкое применение запросов на изменения между итерациями
- Фокус на ценности для пользователей, а не грубо-прямолинейный подход к разработке
- Раннее определение и устранение возникающих проблем
Недостатки
- Нужно много документации
- И соблюдение предписанных процессов
- Инкременты (стадии) основаны на зависимостях между функциями приложения
- Нужно больше включения пользователей/клиентов в процесс, чем в «линейных» методиках, что не всегда достижимо
- Разбивка функций поэтапно может быть проблематичной
- Интеграция между итерациями может быть проблемной в случае если она не предусматривалась при планировании и разработке проекта
Agile
Основана на итеративной и инкрементальной моделях. Требования и решения развиваются путем коллаборации между кросс-функциональными командами.
Применение
В принципе, в любых проектах, допускающих широкое привлечение клиентов/пользователей в процесс, поскольку предполагается что модель должна быть очень интерактивной. Также в случаях, когда клиенту нужно видеть выполненными некоторые функциональные требования уже за две-три недели, а требования не так чтобы очень ясно сформулированы. Гибкая модель позволяет создать ценный и вполне рабочий продукт очень рано в цикле и далее его быстро совершенствовать.
Преимущества
- Уменьшение времени доставки важных функций
- Хорошая личная коммуникация и непрерывный фидбэк от пользователей/клиентов, закрывающий «пробелы» и догадки
- На выходе качественный продукт, получаемый за короткое время
Недостатки
- Не всегда хорошая масштабируемость
- Не всегда команда способна обеспечивать качественную коллаборацию внутри себя и с клиентами
- Документация создается на достаточно поздних этапах
- Уменьшение реюзабельности компонентов
- Нужно специальное обучение персонала как работать «по эджайлу»
Scrum
Вероятно самая популярная Agile-методика (по крайней мере самая «слышная»). Итерации (в терминологии Scrum — «спринты») длятся 2-4 недели, спринту предшествует тщательное планирование, а после его завершения проводится оценка результатов. После описания активностей изменения не вносятся.
Экстремальное программирование (XP)
Типичная итерация длится 1-2 недели. Модель допускает изменения в процесс даже после начала итерации, если команда не начала работать с этим модулем. Подобная гибкость значительно усложняет доставку качественного продукта, но имеет свои плюсы. Предполагается парное программирование (и тестирование), TDD (разработка через тестирование — что это?), автоматизация тестирования, непрерывная интеграция (CI), промежуточные релизы, упрощенный дизайн, и соблюдение стандартов/гайдлайнов по написанию кода.
Канбан
Отличительная черта этого подхода — отсутствуют длительные итерации. Их стараются сделать как можно короче (так называемые «daily sprints»). Упор делается на визуализацию процессов. На канбан-доске изображаются все активности в проекте, их количество, статус (прогресс выполнения), и прикрепленные к активностям сотрудники. Такая прозрачность помогает быстро определить самые важные/срочные задачи и вовремя дать им приоритет. Также, нет отдельного этапа планирования, так что новый запрос может быть выполнен в какое угодно время. Постоянно идет коммуникация с пользователями/клиентами, они могут видеть прогресс в любой момент. Митинги команды могут проводиться практически каждый день. Чаще всего Kanban применяется в проектах с очень активной поддержкой пользователей и быстро развивающихся.
DevOps
Эта методология возникла на пересечении двух трендов. Первый — практическое применение Agile и Lean-подходов, путем создания так называемых операционных команд (Ops) в составе компании. Второй тренд — общий «сдвиг» в ИТ-бизнесе в направлении бОльшей кооперации между операционными командами и командами разработчиков (Dev), на всех этапах SDLC-цикла.
Итак, DevOps — это «разработчики+операции». Следуя методологии DevOps, обе команды работают «в связке», значительно ускоряя разработку и развертывание, и создавая качественные надежные продукты.
Характеристики DevOps-методологии: непрерывный фидбек, соблюдение дисциплины, непрерывное совершенствование процессов, и автоматизация всех ручных процессов разработки (и тестирования) насколько это возможно. Обновления, вносимые в код, являются короткими, но очень частыми.
Преимущества
- Меньше времени и денег уходит на незапланированную работу, а также на устранение дефектов
- Улучшение удовлетворенности пользователей
- Общее уменьшение затрат времени операционной и dev-командами, так как они видят проблемы заблаговременно
- Быстрее восстановление после сбоев/отказов
- Выше надежность готового продукта
Недостатки
- Не очень много. Например, выше риск проблем с безопасностью, таких как спуфинг и MiTM, поскольку темп разработки очень высок
Lean-методология
Возникла в результате «переноса» производственных практик японской компании Toyota в разработку сфта. Базируется на семи принципах:
- Убрать все лишнее («мусор») из всех процессов
- Упор на обучении, повышении квалификации персонала
- Принимать окончательные решения как можно позже
- Доставлять готовый продукт как можно раньше
- Крепить единство команды
- Тем самым укрепляя интегральность продукта
- Уметь видеть картину с высоты птичьего полета
Проектные команды, работающие по Lean, нацелены на поиск возможностей «убрать лишнее» из каждого этапа своего (стандартного) SDLC-цикла. Обычно это делают путем отмены ненужных митингов, и уменьшении количества документации.
В целом, Lean-методология по своему духу очень близка к Agile. Но есть отличия. Наиболее заметное — в подходе к удовлетворению пользовательских потребностей. В Agile они являются приоритетом, с самого начала цикла. Поэтому проектные команды немедленно отвечают на фидбек стейкхолдеров и пользователей на всех этапах SDLC. А в Lean наибольший приоритет отдается устранению всего лишнего — чтобы было заметнее то полезное, что продукт дает пользователям.
Преимущества:
- Применима практически во всех командах в компании, то помогает интегрировать их, улучшить коллаборацию между ними. Поэтому Lean прекрасно сочетается с Agile и DevOps и всегда может применяться комбинированно с ними в каких-то пропорциях, на усмотрение руководства проектом.
- Убрали все лишнее, и значит лучше продумана, выполнена, и «отполирована» основная функциональность
- Легкая масштабируемость, то есть подходит и для крупнейших проектов
- Улучшает гибкость менеджмента в том что касается принятия решений (decision making).
- Улучшает мотивацию у сотрудников
- Ну и разумеется, устранение всего лишнего дает эффект в экономии времени и денег (почему и называется «экономной методологией»)
Недостатки
- Требует высокого уровня навыков ведения проектной документации, особенно бизнес-требований. В противном случае может получиться некачественный продукт, или включающий плохо выполненные части, из-за некачественной документации
- Сильно зависит от команды, от того насколько она способна работать по новому, отвергать старое-привычное, и воспринимать новое. Нужна очень квалифицированная и опытная команда
- Сравнительно велика опасность «потерять фокус» в разработке (у неопытных команд есть такой риск)
Обзорный материал о тестировании по Lean-методологии
Методология Быстрой разработки (RAD)
Придумана и внедрена в IBM 40 лет назад. Достаточно популярна. Отдает приоритет скорости, в сочетании с гибкостью, при этом проводится тщательное «фронтальное» планирование.
Название говорит за себя: очень короткое время разработки (в сравнении с конкурентами IBM в 1980е). Стандартный проект «по RAD-методологии» разрабатывается с ноля за 2-3 месяца.
Проект разбивается на небольшие модули, которые «прикрепляются» к разным командам, затем по мере готовности модули объединяются цельный продукт.
Как и в Agile, приоритет дается сбору фидбека. В целом, SDLC-цикл состоит из стандартных waterfall-этапов (анализ, дизайн, кодинг, тестирование, имплементация, поддержка). Также создаются «быстрые прототипы». Разработчикам разрешается делать множество итераций и обновлений без внесения значительных изменений в начальный график.
Преимущества
- Небольшое количество разработчиков работает над задачами
- Пользовательский фидбек собирается на начальных стадиях цикла
- Короткие итерации, а значит легко подстраиваться под изменения в требованиях
- Легко оценивать продвижение проекта на всех стадиях
- Реюзабельность компонентов
- Ну и, разумеется, скорость разработки
Недостатки
- Если реюзабельных компонентов оказывается мало, преимущество RAD начинает теряться
- Сильно зависит от привлечения пользовательского фидбэка
- Модель довольно сложная в управлении, зависит от квалификации руководства проектом
- Вряд ли подходит для очень маленьких проектов
- Проджект-менеджер должен очень плотно и напряженно работать связующим звеном между пользователями и разработчиками
- Нужны достаточно специализированные инструменты
RUP-методология
Rational Unified Process. Для полноты обзора, кратко об этой методологии, редко применяемой. Является сочетанием линейного и итеративного подхода. Разработка делится на 4 стадии: начальная, уточнения, конструирования, и внедрения. Три последних стадии выполняются в несколько итераций. Все базовые активности (сбор требований, дизайн и т.п.) идут параллельно на всех 4 этапах, но с разной интенсивностью.
При всей необычности, RUP-методология позволяет создавать стабильные и гибкие решения, однако является «небыстрой» и плохо адаптируемой к Agile-методикам (Scrum, Kanban, XP). Включенность пользователей, степень документирования процессов и длительность итераций — зависят от проекта. Кейсы для RUP: большие проекты с высокими рисками, особенно базирующиеся на use-кейсах.
Методология «Большого Взрыва» (Big Bang)
Это модель, в которой не соблюдается какой-то определенный процесс. Разработка начинается, когда на входе есть средства и подобраны сотрудники, и на выходе получаем готовый софт (который может быть, а может и не быть удовлетворяющим потребности заказчиков/клиентов/пользователей). Соответственно, нет устоявшейся процедуры, и очень мало планирования. Даже клиент не очень ясно понимает, чего хочет от будущего продукта. Требования имплементируются «на лету», по ситуации, без особого анализа.
Обычно так разрабатываются маленькие проекты, с небольшим количеством привлеченных сотрудников, даже одним-двумя, и соответствующим количеством тестировщиков. Так разрабатываются pet-проекты, академические проекты, или самописные поделки «для себя и друзей».
Преимущества
- Все очень просто, проще некуда
- Без планирования
- Легко управлять — людей мало
- Нужно мало ресурсов
- Гибкость
- Хорошо учиться и приобретать опыт в таких проектах
Недостатки
- Высокие риски неудачного завершения
- Разумеется, такое никак не подходит для крупных серьезных проектов
Как выбрать методологию разработки ПО
| Факторы | Каскадная (водопад) | V-модель | Эволюци-онного прототипи-рования | Спиральная | Итеративная и инкремен-тальная | Agile |
|---|---|---|---|---|---|---|
| Неясные пользова-тельские требования | Плохо подходит | Плохо подходит | Хорошо подходит | Отлично подходит | Хорошо подходит | Отлично подходит |
| Новые/незнакомые технологии | Плохо | Плохо | Отлично | Отлично | Хорошо | Плохо |
| Сложная система | Хорошо | Хорошо | Отлично | Отлично | Хорошо | Плохо |
| Надежная система | Хорошо | Хорошо | Плохо | Отлично | Хорошо | Хорошо |
| Нехватка времени на разработку | Плохо | Плохо | Хорошо | Отлично | Отлично | Отлично |
| Сильный проджект-менеджер | Отлично | Отлично | Отлично | Отлично | Отлично | Отлично |
| Ограничение по деньгам | Плохо | Плохо | Плохо | Плохо | Отлично | Отлично |
| Постоянный контакт со стейкхолдерами | Хорошо | Хорошо | Отлично | Отлично | Хорошо | Отлично |
| Ограничения по скиллам у команды | Хорошо | Хорошо | Плохо | Плохо | Хорошо | Плохо |
| Документация | Отлично | Отлично | Хорошо | Хорошо | Отлично | Плохо |
| Реюзабельность компонентов | Отлично | Отлично | Плохо | Плохо | Отлично | Плохо |
Популярные модели SDLC, по шкале линейности/спонтанности операций, и формальности/неформальности подходов:
Сравнение SDLC-моделей по затратам, качеству и TCO
***
SDLC-модели/методологии/подходы очень сжато изложены здесь — для быстрого ознакомления перед собеседованием. Также: Сказ о ненастоящем эджайле
