Меню

Какие модели жизненного цикла программного средства существуют



Популярные жизненные циклы разработки ПО

Жизненный цикл программного обеспечения (ПО) – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

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

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

Каскадная или водопадная модель (Waterfall model)

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

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

V-образная модель (V-model)

Данная модель стала последователем каскадной модели, так как с ее помощью можно устранить недостатки, которые были ранее.

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

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

Инкрементная модель (Incremental model)

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

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

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

Спиральная модель (Spiral model)

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

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

Гибкая модель (Agile model)

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

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

Скрам (Scrum)

Скрам – это гибкая модель разработки ПО, в которой делается акцент на качественном контроле процесса разработки.

Роли в методологии (Scrum Master, Product Owner, Team) позволяют четко распределить обязанности в процессе разработки. За успех Scrum в проекте отвечает Scrum Master и является связующим звеном между менеджментом и командой. За разработку продукта отвечает Product Owner, который также ставит задачи и принимает окончательные решения для команды.

Читайте также:  Если ребенок глотнул моющего средства

Команда – это единое целое, в ней результаты оцениваются не по каждому отдельному участнику, а по тому, что получается в итоге у всех.
Спринты в данной методологии длятся от 1 до 4 недель. После каждого спринта команда предоставляет вариант законченного продукта.

  • быстрая обратная связь от специалистов в разных сферах (дизайнеров, архитекторов, тестировщиков и пр.);
  • благодаря вовлеченности тестировщика в работу происходит быстрое добавление нового функционала и быстрый запуск продукта с минимальными функциями;
  • самостоятельная и самоорганизованная команда.
  • некоторые люди, знающие продукт, становятся незаменимыми, так как документация не предоставляется в процессе разработки;
  • невозможно спланировать точную дату завершения, так как всё уточняется по результатам предыдущего спринта;
  • заказчики не всегда могут понять суть данной методологии и необходимо потратить время на “ликбез”.

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

Источник

QA evolution

Жизненный цикл программного обеспечения

Следует начать с определения, Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

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

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

Каскадная модель

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

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

Жизненный цикл традиционно разделяют на следующие основные этапы :

  1. Анализ требований,
  2. Проектирование,
  3. Кодирование (программирование),
  4. Тестирование и отладка,
  5. Эксплуатация и сопровождение.

Каскадная модель Жизненного цикла

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

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

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

Реализовать Каскадную модель жизненного цикла затруднительно ввиду сложности разработки ПС без возвратов к предыдущим шагам и изменения их результатов для устранения возникающих проблем.

Область применения Каскадной модели

Ограничение области применения каскадной модели определяется её недостатками. Её использование наиболее эффективно в следующих случаях:

  1. при разработке проектов с четкими, неизменяемыми в течение жизненного цикла требованиями, понятными реализацией и техническими методиками;
  2. при разработке проекта, ориентированного на построение системы или продукта такого же типа, как уже разрабатывались разработчиками ранее;
  3. при разработке проекта, связанного с созданием и выпуском новой версии уже существующего продукта или системы;
  4. при разработке проекта, связанного с переносом уже существующего продукта или системы на новую платформу;
  5. при выполнении больших проектов, в которых задействовано несколько больших команд разработчиков.
Читайте также:  Логопедия как средство специального обучения детей с нарушением речи

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

(поэтапная модель с промежуточным контролем)

Инкрементная модель ( англ . increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.

Поэтапная модель с промежуточным контролем

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

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

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

  • отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;
  • отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;
  • требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у её пользователей неприятие и только “затормозить” процесс перехода на новые технологии. Образно говоря, они могут просто “не переварить большой кусок, поэтому его надо измельчить и давать по частям”.

Достоинства и недостатки этой модели (стратегии) такие же, как и у каскадной (классической модели жизненного цикла). Но в отличие от классической стратегии заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора.

  • затраты, которые получаются в связи с изменением требований пользователей, уменьшаются, повторный анализ и совокупность документации значительно сокращаются по сравнению с каскадной моделью;
  • легче получить отзывы от клиента о проделанной работе — клиенты могут озвучить свои комментарии в отношении готовых частей и могут видеть, что уже сделано. Т.к. первые части системы являются прототипом системы в целом.
  • у клиента есть возможность быстро получить и освоить программное обеспечение — клиенты могут получить реальные преимущества от системы раньше, чем это было бы возможно с каскадной моделью.
  • менеджеры должны постоянно измерять прогресс процесса. в случае быстрой разработки не стоит создавать документы для каждого минимального изменения версии;
  • структура системы имеет тенденцию к ухудшению при добавлении новых компонентов — постоянные изменения нарушают структуру системы. Чтобы избежать этого требуется дополнительное время и деньги на рефакторинг. Плохая структура делает программное обеспечение сложным и дорогостоящим для последующих изменений. А прерванный Жизненный цикл ПО приводит еще к большим потерям.

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

Читайте также:  Средства для чистки золотых украшений с камнями в домашних

Спиральная модель

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

Спиральная модель жизненного цикла

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

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

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

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

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

Область применения спиральной модели

Применение спиральной модели целесообразно в следующих случаях:

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

Источник

Adblock
detector