Реферат: Сравнительный анализ каскадной и спиральной моделей разработки программного обеспечения - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

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

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 348 kb, скачать бесплатно
Обойти Антиплагиат
Повысьте уникальность файла до 80-100% здесь.
Промокод referatbank - cкидка 20%!
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

14 Министерство образования РФ Воронежский Государственный Университет Факультет Компьютерных Наук Сравнительный анализ каскадной и спиральной моделей разработки программного о беспечения Выполнил : Шумлянский Михаил Сергеевич Воронеж 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 . Системное проектирование . Это действие состоит из следующих задач , к оторы е разработчик должен выполнить или поддерживать , как требуется контрактом. Должна быть представлена архитектура верхнего уровня системы . Архитектура должна определять элеме нты аппаратного , программного обеспечения и р учные операции . Должна быть гарантия т о го , что все системные требования полн остью распределены среди элементов . Эти элеме нты должны быть впоследствии определены как элементы аппаратной конфигурации (ЭАК ), элемен ты конфигурации программного обеспечения (ЭКПО ) и соответственно ручные операции . А р хитектура системы и системные требования , распределенные между элементами аппаратной , конфигурации , конфигурации ПО и ручными опера циями , должны быть зарегистрированы. Архитектура системы и требования для элементов конфигурац ии и ручных операций должны бы т ь оценены в соответствии со следующим и критериями : различимость систем ных требований ; согласованность с системными требованиями ; соответствие стандартам и испол ьзуемым методам проектирования ; осуществимость н аполнения элементов конфигурации ПО распределенн ыми для них требованиями ; выполнимость эксплуатации и поддержки. 4 . Анализ требований к пр ограммному обеспечению . Для каждого ЭКПО это действие состоит из следующих задач , кото рые разработчик должен исполнить. Разработчик дол жен представить и зарегистриров ать требов ания к программному обеспечению , включая спец ификации характеристик качества , описанных ниже : спецификации функций и возможности , включая исполнение , физические характеристики , условия окружающей среды , при которых выполняется про граммное обеспе ч ение ; внешний интерф ейс ЭКПО ; квалификационные требования ; специфик ации безопасности , включая относящиеся к мето дами эксплуатации и поддержки , влиянию окружа ющей среды и повреждению персоналом ; специфи кации защиты , включая касающиеся особой инфор мации и м а териалов ; человеческий фактор и спецификации человеко-машинного взаимоде йствия , включая относящиеся к ручным операция м , человеко-машинным взаимодействиям , ограничениям на персонал и области , требующие концентрации человеческого внимания , чувствительные с т очки зрения ошибок человека и его опыта ; требования определения данных и требования к базам данных ; требования п о инсталляции и приемке поставляемого програм много обеспечения в эксплуатацию и сопровожде ние ; документация пользователя ; требования по эксплуа т ации пользователя и исполн ению ; требования по пользовательскому сопровожде нию. Разработчик должен оценить требования к программному обеспечению , руководствуясь приведенными ниже критериями : прослеживаемость системных требований и системного проекта ; внешн я я согласованность с системными требовани ями ; внутренняя согласованность ; тестовое покры тие требований ; тестируемость ; выполнимость про ектирования программного обеспечения ; осуществимость эксплуатации и сопровождения. После успешного завершения обзора долж н а быть представлена основа для требований к ЭКПО. 5 . Проектирование пр ограммного обеспечения . Для каждого ЭКПО это действие состоит из следующих задач , кото рые разработчик должен быть выполнить. Разработчи к должен преобразовать требования для ЭКПО в архите ктуру , описывающую структуру ег о верхнего (высшего ) уровня и определяющую главные компоненты . Должна быть гарантия того , что требования к ЭКПО полностью распреде лены между его компонентами и далее уточн ены для облегчения детального проектирования . Разраб о тчик должен разработать и зарегистрировать : проект высшего уровня для внешнего взаимодействия с ЭКПО и между компонентами программного обеспечения ; проект вы сшего уровня для баз данных ; предварительные версии руководства для пользователя ; предва рительные т естовые требования и пла н интеграции программного обеспечения. Разработчик должен оценить архитектуру ЭКПО и проекты интерфейса и баз данных , руководствуясь п риведенными ниже критериями : прослеживаемость тр ебований к ЭКПО ; внешняя согласованность с требов а ниями к ЭКПО ; внутренняя согласованность между компонентами ; соответствие методов проектирования и стандартов , которые были использованы ; выполнимость детализированно го проектирования осуществимость эксплуатации и сопровождения. 6 . Детал ьное проектировани е программного обеспечения . Для каждого ЭКПО это действие состоит из следующих задач , которые разработчик дол жен выполнить. Разработчик должен разработать дет альный проект для каждого компонента программ ного обеспечения ЭКПО . Компоненты программного обесп е чения должны быть уточнены на нижних уровнях , содержащих модули програ ммного обеспечения , которые могут кодироваться , компилироваться и тестироваться . Должна быть гарантия того , что требования к программном у обеспечению полностью локализованы в модуля х пр о граммного обеспечения . Детализир ованный проект должен быть зарегистрирован. Разра ботчик должен разработать и задокументировать детальный проект для внешнего интерфейса Э КПО между компонентами программного обеспечения и между модулями программного обеспече н ия . Детальный проект интерфейса д олжен позволять писать код программы без необходимости в дополнительной информации. Разработч ик должен разработать и зарегистрировать дета льный проект базы данных. Разработчик должен обновить руководство пользователя наско л ько это необходимо. Разработчик должен оп ределить и задокументировать тестовые требования и расписание тестирования блоков программног о обеспечения . Тестовые требования должны вкл ючать испытания программного обеспечения на п ределе требований . Разработчик должен обновить тестовые требования и расписание интеграции программного обеспечения. Разработчик дол жен оценить детальный проект программного обе спечения и тестовые требования с точки зр ения критериев , приведенных ниже : прослеживаемость требований ЭКПО ; в нешняя согласованность с архитектурой проекта ; в нутренняя согласованность между компонентами и модулями ; соответствие методов проектирования и используемых стандартов ; выполнимость тестирован ия ; выполнимость эксплуат ации и сопровождения. 7 . Программировани е и отладка . Для каждого ЭКПО это действие состоит из следующих задач , которые должен выполнит ь разработчик. Разработчик должен разработать и задокументировать следующее : а ) каждый модул ь программного обеспечения и базы данных ; б ) процедуры тестирования и данные для тестирования каждого модуля и базы данных. Разработчик должен тестировать каждый мо дуль ПО и базы данных , убеждаясь в том , что они удовлетворяют требованиям . Результат ы тестирования должны быть задокументированы. Раз работчик должен обновить рук о водство пользователя , тестовые требования и расписан ие интеграции ПО , оценить код ПО и рез ультаты теста в соответствии с критериями , приведенными ниже : прослеживаемост ь требований ЭКПО и проекта ; внешняя согласованность с требованиям и ЭКПО и архитектурой п роекта ; внутренняя согласованность меж ду требованиями модулей ; тестирование модулей ; соответствие методов кодирования и исполь зуемых стандартов ; выполн имость интеграции ПО и тестирования ; выполнимость эксплуатации и сопровождения. 8 . Интеграция программног о обеспечения . Для каждого ЭКПО это действие состоит из следующих задач , которые должен выполнить разработчик. Разработчик должен разработать план интеграции для объединения модулей ПО и компонентов в ЭКПО . План должен включать требования , процедуры , данн ы е , отв етственность и расписание . Разработчик должен объединить модули ПО и компоненты . Должна быть гарантия того , что каждый компонент удовлетворяет требованиям и полностью интегри рован как результат этой деятельности . Интегр ация и результаты теста дол ж ны быть задокументированы . Разработчик должен об новить руководство пользователя , если это тре буется. Разработчик должен разработать и задокуме нтировать для каждого квалификационного требован ия ЭКПО полный набор тестов , ситуаций (вхо д , выход , критерии тес т ирования ) и процедуры тестирования для управления квалиф икационным тестированием ПО. Разработчик должен о ценить план интеграции , проект , код , тесты , результаты тестирования и руководства пользовате ля с точки зрения критериев , приведенных н иже : отслеживаемо сть системны х требований ; внешняя согласованность с системными требованиями ; внутренняя согласованность ; тестирование ЭКПО требовани й ; соответствие используе мых стандартов и методов тестирования ; соответствие с ожидаемыми результатами ; выполнимость квали фикационного тестирования ПО ; выполнимость эксплуатации и сопровождения. 9. Квалификационное тестирование программного обеспечения . Для каждого ЭКПО это действие состоит из следующих задач , которые долже н выполнить разработчик : Разработчик должен руководит ь квалификационным тестированием в соответствии с квалификационными требованиями , особыми для ЭКПО . Должно быть гарантировано , что реализация каждого требования к ПО полностью протестирована . Результаты квалификаци онного тестирования должны быть зарегистр и рованы. Разработчик должен оценить проект , код , тесты , результаты тестирования и руков одство пользователя в соответствии с приведен ными ниже критериями : тестировани е требований к ЭКПО ; согласованность с ожидаемыми результатами ; выполнимость системной интег рации и тестирования ; выполнимость эксплуатации и сопровожд ения. Результаты аудита должны бы ть задокументированы . Если разрабатываются или интегрируются ПО и аппаратное обеспечение , аудит может быть отложен до квалификационного тестирования системы. После успешного заве ршения аудита , если предписано , разработчик до лжен : а ) обновить и подготовить к поставк е ПО для системной интеграции , квалификационн ого тестирования системы , инсталляции или под держки приема ПО , как полагается ; б ) предс тавить основную линию п роектирования и кодирования ЭКПО ; 10. Системная интеграция . Это действие со стоит из следующих задач , которые должен в ыполнить разработчик . ЭКПО должен быть интег рирован с ЭАК , руководством по эксплуатации и другими системами в единую систему . С оставляющие должны быть протестированы на соответствие требованиям . Интеграция и результа ты тестирования должны быть задокументированы. Дл я каждого квалификационного требования к сист еме должны быть разработаны и задокументирова ны полный набор тестов , ситуаций (вход н ых , выходных , критериев тестирования ), проц едур тестирования . Разработчик должен гарантирова ть , что интегрированная система готова для квалификационного тестирования. Интегрированная систем а должна быть оценена в соответствии с приведенными ниже критериям и : зона тестирования требований к систе ме ; приемлемость использу емых методов и стандартов тестирования ; согласованность с ожидаемыми результатами ; выполнимос ть квалификационного тестирования системы ; выполнимость эксплуатации и сопровождения. 11 . Квалификац ионное тестирование системы . Это действие состоит из следующих задач , выполняемых разработчиком. Квалификационное тестиро вание системы должно руководствоваться в соот ветствии с квалификационными требованиями , опреде ленными для системы . Должно быть гаранти р овано , что выполнение каждого тре бования к системе протестировано полностью и система готова к поставке . Результаты ква лификационного тестирования должны быть задокуме нтированы. Система должна быть оценена в соот ветствии с приведенными ниже критериями : зон а тестирования требований к системе ; подтверждение ожидаемыми результатами ; выполнимость эксплуатации и сопровождения. После успешного завершения аудита , если предписано , разработчик должен : обновит ь и подготовить к поставке ЭКПО для и нсталляции ПО и его п риемки ; обоснов ать основные направления для проектирования и кодирования ЭКПО. 12. Инсталляция ПО . Это действие состоит и з следующих задач , выполняемых разработчиком. Раз работчик должен разработать план инсталляции ПО в намеченную среду . Ресурсы и информац ия , необходимые для установки ПО , долж ны быть определены и доступны . Разработчик должен помогать поставщику при установке . П осле того , как ПО установлен в существующу ю систему , Разработчик должен поддерживать не которые параллельно выполняемые действия . Пл а н установки должен быть задокуме нтирован. Разработчик должен установить ПО в соответствии с планом установки . Должно быть гарантировано , что ПО и базы данных и нициализируются , функционируют и прекращают работ у , как указано в контракте . Процесс устано вки и результаты должны быть задок ументированы. 12. Поддер жка приемки ПО . Это действие состоит из следующих задач , выполняемых разработчиком. Разрабо тчик должен поддерживать процесс приемки пост авщиком и тестирование ПО . Приемка и тести рование должны основыватьс я на общем обзоре , аудите , квалификационном тестировании , квал ификационном тестировании системы (если оно в ыполнялось ). Результаты приемки и тестирования должны быть задокументированы. Реализация Целью является получение исходног о кода , который должен д опускать трасс ировку , проверку , быть непротиворечивым и корр ектно реализовывать требования НУ. Входные данные : - требования НУ ; - архитектура ПО ; - план разработки ПО ; - стандарты кодирования ПО Первичный результат - исходный код и о бъектный код. Основные принципы : - исходный код должен реализовывать требования НУ и соответствовать архитектуре ПО ; - исходный код должен соответствовать стандартам кодирования ПО ; - исходный код должен сводиться к опис анию проекта ; - неадекватные или некорректные входные данн ы е должны быть переда ны либо подэтапу разработки требований к ПО , либо подэтапу проектирования ПО , либо этапу планирования разработки ПО по принципу обратной связи для разъяснения или испра вления. Внедрение Целью является загрузка исполняем ого объектного кода в аппаратное или программно-аппаратное обеспечение. Входные данные : - архитектура ПО ; - исходный код ; - объектный код. Результат - исполняемый объектный к од , а также компонуемые и загружаемые данн ые. Основные принципы : - исполняемый объектный код дол жен быть сгенерирован из исходног о кода и компонуемых и загружаемых данных ; - ПО должно быть загружено в целевой компьютер для программно-аппаратной интеграции ; - неадекватные или некорректные входные данные должны быть переданы либо подэтапу разра ботки т р ебований к ПО , либо по дэтапу проектирования ПО , либо подэтапу кодир ования ПО , либо этапу планирования разработки ПО по принципу обратной связи для ра зъяснения или исправления. Сопровождение и Эксплуатация Процесс эксплуатации Процесс эксплуатации состои т из действий и задач того , кто эксплуатирует разработанное П О . Процесс включает эксплуатацию ПО и подд ержку пользователей . Поскольку эксплуатация ПО является интеграционной составляющей эксплуатации системы , действия и задачи этого процесса относятся и к системе. Оператор у правляет процессом эксплуатации на уровне про екта , следуя процессу управления , являющемуся примером ; представляет инфраструктуру процесса , со гласно процессу инфраструктура ; подстраивает проц есс для проекта согласно процессу подгонки ; р у ководит процессом на организацио нном уровне согласно процессу усовершенствования . Перечень действий . Этот процесс состоит следующих задач : выполнения процесса , тестирование , эксплуатация системы и поддержка пользователей. Процесс сопровождения Процесс п оддержки состоит из действий и за дач лица , выполняющего сопровождение . Этот про цесс начинается , когда необходима модификация из-за допущенных ошибок , неучтенных проблем , не обходимости усовершенствования или адаптации код а ПО и соответствующей документации. Его цель - модифицировать существующее ПО , сохрани в его целостность . Этот процесс включает р аспространение и замену ПО . Процесс завершает ся заменой ПО. Действия , обеспечиваемые этим р азделом , определены как процесс сопровождения , однако процесс может исп о льзовать другие процессы этого стандарта . Если испол ьзуется процесс разработки , термин разработчик интерпретируется ка к обеспечивающий сопровождение . Обеспечивающий сопровождение руководит процессом сопровождении на уровне проекта , следуя процессу управле ния . Перечень действий . Процесс с остоит из следующих действий : процесс реализа ции , анализ проблем и модификации , реализация модификации , приемка , распространение , замена ПО. Заключение Сравнивая каск адную и спиральную модели , можно сказать , что каскад ная модель более универсальна , т . е . она применима к производству ра зных изделий , будь то отбойный молоток или графический редактор . Для разных изделий просто будут изменяться количество и название этапов модели . Спиральная же модель более ориентирована и м енно на информац ионные системы , особенно на программные проду кты , поэтому при разработке информационных си стем и их программного обеспечения она пр едпочтительнее каскадной. Список ист очников : 1. www.aanet.ru 2. ww w.interface.com 3. www.setevoi.ru 4. Дж . Фокс “Программное обеспечение и его разработка” 1985 г. SMS® www.shms@box.vsi.ru www.cs.vsu.ru/~shumlyansky
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Утро. Маршрутка. Тишина. У мужика сотовый телефон звонит, но вместо мелодии собачий лай. Он подносит его к уху и нежно говорит:
- Да, дорогая...
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2017
Рейтинг@Mail.ru