Методологии разработки программного обеспечения кратко

Обновлено: 02.07.2024

На данный момент насчитывается достаточно большое количество методологий разработки и различных вариантов их компиляций. В этой заметке постараюсь раскидать нюансы для классификации хотя бы самых основных.

WATERFALL

Одна из самых старых моделей. В первых версиях была четко закреплена последовательность выполнения этапов. К следующему приступали только после завершения предыдущего. Это может породить простои команды не занятой в текущем этапе, приводит к увеличению стоимости внесения изменений и повышенной бюрократии. Однако точная регламентация желаемого функционала на входе позволяет сразу рассчитать стоимость воплощения. Т.е. при наличии заказчика идеально понимающего, что ему нужно и при неизменной среде (или относительно малых сроках реализации) модель может показать себя эффективнее гибких методологий (но это не точно)

В более поздних версиях модель в основном используется в сплаве с итеративными методологиями.

Недостатки каскадной модели достаточно быстро себя проявили и стали появляться её вариации и различные пути развития:

V-model

Модель предназначена для проектирования систем, которым критично важно бесперебойное функционирование. Повышенное внимание и выделение ресурсов на тестирование на всех этапах проекта. Крайне жручая к квалифицированным тестировщикам и так же обладает малой гибкостью и большой стоимостью внесения изменений т.к. работы ведутся по четкому ТЗ, составляемому в начале проекта

Итеративная модель

Модель нацелена на быстрое представление прототипа и постепенное наращивание функционала на его "костяке". Цель каждой итерации - получение конечной версии программы, вобравшую функционал предыдущих и текущего отрезка. Такая "эволюция" прототипа продолжается до финальной итерации, после которой и появится готовый продукт. Модель предполагает возможность перехода между этапами с незавершенными задачами, которые будут исправлены при следующей итерации.

RAD (быстрая разработка приложений)

Гибкая методология разработки

Если вы дочитали до этого момента, то осталось еще примерно столько же, но веселее :) Соль гибкой методологии в том, что заказчик не должен сразу согласовывать четкий план прописанный до конца проекта. Изменения могут появиться во время разработки и тут же будут включены в следующий "спринт". Это позволяет более эффективно подстраиваться под рынок, но может растягивать сроки разработки и раздувать бюджет.

Как только начинаешь искать инфу об Agile сразу же натыкаешься на упоминание Lean, Scrum, Kanban, XP и все это в одной статье с огромным VS между. Помогла вот такая картинка:

Lean - концепция, основными элементами которой являются value (как ценность, в первую очередь в глазах клиента), waste (как потери. Что-то что не приносит ценности или тратит излишние ресурсы) и flow (как процесс предоставления продукта от получения заказа до доставки клиенту). Если совсем коротко, то основные постулаты можно сформулировать так:

Смотри на весь процесс в целом
Привноси ценность
Отрезай потери

Agile - концепция, возникшая в противовес "тяжеловесным методологиям разработки ПО". Основные идеи изложены в манифесте и частично повторяют принципы Lean, частично развивают их и ближе подводят к сфере разработки.

Сравнение этих концепций очень хорошо изложено в этой статье.

Scrum - набор более конкретных принципов и методик позволяющих выстроить работу в духе Agile . Именно здесь появляются "спринты", (отрезки времени, за которые может быть получен результат. Обычно 1-4 недели), ежедневные "stand up"ы (не как у тех юморных чуваков с микрофонами, а как тактический инструмент для определения сделанного, планов и препятствий) и "ретроспективы" по окончанию спринта (В идеале, должны отвечать на вопросы "Что сделали?" "Как быть эффективнее?"). Для поддержания всей ритуалистики заводится отдельная роль Scrum-мастера. Это человек, следящий за выполнением скрам процедур и мотивацией команды. Он не руководит, потому что команда должна быть самоорганизованной (принцип Agile). Чтобы за всеми ритуалами и стендапами команда не забыла о главной цели так же вводится роль Product Owner'a, чья задача настойчиво нести видение заказчика, находясь в постоянной связи с командой разработчиков.

