Во-первых, независимо от модели развития. Разработка программного обеспечения включает как минимум следующие циклы, в том числе:

1. Сбор/анализ требований (системный анализ, анализ программного обеспечения)
2. дизайн
3. выполнить
4. тест
5. опубликовать (запустить)
6. поддерживать

Поскольку все модели разработки имеют одинаковый цикл разработки, в чем отражаются различия между разными моделями разработки? Или каковы различия между разными моделями разработки в управлении процессом разработки?

Различия, которые я понимаю, в основном отражаются в:

1. Рабочий лимит для каждого цикла активности
2. Сколько раз каждый цикл повторяется
3. Когда периодические действия повторяются
4. Объем руководства по разработке программного обеспечения

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

• модель водопада：Ожидайте, что вся система будет целостной от начала до конца.,Все действия цикла выполняются только один раз. То есть, необходимо выполнить сбор требований только один раз (получить все требования одновременно).,Один анализ спроса (завершить весь анализ спроса одновременно),Один раз дизайн и так далее.
• инкрементная модель：инкрементная модель структурно разбивает всю систему на несколько инкрементов (функциональных модулей) -- Например, 3, каждый полный цикл завершает приращение, и если приращений несколько, оно будет повторяться в течение нескольких циклов.
• итеративная разработка：При итеративной Разработка делит работу по разработке системы на итерации и не требует завершения разработки всей системы в одну линию (по сравнению с каскадной разработкой). итеративная В настоящее время существует два типа разработки: одна предполагает использование модели на каждой итерации. водопада. Другой — завершить определенный этап разработки программного обеспечения на каждой итерации. Первое легко понять. В этой последней итерационной модели,В начале каждой итерации вам нужно только определить требования к текущей итерации, чтобы начать итерацию. Например, итерация 0 завершает сбор требований и разработку архитектуры итерации 1.,Подготовительные работы к разработке, тестированию и т.д.,Итерация 1 завершает сбор требований для итерации 2 и завершение итерации 1.,Итерация 2 завершает требования итерации 3 и разработку итерации 2 и итерации 1.,Итерация 3 завершает требования итерации 4, разработку итерации 3, разработку итерации 2 и тестирование итерации 1. в это время,Итерировать1Готов к публикации。Каждый последующий Итерировать Вы можете опубликовать его один раз。Это продолжает цикл。
  • Эволюционная модель：Эволюционная модельпринадлежатьитеративная идея. Эволюционное развитие не требует (или не может) выявить все потребности с самого начала. Поэтому сначала разработайте относительно упрощенный прототип и разместите его в сети (используя модель водопада), а затем определить требования для следующей итерации на основе различных источников спроса и повторить модель. водопада завершить следующую итерацию.
  • спиральная модель：спиральная модель относится к эволюционной разработке (также относится к итеративной разработка）。спиральная модель сочетает в себе итеративную и модель эволюционного развития Систематика и мониторинг водопада. Самой большой особенностью является введение анализа рисков, которого нет в других моделях. В каждой итерации после определения целей, планов и ограничений наступает этап оценки рисков (выявление и устранение рисков). Если существуют неопределенные риски, необходима дальнейшая работа по выявлению всех рисков. Чрезмерный риск может даже привести к прекращению проекта. Когда идентификация риска завершена и определен план устранения риска, продолжайте использовать модель Завершение водопада является одноразовым итеративным. идея. После многих итераций желаемый эффект был достигнут.
• Гибкая разработка：Если только изразвиватьначиная с основной стадии,Гибкая разработкато естьитеративная разработка。Ран Фактическиитеративная разработкада Гибкая Часть разработки, часть, которая управляет этапом разработки. Гибкая разработка Также включеноитеративная Что не включает в себя: открытие карты, закрытие карты, TDD, Pair Практическая деятельность, такая как программирование, обзор, обратная связь и т. д. Гибкая разработкасуществоватьитеративная На основе разработки,Внедряя некоторые мероприятия для достижения командной самоциркуляции и самосовершенствования.,тем самым повторяя работу самой команды,улучшить командуразвиватьэффективность、качество、Опыт и т. д.
• модель фонтана：модель фонтана воплощает безграничный характер разработки программного обеспечения (нет четких границ между каждым этапом) и итераций. Словно вода из фонтана бьет и снова падает. То же самое относится и к этапам разработки. Вы можете вернуться с определенного этапа на любой предыдущий этап (например, от тестирования обратно к сбору требований). PS: Такое ощущение, что Модифицируйте и моделируйте одновременно。
• Модифицируйте и моделируйте одновременно：Модифицируйте и моделируйте одновременнопринадлежатьпрограммное обеспечениеразвивать Модель без ограничений（такжедапрограммное обеспечениеразвиватьсамая легкая модель）。Модифицируйте программное обеспечение под модель, делая эторазвиватьнет фиксированного、четкие циклы и фазы。Когда появляется какая-либо идея（Пока не могу сказатьдануждаться）,Я начал заниматься дизайном (анализ потребностей был неосознанно интегрирован в дизайн и разработку и даже ссылки на тестирование). После выпуска 30-й версии для начала разработки будет выбрана первая версия. В середине разработки я решил добавить немного вдохновения (возможно, отменив ранее созданные функции) и даже решил принять вторую версию. После неоднократных перепланировок и перепланировок,Наконец половина разработана,Обнаружение недостаточности ресурсов/времени,Мне сказали, что завтра он должен быть онлайн. После финальной задержки в полгода было обнаружено множество ошибок (ошибки сочетания системных функций, ошибки дизайна, ошибки разработки и т. д.).,Начните совершать ошибки и одновременно исправлять их.bugэтап（вероятный проектразвивать Половина умерла в младенчестве）。

Давайте сосредоточимся на модели водопад, инкрементная модель, итеративная разработка、Гибкая разработка。

модель водопада

Ее также можно рассматривать как модель жизненного цикла программного обеспечения.

Основные этапы напрямую связаны с основной деятельностью по развитию:

• Анализ и определение требований：Создание системных сервисов путем консультирования пользователей системы.、ограничения и цели。и определить его подробно, чтобы сформировать системуописывать。
• Проектирование систем и программного обеспечения：системадизайн Процесс устанавливаетсясистема Общая архитектурануждаться Аппаратное обеспечениенуждатьсяипрограммное обеспечениенуждаться。программное обеспечениедизайнвключая выявление иописыватьнекоторые базовыепрограммное обеспечениесистема Абстракции и их отношения。
• Внедрение и модульное тестирование：существоватьэтотэтап,Воляпрограммное обеспечениедизайнвыполнитьпредставляет собой набор программ или программных модулей。единицатестто есть Проверьте каждыйединицада Соответствует ли оно своимописывать。
• Интеграция и тестирование системы：Интегрируйте отдельные программыединицаили набор процедур,И выполните тестирование системы в целом, чтобы убедиться, что она соответствует потребностям программного обеспечения. после теста,Программный комплекс будет передан заказчику для использования.
• Эксплуатация и обслуживание：В обычных обстоятельствах（Нетданеобходимый）,Это стадия с самым длинным жизненным циклом. Система установлена ​​и введена в эксплуатацию. поддержка включает в себя исправление ошибок, обнаруженных в конце более ранних этапов,Улучшение производительности различных узлов системы,И улучшайте сервисные возможности системы при возникновении новых потребностей.

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

постепенное развитие

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

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

Некоторые важные преимущества постепенного развития перед моделью водопада:

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

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

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

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

С добавлением новых прибавок,Структура системы постепенно деградирует。除非投入时间и金钱用существовать Рефакторингсистемаструктурно улучшитьпрограммное обеспечение,В противном случае регулярные изменения могут повредить структуру системы. через некоторое время,Чем дальше вы продвигаетесь, тем труднее менять систему.,И затраты будут постепенно расти.

Итеративная разработка:

Так что же такое «итеративная разработка»? Английское слово «итерация» — iterative, что буквально переводится как «повторение». Итеративная разработка на самом деле означает «повторяющаяся разработка».

Итеративная разработка разбивает большую задачу на несколько последовательных разработок, и ее суть — постепенное улучшение. Итак, его определение:

При итеративной разработке Вся работа разбита на серию небольших, фиксированных по времени небольших проектов. Это называется серией итераций, то есть итеративной. разработка。

Еще в конце 1950-х годов в области программного обеспечения появились итеративные модели.

Самый ранний итерационный процесс можно описать как «поэтапную модель». Итеративная модель — это периодическая модель, рекомендованная RUP. Определяется как: Итерация включает в себя все действия по разработке, которые приводят к выпуску продукта (стабильной исполняемой версии продукта), а также все другие периферийные элементы, необходимые для использования этого выпуска.

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

По сути, это что-то вроде небольшого проекта-водопада.

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

итеративная разработкасамдаплановая стратегия пересмотра：проходил несколько разразвиватьулучшитьсуществовать Особенности сборки,Шаг за шагом к идеальному решению。Например,Продукт, о котором мало что известно,Начните с создания прототипа, чтобы получить важные знания,Затем вы можете создать немного лучшую ревизию.,Далее следует довольно хорошая версия. Например,В процессе написания статьи,Получив обратную связь и получив более глубокое понимание того, как выразить тему, я,Каждую главу я пересматривал несколько раз.

Разница между поэтапной разработкой и итеративной разработкой

Поэтапное развитие:

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

Итеративная разработка:

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

Итеративная разработка требует лишь разделения разработки на несколько итераций и не отвечает на важный вопрос: как разделить итерации, какие задачи находятся в этой итерации, а какие задачи в следующей итерации? В настоящее время для разделения итераций обычно используется «инкрементальная разработка» (incremental development).

Так называемая «поэтапная разработка» означает, что в каждую версию программного обеспечения будет добавлена ​​полная функция, понятная пользователям. Другими словами, итерации делятся по новым функциям.

Гибкая разработка

Гибкая разработка（agile development) — очень популярный метод разработки программного обеспечения. По статистике 90% разработок ПО в 2018 году использовали Гибкую разработка。

