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

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

Министерство образования РФ

Воронежский Государственный Университет

Факультет Компьютерных Наук

Сравнительный анализ каскадной и спиральной моделей разработки программного

обеспечения

Выполнил : Шумлянский Михаил Сергеевич

Воронеж 2003

Содержание

Введение ………………………………………………………………………………………………..2

Водопадная модель процесса разработки ……………………………………………………………..3

Спиральная модель процесса разработки ……………………………………………………………..4

Итерации по спирали ………………………………………………………………………………4

Общие характеристики этапов разработки программного обеспечения

…………………………..5

Этап планирования и анализа требований

…………………………………………….5

Этап разработки ………………………………………………………………………………6

Реализация ………………….…………………………………………………………………...10

Внедрение ………………………………………………………………………………………10

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

Заключение ………………………………………………………………………………………………..11

Список источников ……………………………………………………………………………………….11

Введение

В настоящее время просматривается тенденция в сторону увеличения объема

работ, связанных с разработкой программного обеспечения по сравнению с

работами, выполнение которых позволит получить аппаратные средства ЭВМ.

В основе деятельности по созданию и использованию программного

обеспечения лежит понятие жизненного цикла. В общем случае различают

понятия жизненного цикла программного обеспечения и технологического

процесса его разработки. Более четко различия между данными понятиями

просматривается в отношении программных средств. Жизненный цикл является

моделью создания и использования программного обеспечения, отражающей его

различные состояния, начиная с момента возникновения необходимости в данном

ПО и заканчивая моментом его полного выхода из употребления у

пользователей.

Существует несколько моделей жизненного цикла. Традиционно выделяют

следующие основные этапы жизненного цикла :

