СиППО (1-4, 8, 10) (Ответы на все вопросы), страница 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) использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели:

1) новизна (отсутствует достаточная статистика эффективности модели);

2) повышенные требования к заказчику;

3) трудности контроля и управления временем разработки.

8.     СОСОМО модель. Важнейшие количественные характеристики процесса разработки программного обеспечения.

В данной модели для вывода формул использовался статистический подход — учитывались реальные результаты огромного количества проектов. Автор оригинальной модели — Барри Боэм (1981) —дал ей название СОСОМО 81 (Constructive Cost Model - Конструктивная модель стоимости) и ввел в ее состав три разные по сложности статистические подмодели.

Иерархию подмоделей Боэма (версии 1981 года) образуют:

• базисная СОСОМО — статическая модель, вычисляет затраты разработки и ее стоимость как функцию размера программы;

• промежуточная СОСОМО — дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;

• усовершенствованная СОСОМО — объединяет все характеристики промежуточной модели, дополнительно учитывает влияние всех атрибутов стоимости на каждый этап процесса разработки ПО (анализ, проектирование, кодирование, тестирование и т. д.).

Подмодели СОСОМО 81 могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:

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

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

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

Уравнения базовой подмодели имеют вид

Е=а_bx(KLOC) [чел-мес];

D = c_bx (E) [мес],

где Е — затраты в человеко-месяцах, D — время разработки, KLOC — количество строк в программном продукте.

Коэффициенты а_b, b_b, с_b, d_b берутся из таблицы.

В 1995 году Боэм ввел более совершенную модель СОСОМО II, ориентированную на применение в программной инженерии XXI века [21].

В состав СОСОМО II входят:

• модель композиции приложения;

• модель раннего этапа проектирования;

• модель этапа пост-архитектуры.

Для описания моделей СОСОМО II требуется информация о размере программного продукта. Возможно использование LOC-оценок, объектных указателей, функциональных указателей.

Модель композиции приложения

Модель композиции используется на ранней стадии конструирования ПО, когда:

•  рассматривается макетирование пользовательских интерфейсов;

•  обсуждается взаимодействие ПО и компьютерной системы;

•  оценивается производительность;

•  определяется степень зрелости технологии.

Модель композиции приложения ориентирована на применение объектных указателей.

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

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

Для учета реальных условий разработки вычисляется процент повторного использования программных компонентов %REUSE и определяется количество новых объектных указателей NOP: NOP = (Объектные указатели) х [(100 - %REUSE) /100].

Проектные затраты оцениваются по формуле: ЗАТРАТЫ = NOP /PROD [чел.-мес],