Обзор жизненного цикла разработки программного обеспечения (SDLC)

Основные модели разработки включают водопадную модель, инкрементную модель, спиральную модель, фонтанную модель, интеллектуальную модель, V-модель, модель RAD, модель CBSD, метод прототипа, метод XP, метод RUP и т. д.

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

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

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

Модель трансформации

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

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

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

Модель фонтана

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

V модель

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

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

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

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

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

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

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

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

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

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

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

Бизнес-моделирование: какая информация управляет работой бизнес-процесса? Какая информация должна быть сформирована? Кто его сгенерировал? Куда идет информационный поток? Кто справится с этим? Могут быть дополнены диаграммами потоков данных.

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

Моделирование процессов: позволяет объектам данных выполнять различные бизнес-функции в информационном потоке. Процесс создания описывает добавление, изменение, удаление и поиск объектов данных, то есть уточнение блока обработки на диаграмме потока данных.

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

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

Компонентная модель

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

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

Метод прототипа

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

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

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

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

XP-метод

XP — это легкий (гибкий), эффективный, безопасный, гибкий, предсказуемый, научный и увлекательный метод разработки программного обеспечения. По сравнению с другими методологиями самое большое отличие заключается в следующем:

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

Метод единого процесса (УП)

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

По сравнению с другими программными процессами UP имеет три примечательных характеристики: ориентированность на прецеденты, сосредоточенность на базовой архитектуре, итерации и приращения. Программный процесс в Rational Unified Process разбит на четыре последовательных этапа во времени, а именно начальный этап, этап уточнения, этап построения и этап поставки. В конце каждого этапа должен быть организован технический обзор, чтобы определить, были ли достигнуты цели этого этапа. Если результаты рассмотрения удовлетворительны, проект может быть допущен к переходу на следующий этап.

Узнать больше

• Что такое модель программного процесса?
• Адаптивное и прогнозное планирование: когда Agile? Когда Водопад?
• Что такое жизненный цикл разработки программного обеспечения?
• Руководства по обучению скраму
• Руководства по обучению управлению проектами
• Что такое УМЛ?
• Что такое гибкая разработка программного обеспечения?
• История пользователя и вариант использования для гибкой разработки программного обеспечения