Все что было упомянуто до этого (Lean, Agile, Scrum) достаточно абстрактно и может применяться практически в любой сфере бизнеса. На одной из работ где я работал, в фирме по продажам инженерной сантехники, скрам+канбан с небольшими "авторскими нововведениями" использовали для управления отделами маркетинга, продаж, сервисного центра. К слову, получалось вполне упорядоченно и удобно. Но следующая методология разработана исключительно для программирования.

XP (Экстремальное программирование, не путать с Windows) - гибкая методология разработки программного обеспечения. В основе лежит 13 практик, которые подразумевают общее владение кодом(исправлять может каждый участник команды и любой участок), жесткую стандартизацию кода (если все могут исправлять, необходимо сохранить читаемость), постоянное получение обратной связи от заказчика и забетонированный финальный срок. В случае, если проект не укладывается в срок, то дату релиза не трогают, но режут функционал. А еще есть забавная практика "парного программирования". Сколько нужно программистов, чтобы закодить 1 функционал? Если серьезно, то такая методика должна позволять сразу выбирать наилучшее решение и проводить код-ревью одновременно с написанием.

Ну вот вроде и все на сегодня. Получилась достаточно объемная "шпаргалка". В рамках одной заметки нереально собрать исчерпывающее описание всех методологий, но для подкрепления верхнеуровневого понимания или "напоминалки" эта заметка вполне сгодится.

Подходы к разработке программного обеспечения определяют успех проекта, ведь без правильно подобранной методологии сложно достичь стабильности в работе продукта, безопасности и устойчивости функциональных особенностей. Руководители проекта стараются найти оптимальный вариант из множества. Рассказываем вам о них.

Методология разработки ПО – это система, определяющая порядок выполнения задач, методы оценки и контроля. Модели разработки ПО выбирают, исходя из направления проекта, его бюджета, сроков реализации конечного продукта, а также внимание стоит обратить и на характер и темперамент руководителя проекта и его команды. Подходы разработки ПО отличаются друг от друга тем, как этапы жизненного цикла программного обеспечения взаимосвязаны между собой внутри цикла разработки.

Разработка программного обеспечения состоит из следующих этапов:

• определение стратегии: выяснение требований, оценка реализации этих требований, подсчитывание бюджета и определение возможности выполнения работ для клиента на взаимных условиях. Этот этап может происходить в цикле лишь один раз.

• анализ: исследование функций, которые определились на этапе стратегии, атрибутов и связей. Данный этап обычно происходит сразу после определения стратегии и может повторяться в цикле.

• проектирование – сбор модели данных.

• реализация: разработка продукта по требованиям, взаимодействие всей команды для достижения конечной цели, один из самых насыщенных этапов цикла разработки.

• тестирование. Этот этап может идти параллельно с фазой реализации. Происходит тестирование всего, что делают разработчики, работы продукта.

• внедрение. Зачастую продукт внедряется итерациями, чтобы сделать это более качественно, постепенно справляясь с багами и трудностями. На этапе внедрения вашим главным тестировщиком будет ваш клиент. Вся система выходит на полную мощность и начинает работать для своих пользователей.

• использование и техническая поддержка. Поддержание проекта на плаву, взаимодействие с клиентом, пользователями и так далее. Все зависит от условий работы над проектом.

Чередование этих этапов, взаимодействие между ними может меняться, исходя из выбранной вашим руководителем или вами модели процесса разработки ПО.

Давайте рассмотрим популярные подходы или образцы жизненного цикла программного обеспечения.

Как известно, эту модель ПО относят к классике, так как она одна из самых первых моделей разработки ПО. Ее суть заключается в последовательном выполнении этапов жизненного цикла: анализ, дизайн, разработка, тестирование, релиз и поддержка. Каждая стадия должна быть завершена до начала новой. Преимуществом данной модели является то, что оценку качества можно выполнять после каждого этапа. Но сложно представить проект, который можно было бы реально выполнить строго последовательно. Поэтому модель часто считают устаревшей. Как к плюсам, так и к минусам можно отнести то, что при использовании данного подхода бюджет проекта и сроки его реализации точно определены. Также Водопад не дает делать шагов назад, что затрудняет тестирование, которое чаще всего осуществляется в конце разработки продукта. Получается, что последующие изменения будут значительно увеличивать бюджет и затягивать релиз проекта. Такую модель советуем использовать только на маленьких проектах, где точно не возникнет противоречий с требованиями. Каскадная модель не совсем совместима с разработкой ПО.

