Каскадная и спиральная модель жизненного цикла программного сред. Реферат каскадная и спиральная модель жизненного цикла программного средства
 Скачать 27.98 Kb.
|
|
Федеральное государственное бюджетное образовательное учреждение высшего образования «ОМСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» Кафедра Кафедра "Автоматизированные системы обработки информации и управления" РЕФЕРАТ «КАСКАДНАЯ И СПИРАЛЬНАЯ МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО СРЕДСТВА» Выполнил: Ратько Илья Александрович гр. ЗПИ-201 Проверил: профессор к.т.н Никонов Александр Васильевич Омск - 2021 Содержание: Понятие и основные назначения ЖЦ Виды ЖЦ: Каскадная модель; Итерационная модель; Спиральная модель; V-образная модель; Инкрементная модель; Модель быстрого прототипирования; Список Литературы. В стандарте ISO/IEC 12207 Модель жизненного цикла - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Наибольшее распространение получили две основные модели ЖЦ: · каскадная модель (70-85 гг.); · спиральная модель (86-90 гг.); Так же существуют и другие модели, которые мы так же затронем. Основные назначения моделей жизненного цикла: 1) Планирование и распределение работ между разработчиками и ресурсов, а также управление программным проектом; 2) Обеспечение взаимодействия между разработчиками проекта и заказчиком; 3) Наблюдение и контроль работ, оценивание промежуточных продуктов ЖЦ на соблюдение спецификаций требований, правильное их выполнение, оценивание продукта и реальных затрат, в том числе и по применяемым программным средствам и инструментам; 4) Согласование промежуточных результатов с заказчиком; 5) Проверка правильности конечного продукта путем его тестирования на запланированных и согласованных с заказчиком наборах тестов; 6) Оценивание соответствия характеристик качества полученного продукта заданным требованиям; 7) Обсуждение используемых процессов ЖЦ в плане оценки их возможностей и недостатков, проявившихся при их применении, а также определение направлений усовершенствования или модернизации ЖЦ и др. Виды жизненных циклов: Каскадный способ - разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Положительные стороны применения каскадного подхода: · на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; · выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако реально в процессе создания ПО постоянно возникает потребность в возврате к предыдущим этапам, уточнении или пересмотре ранее принятых решений, что и является главным недостатком каскадной модели ЖЦ. Итерационная модель ЖЦ Модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Подход имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже» Спиральная модель ЖЦ Исходя из возможности внесения изменений, как в процесс, так и в создаваемый промежуточный продукт была создана спиральная модель. Внесение изменений ориентировано на удовлетворение потребности пользователей сразу, как только будет установлено, что созданные артефакты или элементы документации (описание требований проекта, комментарии различного вида и т.п.), не соответствуют действительному состоянию разработки. Данная модель ЖЦ допускает анализ продукта на витке разработки, его проверку, оценку правильности и принятия решения двигаться на следующий виток или опуститься на предыдущий виток для доработки на нем промежуточного продукта. Отличие этой модели от каскадной модели состоит в возможности обеспечивать многоразовое возвращение к процессу формулирования требований и к повторной разработке с любого процесса выполнения работ. На изображенной модели, каждый виток спирали соответствует одной из версий разработки системы. При необходимости внесения изменений в систему на каждом витке с целью получения новой версии системы обязательно вносятся изменения в предварительно зафиксированные требования, после чего происходит возврат на предыдущий виток спирали для продолжения реализации новой версии системы с учетом изменений. Однако применение таких методов наряду с быстрым эффектом дает снижение управляемости проектом в целом и стыкуемости различных фрагментов информационной системы. Основная проблема спирального цикла - определение момента перехода на следующий этап. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. V-образная модель ЖЦ Эта модель была разработана как разновидность каскадной модели, в которой особое внимание уделяется верификации и аттестации программного продукта. Модель показывает, что тестирование продукта обсуждается, проектируется и планируется, начиная с ранних этапов жизненного цикла разработки. От каскадной модели v-образная модель унаследовала последовательную структуру, в соответствии с которой каждая последующая фаза начинается только после успешного завершения предыдущей фазы. Данная модель основана на систематическом подходе к проблеме, для решения которой определены четыре базовых шага: анализ, проектирование, разработка и обзор. При выполнении анализа осуществляются планирование проекта и составление требований. Проектирование разделяется на высокоуровневое и детальное (низкоуровневое). Разработка включает в себя кодирование, обзор – различные виды тестирования. На модели хорошо просматриваются взаимосвязи между аналитическими фазами и фазами проектирования, которые предшествуют кодированию и тестированию. Горизонтальные стрелки показывают, что эти фазы надо рассматривать параллельно. Модель включает в себя следующие фазы: Составление требований к проекту и планирование – определяются системные требования и выполняется планирование работ; Составление требований к продукту и их анализ – составляется полная спецификация требований к программному продукту; Высокоуровневое проектирование – определяется структура программного обеспечения, взаимосвязи между основными его компонентами и реализуемые ими функции; Детальное проектирование – определяется алгоритм работы каждого компонента; Кодирование – выполняется преобразование алгоритмов в готовое программное обеспечение; Модульное тестирование – выполняется проверка каждого компонента или модуля программного продукта; Интеграционное тестирование – осуществляются интеграция программного продукта и его тестирование; Системное тестирование – выполняется проверка функционирования программного продукта после помещения его в аппаратную среду в соответствии со спецификацией требований; Эксплуатация и сопровождение – запуск программного продукта в производство. На этой фазе в программный продукт могут вноситься поправки и может выполняться его модернизация. Инкрементная модель ЖЦ Первая создаваемая промежуточная версия системы (выпуск 1) реализует часть требований, в последующую версию (выпуск 2) добавляют дополнительные требования и так до тех пор, пока не будут окончательно выполнены все требования и решены задачи разработки системы. Для каждой промежуточной версии на этапах ЖЦ выполняются необходимые процессы, работы и задачи, в том числе, анализ требований и создание новой архитектуры, которые могут быть выполнены одновременно. Процессы разработки технического проекта ПС, его программирование и тестирование, сборка и квалификационные испытания ПС выполняются при создании каждой последующей версии. В соответствии с данной моделью ЖЦ, процессы которой практически такие же, что и в каскадной модели, ориентир делается на разработку некоторой законченной промежуточной версии, а задачи процесса разработки выполняются последовательно или частично параллельно для ряда отдельных промежуточных структур версии. Работы и задачи процесса разработки следующей версии системы с дополнительными требованиями или функциями могут выполняться неоднократно в той же последовательности для всех промежуточных версий системы. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки версии путем проверки частично реализованных требований в каждой промежуточной версии и так до получения законченного варианта системы. Вспомогательные и организационные процессы ЖЦ обычно выполняются параллельно с процессом разработки версии системы и к концу разработки будут собраны данные, на основании которых может быть установлен уровень завершенности и качества изготовленной системы. При применении данной модели необходимо учитывать следующие факторы риска: требования составлены с учетом возможности их изменения при реализации продукта; все возможности системы требуется реализовать с начала; быстрое изменение технологии и требований к системе может привести к нарушению полученной структуры системы; ограничения в ресурсном обеспечении (исполнители, финансы) могут привести к затягиванию сроков сдачи системы в эксплуатацию. Данную модель ЖЦ целесообразно использовать, в случаях когда: Желательно реализовать некоторые возможности системы быстро за счет создания промежуточной версии продукта; Система декомпозируется на отдельные составные части, которые можно реализовывать как некоторые самостоятельные промежуточные или готовые продукты; Возможно увеличение финансирования на разработку отдельных частей системы. Модель быстрого прототипирования Модель прототипитования позволяет создать прототип программного продукта до или в течение этапа составления требований к программному продукту. Потенциальные пользователи работают с этим прототипом, определяя его сильные и слабые стороны, о результатах сообщают разработчикам программного продукта. Таким образом, обеспечивается обратная связь между пользователями и разработчиками, которая используется для изменения или корректировки спецификации требований к программному продукту. В результате такой работы продукт будет отражать реальные потребности пользователей. Жизненный цикл разработки программного продукта начинается с разработки плана проекта, затем выполняется быстрый анализ, после чего создаются база данных, пользовательский интерфейс и выполняется разработка необходимых функций. В результате этой работы получается документ, содержащий частичную спецификацию требований к программному продукту. Данный документ в дальнейшем является основой для итерационного цикла быстрого прототипирования. В результате прототипирования разработчик демонстрирует пользователям готовый прототип, а пользователи оценивают его функционирование. После этого определяются проблемы, над устранением которых совместно работают пользователи и разработчики. Этот процесс продолжается до тех пор, пока пользователи не будут удовлетворены степенью соответствия программного продукта, поставленным перед ним требованиям. Затем прототип демонстрируют пользователям с целью получения предложений по его усовершенствованию, которые включаются в последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной. После этого получают от пользователей официальное одобрение (утверждение) функциональных возможностей прототипа и выполняют его окончательное преобразование в готовый программный продукт. Модель протипирования обладает целым рядом преимуществ: 1) Взаимодействие заказчика с разрабатываемой системой начинается на раннем этапе; 2) Благодаря реакции заказчика на прототип сводится к минимуму число неточностей в требованиях; 3) Снижается вероятность возникновения путаницы, искажения информации или недоразумений при определении требований к программному прдукту, что приводит к созданию более качественного программного продукта; 4) В процессе разработки всегда можно учесть новые, даже неожиданные требования заказчика; 5) Прототип представляет собой формальную спецификацию, воплощенную в программный продукт; 6) Прототип позволяет очень гибко выполнять проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла разработки; 7) Заказчик всегда видит прогресс в процессе разработки программного продукта; 8) Возможность возникновения противоречий между разработчиками и заказчиками сведена к минимуму; 9) Уменьшается число доработок, что снижает стоимость разработки: возникающие проблемы решаются на ранних стадиях, что резко сокращает расходы на их устранение; заказчики принимают участие в процессе разработки на протяжении всего жизненного цикла и в конечном итоге в большей степени довольны результатом работы. Кроме указанных достоинств модели прототипирования присущ и целый ряд недостатков: 1) Решение сложных задач может отодвигаться на будущее; 2) Заказчик может предпочесть получить прототип, а не законченную полную версию программного продукта; 3) Прототипирование может неоправданно затянуться; 4) Перед началом работы неизвестно, сколько итераций придется выполнить. Модель прототипирования рекомендуется применять в следующих случаях: 1) Требования к программному продукту заранее неизвестны; 2) Требования не постоянны или неудачно сформулированы; 3) Требования необходимо уточнить; 4) Нужна проверка концепции; 5) Существует потребность в пользовательском интерфейсе; 6) Выполняется новая, не имеющая аналогов разработка; 7) Разработчики не уверены в том, какое решение следует выбрать. Список использованной литературы: С.Н. Карпенко «Введение в программную инженерию» Гагарина Л.Г. «Основы технологии и разработки программных продуктов» Соммервилл И. « Инженерия программного обеспечения.» |