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

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

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

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

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

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

Воронеж 2003

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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


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


<span Times New Roman"; mso-hansi-font-family:«Times New Roman»;mso-char-type:symbol;mso-symbol-font-family: Symbol">·

стратегическое планирование; анализтребований;
<span Times New Roman"; mso-hansi-font-family:«Times New Roman»;mso-char-type:symbol;mso-symbol-font-family: Symbol">·проектирование (предварительное идетальное);
<span Times New Roman"; mso-hansi-font-family:«Times New Roman»;mso-char-type:symbol;mso-symbol-font-family: Symbol">·кодирование (программирование);
<span Times New Roman"; mso-hansi-font-family:«Times New Roman»;mso-char-type:symbol;mso-symbol-font-family: Symbol">·тестирование и отладка;
<span Times New Roman"; mso-hansi-font-family:«Times New Roman»;mso-char-type:symbol;mso-symbol-font-family: Symbol">·эксплуатация и сопровождение.

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

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

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

<img src="/cache/referats/13552/image002.jpg" v:shapes="_x0000_s1029">
К середине 80-х годов наибольшее распространение получил «водопадный»(waterflow) или «каскадный» процесс создания программногообеспечения. Схема «водопадного» процесса приведена на рис. 1.1. Егоосновной характеристикой является разбиение всей разработки на этапы, причемпереход с одного этапа на следующий происходит только после того, как будетполностью завершена работа на текущем. Каждый этап завершается выпуском полногокомплекта документации, достаточной для того, чтобы разработка могла бытьпродолжена другой командой разработчиков.

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

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

<img src="/cache/referats/13552/image003.gif" v:shapes="_x0000_s1030">

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

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

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

<img src="/cache/referats/13552/image005.gif" v:shapes="_x0000_s1031">
В реальной жизни оказывается, что на стадии формулировки требований заказчик неможет точно определить все требования к программному продукту. Для преодоленияданной проблемы во второй половине 80-х годов был предложен«спиральный» процесс создания программ (рис. 1.3), делающий упор наэтапы анализа и проектирования. Разработка системы по данной методологиипроисходит итерациями, и после прохождения каждого витка спирали пользовательполучает очередную версию системы. После получения заказчиком каждой версииуточняются цели и характеристики проекта, определяется его качество ипланируются работы следующего витка спирали.

 

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

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

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

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

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

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

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

3. Согласовываются временныерамки проекта. Часто для этого применяются методики стоимостногопрогнозирования. Далее исполнитель решает, сколько функциональных возможностейв соответствии с их приоритетами удастся реализовать в оговоренный срок.

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

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

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

5. Готовится план работ. Онориентирован на сроки, определенные на третьем этапе, и нацелен на скорейшуюреализацию ядра системы. Взаимодействуя с работающим прототипом, заказчикбыстрее и точнее вырабатывает и уточняет дальнейшие требования и корректируетприоритеты.

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

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

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

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

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

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

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

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

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

Цель:
— получение требований ;
— выработка производных от них требований для этапа оценки безопасности.
Входные данные:
— требования к системе, аппаратный интерфейс, архитектура системы;
— план разработки ПО;
— стандарты на требования к ПО.

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

На этапе планирования разработкиПО создаются планы и выбираются стандарты, которые направляют этап разработки иинтегрированный этап. Его целью является определение средств для создания ПО,которое будет удовлетворять требования, предъявляемые к нему и обеспечиватьдостаточный уровень надежности. На этом этапе производиться:
определение действий на этапах разработкии интегрированном этапе, которые будут посвящены определению системныхтребований и уровня ПО;
определение ЖЦ ПО, включая взаимодействие между этапами, механизм взаимноговлияния этапов, критерии оценки ПО при переходе от одного этапа к другому;
определение среды ЖЦ, т.е. методы и инструментальные средства, используемые накаждом этапе;
формирование дополнительных замечаний к ПО;
рассмотрение стандартов разработки ПО, соотношение их с системными целямибезопасности, относящиеся к разрабатываемому ПО;
разработка плана создания ПО;
доработка и проверка плана создания ПО.
Эффективность планирования — определяющий фактор при разработке ПО. Основныеруководящие принципы этого этапа следующие.
1. План разработки ПО должен бытьразработан в такой момент ЖЦ, чтобы обеспечить своевременное управлениеконкретными действиями на этапе разработки и интегрированном этапе.
2. Стандарты разработки ПО,используемые в проекте, должны быть строго определенными и четкими.
3. Выбранные методы иинструментальные средства должны быть такие, чтобы обеспечили предотвращениеошибок на этапе разработки или свели их к минимуму.
4. Этап планирования разработки ПОдолжен обеспечить координацию между остальными этапами с целью согласования ихстратегий в плане разработки ПО.
5. Этап планирования разработки ПОдолжен включать в себя средства проверки плана на этапе реализации проекта.
6. На завершающей стадии этапапланирования, план и стандарты разработки ПО должны быть проанализированы напредмет полноты и непротиворечивости.
Другие этапы ЖЦ могут быть начаты до окончания этапа планирования при условии,что имеются планы и процедуры для действий на этих этапах.

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

