1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ.
Когда использовать каскадную методологию?
- Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
- Нет проблем с доступностью программистов нужной квалификации.
- В относительно небольших проектах.
2. «V-Model»
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
- Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
- Для малых и средних проектов, где требования четко определены и фиксированы.
- В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.
Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
- Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
- Требуется ранний вывод продукта на рынок.
- Есть несколько рисковых фич или целей.
4. «RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
- Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
- Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
- Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
- Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
- Тестирование: тестируются новые компоненты и интерфейсы.
Когда используется RAD-модель?
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
5. «Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
- отчёт о проделанной работе с момента последнего Scrum’a;
- список задач, которые сотрудник должен выполнить до следующего собрания;
- затруднения, возникшие в ходе работы.
Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка. Соответственно, в процессе реализации требования изменяются. Стоит вспомнить класс творческих людей, которым свойственно генерировать, выдавать и опробовать новые идеи еженедельно или даже ежедневно. Гибкая разработка лучше всего подходит для этого психотипа руководителей. Внутренние стартапы компании мы разрабатываем по Agile. Примером клиентских проектов является Электронная Система Медицинских Осмотров, созданная для проведения массовых медосмотров в считанные минуты.
Когда использовать Agile?
- Когда потребности пользователей постоянно меняются в динамическом бизнесе.
- Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
- В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
6. «Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.
Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
- Требования к конечной системе заранее четко определены и понятны.
- Проект большой или очень большой.
- Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
- планирование;
- анализ рисков;
- конструирование;
- оценка результата и при удовлетворительном качестве переход к новому витку.
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование. Два совещания об изменении кодификации разделов электронного архива занимают больше времени, чем объединение двух папок программистом. Государственные проекты, в которых мы участвовали, начинались с подготовки экспертным сообществом дорогостоящей концепции, которая отнюдь не всегда бесполезна, поскольку окупается в масштабах страны.
Подытожим
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (40)
gandjustas
03.11.2015 21:54+24Смешались в кучу
кони, людимодели и методологии.
Waterfall, V, Инкременты, эволюция прототипов, спираль — модели. Модели нужны чтобы предсказывать будущее поведение систем.
Scrum, Kanban, RUP, CMM, MSF, XP и даже TDD — методологии, то есть набор артефактов и ритуалов. Методологии нужны чтобы система работала (и вообще существовала как система), а еще нужны чтобы продавать софт, консалтинг, книги и прочий инфобизнес.
Agile это не модель и не методология, это набор принципов на основе которых можно построить множество моделей и методологий.
artur_g
04.11.2015 09:18+1+1.
Например Scrum и SAFe — совершенно разные методологии, которые поддерживают принципы Agile и реализуют итеративную модель жизненного цикла.
artur_g
04.11.2015 09:43+12Справедливости ради, нужно отметить, что в данной статье клёвые картинки :)
artur_g
03.11.2015 22:17+2По вашему получается, что тщательное тестирование происходит только в V-Model, а спиральная модель — то же самое что итеративная, только зачем то выделено 4 этапа.
На мой взгляд главная особенность V-Model — связь этапов анализа и проектирования с этапом тестирования. Пример: пока аналитик уточняет требования, тестировщики продумывают высокоуровненвые методы и подходы к тестированию, пока архитектор проектирует систему, тестировщики продумывают тест-планы, пока архитекторы проектируют компоненты системы, тестировщики создают тест-кейсы, инструменты, инструкции и т.п. Т.е. к тому времени пока мы подойдём к реализации уже есть куча документации, не только по требованиям и архитектуре, но и по тщательно продуманному тестированию.
Важная особенность спиральной модели — на этапе анализа риска мы создаём концепты, прототипы и модели чтобы попробовать оценить и разрешить риск до того, как приступим к реализации
ToSHiC
04.11.2015 00:33Скажите пожалуйста, что такое «большой проект», сколько это человеколет разработки? У вас это написано как критерий, а определения нету.
AmdY
04.11.2015 02:20+6Просто удивительно, как мнеджеры любят изобретать велосипеды, читать модные книжки по управлению проектами, ходить на треннинги, получать сертификаты, обязательно певать в сторону водопадной модели, но при этом умудряются так и не прочитать десять страничек о ройсовских водопадах.
artur_g
04.11.2015 07:37+5Причина плевков в сторону не-ройсовских водопадов это то, что именная такая модель часто приводит к провалу крупных проектов. Ройсовские водопады, с их возможностью возврата на предыдущий этап, на мой взгляд, всё равно хуже итеративной модели. Не стоит забывать, что в то время, когда Ройс написал свою статью, процесс разработки был совершенно иным. Отлаживали в уме и на листочке, писали на перфокартах, относили их в компьютерный центр, ждали неделю когда протестируют, а потом исправляли ошибки. Понятно что в то время итеративный подход был неприменим, не говоря уж о TDD, непрерывной интеграции и т.п.
Ivan22
04.11.2015 11:16+3Как-то не очевидны отличия между этими моделями.
Вот давайте на примере, по простому:
Если мы имеем
1. Есть новый кусок требований у заказчика:
2. Аналитики проанализировали, написали какое-то ТЗ на разработку
3. Разработчики разработали
4. Тестировщики оттестировали
5. Выкатили в прод, заказчик посмотрел и появились новые требования
— и дальше Go To 1
Это вот какая модель разработки??? Водопад или итерационная? Или спиральная. Я как-то теряюсь.
И как она будет выглядить во всех 7 разных вариантах.
p.s. Реально хочется разобраться, без наезда!dtestyk
04.11.2015 14:21субъективно:)
- каскадная: требования не меняются в процессе разработки
- V-Model: задачи разбиваются на подзадачи, для каждой задачи создается задача проверки
- инкрементная: имплементят фичи одну за другой, пока их становится слишком много
- RAD: рисование UML и прочих диаграмм, генерация кода по ним, SQL в визуальном редакторе, рисование формочек в конструкторе и т.д.
- agile: ежедневные митинги, где можно похвастаться достижениями и пожаловаться на проблемы
- итеративная: быстро делают протототип, потом долго отлавливают баги, отвлекаясь на изменяющиеся требования заказчика
- спиральная: в колесо цикла разработки вставляется палка в виде анализа рисков
модели разработкиIvan22
04.11.2015 14:553. Внутри каждой фичи они разрабатываются водопадно?? или как?
4. Вообще не понял. А в любой другой модели нельзя рисовать uml и генерить код визуально, так чтоли?
5. Хм… вом мы как бы инкрементально по фичам работаем и каждый день митинги проводим — это аджайл или нет?dtestyk
04.11.2015 18:31+13. в оптимистическом варианте
4. можно(например, в рамках спиральной модели), это же методология(способ)
посмотрите на картинку
в цикле нет явного планирования, тестирования
субъективно:
- заказчик смотрит на программу и говорит:
- «у пользователя может быть два телефона»
- «а что если кнопочка будет желтая»
- добавляете поле, соответсвующее поведение
- меняете цвет
- показываете заказчику
tangro
04.11.2015 13:13+15А в опросе не хватает пункта «мы врём заказчику, начальству, друг другу и сами себе, что используем Agile, а на самом деле у нас хаос».
PavelSandovin
04.11.2015 20:50В чем принципиальное различие между перечисленными в статье итерационными моделями?
Глядя на процессы с точки зрения заказчика, если я заказываю «Мону Лизу» — мне все равно, будет она писаться итерациями с прорисовкой деталей поверх общего эскиза, или же итерациями с прорисовкой отдельных областей.
Главное, чтобы это была «Мона Лиза», в срок и в рамках бюджета.Ivan22
05.11.2015 09:09Как раз таки я очень понимаю разницу с т.з заказчика. В итеративной модели быстро можно увидеть всю картину (недоделанную, нетестированную, с багами, но всю!) Это очень, скажем так — воодушевляет заказчика (на самом деле). А когда частями — некоторые части не увидеть совем до последнего дедалйна — и если эта часть внезапно совсем не то что надо — может быть поздно!
Shchvova
programming-motherfucker.com
i360u
Результатом этого мазафака-программинга, без того, что перечисленно вначале, будет огромное количество никому не нужного кода. То есть полный фейл. К сожалению.
Shchvova
Результатом всяких «методик разработки» есть красивые графики которые можно показать начальству. И многократное замедление процесса разработки. Как будто тикеты когда-то увеличивали полезность кода. Или, как будто, скрам мастер вдруг сделает что код не бесполезен. Три раза «ха».
i360u
Тикеты — это формальные указатели на задачи, которые требуется решить. Что вы собрались писать, не имея представления о задачах и приоритетах? Тикеты — это инструмент структурированного (эффективного) общения в команде. Как вы собираетесь синхронизировать свою работу с остальными, не имея удобных сущностей для привязки? Тикеты — это удобный инструмент внутрикомандного планирования, причем тут вообще начальство? По большому счету, абсолютно пофигу как вы называете свою методологию, но совсем без нее вы получите только несъедобную кашу: в головах, в коде, в общем результате. Проходили такое. Ха.
Shchvova
Ваши утверждения о «эффективности» голословны. Более того, я считаю что они еще беспочвенны и неправильны.
i360u
Ну конечно. У меня ведь нет совершенно никакого собственного опыта управления и участия в разработке, вам ведь лучше знать. Ок. =)
VladimirKuzmenko
Позвольте не согласиться. Методологии устанавливают правила игры, которых должна придерживаться команда проекта чтобы не «влазить в чужие тапки», по возможности избегать конфликтов и понимать «где мы сейчас находимся и что нам осталось». И по-сути тут всего два больших подхода:
Весь современный уход в «гибкость» вызван высокой конкурентностью рынка ИТ-продуктов. Пока одни думают «как сделать сразу всё правильно» — другие уже выпустили «хоть что-то» и забили место в своём сегменте.
При этом «гибкость» часто приносит в жертву правильное планирование архитектуры. А 2-3 этапа рефакторинга между версией 1 (вышли в паблик) и 2 (вот теперь у нас все фичи и монетизация) таки растягивают и сроки и бюджеты. Что и вызывает необходимость в экспертах по «экстремальному программированию»
Shchvova
Да, я согласен. Методологии это компенсация если в команде поломано общение. Я и не спорю. Но не надо рассказывать про «эффективность» и прочую ахинею. Любая формализация идет в убыток производительности. Если у вас не хорошо слаженна работа в команде, то безусловно, можно выбрать процесс и следовать ему.
P.S.
Я, кстате, так и не понял с чем Вы не согласны.
VladimirKuzmenko
Мне не понравилось утверждение, что «Результатом всяких «методик разработки» есть красивые графики которые можно показать начальству»
«Методики разработки» нужно грамотно подбирать под конкретную команду и особенности проекта. И тогда эффективность — речь об эффективности работы команды — будет расти.
Т.е. эффективность является скорее метрикой работы команды. А знание методик и умение грамотно их применять в конкретных случаях — её повышает
Shchvova
Ну, а что еще? Любая бюрократия идет в убыток максимальной возможной производительности.
Знание методик и умение их применять может только уменьшить убыток от бюрократии которую они тащат. Если ваша команда не может без бюрократии — пожалуйста. Суйте свои оверхеды методик.
michael_vostrikov
Речь не о бюрократии, а об организации процесса постановки задач. Можно полчаса обсуждать задачу с начальником/заказчиком в то время, когда удобно им, а можно за 2 минуты прочитать общую постановку задачи в таск-трекере, потратить 2 минуты на написание коммента с уточняющими вопросами, и через час потратить еще 2 минуты на чтение ответа. В остальное время можно заниматься другой работой или
пинать балдусвоими делами (в зависимости от ситуации).Мне кажется, вы просто переносите свой негативный опыт в конкретной ситуации на все методологии организации процесса разработки.
Shchvova
И я не спорю что я выражаю отвращение и собственный негативный опыт внедрений эджайла консультантами которыми было интересно получить деньги а не достичь результата. И я далеко не один такой.
Ни одного позитивного опыта внедрения процесса я не видел. Было плохо или стало еще хуже, или было хорошо и осталось хорошо, но с красивыми графиками для начальства.
О тикетах у меня очень другое мнение. Я считаю что лучше поговорить пол часа с заказчиком, понять что нужно сделать, и сделать это, чем писать комменты, и пинать балду остальное время, а потом переделывать фичу в следующем спринте потому что не так что-то поняли в переписке.
У тикетоной модели есть бонусы — это формальная методология, у которой работники это шестеренки в системе. Их можно легко заменять. Уволился человек, ничего страшного, раскидали его тикеты, и дальше идет машина.
korvinriner
Хмм, а потом вы заболеете, умрете, уйдете в другой проект… то что вы «наговорили» с заказчиком уйдет вместе с вами… А оставшиеся, через полтора месяца, будут ломать голову, как должен был работать вот именно тот кусок кода, который вы тогда написали, и работает ли он правильно сейчас… В конечном итоге — переписанный за вами функционал, который возможно и правильно работал и его потом еще раз перепишут, протестируют, интегрируют… потратят 100500 часов, вместо одного-двух часов «бюрократии»… В конечном итоге методология — инструмент не только разработки, но и общения и сохранения знаний о проекте. При нормальных или близких к нормальным условиях.
Shchvova
А при чем здесь «эффективность»?
korvinriner
Эффективность — отношение затрат к полученному результату. В случае с разработкой ПО — получение максимально ожидаемого и предсказуемого результат с наименьшими затратами — высокая эффективность. В случае, который я привел, как пример, «без бюрократии» затраты во много раз превысят затраты «с бюрократией», соответственно эффективность процесса будет ниже в разы. Но про эффективность как таковую я не писал, я просто привел пример, почему методологии/методики/принципы и т.п. стоит применять и подчиняться правилам. Когда все идет как должно идти пользу методологии вы не увидите, она будет казаться вам чем то лишним и ненужным, а вот когда случится какая-нибудь *опа… Снизить риски и потери как компании так и сотрудников (в том числе и имиджевые) может только грамотно настроенная и соблюдаемая методология производства… А *опа случится обязательно рано или поздно… «Просто писать код» — это круто, но не надо тогда удивляться, когда однажды вместо зп получите кукиш, просто потому что сочетание различных обстоятельств привело к тому, что контора не получила доход, а вы (или ваше начальство и коллеги) никак не поучаствовали в том, чтобы хотя бы часть из этих обстоятельств отработать хотя бы методологией…
saboteur_kiev
Вы конкретно путаете бюрократию (причем именно негативную ее часть) и организацию дела.
Вы считаете, что ничего не нужно для того, чтобы производить продукт. Но кто-то должен платить налоги, получать переводы, чтобы вы могли получить за продукт зп. Если вы не получите ЗП, вы не будете разрабатывать, следовательно производительность упадет.
То, что вам не понравилось, как в какой-то отдельно взятой конторе менеджер бегает за красивыми словами, а не за организацией труда, никак не умаляет плюсы и agile и waterwall, грамотно реализованными.
Shchvova
Я считаю что нужно писать код. Все остальное не стоящая внимания фигня придуманная бездельниками.
В больших компаниях такое не работает, но и большие компании я считаю болотом на 80% заселенными бездельниками.
Те кто не бездельники обязаны тратить время на бюрократия. Кстате, бюрократия это по определению следование процессу.
JustRoo
И это пипец какое распространенное и дорогое заблуждение. Не нужно писать код. Нужно решать проблемы. Если ты написал 100к строк охренительного кода, но этот код никаких проблем не решает, ты выкинул N времени своей жизни в трубу, потому что лучше-то от твоего кода никому не стало, только энтропия увеличилась. И не полезет никто никогда в твой код, потому что он никому не нужен. Собственно, всем вообще наплевать, есть твой код или нет. У всех проблем по горло, а тут какой-то код, который вообще хрен знает, для кого.
И вот ровно затем, чтобы все четко понимали, чью проблему, какую проблему, как и в какие сроки они пытаются решить, нужна организация производственного процесса, то есть — бюрократия. Работающая. Эффективная. Решающая проблемы. Делающая мир лучше. Бюрократия. Добро пожаловать.