что такое итеративная разработка
Итеративная разработка
Преимущества итеративного подхода:
Пример реализации итеративного подхода — Rational Unified Process.
Примечания
Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)
CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML
Полезное
Смотреть что такое «Итеративная разработка» в других словарях:
Итеративная модель разработки — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ | Проектирование | Реализация | Тестирование | Внедрение | Сопровождение Модели / методы Agile | Cleanroom | Итеративная | Scrum | RUP | MSF | Спиральная | Во … Википедия
Разработка — может означать: Процесс проектирования и конструирования изделия (см. Разработка нового продукта и Разработка с общедоступными наработками) Итеративная разработка Разработка алгоритмов Разработка программного обеспечения Разработка приложений для … Википедия
Разработка приложений для мобильных устройств — Разработка приложений для мобильных устройств это процесс при котором приложения разрабатываются для небольших портативных устройств таких как КПК, смартфоны или сотовые телефоны. Эти приложения могут быть предустановлены на устройство в… … Википедия
Разработка программного обеспечения — Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия
Разработка ПО — Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия
Разработка через тестирование — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Разработка требований к ПО — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Бережливая разработка программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Анализ требований (разработка ПО) — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Реализация • … Википедия
Аспектно-ориентированная разработка программного обеспечения — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Что такое итеративная разработка
Проект, в котором применяется итерационная разработка, имеет жизненный цикл, состоящий из нескольких итераций. Итерация включает приблизительно последовательный набор задач бизнес-моделирования, требований, анализа и проектирования, реализации, тестирования и развертывания в различных пропорциях, в зависимости от расположения итерации в цикле разработки. Итерации на начальном этапе и этапе уточнения фокусируются на управлении, требованиях и проектировании; итерации на этапе построения фокусируются на проектировании, реализации и тестировании; а итерации на этапе внедрения фокусируются на тестировании и развертывании. Итерациями следует управлять как timeboxed, то есть расписание итерации следует считать фиксированным и управлять областью содержимого итерации, чтобы она соответствовала этому расписанию.
Зачем нужна итерационная разработка?
В начальном проекте по отношению к его ключевым требованиям с большой вероятностью будут содержаться ошибки. Позднее обнаружение дефектов проекта приводит к дорогостоящим затратам и, в некоторых случаях, даже к прекращению проекта.
Любой проект влечет за собой определенные риски. Чем раньше в жизненном цикле можно проверить отсутствие рисков, тем более точно можно выполнять планирование. Многие риски не удается обнаружить до тех пор, пока не будет предпринята попытка интеграции системы. Невозможно предугадать все риски, независимо от опыта коллектива разработчиков.
В водопадном жизненном цикле невозможно убедиться в отсутствии рисков на ранних этапах жизненного цикла.
В итерационном жизненном цикле вы на основании списка ключевых рисков выбираете инкремент для разработки в итерации. Поскольку в итерации создается протестированный исполняемый продукт, то можно проверить, были ли в результате снижены риски или нет.
Преимущества итерационного подхода
Итерационный подход в целом имеет преимущество перед линейным или водопадным подходом по целому ряду причин.
Однажды заказчик сказал: «При водопадном подходе все выглядит прекрасно практически до конца проекта, иногда вплоть до середины интеграции. А затем все распадается. При итеративном подходе очень трудно долго скрывать правду.»
Руководители проектов часто оказывают сопротивление итерационному подходу, считая его бесконечным. В Rational Unified Process итерационный подход полностью управляем; планируется число, продолжительность и цели итераций. Определяются задачи и ответственности участников. Собираются объективные показатели выполнения. От одной итерации к следующей существует некоторый объем повторяющихся действий, однако это также тщательно контролируется.
Снижение рисков
Итерационный подход позволяет снизить риски раньше, поскольку многие риски обнаруживаются только во время интеграции. При развертывании ранней итерации вы проходите через все разделы, изучая многие аспекты проекта: инструменты, готовое программное обеспечение, навыки сотрудников и так далее. Предполагаемые риски могут не подтвердиться, в то время как могут быть обнаружены новые, неожиданные риски.
Внесение изменений
Итерационный подход позволяет учитывать изменения в требованиях, поскольку обычно они будут изменяться по мере работы над проектом.
Итеративный жизненный цикл обеспечивает управление путем внесения тактических изменений в продукт. Например, для того чтобы составить конкуренцию существующим продуктам, вы можете принять решение выпустить продукт с ограниченным набором функций раньше, для того чтобы опередить действия конкурента, либо можно адаптировать другого вендора для данной технологии.
Итерации также поддерживают технологические изменения по мере продвижения работы над проектом. Если какая-либо технология изменяется или становится стандартом при появлении новой технологии, то это может дать проекту определенные преимущества. Это в особенности относится к изменениям платформы и изменениям инфраструктуры на более низких уровнях.
Достижение более высокого качества
Итерационный подход позволяет получить более устойчивую архитектуру, поскольку ошибки исправляются на протяжении нескольких итераций. Первые дефекты обнаруживаются уже в первых итерациях продукта. Обнаруживаются узкие места в производительности, которые можно исправить сразу, а не непосредственно перед доставкой.
Итерационная разработка, в отличие от выполнения тестов в конце проекта, позволяет протестировать продукт более тщательно. Наиболее важные функции можно протестировать в нескольких итерациях.
Обучение и улучшение
Разработчики могут обучаться по мере продвижения работы, и различные умения и специализации более полно используются в течение всего жизненного цикла.
Тестеры, вместо длительного ожидания, в течение которого они только строят планы и оттачивают свои навыки, начинают выполнять тестирование раньше, раньше начинается создание технической документации и так далее. При оценке ранних итераций можно обнаружить необходимость в дополнительном обучении или помощи извне.
Также можно улучшить сам процесс. Оценка в конце итерации не только дает обзор состояния проекта с точки зрения планирования продукта, но также позволяет проанализировать, что необходимо изменить в организации и проекте для улучшения работы в следующей итерации.
Увеличение возможностей повторного применения
Итерационный жизненный цикл облегчает повторное применение. Облегчается идентификация стандартных компонентов, если они разрабатываются или реализуются по-отдельности, по сравнению с идентификацией всей общности.
Идентификация и разработка многоразовых компонентов является сложной задачей. Обзоры проекта в ранних итерациях позволяют архитекторам программного обеспечения обнаружить возможность потенциального повторного применения, и в последующих итерациях они могут далее разрабатывать и развивать этот стандартный исходный код.
Применение итерационного подхода облегчает использование преимуществ коммерческих готовых продуктов. На протяжении нескольких итераций можно выбрать такие продукты, интегрировать их и убедиться, что они соответствуют данной архитектуре.
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Ещё раз про семь основных методологий разработки
Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.
1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.
Когда использовать каскадную методологию?
2. «V-Model»
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.
Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
4. «RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
5. «Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
Когда использовать Agile?
6. «Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.
Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
Подытожим
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
Непрерывный цикл разработки — это как?
CI/CD на простых примерах
В разработке любого софта есть два подхода: итеративный и непрерывный. Они отличаются методами работы и сложностью организации. Если будете работать в сфере ИТ, наверняка вам встретятся оба подхода.
Итеративный подход
Итеративный — это значит, что разработка идёт итерациями, отдельными шагами. Разработчики пишут код, потом проверяют его и выпускают новую версию программы. После этого отдыхают, и снова за работу — пилить следующую версию.
👉 В итеративном подходе заказчик или пользователи видят результат только в самом конце этапа и до этого пользуются старой версией.
Непрерывный подход
Непрерывный подход — это когда разработка идёт маленькими шажками каждый день, и каждый день в репозиторий отправляются какие-то мелкие изменения. Если вы не знаете, что такое репозиторий, почитайте наш гит-словарик, с ним будет гораздо проще.
👉 При непрерывном подходе пользователи каждый день получают новую версию, которой уже можно пользоваться.
Непрерывная интеграция
Чтобы непрерывная разработка работала как задумано, для неё нужно подготовить особые условия работы:
👉 В программировании непрерывный подход называют непрерывной интеграцией (Continuous Integration, CI), потому что результаты работы за день сразу интегрируются в мастер-ветку продукта.
Непрерывная доставка
Ежедневная внутренняя сборка ещё не означает, что эта версия сразу попадёт к пользователям. Для этого нужно настроить другие процессы:
👉 Такие действия называют непрерывной доставкой (Continuous Delivery, CD), потому что они доставляют пользователям свежие результаты работы программистов. Обычно эти две аббревиатуры, CI/CD, используются вместе, потому что это взаимосвязанные процессы. Непрерывная интеграция постоянно выдаёт свежие версии, а непрерывная доставка делает их доступными для пользователей.
Кто это настраивает
Почти всё из этого зависит от тестировщиков и девопсов.
Тестировщики следят за тем, чтобы все новые изменения работали без сбоёв и не ломали то, что было до этого. Так как новые версии появляются каждый день, то тестировщикам нужно переложить как можно больше задач на автоматическое тестирование. Это позволяет держать темп и тестировать вручную только сложные моменты или то, что не удалось покрыть автотестами.
Задача девопсов — подготовить среду разработки и тестирования, чтобы всё работало максимально автоматически:
Зачем это нужно
Смысл CI/CD в том, чтобы не откладывать процесс финальной сборки на самый конец, как это делается в итеративном подходе, а собирать все кусочки по чуть-чуть, но сразу. Это позволяет пользователям постоянно получать свежие версии программ, а разработчикам — не опасаться того, что на этапе финальной сборки всё сломается.
Кому не подходит
Непрерывная разработка — дорогой и сложный процесс, который не подходит маленьким командам с ограниченным бюджетом. Для настройки и запуска такого процесса нужно нанимать много разных специалистов, а это дорого и не всегда оправданно.
А ещё есть области, в которых важна не скорость появления новых фич, а стабильность — медицина, космонавтика, пассажирские перевозки. Там новые версии могут выходить раз в три года, и это нормально — главное, чтобы работало без сбоёв.
Модели и методологии разработки ПО
За прекрасную картинку спасибо Toggl.com.
Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.
Существуют модели разработки ПО. И существуют методологии. В интернете много противоречивой информации о том, что есть что и как их отличать. Начинающему специалисту бывает сложно в этом разобраться. В этой статье мы расставим все точки над i.
Этапы жизненного цикла ПО
У любого программного обеспечения есть жизненный цикл — этапы, через которые оно проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка, проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на более мелкие стадии.
Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.
Подготовка. Иван решил запустить книжный интернет-магазин и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.
Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.
Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.
Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.
Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.
А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.
Основные модели разработки ПО
Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.
Waterfall (каскадная модель, или «водопад»)
В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.
Преимущества «водопада»
Недостатки каскадной модели
«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.
При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.
V-образная модель (разработка через тестирование)
Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.
Преимущества V-образной модели
Количество ошибок в архитектуре ПО сводится к минимуму.
Недостатки V-образной модели
Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».
V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.
Incremental Model (инкрементная модель)
Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.
Преимущества инкрементной модели
Недостатки инкрементной модели
Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок.
Iterative Model (итеративная модель)
Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техзадание.
Рассмотрим на примере создания мессенджера, как эта модель работает.
Преимущества итеративной модели
Недостатки итеративной модели
Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.
Spiral Model (спиральная модель)
Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.
Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».
Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски.
Преимущества спиральной модели
Большое внимание уделяется проработке рисков.
Недостатки спиральной модели
На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.
Что такое Agile?
Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:
Различия между Agile и традиционным подходом к разработке мы свели в таблице:
Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.
Kanban
Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.
В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.
Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!
За прекрасную картинку спасибо Toggl.com.
Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.
Существуют модели разработки ПО. И существуют методологии. В интернете много противоречивой информации о том, что есть что и как их отличать. Начинающему специалисту бывает сложно в этом разобраться. В этой статье мы расставим все точки над i.
Этапы жизненного цикла ПО
У любого программного обеспечения есть жизненный цикл — этапы, через которые оно проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка, проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на более мелкие стадии.
Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.
Подготовка. Иван решил запустить книжный интернет-магазин и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.
Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.
Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.
Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.
Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.
А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.
Основные модели разработки ПО
Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.
Waterfall (каскадная модель, или «водопад»)
В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.
Преимущества «водопада»
Недостатки каскадной модели
«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.
При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.
V-образная модель (разработка через тестирование)
Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.
Преимущества V-образной модели
Количество ошибок в архитектуре ПО сводится к минимуму.
Недостатки V-образной модели
Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».
V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.
Incremental Model (инкрементная модель)
Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.
Преимущества инкрементной модели
Недостатки инкрементной модели
Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок.
Iterative Model (итеративная модель)
Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техзадание.
Рассмотрим на примере создания мессенджера, как эта модель работает.
Преимущества итеративной модели
Недостатки итеративной модели
Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.
Spiral Model (спиральная модель)
Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.
Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».
Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски.
Преимущества спиральной модели
Большое внимание уделяется проработке рисков.
Недостатки спиральной модели
На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.
Что такое Agile?
Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:
Различия между Agile и традиционным подходом к разработке мы свели в таблице:
Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.
Kanban
Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.
В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.
Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!