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

Модели жизненного цикла ИС

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

Каскадная модель. Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований

2. Проектирование

3. Реализация

4. Тестирование

5. Ввод в действие

6. Эксплуатация и сопровождение

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

Каскадная модель (waterfall model) жизненного цикла (рис.9) считается основой технологических подходов к ведению жизненного цикла. Эта модель была предложена в 1970 году У. Ройсом. Впоследствии данная модель была регламентирована множеством нормативных документов, в частности, широко известным стандартом Министерства обороны США Dod-STD-2167A и российскими стандартами серии ГОСТ 34. Принципиальными свойствами так называемой «чистой» каскадной модели являются следующее:

· фиксация требований к системе до ее сдачи заказчику;

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

Рис.9. Каскадная модель жизненного цикла.

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

Преимущества применения каскадной модели заключаются в следующем:

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

· выполняемые в логичной последовательности стадии работ

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

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

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

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

Рис.10. Модель реального процесса разработки системы.

Основными недостатками каскадного подхода являются:

· позднее обнаружение проблем;

· выход из календарного графика, запаздывание с получением результатов;

· избыточное количество документации;

· невозможность разбить систему на части (весь продукт разрабатывается за один раз);

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

Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами:

· пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;

· за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

Источник

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 28 марта 2021; проверки требуют 13 правок.

Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад») – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.

Содержание модели[править | править код]

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

В исходной каскадной модели следующие фазы шли в таком порядке:

Определение требований
Проектирование
Конструирование (также «реализация» либо «кодирование»)
Воплощение
Тестирование и отладка (также «верификация»)
Инсталляция
Поддержка

Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей

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

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

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

Критика каскадной модели и гибридные методологические решения[править | править код]

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

Начиная с PMBOK 4-й версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом управления проектами (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

См. также[править | править код]

Гибкая методология разработки
Итеративная разработка
Спиральная модель

Примечания[править | править код]

Ссылки[править | править код]

Royce, Winston (1970), Managing the Development of Large Software Systems (англ.)

Источник

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

жизненный цикл ПО каскадная модель

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

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

Давайте поочередно рассмотрим все этапы жизненного цикла:

1. Анализ требований

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

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

Видение проекта

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

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

Сбор требований

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

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

2. Проектирование программного обеспечения

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

Масштабы и границы проекта

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

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

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

https://invisionapp.com/

https://webflow.com/

https://moqups.com/

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

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

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

Спецификация требований программного обеспечения

Спецификация требований программного обеспечения (SRS) описывает требования, которым должно отвечать создаваемое программное обеспечение. Она должна быть логичной, последовательной, доступной и полной. Требования могут выражаться в разных формах, например, в виде традиционных утверждений долженствования (н-р, “Система Staff Manager должна поддерживать следующие браузеры: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+”) или в виде пользовательских историй (н-р, “поскольку я являюсь менеджером, мне необходим доступ к персональной информации всех сотрудников”).

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

Для создания прототипа вам необходимо выяснить следующее:

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

Мокапы (или прототипы) передаются UI/UX-дизайнерам, которые превращают их в красочные шаблоны.

3. Разработка программного обеспечения

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

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

4. Тестирование программного обеспечения

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

5. Техническая поддержка программного обеспечения

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

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

Заключение

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

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

Данная статья была подготовлена под руководством опытных бизнес-аналитиков компании XB Software.

The following two tabs change content below.

Об авторе
Последние статьи

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

Источник