Гибкая разработкаосновнойдаитеративная разработка（iterative разработка). Agile должен быть принят итеративно разработкаспособ。

Гибкая разработка — это общая концепция, а итеративная разработка — это практика Гибкая Средство разработки концепции. Гибкая Помимо итеративной разработки, разработка также включает в себя множество других методов управления и инженерных технологий, таких как проектирование эволюционной архитектуры, гибкое моделирование, рефакторинг и автоматический регрессионный тест (ART). Подводя итог, Гибкая разработкаиитеративная Разработка — это отношения между целым и частями. Первое — это семья, а второе — члены семьи. Хотя Agile и итерация — разные вещи, они неразделимы. Органическое сочетание этих двух факторов может не только обеспечить качество продукта, но и сохранить преимущества в процессе постоянного улучшения проекта. Впитайте суть и устраните шлаки. Только так проект станет идеальным.

Приращениеразвиватьплюситеративная разработка,Вот настоящая Гибкая разработка。

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

Гибкая разработка Преимущества

ранняя доставка

Гибкая Первое преимущество разработки – ранняя доставку, тем самым существенно сокращая затраты。

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

Гибкая идея — первое здание, сданное за шесть месяцев.,Каждые два месяца будет сдаваться одно здание. поэтому,Возврат 10% в течение полугода.,В будущем денежный поток будет поступать каждый месяц.,Финансовое давление значительно снижается.

