Waterfall текст. Традиционная (каскадная, водопадная) модель 2 слайд
 Скачать 23.97 Kb.
|
|
Традиционная (каскадная, водопадная) модель 2 слайд Источником данной модели принято считать статью Уинстона Уокера Ройса, вышедшею в 1970 году. Сам Уинстон Ройс не называл этот подход “каскадным”, но сама логика повествования и иллюстрации очень напоминали “каскад” водопадов, поэтому модель больше известна как “waterfall model” или “каскадная модель”. Описанный подход был очень похож на конвейер, используемый в материальном производстве сложных устройств (автомобилей и др). Работа двигалась по стадиям, как по ленте конвеера, и в результате появлялся готовый продукт. Однако, сам Ройс описывал эту модель как пример, противопоставленный итеративной модели, применимый только для очень простых проектов и сам пользовался итеративными методологиями. На начальном периоде она сыграла ведущую роль как метод регулярной разработки сложного ПО. В 70x — 80x годах XX века модель была принята как стандарт министерства обороны США. 3 слайд По мере развития методологий каскадная модель подвергалась жесткой критики со стороны всех исследователей, предлагавших свои методологии. Однако для проектов, затрагивающих безопасность жизнедеятельности строго поставленные требования и высокая степень формализации является основополагающим и необходимым фактором. Кроме того, несмотря, на модную сейчас критику традиционной модели, она играет важную роль, потому что налагает на процесс разработки требование крайне необходимой для него дисциплинированности, с помощью которой удается благополучно обходить неструктурированные процессы. Данная модель внесла фундаментальный вклад в понимание процессов разработки ПО следующими утверждениями: процесс должен подчиняться дисциплине, разумному планированию и управлению; реализация продукта должна быть отложена до полного понимания целей этой реализации 4 слайд В исходной “каскадной модели” стадии шли в таком порядке: Системные требования Требования к программному обеспечению Анализ Разработка программы Кодирование Тестирование Поддержка В процессе разработки все стадии проходятся строго последовательно, один за другим. Тем самым “каскадная модель” подразумевает, что переход от одной стадии разработки к другой происходит только после полного и успешного завершения предыдущей стадии, и что переходов назад либо вперед или перекрытия стадий не происходит. Для своего времени это был гигантский прорыв. Впервые появилась модель, которая описывала конкретные этапы реализации программного обеспечения и переходы между ними. Это давало понятный алгоритм работы, который расставлял зоны ответственности, позволял планировать и бюджетировать отдельные этапы, снижал многие риски и делал проект более прозрачным. В более сложных случаях Уинстон Ройс предлагал действовать итеративно, разбивая выпуск ПО на два этапа. На первом этапе делалась самая простая реализация, которая доводилась до стадии внутреннего тестирования, а затем, на основе выявленных ограничений, вскрывшихся рисков и неучтенных граничных условий, делалось повторное уточнение исходных требований, новая стадия проектирования и все последующие этапы. И только результаты второй итерации поставлялись заказчику для использования. 5 слайд Основными принципами каскадной модели являются: Строго последовательное выполнение фаз. Каждая последующая фаза начинается лишь тогда, когда полностью завершено выполнение предыдущей фазы. Каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные. Каждая фаза полностью документируется Переход от одной фазы к другой осуществляется посредством формального обзора с участием заказчика Основа модели – сформулированные требования (техническое задание), которые меняться не должны Критерий качества результата – соответствие продукта установленным требованиям. 6 слайд Каскадная модель достаточно гибкая, и некоторые этапы могут частично совпадать. Рассмотрим все этапы современной каскадной модели. Анализ требований. На этом этапе важно задокументировать все требования к будущему программному обеспечению. Необходимо посвятить достаточно времени обсуждению деталей проекта со всеми заинтересованными сторонами. Все поступающие данные нужно проанализировать и систематизировать. Важно также учесть все технические ограничения, которые могут возникнуть на стороне заказчика. Итогом данного этапа должно стать создание подробной спецификации, отвечающей всем требованиям заказчика. Также следует обратить внимание и на другие факторы, которые могут затруднять процесс разработки. К ним относятся дедлайны, установленные заказчиком, а также бюджетные ограничения. Важной задачей является создание подробного документа видения (или образа) проекта, который включает краткое описание проекта, бизнес-цели, а также критерии успеха проекта, факторы бизнес-рисков и описание конечного пользователя продукта. Готовый документ необходимо передать на утверждение заказчику, чтобы убедиться в том, что все поставленные требования были учтены, а также чтобы проинформировать его о любых рисках, которые могут возникнуть после релиза проекта. После того, как все основные вопросы решены, рекомендуется провести дополнительные обсуждения и интерактивные семинары со всеми заинтересованными сторонами. Это поможет выявить какие-либо неочевидные моменты, которые в дальнейшем могут стать причиной внесения изменений в интерфейс приложения или необходимости переписывания паттернов кода. Данный этап может также включать заполнение анкет, рассмотрение кейсов, мозговой штурм и т. д. Многие проекты заходят в тупик из-за дополнительных требований, которые всплывают на стадии разработки. Поэтому очень важно понимать начальные бизнес-цели и главную идею будущего приложения. 7 слайд Проектирование программного обеспечения. Следующим этапом жизненного цикла ПО является создание документа, описывающего масштабы и границы проекта. Данный документ включает в себя скетчи интерфейса будущего приложения, а также подробную спецификацию требований программного обеспечения. Масштабы и границы проекта. В документе, описывающем масштабы и границы проекта, должны быть перечислены основные функции создаваемого программного обеспечения. Они определяются на основании документа видения проекта, и безусловно, с учетом указанных временных рамок и установленного бюджета. На этом этапе также поднимается вопрос о послепродажном обслуживании продукта. Вы должны уведомить заказчика о том, каким образом будет осуществляться техническая поддержка после завершения этапа тестирования и последующего релиза продукта. Спецификация требований программного обеспечения. Спецификация требований программного обеспечения (SRS) описывает требования, которым должно отвечать создаваемое программное обеспечение. Она должна быть логичной, последовательной, доступной и полной. Требования могут выражаться в разных формах, например, в виде традиционных утверждений долженствования или в виде пользовательских историй. 8 слайд Разработка программного обеспечения. Необходимо отметить, что разработка программного обеспечения может также включать в себя создание интерактивного прототипа, который, в сущности, является основой будущего приложения. Такой прототип помогает определить архитектуру системы в целом. На данном этапе пишется мало кода: например, код кнопок и простых форм, чтобы дать заказчику общее представление о том, как будет работать конечный продукт. Поэтому мы включили создание прототипа в этап разработки программного обеспечения. Как только интерактивный прототип и дизайн приложения готов и утвержден заказчиком, начинается разработка стандартов приложения. После этого можно смело переходить к следующему этапу жизненного цикла, а именно, к разработке программного обеспечения. Разработка ПО может быть разделена на небольшие части, или юниты, и каждый юнит разрабатывается и тестируется разработчиками для проверки его функциональности. Тестирование программного обеспечения. После завершения этапа разработки продукт должен пройти тщательное тестирование, чтобы убедиться в том, что он соответствует поставленным требованиям. На этапе приемочного тестирования необходимо, чтобы заказчик попытался применить продукт локально точно таким же образом, как он собирается использовать его после релиза. Когда будут исправлены основные ошибки, программное обеспечение можно внедрять. Для исправления незначительных ошибок может использоваться простая система отслеживания, что позволит исправлять любые недоработки уже на этапе сопровождения ПО. 9 слайд Техническая поддержка программного обеспечения. После того, как продукт был протестирован и развернут на сервере заказчика, начинается следующая фаза жизненного цикла разработки программного обеспечения, которая называется сопровождением или технической поддержкой ПО. В целом, сопровождение подразумевает под собой исправление незначительных ошибок, которые обнаруживаются на этом этапе. Тем не менее, вполне возможно, что вам придется вносить некоторые изменения в созданное программное обеспечение, несмотря на все усилия, приложенные вами на предыдущих этапах. Заказчик может решить внести изменения в функциональность разработанного продукта. Следовательно, вам придется собирать, описывать и обсуждать новые требования с заказчиком, чтобы внести в продукт необходимые изменения. В данном случае вам предстоит работа с новым каскадным проектом, и все вышеописанные шаги придется повторять с начала. 10 слайд На данные момент существуют различные инструменты, используемые при разработке проектов по методологии Waterfall: Monday.com, Wrike, Smartsheet, Atlassian Jira, Pivotal Tracker и другие. 11 слайд Примеры успешных проектов, реализованных с помощью данной методологии. В отдельных отраслях и видах проектов “каскадная модель” и сейчас показывает себя хорошо. Как правило, это происходит в случаях, когда стоимость ошибки столь высока, что лучше делать “долго и дорого”, чем допустить вероятность переделки. Например, NASA делает космические аппараты по процессу, который очень похож на “каскадный”. С помощью каскадной модели создается множество проектов «с нуля». Проекты, которые также реализованы с помощью каскадной модели: рентгеновский микротомограф, автообновление службы Windows на AWS. Ученые Томского госуниверситета создали микротомограф, который может получать данные о внутренней структуре различных материалов, например, алмазов, с точностью до одного микрона. Томограф может сканировать вещество с разрешением до одного микрона. То есть в сто раз тоньше ширины человеческого волоса. После завершения сканирования программа создает 3D-модель, которая показывает не только внешний вид объекта, но и его внутреннюю структуру. 12 слайд Автообновление службы Windows на AWS. В качестве сервиса для хранения пакетов обновления был выбран сервис Amazon Web Services (AWS). Основные причины его выбора были такие: AWS предоставляет год бесплатного доступа с небольшими ограничениями; AWS предоставляет API для работы с облачным хранилищем, для работы с которым разработана библиотека, доступная через NuGet (AWSSDK.S3). Во время установки программного обеспечения инсталлятор регистрирует в планировщике Windows запуск программы автообновления по расписанию. Запуск программы автообновления планировщиком. Проверка наличия нового пакета установки на сервисе AWS Получение нового пакета установки. Остановка службы. Запуск нового пакета в «тихом» режиме, и завершение процесса программы обновления. Новый пакет установки производит следующие действия. Удаление предыдущей версии программного обеспечения из системы (uninstall). Установка новой версии программного обеспечения (install). Вместе с новой версией программного обеспечения обновляется и программа обновления. Запуск обновленной службы. Представленный механизм автообновления возможно не единственный, но хорошо зарекомендовал себя в течение нескольких месяцев безупречной работы. При этом затраты на его создание оказались минимальными. |