( стратегическое планирование; анализ требований;

( проектирование (предварительное и детальное);

( кодирование (программирование);

( тестирование и отладка;

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

Под моделью обычно понимается структура, определяющая последовательность

выполнения и взаимосвязи процессов, действий и задач на протяжении

жизненного цикла. Из существующих в настоящее время моделей наиболее

распространены две: каскадная и спиральная.

Каждому этапу соответствуют определенный результат и набор документации,

являющейся исходными данными для следующего этапа. В заключение каждого

этапа производится верификация документов и решений с целью проверки их

соответствия первоначальным требованиям заказчика.

Водопадная модель процесса разработки

К середине 80-х годов наибольшее распространение получил "водопадный"

(waterflow) или "каскадный" процесс создания программного обеспечения.

Схема "водопадного" процесса приведена на рис. 1.1. Его основной

характеристикой является разбиение всей разработки на этапы, причем переход

с одного этапа на следующий происходит только после того, как будет

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

полного комплекта документации, достаточной для того, чтобы разработка

могла быть продолжена другой командой разработчиков.

Рис 1.1. "Водопадный" процесс

Применение "водопадного" процесса эффективно для систем, для которых в

самом начале разработки можно достаточно точно и полно сформулировать все

требования, с тем чтобы предоставить разработчикам свободу реализовать их

как можно лучше с технической точки зрения. В эту категорию попадают

сложные расчетные системы, системы реального времени и другие подобные

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

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

программных систем никогда полностью не укладывался в такую жесткую схему.

В процессе создания ПО постоянно возникала потребность в возврате к

предыдущим этапам и уточнении или пересмотре ранее принятых решений. В

результате реальный процесс создания систем принимал следующий вид (рис.

1.2):

Рис 1.2. Реальный процесс "водопадной" схемы

Данный процесс обладает рядом существенных недостатков, основным из

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

"заморожены" в виде технического задания на все время ее создания. Таким

образом, пользователи могут внести свои замечания только после того, как

работа над системой будет полностью завершена. В случае неточного изложения

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

пользователи получают систему, не удовлетворяющую их потребностям.

Спиральная модель процесса разработки

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

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

Для преодоления данной проблемы во второй половине 80-х годов был предложен

"спиральный" процесс создания программ (рис. 1.3), делающий упор на этапы

анализа и проектирования. Разработка системы по данной методологии

происходит итерациями, и после прохождения каждого витка спирали

пользователь получает очередную версию системы. После получения заказчиком

каждой версии уточняются цели и характеристики проекта, определяется его

качество и планируются работы следующего витка спирали.

Рис 1.3. Спиральная модель

Итерации по спирали

Спиральная модель разработки ПО, в тех или иных версиях используемая во

множестве конкретных прикладных методик, построена на следующем шаблоне.

Прежде всего в ходе общения с заказчиком определяется набор наиболее важных

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

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

Формируется план, начинаются работы и отслеживается их выполнение .

В основу спиральной модели заложены две посылки. Многочисленными

исследованиями подтверждено, что и заказчик и исполнитель обычно слишком

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

методик оценки объема работ (по функциональным точкам и т. п.). Поэтому

результаты таких оценок предлагается увеличивать (ухудшать) достаточно

серьезно - примерно на 50%. Кроме того, заказчик обычно слабо представляет

архитектуру будущей системы, поэтому ее следует проектировать, закладываясь

на открытые технологии и максимально гибкие возможности расширения и

наращивания функциональности. Уточнение конкретных требований выполняется

итерационно, при этом на каждом витке проектной спирали создается все более

точная версия, соответствующая пожеланиям заказчика.

Шесть шагов спиральной модели

1. В процессе общения с заказчиком формируется общее видение проекта, а

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

реализовать в определенные сроки с нужным качеством.

2. Расставляются приоритеты, задающие порядок реализации основных

функциональных возможностей.

3. Согласовываются временные рамки проекта. Часто для этого применяются

методики стоимостного прогнозирования . Далее исполнитель решает, сколько

функциональных возможностей в соответствии с их приоритетами удастся

реализовать в оговоренный срок.

4. На данном этапе определяются архитектура и ядро будущей системы. Это

наиболее ответственный момент, так как здесь необходимо учесть пока еще не

детализированные полностью требования к проекту - а они вполне могут быть

противоречивыми.

Ядро должно представлять собой законченный работающий вариант системы с

небольшим набором необходимых возможностей. Не исключено, что заказчик

видит архитектуру как жесткую конструкцию и не предусматривает средств ее

расширения для обеспечения дополнительной или менее приоритетной

функциональности. Поэтому далее определяется способ реализации требований с

более низкими приоритетами - это можно делать, например, с помощью

встроенного языка сценариев или подключением динамических библиотек, для

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

Этот шаг выполняется, как правило, в два и большее число итерационных

циклов.

5. Готовится план работ. Он ориентирован на сроки, определенные на

третьем этапе, и нацелен на скорейшую реализацию ядра системы.

Взаимодействуя с работающим прототипом, заказчик быстрее и точнее

вырабатывает и уточняет дальнейшие требования и корректирует приоритеты.

6. Разработка системы в соответствии с планом.

Для этого этапа характерны три типичных класса проблем:

- изменения в требованиях к проекту;

- изменения параметров самого проекта (сроков, бюджета, качества);

- временные задержки, связанные с текущими вопросами (техникой,

персоналом).

В ходе их решения приходится избавляться от задач с меньшими приоритетами

и, возможно, изменять критический путь проекта. Все изменения вносятся с

учетом основного критерия - сохранения сроков проекта.

Данный подход, конечно, не гарантирует соблюдения сроков - они могут быть

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

изменения требований.

Общие характеристики этапов разработки программного обеспечения

Этап планирования и анализа требований

Цель:

- получение требований ;

- выработка производных от них требований для этапа оценки безопасности.

Входные данные:

- требования к системе, аппаратный интерфейс, архитектура системы;

- план разработки ПО;

- стандарты на требования к ПО.

Первичный результат - данные о требованиях.

Основные принципы:

- интерфейсные и функциональные требования к системе, реализуемые на базе

ПО, должны быть проанализированы на предмет противоречий, несоответствия и

неопределенности;

- неадекватные и некорректные входные данные должны быть направлены на

выработавшие их подэтапы для разъяснения или исправления;

- каждое требование к системе, реализуемое на базе ПО, должно быть включено

в требования;

- должны быть особо отмечены требования , соответствующие системным

требованиям по предотвращению выхода системы из строя;

- требования должны соответствовать стандартам на требования к ПО;

- требования должны формулироваться в количественных терминах;

- требования не должны описывать детали разработки или тестирования, за

исключением указанных и проверенных ограничений конструкции;

- каждое системное требование, реализуемое на базе ПО, должно быть сводимо

к одному или более требованиюУ к ПО;

- каждое требование , за исключением производных требований, должно быть

сводимо к одному или нескольким системным требованиям;

- производные требования должны быть направлены этапу оценки безопасности

системы.

На этапе планирования разработки ПО создаются планы и выбираются

стандарты, которые направляют этап разработки и интегрированный этап. Его

целью является определение средств для создания ПО, которое будет

удовлетворять требования, предъявляемые к нему и обеспечивать достаточный

уровень надежности. На этом этапе производиться:

определение действий на этапах разработки и интегрированном этапе, которые

будут посвящены определению системных требований и уровня ПО;

определение ЖЦ ПО, включая взаимодействие между этапами, механизм взаимного

влияния этапов, критерии оценки ПО при переходе от одного этапа к другому;

определение среды ЖЦ, т.е. методы и инструментальные средства, используемые

на каждом этапе;

формирование дополнительных замечаний к ПО;

рассмотрение стандартов разработки ПО, соотношение их с системными целями

безопасности, относящиеся к разрабатываемому ПО;

разработка плана создания ПО;

доработка и проверка плана создания ПО.

Эффективность планирования - определяющий фактор при разработке ПО.

Основные руководящие принципы этого этапа следующие.

1. План разработки ПО должен быть разработан в такой момент ЖЦ, чтобы

обеспечить своевременное управление конкретными действиями на этапе

разработки и интегрированном этапе.

2. Стандарты разработки ПО, используемые в проекте, должны быть строго

определенными и четкими.

3. Выбранные методы и инструментальные средства должны быть такие, чтобы

обеспечили предотвращение ошибок на этапе разработки или свели их к

минимуму.

4. Этап планирования разработки ПО должен обеспечить координацию между

остальными этапами с целью согласования их стратегий в плане разработки ПО.

5. Этап планирования разработки ПО должен включать в себя средства проверки

плана на этапе реализации проекта.

6. На завершающей стадии этапа планирования, план и стандарты разработки ПО

должны быть проанализированы на предмет полноты и непротиворечивости.

Другие этапы ЖЦ могут быть начаты до окончания этапа планирования при

условии, что имеются планы и процедуры для действий на этих этапах.

Этап разработки

Цель:

- создание архитектуры ПО и требований НУ;

- выработка производных от них требований для этапа оценки безопасности.

Входные данные:

- данные о требованиях к ПО;

- план разработки ПО;

- стандарты проектирования ПО.

Первичный результат - описание разработки, включающее архитектуру ПО и

требования НУ.

Основные принципы:

- создаваемые требования НУ и архитектура ПО должны соответствовать

стандартам разработки ПО, быть непротиворечивыми и допускать трассировку

и проверку;- определяемые производные требования должны быть

проанализированы на предмет соответствия ;

- на подэтапе проектирования ПО следует ввести возможные типы сбоев ПО и

наоборот предотвратить остальные, что может изменить ранее назначенный

программный уровень и определить дополнительные данные в качестве

производных требований, передаваемых этапу оценки безопасности системы;

- потоки данных и управления должны быть наблюдаемы согласно требованиям

безопасности;

- реакции на условия сбоев должны соответствовать требованиям

безопасности;

- неадекватные или некорректные входные данные должны быть переданы либо

этапу оценки жизненного цикла системы, либо подэтапу разработки

требований, либо этапу планирования разработки ПО по принципу обратной

связи для разъяснения или исправления.

Процесс разработки содержит действия и задачи разработчика. Процесс

содержит действия для анализа требований, проектирования, программирования,

интеграции, тестирования и инсталляции и приемки, относящейся к

программному обеспечению.

Перечень действий: Этот процесс состоит из следующих видов деятельности.

1. Инструментарий процесс. Это действие состоит из следующих задач:

Если не оговорено в контракте, разработчик должен определить или выбрать

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

назначением, значимостью и сложностью проекта. Действия и задачи этого

процесса должны быть выбраны и отображены в модели жизненного цикла. Эти

действия и задачи могут перекрываться или взаимодействовать и могут быть

исполнены итеративно или рекурсивно.

Разработчик должен выполнять следующее:

документировать результаты в соответствии с процессом документирования;

разместить результаты (выходы) в процессе конфигурации и выполнить

контроль изменений в соответствии с этим;

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

программном продукте и задачах в соответствии с процессом разрешения

проблем ;

другие сопроводительные процессы , как определено в контракте.

Разработчик должен выбрать, довести и использовать внутренние стандарты,

методологии, процедуры и языки программирования (если это не оговорено в

контракте), которые должны быть зарегистрированы, соответствуют и

установлены организацией для исполнения действий процесса разработки и

процесса поддержки.

Разработчик должен разработать планы управления действиями в процессе

разработки. Планы должны включать особые стандарты, методы, средства,

действия и обязанности, связанные с разработкой и квалификацией всех

требований, включая надежность и безопасность. Эти планы должны быть

зарегистрированы и исполнены.

Официально непоставляемые элементы могут быть использованы в разработке или

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

что эксплуатация и поддержка поставляемого программного обеспечения после

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

элементы становятся официально поставляемыми.

2. Анализ системных требований. Это действие состоит из следующих задач,

которые разработчик должен исполнить или поддерживать, как требуется по

контракту.

Особое предполагаемое использование разрабатываемых систем должно быть

проанализировано для определения системных требований. Спецификация

системных требований должна описывать: функции и возможности системы;

надежность, защиту, разработку, интерфейс требования по эксплуатации и

поддержке; ограничения проектирования и квалификационные требования.

Спецификации системных требований должны быть зарегистрированы.

Системные требования должны быть оценены с позиций следующих критериев:

прослеживаемость потребностей заказчика, согласованность с потребностями

заказчика, тестируемость, выполнимость системного проектирования,

осуществимость эксплуатации и поддержки.

3. Системное проектирование. Это действие состоит из следующих задач,

которые разработчик должен выполнить или поддерживать, как требуется

контрактом.

Должна быть представлена архитектура верхнего уровня системы. Архитектура

должна определять элементы аппаратного, программного обеспечения и ручные

операции. Должна быть гарантия того, что все системные требования полностью

распределены среди элементов. Эти элементы должны быть впоследствии

Страницы: 1, 2