Снизить риск

Второе преимущество Гибкой идеи –,Будьте в курсе потребностей рынка,Снизить риск непригодности продукта。

Пожалуйста, подумайте, какая ситуация приведет к меньшим потерям: после того, как все 10 зданий будут построены, и вы обнаружите, что их нельзя продать, или после того, как первое здание будет построено, только для того, чтобы обнаружить, что его нельзя продать, а затем улучшите или остановите строительство следующих 9 зданий ?

Для программных проектов,Сначала создайте прототип продукта,Понять признание рынка,Зачастую это ключ к успеху проекта. Есть книга "Код разрушения снов".,Подзаголовок: «20+ программистов».,три года,4732 ошибки,1 миллион+долларов США,История окончательного провала»,этотто есть Не принят Гибкая Результаты для разработки. Напротив, Инстаграм Изначально это была регистрация по географическому местоположению. App, но позже выяснилось, что пользователей не особо заботит географическое положение и они предпочитают загружать фотографии, поэтому они заменили его на программное обеспечение для загрузки фотографий и стали единорогами.

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

Гибкая разработкаценности

В «Манифесте гибкой разработки программного обеспечения» упоминаются четыре ценности.

1. Инициатива программиста и взаимодействие между программистами имеют приоритет над установленными процессами и инструментами.
2. Работающее программное обеспечение лучше тщательной документации.
3. Тесное сотрудничество с клиентами лучше, чем контракты и переговоры.
4. Уметь реагировать на изменения лучше, чем следовать плану.