(или гибкая модель разработки ПО)

Методологию стоит применять, когда ваш проект постоянно адаптируется к условиям рынка, имеет большой объем и длинный жизненный цикл. Если вы творческий руководитель с миллионом новых идей, которые постоянно тестируете, то этот подход разработки точно для вас.

Agile Model имеет два отдельных гибких подхода:

Поскольку данная модель выделилась из Agile, она состоит из того же, что и Agile model. В таком подходе в команде часто появляется Scrum-мастер, который обеспечивает непрерывную работу все команды, создавая для нее все условия: поддерживая мотивацию, организовывая процедуры, фасилитирует митинги. Также на проекте появляется роль Product Owner – человек, который руководит разработкой, следит за продуктом, как BA, выступает главным звеном между миссией клиента и результатом команды.

Такая система подойдет проектам до десяти человек. Но мы бы не назвали подход эффективным, потому как требования обычно неизвестны на 50%, все постоянно меняется, так как изменения можно вносить на любом этапе разработки: весьма трудно понять затраты на разработку.

Данный подтип разработки отличается своей визуализацией жизненного цикла. Команда ориентируется на выполнение задач, которые сдаются индивидуально: задача должна пройти через все колонки – To do, In progress, Code review, In testing, Done (колонки могут быть изменены в индивидуальном порядке). Цель каждого участника команды – уменьшать количество задач в первой колонке. Данный наглядный подход позволяет понять, где возникла проблема – бутылочное горлышко, а также просто видеть организацию всего проекта.

Модель разработки ПО ориентирована на то, чтобы детально проверять и тестировать продукт на первых стадиях разработки. Уже в момент написания кода разработчиками тестировщики пишут модульные тесты, то есть начинают тестирование параллельно с разработкой. Рекомендуется придерживаться данного подхода, если вам крайне важно бесперебойное функционирование продукта, а также известны четкие требования. V-Model относят к практикам экстремального программирования.

RAD

(известная как rapid application development, быстрая разработка приложений, инкрементальная модель)

Spiral

Данная модель направлена на анализ оценки рисков. И отлично подойдет там, где нет права на ошибку. Также ее удобно использовать для введения новых линеек продукта и проведения исследований. Выглядит эта модель, как спираль, так как начинает оценивать риски сначала на локальных программах, пытаясь предотвратить риски, далее переходит на новый виток спирали, перенаправляясь к работе с более комплексными тасками. Чаще всего мы проходим такие этапы, как: планирование, анализ рисков, конструирование, оценку результата – так, если он удовлетворяет, мы переходим на новый виток.

Подход разумнее использовать на больших и дорогих проектах.

Extreme Programming

(экстремальное программирование, XP)

Extreme Programming считается неформальным подходом разработки ПО, где каждый разработчик – профессионал своего дела. Если же отношение меняется, то внедрять методологию бесполезно. Разработка продукта ведется короткими итерациями. Экстремальность подхода в том, что применяется первое простое решение, что создает большой риск. В методологии практикуется парное программирование и групповая разработка. Целью такой методологии является создать с заказчиком максимально доверительные отношения и значительно сократить срок разработки продукта.

Главное в экстремальном программировании не утратить контроль над происходящим, чтобы разработка не превратилась в хаос.

Lean

(бережливая разработка ПО)

Это не совсем методология разработки программного обеспечения. Скорее, собранные в подход принципы, нацеленные на повышение эффективности разработки продукта и улучшения рабочих процессов. Главная задача этого подхода в том, чтобы сделать проект в три раза быстрее, в три раза дешевле и в три раза чище, чем можно было бы.

В Lean есть семь принципов, которые помогают достичь цели:

• Decide as late as possible;

• Deliver as fast as possible;

• Enpower the team;

• Build integrity in;

Мы познакомили вас с основными моделями разработки программного обеспечения. Нельзя сказать, какая из них подойдет больше вашему проекту. Вы должны выбрать оптимальную сами. Многие из них пересекаются между собой, возможно, вам придется попробовать несколько, прежде чем, вы найдете ту, которая приведет ваш проект к успеху и сделает работу продуктивнее.

