На каком этапе каскадной модели происходит сдача готового продукта

Жизненный цикл ПО. Каскадная модель (Waterfall)

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

Как правило, мы отдаем предпочтение спиральной модели, которая включает в себя гибкие методологии разработки 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 с большим опытом в области интернет-маркетинга. Увлекается юзабилити и стремится создавать полезный контент, отвечающий интересам ИТ-аудитории.

Источник

Каскадная модель разработки ПО ???? «Waterfall» — этапы и особенности «Водопадной» модели

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

Что такое каскадная модель

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

Краткая история «водопадной» модели Waterfall

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

Примеры применения каскадной модели

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

Модель «Waterfall»

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

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

Получите доступ к нашему Google-диску

Что такое каскадная модель

В 1970 году Уинстон Ройс выпустил статью с концепцией новой модели разработки. Она стала известна под названием каскадной или водопадной модели. В ней процесс разработки представлен как поток, состоящий из нескольких фаз:

• Анализ проекта
• Анализ требований
• Проектирование продукта
• Разработка продукта
• Тестирование
• Поддержка

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

Краткая история «водопадной» модели Waterfall

Часто считается, что в каскадной модели перейти на предыдущий этап невозможно. Однако это не так. В оригинальной работе «MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS», включены циклы обратной связи. Обязательно откройте и просмотрите оригинальный документ, до последней страницы ????

Если вы знакомы с Agile или Scrum то увидите что практически те же принципы включены в модель: циклы обратной связи и бережливая разработка прототипов.

Причина по которой модель не прижилась: циклы подразумевались от 2-3 месяцев на один этап. В Agile — полный цикл разработки команда проходит за 1-2 недели.

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

Содержание каскадной модели

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

Анализ требованийНа этом этапе разработчики создают документацию со всеми требованиями заказчика. Полная документация важна, потому что:

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

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

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

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

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

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

ТестированиеПосле завершения разработки продукт проходит тщательное тестирование, состоящие из трёх последовательных частей:

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

ПоддержкаПосле релиза продукта наступает этап поддержки. Здесь команда разработчиков:

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

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

Водопадная модель разработки обладает преимуществами перед другими моделями. Вот часть её достоинств:

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

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

Разработчики критикуют каскадную модель. У неё есть недостатки:

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

Примеры применения каскадной модели

Водопадную модель лучше применять в следующих случаях:

• Когда известны четкие, неизменяемые требования с понятными путями решения.
• Если разработчиками ранее создавалась система подобного типа. Если программисты уже делали систему автоматического начисления зарплаты, создать подобный продукт будет легче.
• При переносе проекта на другую платформу. Если возникла потребность сделать версию ПО для MAC OS или LINUX, водопадная модель подойдет.
• При реализации больших проектов, в которых задействовано несколько команд разработчиков.
• Для реализации относительно небольших проектов.
• Проект длится от нескольких недель до 2-3 месяцев. Требования к проекту не успевают устареть.

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

Заключение

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

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

Источник