Гибкая разработкадвенадцать принципов

В декларации также предлагалось двенадцать принципов Гибкой идеи.

1. повысить удовлетворенность клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
2. Приветствуйте изменение требований, даже на поздних стадиях разработки проекта. Умейте использовать изменения спроса, чтобы помочь клиентам получить конкурентные преимущества.
3. Постоянно поставляйте работающее программное обеспечение, обычно в течение нескольких недель, но чем короче, тем лучше.
4. В ходе проекта бизнес-персонал и разработчики должны работать вместе.
5. Программы должны строиться вокруг внутренне мотивированных людей, которым следует доверять.
6. Разговор лицом к лицу – лучший способ общения.
7. Доступность является основным показателем для измерения прогресса.
8. Содействовать устойчивому развитию и поддерживать стабильные темпы прогресса.
9. Постоянно спрашивайте, хороша ли технология и хороша ли технология.
10. Простота имеет решающее значение, постарайтесь максимально сократить ненужную работу.
11. Лучшие структуры, требования и идеи рождаются в результате спонтанного понимания внутри команды.
12. Команда регулярно размышляет о том, как стать более эффективной, и соответствующим образом корректирует ситуацию.

итеративная разработкаи Гибкая разработка Разница

Первая представляет собой модель цикла разработки программного обеспечения и процесс разработки, а вторая представляет собой разновидность разработки программного обеспечения; Коллекция методов управления проектами, которая является наиболее фундаментальным различием между ними.。иитеративная разработкапереписыватьсядамодель водопада、спиральная модель,Аналогом Гибкой идеи является Scrum.,XP (экстремальное программирование),Кристалл (кристальное программирование),Так что эти две вещи нельзя путать,Но определенная связь есть.

Гибкая идея требует предварительного планирования

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

За исключением компаний-разработчиков программного обеспечения,На многих традиционных предприятиях,Гибкая разработка превратилась в процесс разработки без ответственного лица. Так называемые менеджеры по продуктам, продажам и генеральные директора могут добавлять функции и изменять требования по своему желанию, а затем передавать их команде разработчиков для «гибкой» разработки. В процессе разработки исследование требований, дизайн, обратная связь, обзоры кода и тестирование не нужны. Это смесь технологий, какой бы шаг ни был достигнут, он считается одним шагом, и Гибкая его полностью игнорирует. Суть идеи.

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

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

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

Разработка программного обеспечения, ориентированная на повторное использование

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

Основные этапы:

