Menu ↓
Урок 3. Выбор методологии разработки
В этом уроке мы разберем жизненный цикл разработки ПО и различные модели разработки. Жизненный цикл раскроет этапы, из которых состоит разработка приложения, а модели предложат, в каком порядке и каким образом проходить эти этапы. В конце урока выберем модель для разработки сайта кофейни.
Жизненный цикл разработки ПО или SDLC
Жизненный цикл разработки программного обеспечения (SDLC — Software Development Life Cycle) описывает этапы, которые необходимо пройти для создания программного приложения. Понимание процесса SDLC позволяет систематизировать разработку и обеспечить качество конечного продукта. Детали процесса разработки могут отличаться у разных команд. Тем не менее есть общие этапы, которые присутствуют в большинстве случаев.
1. Планирование и Анализ требований (Analysis)
На этом начальном этапе формируются основы всего проекта. Ключевые участники здесь – менеджеры проекта и бизнес-аналитики. Они определяют цели проекта, сроки, необходимые ресурсы и основные требования к продукту. Тесное взаимодействие с заказчиками и конечными пользователями помогает точно сформулировать, что должно быть сделано.
Активные участники:
Артефакты: Документ с требованиями, план проекта, анализ рисков.
- Продакт и проджект менеджеры: Проводят встречи с заинтересованными сторонами, определяют общие рамки проекта, ресурсы, сроки, и риски.
- Аналитики: Собирают и анализируют требования, формулируют документацию.
Артефакты: Документ с требованиями, план проекта, анализ рисков.
2. Проектирование (Design)
На этапе проектирования решается, как именно будет работать и выглядеть ПО. Это включает в себя создание архитектуры программы и её интерфейса. Здесь активно вовлечены в работу архитекторы ПО и дизайнеры интерфейса.
Активные участники:
Артефакты: Технические спецификации, дизайн пользовательского интерфейса, схемы архитектуры системы.
- Архитекторы ПО: Разрабатывают структуру программы, выбирают технологии и платформы.
- Дизайнеры: Работают над созданием пользовательского интерфейса.
Артефакты: Технические спецификации, дизайн пользовательского интерфейса, схемы архитектуры системы.
3. Разработка и Кодирование (Development)
На этом этапе разработчики приступают к практической реализации проекта. Они пишут код, преобразуя технические требования и дизайн в работающее программное обеспечение.
Активные участники:
Программисты: Написание кода, реализация функций, интеграция различных компонентов системы.
Артефакты: Исходный код, программные модули, техническая документация.
Программисты: Написание кода, реализация функций, интеграция различных компонентов системы.
- Frontend-разработчики подготовят пользовательский интерфейс приложения.
- Backend-разработчки разработают серверную часть приложения.
Артефакты: Исходный код, программные модули, техническая документация.
4. Тестирование (Testing)
После того как код написан, он должен быть тщательно протестирован. Тестировщики проверяют программное обеспечение на наличие ошибок, тестируют на соответствие требованиям каждый аспект ПО.
Активные участники:
Артефакты: План тестирования, тест-кейсы и чек-листы, баг-репорты, отчет о тестировании.
- Тестировщики: Выявляют баги, проводят различные виды тестирования (например, функциональное, нагрузочное, тестирование безопасности).
Артефакты: План тестирования, тест-кейсы и чек-листы, баг-репорты, отчет о тестировании.
5. Развертывание (Deployment)
После тестирования и утверждения релиза ПО оно разворачивается для конечных пользователей. Приложение деплоиться на продакшн сервер и становится доступным для клиентов в Интернете.
Активные участники:
- Системные администраторы: Устанавливают и настраивают ПО в продакшн-среде.
6. Поддержка (Maintenance)
Даже после запуска проекта, работа над ним не прекращается. Команда продолжает заниматься исправлением обнаруженных ошибок, обновлением функционала и адаптацией к изменяющимся требованиям пользователей или технологий.
Активные участники:
В каждом конкретном проекте эти этапы могут адаптироваться под задачи команды и условия выполнения проекта.
При разработки сайта кофейни мы также пройдем все этапы SDLC, однако, учитывая простоту приложения, в его разработке задействуем меньшее количество участников, чем описано в этапах выше.
- Специалисты поддержки: Обеспечивают техническую поддержку пользователей, решают возникающие проблемы.
- Разработчики: Регулярно обновляют ПО, исправляя ошибки и добавляя новые функции.
- Тестировщики: Тестируют обновления и новые версии программного обеспечения.
В каждом конкретном проекте эти этапы могут адаптироваться под задачи команды и условия выполнения проекта.
При разработки сайта кофейни мы также пройдем все этапы SDLC, однако, учитывая простоту приложения, в его разработке задействуем меньшее количество участников, чем описано в этапах выше.
Модели SDLC: Waterfall и Agile
SDLC описывает этапы разработки приложения. Модели SDLC, такие как Waterfall, Agile, V-образная модель, Спиральная и другие, описывают, как и в какой последовательности проходить эти этапы. Для начинающих разработчиков и тестировщиков нет практического смысла подробно разбирать все эти и другие модели. Мы остановимся на двух: Waterflow и Agile, которые показывают два принципиально разных подхода к разработке.
Waterfall (Водопадная или Каскадная модель)
Waterfall, или Водопадная/Каскадная модель, представляет собой последовательный подход в реализации SDLC. В этой модели этапы разработки следуют строго друг за другом, как ступени водопада: каждый следующий этап начинается только после завершения предыдущего.
Суть модели:
- Линейность: Все этапы SDLC (от анализа требований до поддержки) выполняются один раз и в строгой последовательности.
- Предсказуемость: Легко планировать и прогнозировать работу, так как все этапы и сроки определены заранее.
Разработка сайта кофейни по Waterflow
Анализ (2 недели): Менеджер проекта и аналитик встречаются с заказчиком и интервьюируют его с целью составления требований к сайту. Когда все требования выяснены, согласованы и описаны, то определяется команда, которая будет реализовывать проект и сроки разработки.
Дизайн (2 недели): Архитектор или старший разработчик определить, какой будет стек разработки и архитектура проекта. UX/UI дизайнер разработает интерфейс. После чего все это презентуют заказчику для утверждения и приемки работ.
Разработка и тестирование (3 недели): Программисты напишут код для реализации и отдадут его на тестирование. После окончания подготовки реализации ее презентуют заказчику.
Деплоймент (1 неделя) и поддержка: После утверждения реализации заказчиком ее развернут на продакшн-сервере и приложение станет доступно клиентам в Интернете.
Таким образом, при модели Waterflow мы просто идем по всем этапам SDLC. Важно, чтобы на первом этапе заказчик четко представлял себе результат, которых хочет получить в конце. Если кофейня не сможет точно обрисовать требования к проекту или будет постоянно их менять, то разработка сильно затормозится. Команда разработки просто не сможет двигаться дальше, пока не будет четких и стабильных требований.
Клиенты кофейни увидят сайт в самом конце цикла разработки, в нашем случае через 8 недель, если не будет дополнительных задержек в процессе работы.
Дизайн (2 недели): Архитектор или старший разработчик определить, какой будет стек разработки и архитектура проекта. UX/UI дизайнер разработает интерфейс. После чего все это презентуют заказчику для утверждения и приемки работ.
Разработка и тестирование (3 недели): Программисты напишут код для реализации и отдадут его на тестирование. После окончания подготовки реализации ее презентуют заказчику.
Деплоймент (1 неделя) и поддержка: После утверждения реализации заказчиком ее развернут на продакшн-сервере и приложение станет доступно клиентам в Интернете.
Таким образом, при модели Waterflow мы просто идем по всем этапам SDLC. Важно, чтобы на первом этапе заказчик четко представлял себе результат, которых хочет получить в конце. Если кофейня не сможет точно обрисовать требования к проекту или будет постоянно их менять, то разработка сильно затормозится. Команда разработки просто не сможет двигаться дальше, пока не будет четких и стабильных требований.
Клиенты кофейни увидят сайт в самом конце цикла разработки, в нашем случае через 8 недель, если не будет дополнительных задержек в процессе работы.
Преимущества и недостатки Waterflow
Преимущества подхода:
Каскадная модель хорошо работает в небольших или повторяющихся однотипных проектах, когда есть детальные требования, которые не меняются в процессе разработки. В таких проектах заказчик четко знает чего хочет и, получив то, что требуется, заканчивает разработку и осуществляет только поддержку приложения. На первом этапе понадобится большое вовлечение заказчика, чтобы сформировать все требования. Но на последующих этапах участие заказчика минимальное и сводится к оценке и приемке работ.
Недостатки подхода:
- четкое планирование сроков и затрат, простота управления;
- прозрачность процессов для заказчика.
- полное документирование каждого этапа;
Каскадная модель хорошо работает в небольших или повторяющихся однотипных проектах, когда есть детальные требования, которые не меняются в процессе разработки. В таких проектах заказчик четко знает чего хочет и, получив то, что требуется, заканчивает разработку и осуществляет только поддержку приложения. На первом этапе понадобится большое вовлечение заказчика, чтобы сформировать все требования. Но на последующих этапах участие заказчика минимальное и сводится к оценке и приемке работ.
Недостатки подхода:
- необходимость утверждения полного объема требований к приложению на первом этапе разработки;
- в случае внесения изменений в требования на более поздних этапах, необходимо возвращаться снова к первой стадии и переделывать/приводить в соответствие всю проделанную работу. Это долго и дорого;
- тестирование происходит после окончания разработки всего приложения. Это увеличивает риск нахождения ошибок, которые потребуют существенной переделки проекта.
- пользователи получают доступ к приложению в в самом конце разработки. Это значит, что бизнес не получает ценность весь период разработки, а команда разработки не получает обратную связь от пользователей, что увеличивает риск провала продукта.
Agile (Гибкая модель)
Agile, или Гибкая модель, в отличие от Waterfall, подразумевает итеративный и гибкий подход к разработке. Этапы SDLC здесь не фиксированы строго последовательно, а проект развивается через короткие итерации (спринты).
Суть модели:
- Гибкость: Проект развивается через непрерывные итерации, что позволяет быстро адаптироваться к изменениям.
- Вовлеченность заказчика: Заказчик активно участвует в процессе разработки, что обеспечивает большую удовлетворенность конечным продуктом.
- Общее: Обе модели включают основные этапы SDLC.
- Различия: Waterfall строг и последователен, Agile гибок и итеративен. Agile позволяет вносить изменения на протяжении всего процесса, в то время как Waterfall требует полного определения требований на начальном этапе.
Сходства и различия Waterflow и Agile:
Разработка сайта кофейни по Agile
Если при разработки сайта кофейни по Waterflow мы полностью опирались на этапы SDLC, то при разработке по Agile ключевой единицей становится не этап, а итерация. За итерацию готовится функционал, который можно назвать версией продукта. В первой итерации у нас получается упрощенная версия продукта, которая содержит минимальный функционал. С каждой последующей итерацией продукт обрастает новыми фичами, старые фичи дорабатываются или изменяются. Таким образом, в конце каждой итерации мы получаем новую, более совершенную версию продукта.
Если в Waterflow мы на первом этапе описываем конечную версию и дальше ее разрабатываем, то в Agile разработка идет через создание промежуточных версий, а конечной версии может и не быть, так как продукт пока остается актуален постоянно развивается и адаптируется под требования пользователей. Внутри каждой итерации мы проходим знакомые этапы SDLC.
Если в Waterflow мы на первом этапе описываем конечную версию и дальше ее разрабатываем, то в Agile разработка идет через создание промежуточных версий, а конечной версии может и не быть, так как продукт пока остается актуален постоянно развивается и адаптируется под требования пользователей. Внутри каждой итерации мы проходим знакомые этапы SDLC.
Итерация 1 (2 недели)
Анализ: Менеджеры и аналитики на встрече с представителем кофейни выясняют требования к проекту. В отличие от Waterflow в Agile не нужно выяснять все требования на все приложение сразу. Описываются те требования, которые есть на данный момент. Из них выбираются требования, которые нужно реализовать в первую очередь, чтобы получить первую минимальную работающую версию продукта. Объем работы берется такой, чтобы успеть выполнить ее за время итерации, которая обычно составляет от 1 до 4 недель. В нашем случае таким функционалом может быть создание веб-страницы с секциями меню кофейни и контакты.
Дизайн: Проектируется система только в том объеме, который достаточно для реализации функционала первой итерации. Также и с макетами: дизайнер обрисовывает только тот интерфейс, который войдет в первый релиз: меню кофейни и контакты.
Дизайн: Проектируется система только в том объеме, который достаточно для реализации функционала первой итерации. Также и с макетами: дизайнер обрисовывает только тот интерфейс, который войдет в первый релиз: меню кофейни и контакты.
Разработка: Программисты реализуют функционал итерации: верстку секций меню и контактов, серверную часть, которая по запросу пользователя выдает страницу сайта с данными из базы данных. В базе данных хранится информация о доступных напитках и десертах: наименование, фото, цена.
Тестирование, Деплой, Поддержка: Также выполняются и другие стадии SDLC, чтобы в конце итерации зарелизить первую версию сайта.
Тестирование, Деплой, Поддержка: Также выполняются и другие стадии SDLC, чтобы в конце итерации зарелизить первую версию сайта.
Итерация 2, итерация 3 и т.д.
В следующих итерациях цикл разработки повторится снова:
- менеджеры и аналитики уточнят требования у заказчика (в отличие от Waterflow работа с заказчиком и выяснение/уточнение требований в Agile идет на протяжении всего проекта);
- в итерацию попадет следующий наиболее приоритетный функционал, над которым будет работать команда разработки: дизайнеры, программисты, тестировщики и т.д. Функционал, который добавляется в приложение по итогам спринта, часто называют инкрементом.
- в конце итерации произойдет релиз новой версии приложения со подготовленным за итерацию функционалом.
Преимущества и недостатки Agile
Преимущества Agile:
Недостатки Agile:
Когда применять?
Сложные проекты в которых требования не определены изначально. Однако ключевые требования и цель определены. В проектах, которые подвержены частым изменениям требований
- готовность к изменению требований на каждой итерации. Легко адаптировать продукт под новые потребности пользователей;
- раннее создание работающего ПО: в идеале первая версия продукта доступна пользователям уже после первой итерации. Как следствие команда разработки быстро начинает получать обратную связь от пользователей, что сокращает риск провала продукта;
- каждая инкремент итерации — маленький кусочек программы, который проще тестировать и доставлять пользователям. Благодаря регулярному тестированию и ревизиям риск выявления серьезных проблем на поздних этапах снижается.
Недостатки Agile:
- нет фиксированного бюджета и сроков: разработка осуществляется до тех пор, пока продукт актуален для потребителей;
- требует высокого вовлечения заказчика в процесс разработки;
- могут быть проблемы с архитектурой приложения из-за разрастания или существенного изменения функционала проекта.
Когда применять?
Сложные проекты в которых требования не определены изначально. Однако ключевые требования и цель определены. В проектах, которые подвержены частым изменениям требований
Модель для разработки сайта кофейни
Для разработки сайта кофейни выберем Agile по следующим причинам:
В настоящее время большинство команд разработки используют именно Agile. Однако каждая компания реализуют его принципы по-своему с большим или меньшим успехом. Поэтому процесс разработки может отличаться в разных компаниях, даже если все они декларируют использование одного и того же подхода.
Agile не является универсальным средством. В части проектов лучше использовать Waterflow или собирать гибридную модель, которая будет соответствовать специфики проекта.
- Заказчик хочет как можно быстрее получить первую версию продукта;
- Заказчик планирует постепенно расширят функционал приложения, когда получить больше информации о предпочтениях пользователей.
В настоящее время большинство команд разработки используют именно Agile. Однако каждая компания реализуют его принципы по-своему с большим или меньшим успехом. Поэтому процесс разработки может отличаться в разных компаниях, даже если все они декларируют использование одного и того же подхода.
Agile не является универсальным средством. В части проектов лучше использовать Waterflow или собирать гибридную модель, которая будет соответствовать специфики проекта.
Loading...