Здравствуйте. На последних двух собеседованиях меня спрашивали про методологии. Это не самый важный или сложный вопрос, но иметь шпаргалку-ответ будет неплохо. В этой статье я попытаюсь дать понятие, что такое методология разработки и сравнить те, с которыми встречался лично или о которых спрашивали. Методология разработки ПО – это процесс описания того, как определенный продукт будет разрабатываться, то есть один из способов организации коллективной разработки. Существует множество разных моделей такого процесса, каждая из которых описывает свой подход и нельзя сказать, что среди них выделяется одна, которую нужно использовать в каждом проекте, всё сугубо ситуативно. Предлагаю рассмотреть подробнее три из них.

Waterfal

Полная и согласованная документация на каждом этапе;
Простота использования;
Стабильные требования.
Бюджет и дедлайны заранее определены

Большое количество документации;
Не очень гибкая система;
Нет возможности вернуться на шаг назад.

Scrum

Scrum-команда – это команда работающая над проектом(разработчики, тестеры, дизайнеры).
Scrum-мастер – человек, который следит, чтобы соблюдались принципы скрама.
Product owner – заказчик.

Stand-up – короткий митинг, проводится каждый день, принимают участие все члены команды и каждый участник отвечает на 3 вопроса: что делал? Что будет делать? И какие есть блокеры?
Плэннинг – проводится в начале спринта и на этом собрании определяют какие задачи должны быть выполнены за следующий спринт.
Ретроспектива – проводится в конце спринта и её суть – выяснить, что было сделано хорошо и что можно было улучшить.

Заказчик может наблюдать результат в процессе разработки.
Ежедневный контроль над процессом разработки.
Возможность вносить коррективы во время разработки.
Налаженные коммуникации со всеми членами команды.
Малое количество документации.

Сложно оценить трудозатраты и стоимость, требуемые на разработку
Сложно определить самые узкие места до начала разработки.
Необходимость вовлечения каждого в разработку других членов команды.

Kanban

To do – список задач, которые надо сделать
In progress – задачи над которыми ведется работа в данный момент
Code review – задачи, которые сделаны и отправлены на ревью
In testing – задачи, готовые к тестированию
Done – сделанные задачи.

Простота использования.
Наглядность.(помогает в нахождении узких мест, упрощает понимание)
Высокая вовлеченность команды в сам процесс.
Высокая гибкость в разработке.

Нестабильный список задач.
Сложно применять на долгосрочных проектах.
Отсутствие жестких дедлайнов.

В заключение о методологии разработки ПО

По моему мнению, основательно разбираться в методологиях разработки ПО нужно людям, которые занимают управленческие должности или стремятся к ним, но понимать хотя бы основы желательно всем. Это неотъемлемая часть процесса разработки и используется не только в IT-сфере. Спасибо, что уделили время чтению моей статьи, надеюсь она была вам полезной. Я старался описать только ключевые моменты максимально доступно и коротко, так что статья не является исчерпывающей. Буду рад услышать ваше мнение о ней и ответить на ваши вопросы. Всем добра!

Разработка программного обеспечения — это стандартизированный комплексный процесс, который проходит множество этапов в течение порой длительного времени. Одним из важнейших этапов жизненного цикла ПО являются первые шаги, а именно — подбор методологии разработки и правильное планирование приоритетов на старте. По сути, именно от этого выбора во многом зависит дальнейший успех проекта. Эта статья поможет подобрать оптимальный вариант в большинстве ситуаций.

1. Этапы жизненного цикла ПО

Разработка программного обеспечения — сложный многоступенчатый процесс. Нельзя так просто взять и создать современное приложение. Сначала придумывается идея и концепция, ищутся инвестиции, подбирается команда, составляется список функций, которыми должна обладать конечная программа, подбирается визуальный стиль и так далее. Этот процесс включает в себя множество обязательных этапов, некоторые из которых могут проходить параллельно, в зависимости от сложности и глубины проекта.

Жизненный цикл разработки программного обеспечения от английского Software Development Life Cycle, SDLC — это условная схема, которая содержит в себе все этапы, через которые ПО проходит от формирования в виде идеи до последних дней своей работы, что еще раз подтверждает вышесказанное: разработка приложения не прекращается даже после его релиза.