1. компонентный анализ：Дайте требованияописывать,Затем найдите компоненты, соответствующие вашим потребностям. Обычно ситуация такая,Отсутствие нужного компонента на выбор,Доступные компоненты часто обеспечивают лишь часть необходимой функциональности.
2. Изменение требований:существоватьэтот个этап,Анализ требований на основе полученной информации о компонентах,Затем требования изменяются с учетом доступных компонентов. Когда требования не могут быть изменены,Вам необходимо повторно ввести компонентный анализировать деятельность для поиска других возможных альтернатив.
3. Проектирование системы с использованием повторного использования：существоватьэтот个этап,спроектируйте структуру системы или повторно используйте существующую структуру. дизайн проанализировать те компоненты, которые будут использоваться повторно,и организовать структуру так, чтобы она соответствовала этим компонентам. Когда некоторые многоразовые компоненты недоступны,Необходимо переустановить новое программное обеспечение.
4. развитие и интеграция：Когда компоненты невозможно купить, нужно сделать их самостоятельно.развивать,Затем интегрируйте эти компоненты собственной разработки и готовые компоненты.,Сделайте это целым. В этой модели,Системная интеграция – это не столько самостоятельная деятельность,Скорее, оно сталоразвиватьчасть процесса。

В процессах, ориентированных на повторное использование, могут использоваться три типа программных компонентов:

• Веб-сервисы, разработанные на основе стандартных сервисов, которые можно использовать для удаленных вызовов.
• Коллекция объектов, интегрированных в виде пакета и структуры компонентов, таких как .NET или J2EE.
• Независимая программная система, настроенная для использования в конкретной среде.

Преимущества:

• Уменьшает объем программного обеспечения, которое необходимо разработать, тем самым снижая затраты на разработку программного обеспечения и снижая риски при разработке.
• Обеспечивает быструю доставку программного обеспечения

Более классические модели процессов разработки программного обеспечения включают:

• модель водопада：Эта модель объединяет основные действия процесса.、описывать、развивать、Проверка и эволюция эффективности,рассматриваться как отдельные, независимые этапы процесса,Например,нуждатьсяописыватьэтап、Этап проектирования программного обеспечения、выполнитьэтап、этап тестирования и так далее.
• постепенное развитие：Этот метод делаетописывать Активность、развивать Активностьи有效性验证Активностьпереплетенысуществовать Вместе。системаизразвиватьда建立一系列из版本（Приращение）,Каждая версия добавляет некоторые функциональные возможности к предыдущей версии.
• Разработка программного обеспечения, ориентированная на повторное использование：Методда На основе существующихсуществоватьиз大量可复用из组件。системаразвивать过程着重于集成этот些组件到新системасередина,а не с нуляразвивать。

Эти три модели не являются взаимоисключающими.,и часто используются вместе,Особенно для разработки больших систем. для больших систем,Комплексная модель водопадаи Приращениеразвивать模型из优点да有意义из。

Справочная статья:

Получите модель процесса разработки программного обеспечения в одной статье——модель водопада、постепенное развитие/Разница между поэтапной разработкой и итеративной разработкой https://blog.csdn.net/weixin_55267022/article/details/118121466

Понимание моделей разработки (водопадная, итеративная, гибкая) https://zhuanlan.zhihu.com/p/452759262

Краткое обсуждение Гибкая разработкаконцепции иитеративная разработкаплан  https://www.minjiekaifa.com/agilearticles/agile-development-and-iterative-development-solutions-80369.html

Гибкая вводное руководство по разработке https://www.ruanyifeng.com/blog/2019/03/agile-development.html

Краткое обсуждение Гибкая разработкаконцепции иитеративная разработкаплан https://www.minjiekaifa.com/agilearticles/agile-development-and-iterative-development-solutions-80369.html

ПерепечаткаЭтот сайтстатья《Понимание моделей разработки: каскадная модель/инкрементная/итеративная/гибкая разработка – примечания.》, Пожалуйста, укажите источник：https://www.zhoulujun.cn/html/webfront/engineer/Architecture/8935.html