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

Реферат

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

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

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

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 348 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

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

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 - 2016
Рейтинг@Mail.ru