Этапы, описываемые циклом разработки, также являются для начинающих создателей ПО своеобразной шпаргалкой. Ведь именно вдумчивое прохождение каждого шага, без перескакиваний и спешки, позволит на выходе получить качественный и экономически выгодный продукт, чтобы довольными остались и потребители, и заказчики, и разработчики.

Основные модели разработки ПО

Идея, сбор и анализ требований для ее осуществления.
Дизайн и проектирование.
Реализация и программирование.
Тестирование и отладка.
Внедрение и эксплуатация.
Сопровождение и поддержка.

Остановимся на каждом из них подробнее.

Идея, сбор и анализ требований для ее осуществления

Один из самых важных этапов разработки ПО, на котором принимаются главные решения. Когда у человека есть идея, ее нужно правильно сформировать и донести до других: тех, кто будет выделять на нее деньги, тех, кто будет ее реализовывать, и тех, кто будет пользоваться готовым продуктом.

Необходимо проанализировать нужно ли людям то, что вы хотите создать, будут ли они этим пользоваться, окупятся ли вложенные в производство время и деньги, учесть риски. Поэтому нужно понимать, на кого программа будет рассчитана, что она должна делать, какие у нее есть конкуренты на рынке и так далее, а также четко в задокументированном виде обозначить конкретные цели и результат работы.

Дизайн и проектирование

Когда сформировались четкие требование к ПО, которое нужно создать, переходят к этапу его непосредственной разработки. На основе изложенных идей и требований подбирается техническая архитектура продукта. Описываются функции и технические детали продукта, подбирается визуальный стиль какие элементы будут отображаться, в каком порядке, в какой цветовой палитре и так далее .

Именно на этом этапе подбираются технологии, которые будут применяться для реализации проекта, подбирается команда, определяется загрузка команды, формируется самый приближенный к конечной цифре бюджет разработки.

Реализация и программирование

Это один из самых легких в описании, но порой один их самых трудных в реализации этапов. Именно в этот момент в дело вступают программисты, которые на основе всех составленных документов, схем и иллюстраций пишут код таким образом, чтобы готовое ПО выглядело именно так, как задумывалось, и делало то, что необходимо.

Тестирование и отладка

Код готов и скомпилирован, приложение создано и существует физически. На этом этапе нужно проверить, все ли работает как задумывалось, нет ли каких-то дефектов, ошибок, системных неисправностей, все ли механики правильно реализуются, все ли функции работают корректно.

Тестированием занимаются специально обученные люди, которые проходятся по всем возможным вариантам взаимодействия с ПО, а затем составляют отчеты о найденных ошибках и багах, чтобы разработчики могли их устранить. Этот этап повторяется до тех пор, пока участники проекта не останутся довольны уровнем качества продукта.

Внедрение и эксплуатация

Когда ПО прошло тестирование и готово к использованию, его выпускают на рынок. Этот этап также может проходить плавно. К примеру, приложение можно выпустить на ограниченном рынке только в одной стране , чтобы пройти дополнительную проверку гипотезы ведь пользователи могут столкнуться со сценариями, которые не учитывали разработчики , что даст время доработать и улучшить продукт. Так или иначе, на этом этапе с ПО начинает взаимодействовать конечный потребитель — люди.

Сопровождение и поддержка

Самый длительный этап жизненного цикла ПО. Здесь разработчики следят за тем, чтобы программа работала исправно и не имела багов. Некоторые ошибки исправляют сразу с помощью хотфиксов, некоторые убираются во время следующего обновления.

В обновлениях также часто внедряют новые функции, фишки, улучшают удобство использования продукта, его производительность и так далее. Если приложение успешно и живет долго, разработчики обновляют используемые технологии и стандарты в соответствии с современными возможностями. Также на данном этапе в работу включается отдел технической поддержки, который обеспечивает обратную связь с пользователями.

Естественно, помимо указанных выше, существуют также и другие этапы и процессы, происходящие во время разработки ПО например, маркетинг работает на протяжении всего цикла — от тизеров о грядущем выпуске чего-либо до скидочных предложений на годовщины . Кроме того, некоторые действия могут совершаться одновременно.

В зависимости от сложности и амбиций проекта разные этапы могут занимать разное время. От этого зависит и выбор методологии, от которой идет обратная зависимость к последовательности и длительности разных этапов. Далее мы детально рассмотрим основные модели и практики при разработке ПО.

