Этапы жизненного цикла
Жизненным циклом называют последовательность из нескольких этапов, которые проходит проект разработки программного обеспечения от начала работы до внедрения продукта. Всего их четыре: подготовка, проектирование, создание, поддержка. Оценкой качества каждого из них служит достигнутый результат.
В разных компаниях могут использоваться свои названия для каждого из этапов, причем сами шаги зачастую дробятся на несколько более мелких. Рассмотрим все стадии на конкретном примере:
- Подготовка. Ирина открыла бюро путешествий и хочет запустить свой сайт. Ей нужно провести анализ конкурентов, собрать данные по наполнению их площадок, трафику, ряду других параметров.
- Проектирование. Ирина находит подрядчика, который создаст для нее сайт. Она заключает с ним договор, обсуждает дизайн ресурса, его структуру, способы тестирования для оценки удобства сервиса.
- Разработка. Здесь от Ирины ничего не зависит, так как все исходники и пожелания уже переданы разработчику. Подрядчик приступает к выполнению работ: пишет код, отрисовывает дизайн, согласовывает его с заказчиком, готовит сопроводительную документацию.
- Поддержка. Разработчик размещает сайт на серверах, начинает отслеживать сообщения пользователей об ошибках, исправлять баги.
Подобный пошаговый план — модель разработки программного обеспечения. В нем разобраны этапы жизненного цикла с описанием текущих процессов на каждом из них. То есть модели используются, чтобы предсказывать поведение систем в будущем.
Чтобы управлять моделью, нужно использовать комплекс принципов, техник, правил, практик, который называется методологией. Он служит базой для разработки программного обеспечения и предполагает планомерный подход. Это позволяет тщательно проработать жизненный цикл проекта с учетом требований по управлению разработкой ПО, выстаиванием коммуникации, сотрудничества внутри команды. При этом в методологии не учитывается техническая сторона, например, выбор БД или языка программирования.
Назначение методологии — создание поэтапного плана разработки программного обеспечения, который обеспечит взаимопонимание в команде и выпуск продукта в запланированные сроки.
Модели и методологии часто путают, поэтому мы разбили их на два отдельных блока, а Agile вообще поставили отдельно от них. Почему — расскажем ниже.
Основные модели разработки программного обеспечения
Waterfall (каскадная или водопадная модель)
В Waterfall каждая последующая стадия вытекает из предыдущей после ее полного завершения. Такой цикл проектирования программного обеспечения считается достаточно жестким. Обычно он включает в себя восемь этапов:
- системную аналитику;
- аналитику требований;
- проектные работы;
- дизайн;
- создание кода;
- тестирование;
- запуск продукта;
- техническую поддержку, исправление багов.
Waterfall активно применяется с 1970-х годов. Каскадная модель помогает значительно упростить управление проектом за счет жесткости его структуры. Эта же особенность позволяет заранее определить сроки разработки и стоимость работ.
Используя водопадную модель, проектировщик должен иметь подробные требования к разработке, чтобы исключить ошибку на стадии тестирования. Если она будет обнаружена, все придется начинать сначала.
Waterfall можно использовать при отсутствии противоречивых требований, а также при наличии сформированной документальной базы. Поэтому каскадная модель востребована в разработке проектов, относящихся к научным и техническим отраслям. Например, в медицине, космических технологиях, для автоматического обновления служб в операционных системах. Однако в областях, связанных с проведением экспериментов или внедрением инноваций, эта модель окажется неэффективной.
В таблице ниже представлены плюсы и минусы Waterfall.
| Преимущества | Недостатки |
| Подходит как для небольших, так и для масштабных проектов | Отсутствие гибкости. После перехода на следующий этап не получится вернуться назад для внесения изменений |
| Простота, понятность, четкость, упорядоченность действий, удобство внедрения в рабочий процесс | Минимальная вовлеченность заказчика в процесс реализации продукта. То есть Waterfall не подойдет, если нужно часто связываться с владельцем проекта или использовать итерации |
| Оптимален для проектов, имеющих строгие, четко сформулированные требования | |
| Каждый этап скрупулезно документируется | Ошибки и баги выявляются лишь в конце разработки. На их исправление потребуются дополнительные расходы и время |
| Тестировщикам не обязательно иметь превосходную техническую подготовку | Очень большое количество технической документации, подготовленной разработчиками, задерживает процесс разработки продукта |
| Стоимость работ определяется на стадии заключения договора |
V-Model
Эта модель появилась чуть позже, в 1980-х годах. Она представляет собой более совершенный вариант Waterfall, в котором работа ведется сразу в двух направлениях:
- составляются требования к системе;
- прописываются принципы тестирования на каждой из стадий.
Тщательная проверка при тестировании — особенность, свойственная именно V-модели. При этом этапы проводятся попарно: каждому блоку разработки соответствует определенный тип теста. Этот ступенчатый процесс наглядно показан в таблице ниже.
| Верификация | Валидация данных (тип тестирования) |
| Бизнес-требования | Приемочное |
| Функциональные требования | Функциональное |
| Архитектура системы | Интеграционное |
| Реализация | Модульное |
| Код |
V-модель позволяет создать проект, который будет работать бесперебойно и безошибочно. Например, ее применяют для разработки медицинских программ наблюдения за пациентами, мобильных приложений для путешественников, интегрированного в систему защиты пассажиров автотранспорта программного обеспечения. То есть этот способ подходит для небольших и средних проектов с фиксированными, строго сформулированными требованиями, в которых необходимо тщательно протестировать выпускаемый продукт.
Большинство преимуществ и недостатков V-Model совпадают с каскадной моделью. Например, для нее характерно отсутствие гибкости аналогично Waterfall. То есть вернуться на шаг назад, чтобы исправить ошибку, не получится. А устранение багов после выпуска продукта будет сложным и дорогим. В то же время V-модель в большинстве случаев гарантирует высокую надежность продукта, минимальное число ошибок в архитектуре программного обеспечения.
Модель эволюции прототипов
Этот итеративный подход чаще всего применяют перед внедрением каких-либо идей, так как он предполагает разработку рабочего прототипа и только затем — конечного продукта. Благодаря прототипированию, предприниматель может заранее оценить интерфейс, его удобство для пользователя, эффективность встроенных функций.
Создание прототипа — это способ визуализации идей с последующей их доработкой. Его можно сравнить с разработкой брендбука, в котором прописываются элементы фирменного стиля, цвета, шрифты, паттерны, корпоративные иллюстрации. То есть это основа, позволяющая вживую увидеть, как будет выглядеть и работать завершенный проект.
В модели прототипирования жизненный цикл проекта дополняется еще одним этапом — созданием прототипа. С одной стороны, это удлиняет процесс, с другой — помогает четко сформулировать требования для ускорения разработки.
| Плюсы | Минусы |
| Владелец продукта может оценить проект на начальной стадии разработки, внести в него изменения | На создание даже одного прототипа нужно много времени, а зачастую их требуется несколько |
| Проблемы выявляются на стадии создания прототипа, что уменьшает риски появления багов в готовом продукте | В прототипах отражены не все возможности конечного продукта, поэтому итоговый результат может не в полной мере соответствовать ожиданиям заказчика |
| Визуализация задачи упрощает взаимопонимание между подрядчиком и заказчиком | Прототипирование оплачивается дополнительно, а также требует привлечения дополнительных ресурсов |
Инкрементная модель
Появилась в 1930-х годах, предполагает поэтапную сборку программного обеспечения из нескольких циклов, каждый из которых разрабатывается отдельно. Разработчики называют такую модель мультиводопадной.
Изначально разработка ведется по стандартному «Водопаду», в результате чего на рынок выпускается базовый продукт. После успешного завершения тестирования в реальных условиях программисты собирают дополнительные блоки, которые «подшиваются» к основной системе. Такие доработки называются инкрементами. Каждая новая итерация также сопровождается проведением тестов.
Рассмотрим на конкретном примере. Заказчик планирует запустить ресурс по созданию музыкальных открыток. На первом этапе программисты реализуют только основные функции: набор подложек со статичным дизайном, десяток музыкальных композиций, возможность вставить любую подпись. Затем ресурс постепенно обновляется — появляется градация по темам, возможность залить свой трек, создание анимированных поздравлений, наложение фильтров, загрузка голосовых сообщений.
Получается, что пользователи могут применять продукт уже на начальной стадии его развития. В дальнейшем их интерес к ресурсу будет подогреваться в том числе за счет внедрения обновлений.
| Плюсы | Минусы |
| Минимальные вложения на начальной стадии разработки | Необходимо тщательно планировать все этапы проектирования |
| Возможность получить фидбэк от потребителей для оценки качества, востребованности, пользы продукта, внесения изменений в проект | На протяжении жизненного цикла проекта разработки программного обеспечения сложно предусмотреть все требования, которые нужно реализовать |
| Быстрое обнаружение ошибок | Отсутствие гибкости во всех стадиях итераций |
| Более дешевое исправление ошибок по сравнению с «Каскадом» и V-моделью | Если в одном из блоков будет выявлена ошибка, исправления придется вносить во все инкременты |
Инкрементная модель подходит для проектов с четкими основными требованиями к системе с возможностью последующей доработки. Этот способ также хорош, если продукт нужно вывести на рынок как можно раньше или протестировать решения с высокими рисками.
Модель быстрой разработки приложений (RAD)
RAD относится к классу инкрементных моделей. Ее характерная особенность — одновременная разработка инкрементов сразу несколькими командами разработчиков в условиях жестких временных рамок. Готовые мини-проекты объединяются в единый прототип. Такой подход позволяет ускорить создание рабочего проекта, который можно показать клиенту, чтобы получить от него фидбэк.
Цикл прототипирования содержит:
- бизнес-моделирование, в процессе которого строится модель распределения информационных потоков между подразделениями;
- моделирование данных — на основе полученных сведений определяются сущности, отвечающие за обмен информацией;
- моделирование процесса — определяет связь объектов посредством информационных потоков, которая позволит реализовать все заложенные в проект идеи;
- сборку приложения — собранные модели преобразуются в код;
- тестирование — проводится проверка корректности работы интерфейса, компонентов программного обеспечения перед запуском продукта.
| Плюсы | Минусы |
| Гибкость, адаптивность к изменениям в процессе разработки | Не подходит для сложных больших проектов с жесткими требованиями |
| Снижается риск появления багов после запуска продукта | Нельзя использовать при высоких технических рисках |
| Фидбэк от клиента на каждом этапе | Необходим строгий контроль всех итераций во избежание срывов сроков по каждому из этапов |
| Короткий жизненный цикл проекта | Требует привлечения архитекторов с узкой специализацией и высокой квалификацией |
Спиральная модель
В Spiral Model основной акцент приходится на анализ рисков, которые могут повлиять на организацию жизненного цикла. Сама «Спираль» представляет собой комплекс из прототипирования, «водопада», V-модели. Процесс разработки разбивается на витки, их количество определяется динамически.
В каждом витке выделяют четыре главные фазы.
- Определение целей, альтернативных решений. На старте разработчик получает от заказчика список требований, целей. Проводится поиск оптимальных решений, позволяющих реализовать поставленные задачи.
- Оценка рисков, их устранение или минимизация. Среди выбранных решений отбраковываются наиболее рискованные, создается и дорабатывается единая стратегия с наименьшими рисками.
- Разработка, тестирование. На этом этапе проводится создание первого прототипа, проверяется его эффективность.
- Планирование следующей итерации. Выполняется оценка разработанного прототипа, в том числе выявление и мониторинг рисков. Например, это может быть перерасход выделенных на проектирование средств, срыв запланированных сроков. В этой же фазе планируют последующие этапы работы, которые будут нужны на новом витке.
| Плюсы | Минусы |
| Модель позволяет управлять рисками, сократить их до минимума | Для мониторинга рисков нужно привлекать дополнительные ресурсы, что может оказаться затратным для заказчика |
| На каждом новом витке «Спирали» продукт можно апгрейдить, добавив в него новые функции или внеся другие изменения | |
| Разработка ведется путем последовательного создания нескольких прототипов. За счет этого проще оценить стоимость каждого последующего шага. | Внушительный объем документации из-за большого числа промежуточных этапов |
| Прозрачность проекта за счет тщательного анализа всех итераций | Более сложное управление проектом за счет аналитики каждой итерации |
| В конце каждого витка заказчик видит работающую версию продукта, может принять решение о продолжении работ или их окончании | В начале работы обычно нельзя предсказать сроки завершения проекта |
Agile (гибкая методология разработки)
Мы вынесли Agile в отдельный блок, так как это набор принципов, на основе которых основано более 40 самых разных методологий, фреймворков, подходов.
Все методологии, построенные на принципах Agile, относятся к гибким процессам. Для них характерны:
- адаптивность;
- высокая вовлеченность заказчика;
- возможность добавления новых требований к проекту;
- недорогой рефакторинг в сравнении с традиционными моделями.
В таком подходе есть и минусы — сложность оценки конечной стоимости и трудозатрат.
Agile строится на семи принципах:
- создавать качественный продукт;
- делать просто;
- найти, понять, применить силу изменений;
- работать, развиваться в межфункциональной команде;
- принимать изменения в требованиях;
- обеспечить эффективную коммуникацию;
- позаботиться о самоорганизации команды.
При использовании Agile модель разработки программного обеспечения будет компоноваться из нескольких этапов:
- брейншторм с анализом требований;
- разработка дизайн-концепта;
- создание прототипа;
- поиск дефектов, чистка багов;
- развертка;
- передача заказчику готового проекта.
Если на этапе развертки обнаружены недоработки либо клиента что-либо не устраивает, цикл повторяется.
Основные методологии разработки ПО
На базе Agile разработано множество самых разных методологий. Например, в этот перечень входят:
- Scrum;
- Kanban;
- RUP;
- Microsoft Solutions Framework (MSF);
- экстремальное программирование (XP);
- Test Driven Development (TDD);
- Scaled Agile Framework (SAFe).
В нашей статье расскажем о двух из этих методологий: Scrum и Kanban.
Scrum
Эта методология — одна из наиболее распространенных и популярных. Ее отличает итеративность, то есть разбивка процесса разработки на несколько отдельных этапов, в результате завершения которых появляется некий готовый продукт. Задачи, на которые разбивается весь объем работы, подрядчик должен решить в течение конкретного срока. Поэтому такие блоки стали называть спринтами.
В Scrum на первом месте находится команда профессионалов, работающая с максимальной вовлеченностью. Чтобы добиться сплоченности разработчиков, а также повысить эффективность их работы в методологиии применяют пять так называемых церемоний или Scrum-событий.
- Спринт — строго определенный промежуток времени для постановки краткосрочных, надежных целей. Обычно он занимает 1–4 недели. В спринте участвует вся команда, которая стремится достигнуть конкретного результата.
- Совещание по планированию спринта. Командой разработчиков и владельцем продукта проводится серия переговоров, обсуждений. Их цель — определить элементы, которые должны быть готовы на момент завершения спринта. В некоторых случаях заранее определяются задачи следующего этапа и способы их решения.
- Стендап-совещание — проводится ежедневно в одно и то же время с целью оценить прогресс, вычленить препятствия, составить план работы на день. Стендап-совещания обычно длятся не дольше четверти часа.
- Обзорное совещание — проводится по завершении спринта, чтобы показать итоги проведенной работы. Продолжительность совещания зависит от длительности спринта — на каждую неделю должен приходиться час обзора выполненных задач.
- Ретроспектива — представляет собой заключительную церемонию, в процессе которой по результатам обзорного совещания принимается решение по дальнейшей разработке, адаптации продукта, внесении изменений. Все предложения собираются, распределяются так, чтобы было понятно распределение задач и ролей в команде при дальнейшем проектировании. Обычно продолжительность ретроспективных встреч находится в пределах 1,5–3 часов.
Подход Scrum при разработке ПО позволяет команде своевременно подстроиться под требования потребителей, изменчивые реалии рынка, а также повысить эффективность принятых решений.
| Плюсы | Минусы |
| Прозрачность процесса разработки — совещания проводятся регулярно, что упрощает работу команды, позволяет оценить достигнутый прогресс на каждом этапе | Нежелательно применять для проектов, где строго ограничен бюджет или поставлены жесткие сроки выпуска продукта |
| Гибкость и динамичность — разработку можно адаптировать с учетом изменчивых требований к продукту | На старте обычно встречаются ошибки планирования — времени на спринт оказывается то недостаточно, то избыточно |
| Своевременное выявление, устранение ошибок | |
| Регулярное взаимодействие команды разработчиков с заказчиком — благодаря регулярному и оперативному фидбэку продукт будет максимально соответствовать ожиданиям заказчика, потребностям потребителей | Нужна команда профессионалов, каждому из которых будет комфортно работать с коллегами. При сборе нового коллектива понадобится время на притирку, достижение сплоченности |
| На первое место ставится мотивация членов команды, оформление документов отходит на второй план | Scrum требует жесткого соответствия церемониям. В противном случае будет очень сложно создать безупречный продукт |
| Подходит в том числе для небольших стартапов |
Kanban
Наряду со Scrum Kanban считается одной из наиболее востребованных методологий разработки ПО. Он подразумевает использование досок, карточек, других способов визуализации Agile-проектов для организации рабочих процессов, отслеживания прогресса.
Методология Kanban базируется на трех ключевых принципах.
- Визуализация, где основной инструмент — доска Канбан. Изначально она встречалась преимущественно в производственных проектах, однако сейчас применяется в стартапах, технологических отраслях. В каждой карте историй отражается стадия решения задачи, назначенный исполнитель. Благодаря такой прозрачности все этапы легко отслеживаются, что особенно важно для масштабных проектов с большим числом задач.
- Снижение числа незавершенных задач — минимизация work in progress или сокращенно WIP. На всех стадиях разработки строго очерчивается число решаемых задач. Это позволяет распределить членов команды таким образом, чтобы исключить простои, наиболее эффективно и быстро завершить каждый блок.
- Внесение изменений в процессе разработки, оптимизация жизненного цикла проекта. Например, на нескольких стадиях может быть уменьшено количество задач за счет систематизации информации, четкой фиксации сроков от старта работ до реализации конкретного задания.
| Плюсы | Минусы |
| Визуализация — позволяет увидеть, какие задачи решены, находятся в процессе разработки, ожидают выполнения | Необходима слаженная работа команды, в противном случае может получиться путаница |
| Гибкость — изменения в проект можно вносить по необходимости | Нет жестких временных рамок, что затрудняет планирование с расстановкой приоритетов |
| Работа ведется в условиях непрерывной постановки задач, без простоев и ожидания конкретного спринта | Отсутствие ретроспектив, характерных для Scrum, снижает качество анализа полученных результатов |
| Рост эффективности взаимодействия в команде | Нет четких приоритетов в проектировании — команды выбирают удобные им задачи, не распределяя их по уровням очередности |
Что выбрать для своего проекта
Чтобы выбрать методологию и модель, нужно оценить их преимущества и недостатки с учетом требований к проекту.
Сделать это помогут ответы на следующие вопросы:
- насколько вам важны простота, масштабируемость метода;
- что для вас на первом месте — линейность подхода или его гибкость;
- какой бюджет будет заложен на проектирование;
- каков размер вашего проекта — большой, маленький, гигантский;
- когда продукт должен выйти на рынок хотя бы в виде бета-версии.
Полученная информация позволит ограничить число оптимальных вариантов разработки ПО. Сделать выбор среди них будет намного проще.
Часто в стартапах применяют комбинацию из нескольких методов и методологий. Например, с помощью Kanban можно ставить дедлайны, визуализировать задачи, отслеживать текущие процессы. Параллельно для управления проектами используется Scrum. Такое сочетание обеспечивает контроль разработки на каждой из стадий создания конечного продукта.
Методики разработки подбираются под конкретных исполнителей и особенности проекта. То есть разработчики должны знать модели и методологии, уметь их правильно применять. Это позволяет в разы повысить эффективность работы команды, получив на выходе продукт, максимально соответствующий ожиданиям заказчика.