Цель:

— создание архитектуры ПО итребований НУ;
— выработка производных от них требований для этапа оценки безопасности.
Входные данные:
— данные о требованиях к ПО;
— план разработки ПО;
— стандарты проектирования ПО.

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

Процесс разработки содержитдействия и задачи разработчика. Процесс содержит действия для анализатребований, проектирования, программирования, интеграции, тестирования иинсталляции и приемки, относящейся к программному обеспечению.
Перечень действий: Этот процесс состоит из следующих видов деятельности.
1. Инструментарий процесс. Это действие состоит из следующих задач:
Если не оговорено в контракте, разработчик должен определить или выбрать модельжизненного цикла программного обеспечения в соответствии с назначением,значимостью и сложностью проекта. Действия и задачи этого процесса должны бытьвыбраны и отображены в модели жизненного цикла. Эти действия и задачи могутперекрываться или взаимодействовать и могут быть исполнены итеративно илирекурсивно.
Разработчик должен выполнять следующее:
документировать результаты в соответствии с процессом документирования;
разместить результаты (выходы) в процессе конфигурации  и выполнить контроль изменений в соответствиис этим;
документировать и разрешить проблемы и несоответствия, найденные в программномпродукте и задачах в соответствии с процессом разрешения проблем ;
другие сопроводительные процессы, как определено в контракте.
Разработчик должен выбрать, довести и использовать внутренние стандарты,методологии, процедуры и языки программирования (если это не оговорено вконтракте), которые должны быть зарегистрированы, соответствуют и установленыорганизацией для исполнения действий процесса разработки и процесса поддержки.
Разработчик должен разработать планы управления действиями в процессеразработки. Планы должны включать особые стандарты, методы, средства, действияи обязанности, связанные с разработкой и квалификацией всех требований, включаянадежность и безопасность. Эти планы должны быть зарегистрированы и исполнены.
Официально непоставляемые элементы могут быть использованы в разработке илисопровождении программного обеспечения. Однако должна быть гарантия того, чтоэксплуатация и поддержка поставляемого программного обеспечения после егопоставки заказчику не зависит от таких элементов, другими словами, эти элементыстановятся официально поставляемыми.
2. Анализ системных требований. Этодействие состоит из следующих задач, которые разработчик должен исполнить илиподдерживать, как требуется по контракту.
Особое предполагаемое использование разрабатываемых систем должно бытьпроанализировано для определения системных требований. Спецификация системныхтребований должна описывать: функции и возможности системы; надежность, защиту,разработку, интерфейс требования по эксплуатации и поддержке; ограниченияпроектирования и квалификационные требования. Спецификации системных требованийдолжны быть зарегистрированы.
Системные требования должны быть оценены с позиций следующих критериев:прослеживаемость потребностей заказчика, согласованность с потребностямизаказчика, тестируемость, выполнимость системного проектирования,осуществимость эксплуатации и поддержки.
3. Системное проектирование. Этодействие состоит из следующих задач, которые разработчик должен выполнить илиподдерживать, как требуется контрактом.
Должна быть представлена архитектура верхнего уровня системы. Архитектурадолжна определять элементы аппаратного, программного обеспечения и ручныеоперации. Должна быть гарантия того, что все системные требования полностьюраспределены среди элементов. Эти элементы должны быть впоследствии определеныкак элементы аппаратной конфигурации (ЭАК), элементы конфигурации программногообеспечения (ЭКПО) и соответственно ручные операции. Архитектура системы исистемные требования, распределенные между элементами аппаратной, конфигурации,конфигурации ПО и ручными операциями, должны быть зарегистрированы.
Архитектура системы и требования для элементов конфигурации и ручных операцийдолжны быть оценены в соответствии со следующими критериями:
различимость системных требований;
согласованность с системными требованиями;
соответствие стандартам и используемым методам проектирования;
осуществимость наполнения элементов конфигурации ПО распределенными для нихтребованиями;
выполнимость эксплуатации и поддержки.
4. Анализ требований к программномуобеспечению. Для каждого ЭКПО это действие состоит из следующих задач, которыеразработчик должен исполнить.
Разработчик должен представить и зарегистрировать требования к программномуобеспечению, включая спецификации характеристик качества, описанных ниже:
спецификации функций и возможности, включая исполнение, физическиехарактеристики, условия окружающей среды, при которых выполняется программноеобеспечение;
внешний интерфейс ЭКПО;
квалификационные требования;
спецификации безопасности, включая относящиеся к методами эксплуатации иподдержки, влиянию окружающей среды и повреждению персоналом;
спецификации защиты, включая касающиеся особой информации и материалов;
человеческий фактор и спецификации человеко-машинного взаимодействия, включаяотносящиеся к ручным операциям, человеко-машинным взаимодействиям, ограничениямна персонал и области, требующие концентрации человеческого внимания, чувствительныес точки зрения ошибок человека и его опыта;
требования определения данных и требования к базам данных;
требования по инсталляции и приемке поставляемого программного обеспечения вэксплуатацию и сопровождение;
документация пользователя;
требования по эксплуатации пользователя и исполнению;
требования по пользовательскому сопровождению.
Разработчик должен оценить требования к программному обеспечению,руководствуясь приведенными ниже критериями:
прослеживаемость системных требований и системного проекта;
внешняя согласованность с системными требованиями;
внутренняя согласованность;
тестовое покрытие требований;
тестируемость;
выполнимость проектирования программного обеспечения;
осуществимость эксплуатации и сопровождения.
После успешного завершения обзора должна быть представлена основа длятребований к ЭКПО.
5. Проектирование программногообеспечения. Для каждого ЭКПО это действие состоит из следующих задач, которыеразработчик должен быть выполнить.
Разработчик должен преобразовать требования для ЭКПО в архитектуру, описывающуюструктуру его верхнего (высшего) уровня и определяющую главные компоненты.Должна быть гарантия того, что требования к ЭКПО полностью распределены междуего компонентами и далее уточнены для облегчения детального проектирования.
Разработчик должен разработать и зарегистрировать:
проект высшего уровня для внешнего взаимодействия с ЭКПО и между компонентамипрограммного обеспечения;
проект высшего уровня для баз данных;
предварительные версии руководства для пользователя;
предварительные тестовые требования и план интеграции программного обеспечения.
Разработчик должен оценить архитектуру ЭКПО и проекты интерфейса и баз данных,руководствуясь приведенными ниже критериями:
прослеживаемость требований к ЭКПО;
внешняя согласованность с требованиями к ЭКПО;
внутренняя согласованность между компонентами;
соответствие методов проектирования и стандартов, которые были использованы;
выполнимость детализированного проектирования
осуществимость эксплуатации и сопровождения.
6. Детальное проектированиепрограммного обеспечения. Для каждого ЭКПО это действие состоит из следующихзадач, которые разработчик должен выполнить.
Разработчик должен разработать детальный проект для каждого компонентапрограммного обеспечения ЭКПО. Компоненты программного обеспечения должны бытьуточнены на нижних уровнях, содержащих модули программного обеспечения, которыемогут кодироваться, компилироваться и тестироваться. Должна быть гарантия того,что требования к программному обеспечению полностью локализованы в модуляхпрограммного обеспечения. Детализированный проект должен быть зарегистрирован.
Разработчик должен разработать и задокументировать детальный проект длявнешнего интерфейса ЭКПО между компонентами программного обеспечения и междумодулями программного обеспечения. Детальный проект интерфейса должен позволятьписать код программы без необходимости в дополнительной информации.
Разработчик должен разработать и зарегистрировать детальный проект базы данных.
Разработчик должен обновить руководство пользователя насколько это необходимо.
Разработчик должен определить и задокументировать тестовые требования ирасписание тестирования блоков программного обеспечения. Тестовые требованиядолжны включать испытания программного обеспечения на пределе требований.
Разработчик должен обновить тестовые требования и расписание интеграциипрограммного обеспечения.
Разработчик должен оценить детальный проект программного обеспечения и тестовыетребования с точки зрения критериев, приведенных ниже:
прослеживаемость требований ЭКПО;
внешняя согласованность с архитектуройпроекта;
внутренняя согласованность междукомпонентами и модулями;
соответствие методов проектирования ииспользуемых стандартов;
выполнимость тестирования;
выполнимость эксплуатации исопровождения.
7. Программирование и отладка. Длякаждого ЭКПО это действие состоит из следующих задач, которые должен выполнитьразработчик.
Разработчик должен разработать и задокументировать следующее:
а) каждый модуль программного обеспечения и базы данных;
б) процедуры тестирования и данные для тестирования каждого модуля и базыданных.
Разработчик должен тестировать каждый модуль ПО и базы данных, убеждаясь в том,что они удовлетворяют требованиям. Результаты тестирования должны бытьзадокументированы.
Разработчик должен обновить руководство пользователя, тестовые требования ирасписание интеграции ПО, оценить код ПО и результаты теста в соответствии скритериями, приведенными ниже:
прослеживаемость требований ЭКПО ипроекта;
внешняя согласованность с требованиямиЭКПО и архитектурой проекта;
внутренняя согласованность междутребованиями модулей;
тестирование модулей;
соответствие методов кодирования ииспользуемых стандартов;
выполнимость интеграции ПО итестирования;
выполнимость эксплуатации исопровождения.
8. Интеграция программногообеспечения. Для каждого ЭКПО это действие состоит из следующих задач, которыедолжен выполнить разработчик.
Разработчик должен разработать план интеграции для объединения модулей ПО икомпонентов в ЭКПО. План должен включать требования, процедуры, данные,ответственность и расписание.
Разработчик должен объединить модули ПО и компоненты. Должна быть гарантиятого, что каждый компонент удовлетворяет требованиям  и полностью интегрирован как результат этой деятельности. Интеграция ирезультаты теста должны быть задокументированы.
Разработчик должен обновить руководство пользователя, если это требуется.
Разработчик должен разработать и задокументировать для каждогоквалификационного требования ЭКПО полный набор тестов, ситуаций (вход, выход, критериитестирования) и процедуры тестирования для управления квалификационнымтестированием ПО.
Разработчик должен оценить план интеграции, проект, код, тесты, результатытестирования и руководства пользователя с точки зрения критериев, приведенныхниже:
отслеживаемость системных требований;
внешняя согласованность с системнымитребованиями;
внутренняя согласованность;
тестирование ЭКПО требований;
соответствие используемых стандартов иметодов тестирования;
соответствие с ожидаемыми результатами;
выполнимость квалификационноготестирования ПО;
выполнимость эксплуатации исопровождения.
9. Квалификационное тестированиепрограммного обеспечения. Для каждого ЭКПО это действие состоит из следующихзадач, которые должен выполнить разработчик:
Разработчик должен руководить квалификационным тестированием в соответствии сквалификационными требованиями, особыми для ЭКПО. Должно быть гарантировано,что реализация каждого требования к ПО полностью протестирована. Результатыквалификационного тестирования должны быть зарегистрированы.
Разработчик должен оценить проект, код, тесты, результаты тестирования ируководство пользователя в соответствии с приведенными ниже критериями:
тестирование требований к ЭКПО;
согласованность с ожидаемымирезультатами;
выполнимость системной интеграции итестирования;
выполнимость эксплуатации исопровождения.
Результаты аудита должны быть задокументированы. Если разрабатываются илиинтегрируются ПО и аппаратное обеспечение, аудит может быть отложен доквалификационного тестирования системы.
После успешного завершения аудита, если предписано, разработчик должен:
а) обновить и подготовить к поставке ПО для системной интеграции,квалификационного тестирования системы, инсталляции или поддержки приема ПО,как полагается;
б) представить основную линию проектирования и кодирования ЭКПО;
10. Системная интеграция. Этодействие состоит из следующих задач, которые должен выполнить разработчик.
ЭКПО должен быть интегрирован с ЭАК, руководством по эксплуатации и другимисистемами в единую систему. Составляющие должны быть протестированы насоответствие требованиям. Интеграция и результаты тестирования должны бытьзадокументированы.
Для каждого квалификационного требования к системе должны быть разработаны изадокументированы полный набор тестов, ситуаций (входных, выходных, критериевтестирования), процедур тестирования. Разработчик должен гарантировать, чтоинтегрированная система готова для квалификационного тестирования.
Интегрированная система должна быть оценена в соответствии с приведенными нижекритериями:
зона тестирования требований к системе;
приемлемость используемых методов истандартов тестирования;
согласованность с ожидаемымирезультатами;
выполнимость квалификационноготестирования системы;
выполнимость эксплуатации исопровождения.
11. Квалификационное тестированиесистемы. Это действие состоит из следующих задач, выполняемых разработчиком.
Квалификационное тестирование системы должно руководствоваться в соответствии сквалификационными требованиями, определенными для системы. Должно бытьгарантировано, что выполнение каждого требования к системе протестированополностью и система готова к поставке. Результаты квалификационноготестирования должны быть задокументированы.
Система должна быть оценена в соответствии с приведенными ниже критериями:
зона тестирования требований к системе;
подтверждение ожидаемыми результатами;
выполнимость эксплуатации исопровождения.
После успешного завершения аудита, если предписано, разработчик должен:
обновить и подготовить к поставке ЭКПО для инсталляции ПО и его приемки;
обосновать основные направления для проектирования и кодирования ЭКПО.
12. Инсталляция ПО. Это действиесостоит из следующих задач, выполняемых разработчиком.
Разработчик должен разработать план инсталляции ПО в намеченную среду. Ресурсыи информация, необходимые для установки ПО, должны быть определены и доступны.Разработчик должен помогать поставщику при установке. После того, как ПОустановлен в существующую систему, Разработчик должен поддерживать некоторыепараллельно выполняемые действия. План установки должен быть задокументирован.
Разработчик должен установить ПО в соответствии с планом установки. Должно бытьгарантировано, что ПО и базы данных инициализируются, функционируют ипрекращают работу, как указано в контракте. Процесс установки и результатыдолжны быть задокументированы.
12. Поддержка приемки ПО. Этодействие состоит из следующих задач, выполняемых разработчиком.
Разработчик должен поддерживать процесс приемки поставщиком и тестирование ПО.Приемка и тестирование должны основываться на общем обзоре, аудите,квалификационном тестировании, квалификационном тестировании системы (если оновыполнялось). Результаты приемки и тестирования должны быть задокументированы.