2. Основные модели разработки ПО

Методология разработки ПО — это система, которая определяет порядок и сроки выполнения задач внутри этапов жизненного цикла, методы оценки и контроля. Бюджет и сроки выполнения проекта и метод разработки связаны и зависят друг от друга.

От выбора методологии будет зависеть то, как разные этапы жизненного цикла будут связаны между собой и в какой последовательности реализованы. Чтобы правильно выбрать модель, нужно понимать плюсы и минусы каждой из них и суть своего проекта.

С одной стороны, проектом легко управлять, есть четкая последовательность действий, сроки выполнения и бюджет известен заранее. С другой — проекты с такой моделью не терпят правок, требующих возвращения к предыдущим этапам, а результат заказчик видит только на завершающих этапах разработки, когда приложение почти готово.

Таким образом, для небольших проектов с относительно малыми сроками реализации при грамотно составленной документации требованиях к продукту каскадная модель — лучший выбор. Когда все понятно и оговорено, все этапы проходятся быстро и получается отличный результат без переплат за дополнительное перепрохождение различных этапов в других методиках.

Однако чем проект больше, тем больше риск ошибиться в какой-то момент и получить на выходе не то, что нужно, что увеличит бюджет в несколько раз из-за необходимости возвращаться к давно пройденным этапам.

Преимущества каскадной модели

Простое управление разработкой при наличии четко сформулированной документации.
Стоимость и сроки известны на начальном этапе.
Низкая вероятность ошибок в небольших проектах.
Тестирование могут проводить люди с более низкой квалификацией из-за наличия подробной документации .

Недостатки каскадной модели

Тестирование происходит на последних этапах.
Чем масштабнее проект, тем большая вероятность критических ошибок, исправление которых потребует значительного увеличения бюджета.
Заказчик видит готовый продукт лишь в конце разработки.
Написание и согласование подробной документации также может вызвать множество задержек.

V-образная модель (разработка через тестирование)

К примеру, тесты удобства интерфейса проходят еще на этапе дизайна, функциональные и нагрузочные тесты — по мере написания кода, интеграционные тесты, которые подтверждают, что несколько компонентов от различных производителей вместе работают стабильно, — по мере добавления элементов платежные системы, модули связи с почтовыми ящиками и так далее .

Соответственно, V-образная модель также подходит для небольших и средних по объемам проектов, где вся документация четко прописана и требуется определенный уровень качества (высокий). Это могут быть приложения безопасности, наблюдения за тяжелобольными пациентами, ПО для атомных электростанций и так далее.

Преимущества V-образной модели

Тестирование проходит на всех этапах разработки.
Вероятность ошибок сводится к минимуму.

Недостатки V-образной модели

Требуется высокий уровень квалификации тестировщиков и/или их высокая занятость.
Если ошибка все же была допущена, то вернуться к предыдущему этапу будет даже дороже, чем при каскадной модели.

Incremental Model (инкрементная модель)

Имеется в виду, что процесс создания программы со множеством задуманных функций начинается с воплощения в жизнь базовой версии. Проходят этапы анализа, дизайна, программирования, тестирования и выпуска продукта на рынок.

К примеру, создатели задумывали приложение для обмена фото, музыкой и видео, но чтобы оно быстрее добралось до пользователей, реализовали только фотообмен. Затем начинается разработка модуля для обмена музыкой и весь процесс повторяется. Затем цикл проходит в третий раз, когда создается модуль обмена видео.

Преимущества инкрементной модели

Есть возможность раннего выхода на рынок, чтобы посмотреть реакцию пользователей.
Базовая версия ПО стоит дешевле. Модули можно доделывать по мере появления денег, либо не делать вовсе за ненадобностью. Самые рискованные идеи можно отложить на потом.
Исправление ошибок обходится дешевле.

Недостатки инкрементной модели

RAD (быстрая разработка)

RAD Model (Rapid Application Development model) — это модель быстрой разработки приложений. Это своего рода ответвление инкрементной модели, так как процесс создания ПО происходит таким же образом с единственным исключением — над проектом работает сразу несколько команд. То есть в один момент времени параллельно существует несколько мини-проектов в одном большом проекте, которые интегрируются в рабочий прототип по мере готовности.

