Ответы на экзамен (987689), страница 3

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

Текст из файла (страница 3)

∙••••••• Возможность эксплуатации и сопровождения.

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

Ввод в действие программных средств

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

Обеспечение приемки программных средств

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

2) Процесс эксплуатации

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

∙••••••• Подготовка процесса.

∙••••••• Эксплуатационные испытания.

∙••••••• Эксплуатация системы.

∙••••••• Поддержка пользователя.

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

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

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

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

3) Процесс сопровождения

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

Процесс сопровождения состоит из следующих работ:

∙••••••• Подготовка процесса.

∙••••••• Анализ проблем и изменений.

∙••••••• Внесение изменений.

∙••••••• Проверка и приемка при сопровождении.

∙••••••• Перенос.

∙••••••• Снятие с эксплуатации.

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

Анализ проблем и изменений включает следующие работы:

∙••••••• Анализ сообщений о проблеме или заявок на изменение по их влиянию на организационные вопросы, существующую систему и интерфейсы с другими системами. При этом выясняют тип изменений, объем, критичность.

∙••••••• На основе проведенного анализа разрабатывают варианты реализации изменений.

∙••••••• Документальное оформление сообщения о проблеме или заявку на изменение, результаты анализа и варианты реализации.

∙••••••• Согласование выбранного варианта изменения в соответствии с договором.

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

∙••••••• Проанализировать, какие документы, программные модули или их версии требуют изменений.

∙••••••• Реализация изменений выполняется как процесс разработки. В том числе должны быть установлены критерии проведения испытаний, оценки их результатов и оценки измененных и неизмененных объектов. Должно быть обеспечено, чтобы неизмененные требования не изменились.

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

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

∙••••••• Анализ и установление требований к переносу.

∙••••••• Разработка инструментальных средств для выполнения переноса.

∙••••••• Настройка программного продукта и данных к новым условиям эксплуатации.

∙••••••• Выполнение переноса.

∙••••••• Верификация переноса.

∙••••••• Последующая поддержка прежней среды.

Пользователям должно быть направлено уведомление о планах и работах по переносу объекта. В уведомление должно быть включено:

∙••••••• Обоснование необходимости переноса.

∙••••••• Описание новой среды с указанием даты, с которой она доступна для пользователей.

∙••••••• Описание других доступных вариантов поддержки в случае прекращения поддержки прежней среды.

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

Снятие с эксплуатации. План снятия с эксплуатации включает следующее:

∙••••••• Сроки прекращения полной или частичной поддержки.

∙••••••• Требования к архивации программного продукта и документации.

∙••••••• Обязательства по оставшимся вопросам поддержки.

∙••••••• Сроки перехода, при необходимости, к новому программному продукту.

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

∙••••••• Описание заменяющего объекта с указанием даты его доступности для пользователей.

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

∙••••••• Описание других доступных вариантов поддержки в случае прекращения поддержки прежнего объекта.

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

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

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

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

· Анализ.

· Проектирование.

· Реализация.

· Сборка и испытания.

· Внедрение.

· Сопровождение.

Рис. 1.1.

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

В настоящее время, особенно в связи с распространением объектно-ориентированного подхода к разработке программных средств распространение получила модель «Спираль».

Существуют 3 стратегии конструирования ПО:

• однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;

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

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

4. Особенности модели жизненного цикла «спираль»

У Марана вот такая вот картинка, может, нагляднее будет:

Спиральная модель — классический пример применения эволюционной стратегии конструирования.

Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска, отсутствующий в этих парадигмах [19].

Рис. 1.6. Спиральная модель: 1 — начальный сбор требований и планирование проекта; 2 — та же работа, но на основе рекомендаций заказчика; 3 — анализ риска на основе начальных требований; 4 — анализ риска на основе реакции заказчика; 5 — переход к комплексной системе; 6 — начальный макет системы; 7 — следующий уровень макета; 8 — сконструированная система; 9 — оценивание заказчиком

Как показано на рис. 1.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

1. Планирование — определение целей, вариантов и ограничений.

2. Анализ риска — анализ вариантов и распознавание/выбор риска.

3. Конструирование — разработка продукта следующего уровня.

4. Оценивание — оценка заказчиком текущих результатов конструирования.

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

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

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

Достоинства спиральной модели:

1) наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

2) позволяет явно учитывать риск на каждом витке эволюции разработки;

3) включает шаг системного подхода в итерационную структуру разработки;

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

Характеристики

Список файлов ответов (шпаргалок)