Реализация

Целью является получениеисходного кода, который должен допускать трассировку, проверку, бытьнепротиворечивым и корректно реализовывать требования НУ.
Входные данные:
— требования НУ;
— архитектура ПО;
— план разработки ПО;
— стандарты кодирования ПО

Первичный результат — исходныйкод и объектный код.
Основные принципы:
— исходный код должен реализовывать требования НУ и соответствовать архитектуреПО;
— исходный код должен соответствовать стандартам кодирования ПО;
— исходный код должен сводиться к описанию проекта;
— неадекватные или некорректные входные данные должны быть переданы либоподэтапу разработки требований к ПО, либо подэтапу проектирования ПО, либоэтапу планирования разработки ПО по принципу обратной связи для разъяснения илиисправления.

Внедрение

Целью является загрузкаисполняемого объектного кода в аппаратное или программно-аппаратноеобеспечение.
Входные данные:
— архитектура ПО;
— исходный код;
— объектный код.

Результат — исполняемый объектныйкод, а также компонуемые и загружаемые данные.
Основные принципы:
— исполняемый объектный код должен быть сгенерирован из исходного кода икомпонуемых и загружаемых данных;
— ПО должно быть загружено в целевой компьютер для программно-аппаратнойинтеграции;
— неадекватные или некорректные входные данные должны быть переданы либоподэтапу разработки требований к ПО, либо подэтапу проектирования ПО, либоподэтапу кодирования ПО, либо этапу планирования разработки ПО по принципуобратной связи для разъяснения или исправления.

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

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

еще рефераты
Еще работы по программному обеспечению