Все преимущества и недостатки инкрементной модели справедливы и для RAD, просто процесс идет еще быстрее, но требует еще более качественного и жесткого менеджмента, а также крепкой обратной связи и синергии между всеми командами. Каждый участник должен понимать итоговую цель.

Iterative Model (итеративная модель)

По сути, итеративная модель — это также разновидность инкрементной модели, которая, однако, лучше показывает себя в больших проектах, где конечная цель заранее не определена либо планируется применение каких-либо инновационных подходов.

То есть в инкрементной модели реализуется задуманный набор функций готовыми кусками сделали чат, добавили полноценную работу с фото, добавили полноценную работу с видео , а в итеративной — реализуется костяк с не доведенными до ума функциями с постепенным их улучшением сделали чат и фото профиля, добавили обмен фото и встроенное видео, добавили обмен видео и придумали новую фишку .

Преимущества итеративной модели

Есть возможность раннего выхода на рынок, чтобы посмотреть реакцию пользователей.
Возможность запустить проект, когда конечная цель до конца не определена.
Добавлять новые функции и менять направление проекта можно с каждой новой итерацией в зависимости от бюджета.

Недостатки итеративной модели

Spiral Model (спиральная модель)

Таким образом, эта модель подходит для тех, чей бизнес зависит от финансового успеха продукта то есть тех, кто не может позволить себе неудачу из-за риска банкротства , либо для очень объемных, сложных и дорогих проектов, где нужен постоянный контроль рисков.

В целом, преимущества и недостатки подобных моделей справедливы и для спиральной. Только здесь анализ рисков идет постоянно и выпустить ненужный продукт практически невозможно, но при этом можно надолго застрять на одном из этапов, бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.

3. Что такое Agile и Lean: принципы разработки ПО

На основе семейства итеративных моделей также был придуман сверхпопулярный ныне гибкий подход к разработке ПО — Agile. И это, скорее, действительно подход, а не отдельная методология, потому что внутри проекта, который ведется по Agile, на разных этапах могут применяться и каскадные, и итерационные модели.

В основе подхода стоит разбиение разработки на множество отдельных задач, которые разные специалисты могут выполнять практически независимо друг от друга. Ежедневно проходят встречи команды (Scrum), где обсуждается текущий прогресс. Разработка при этом делится на этапы — так называемые спринты (Sprint), в ходе которых команда должна достигнуть определенного результата полностью закончить дизайн, показать базовую версию продукта и так далее .

Такой подход хорошо работает, когда у заказчика много идей и он на начальном этапе не уверен, какие из них будут реализованы, а с течением времени например, в процессе запуска первых версий у него еще и появляются новые. Agile также подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка.

Преимущества гибкой модели

Возможность начать разработку ПО без четкого плана, имея лишь набор идей.
Возможность для заказчика видеть даже минимальный результат работы и вносить изменения на ходу, что уменьшает вероятность необходимости правок на поздних этапах.
Более дешевая поэтапная разработка, а также возможность постоянной адаптации к изменяющимся условиям рынка из-за наличия коротких спринтов.

Недостатки гибкой модели

Agile включает в себя множество разных подходов, техник и методологий, которые сводятся к поэтапному созданию конечного продукта. Среди них можно выделить:

Scrum — где люди постоянно общаются и взаимодействуют между собой на собраниях и обсуждениях.
Kanban — где есть виртуальная доска с задачами, которые можно выполнять в любом порядке.
RUP — где есть четкие фазы планирования, уточнения и построения новых итерация ПО.
Extreme Programming — где применяется высокая частота обновления версии продукта ориентация на постоянные изменения требований и поиск самых быстрых решений.

Везде применяется философия готовности к изменениям, сотрудничества с заказчиком, а не следования контракту, нацеленности не на описание документации, а на создание рабочего ПО, а также важности самоорганизации людей, занятых в проекте.

Как видно из всего вышесказанного, у каждой методики и модели есть свои яркие преимущества и неизбежные недостатки и каждая из них может работать для достижения определенного круга задач.

В заключение, чтобы еще больше углубиться в эту большую тему, можно посмотреть это подробное видео:

Читайте также: