Глухова Л.А. Технологии разработки программного обеспечения

Подождите немного. Документ загружается.

Рисунок 2.4 – Структура фрагмента каскадной модели

с возможностью возврата к любому шагу

К недостаткам каскадной модели с обратными связями по сравнению с

классической каскадной моделью можно отнести сложности планирования и

финансирования проекта, достаточно высокий риск нарушения графика

разработки.

2.2.4. Вариант каскадной модели

по ГОСТ Р ИСО/МЭК ТО 15271-2002

В ГОСТ Р ИСО/МЭК ТО 15271-2002 [6] приводится вариант каскадной

модели, ориентированный на разработку систем (рисунок 2.5). В данном

варианте модели, как и в предыдущих вариантах, понятие шага разработки

совпадает с понятием работы процесса разработки, определенного в стандарте

СТБ ИСО/МЭК 12207-2003 [8].

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

программных средств, входящих в состав системы, различными командами

разработчиков или выбора ПС из уже готовых (или разработанных ранее).

Вариант учитывает также необходимость разработки или выбора технических

компонентов системы.

Рисунок 2.5 – Вариант каскадной модели

по ГОСТ Р ИСО/МЭК ТО 15271-2002

Анализ

требований

системе

Проектир

вание сис-

темной ар-

хитектуры

Анализ

требований к ПС

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

программной

архитектуры

Техническое

проектирование

ПС

Программиро

вание и

тестирование ПС

Сборка

и квал

фикационные

испытания ПС

Програм

ный

объект N

Технич

кие

объекты

Сборка

системы

Квалифик

ционные

испытания

системы

Ввод

системы

действие

Обесп

чение

при

емки

ПС

ПО - программный объект

ПС – программное средство

ПО1

ПО N

2.2.5. V-образная модель

Основное назначение V-образной модели – обеспечение планирования

тестирования (испытаний) системы на ранних стадиях проекта.

V-образная модель поддерживает каскадную стратегию однократного

выполнения этапов разработки жизненного цикла и базируется на

предварительном полном формировании требований.

V-образная модель представляет собой разновидность каскадной модели.

Она так же имеет последовательную структуру цикла разработки. Каждый шаг

начинается после завершения предыдущего шага (в классической V-образной

модели).

Однако в V-образной модели выделены связи между шагами,

предшествующими программированию, и соответствующими видами

тестирования и испытаний.

Рисунок 2.6 иллюстрирует вариант V-образной модели, адаптированный

к работам процесса разработки, определенного в СТБ ИСО/МЭК 12207-2003

[8].

На этапе анализа требований к системе выполняется анализ предметной

области и формулируются требования к системе. Кроме этого разрабатывается

план ввода в действие и обеспечения приемки.

На этапе проектирования системы выполняется проектирование

системной архитектуры и анализ требований к программным средствам. На

данном этапе, помимо этого, разрабатывается план квалификационных

испытаний системы.

На этапе проектирования программных средств выполняется

проектирование программной архитектуры и техническое проектирование

программных средств (разбиение программных средств на программные

модули). Одновременно составляются план сборки программных средств и

план квалификационных испытаний программных средств.

На этапе программирования и тестирования программных средств

выполняется кодирование и тестирование программных модулей.

На этапе сборки и квалификационных испытаний программных средств

осуществляется последовательная сборка программных модулей в

программные средства и квалификационные испытания последовательных

результатов сборки. Одной из основных целей данного этапа является

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

На этапе сборки и квалификационных испытаний системы выполняется

сборка программных средств, технических средств и ручных операций в

единую систему и квалификационные испытания системы. Одной из основных

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

системы.

На этапе ввода в действие и обеспечения приемки осуществляются

приемочные испытания, целью которых является проверка пользователем

соответствия системы исходным требованиям.

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

тестирования и по подтверждению результатов соответствующих этапов (см.

рисунок 2.6) обозначены пунктирными линиями.

Как и в каскадной модели, работы вспомогательных процессов

жизненного цикла программных средств выполняются на всех этапах. Они

включают управление проектом, обеспечение качества, верификацию и

аттестацию, управление конфигурацией, разработку документации.

Рисунок 2.6 – V-образная модель жизненного цикла

С целью сокращения недостатков каскадной стратегии разработан ряд

модификаций V-образной модели, обусловленных разновидностью обратных

связей, которые обеспечивают возможность изменения результатов

предыдущих этапов разработки.

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

системы

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

программных

средств

Сборка и ква-

лификационные

испытания ПС

Сборка и квали-

фикационные

испытания

системы

Ввод в действие

и обеспечение

приемки

Анализ

требований

к системе

Программиро-

вание и

тестирование

ПС

Подготовка

процесса

разработки

Эксплуатация и

сопровождение

Например, рисунок 2.7 иллюстрирует V-образную модель с организацией

обратных связей между соседними этапами процесса разработки.

Рисунок 2.7 - V-образная модель жизненного цикла

с организацией обратных связей между соседними этапами

V-образная модель поддерживает каскадную стратегию разработки

программных средств и систем. Поэтому она обладает всеми достоинствами

данной стратегии. Кроме того, при подходящем использовании V-образная

модель обладает следующими дополнительными достоинствами:

1) планирование на ранних стадиях разработки системы ее тестирования

(испытаний);

2) упрощение аттестации и верификации всех промежуточных

результатов разработки;

3) упрощение управления и контроля хода процесса разработки,

Подготовка

процесса

разработки

Эксплуатация

сопровождение

Проектирова-

ние системы

Проектирова-

ние ПС

Сборка и квали-

фикационные

испытания ПС

Сборка и квали-

фикационные

испытания

системы

Ввод в действие

и обеспечение

приемки

Анализ

требований

к системе

Программиро-

вание и

тестирование

ПС

возможность более реального использования графика проекта.

При использовании V-образной модели для несоответствующего ей

проекта выявляются следующие ее недостатки:

1) поздние сроки тестирования требований в жизненном цикле, что

оказывает существенное влияние на график выполнения проекта при

необходимости выполнить их изменения;

2) отсутствие, как и в базовой каскадной модели, действий,

направленных на анализ рисков.

2.3. RAD-модель быстрой разработки

приложений

Модель быстрой разработки приложений (Rapid Application Development,

RAD) появилась в 80-е годы в связи с бурным развитием мощных технологий и

инструментальных средств разработки ПС. Данная модель, исходя из

особенностей ее реализации и целей ее использования, может поддерживать

как инкрементную, так и эволюционную стратегию разработки системы или

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

другой модели для ускорения цикла разработки прототипа (версии) системы

или ПС (см. пп. 2.5.3, 2.5.4).

Модели жизненного цикла, реализующие инкрементную или

эволюционную стратегию разработки, широко применяют понятие быстрого

прототипирования. RAD-модель представляет собой модель, на которой

прототипирование базируется.

Основу RAD-модели составляет использование мощных

инструментальных средств разработки. Такими средствами являются языки

четвертого поколения 4GL (Fourth Generation Language – язык

программирования четвертого поколения) и CASE-средства, благодаря

наличию в них сред визуальной разработки и кодогенераторов. Поэтому в

процессе RAD-разработки основное внимание уделяется не программированию

и тестированию ПС, а анализу требований и проектированию.

Использование инструментальных средств позволяет задействовать

пользователя, а следовательно, и дать оценку продукту на всех стадиях его

разработки.

Характерной чертой RAD-модели является короткое время перехода от

анализа требований до создания полной системы или программного средства.

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

периодом времени (временным блоком; обычно 60 дней) [19, 20, 10]. При

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

использование RAD-модели позволяет за временной блок создать полностью

функциональную систему.

2.3.1. Базовая RAD-модель

Рисунок 2.8 представляет вариант базовой RAD-модели быстрой

разработки приложений для отдельной итерации некоторой эволюционной

модели. Данный рисунок отражает также зависимость трудозатрат по

разработке и участия пользователя от этапов RAD-модели.

Рисунок 2.8 – Базовая RAD–модель быстрой разработки приложений

На этапе анализа требований к системе совместно с заказчиком

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

требований к системе.

На этапе проектирования выполняется проектирование системной

архитектуры, анализ требований к программным средствам, проектирование

программной архитектуры и техническое проектирование программных

средств. При этом, как правило, используются автоматические

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

информации и визуальное проектирование.

На этапе программирования и квалификационных испытаний

осуществляется программирование и тестирование программных средств,

сборка и квалификационные испытания системы. При этом используются

соответствующие инструментальные средства автоматической кодогенерации.

На этапе ввода в действие и обеспечения приемки выполняются

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

Анализ

требований

к системе

Проектиро-

вание

Программи-

рование и

квалифика-

ционные

испытания

Ввод в

действие и

обеспечение

приемки

Временной блок

Трудозатраты по разработке

Участие

пользователя

в разработке

2.3.2. RAD-модель, базирующаяся

на моделировании

В RAD-модели для ускорения процесса разработки обычно используются

различные виды моделирований, например, моделирование предметной

области, моделирование данных, моделирование процесса (поведения) с

последующей автоматической кодогенерацией программного средства.

С учетом этого разработан вариант RAD-модели для отдельной итерации

некоторой эволюционной модели (рисунок 2.9). В данной модели выделяется

пять этапов.

Рисунок 2.9 – Вариант RAD-модели, использующий моделирование

Временной блок

(60 дней)

Моделирование

поведения

Автоматическая

кодогенерация

Сборка и

квалификационные

испытания

Моделирование

предметной

области

Моделирование

данных

Основу этапа моделирования предметной области составляет

определение и анализ ее информационных потоков и функций

(функциональное моделирование).

На этапе моделирования данных на базе информационных потоков,

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

предметной области.

На этапе моделирования поведения выполняется динамическое

(поведенческое) моделирование предметной области.

На этапе автоматической кодогенерации на основе информационной,

функциональной и поведенческой моделей выполняется генерация текстов

программных компонентов. При этом используются языки программирования

четвертого поколения (4GL) и CASE-средства. Широко применяются повторно

используемые программные компоненты.

На этапе сборки и квалификационных испытаний выполняется сборка и

испытания результирующей системы, подсистемы или программного средства.

2.3.3. RAD-модель параллельной разработки

функций программного средства

Зачастую используется вариант RAD-модели, которую представляет

рисунок 2.10.

Данный вариант реализует параллельную разработку базовых функций

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

интеграцией разработанных функций в единое ПС или систему.

2.3.4. RAD-модель быстрой разработки

приложений

по ГОСТ Р ИСО/МЭК ТО 15271-2002

Рисунок 2.11 представляет один из вариантов RAD-модели,

рекомендованный к использованию в ГОСТ Р ИСО/МЭК ТО 15271-2002 [6].

На этапе осуществимости выполняется анализ проекта на основе

критических факторов успешности реализации RAD-модели (к данным

факторам могут быть отнесены области применения RAD-модели, приведенные

в п. 2.3.5).

На этапе анализа деловой деятельности определяется область

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

В цикле функциональной модели с помощью инструментальных средств

быстрой разработки (CASE-средств) разрабатывается функциональный

прототип, формулируются нефункциональные требования и стратегия

реализации прототипа.

Рисунок 2.10 – Вариант RAD-модели,

основанный на независимой работе групп разработчиков

Моделирова-

ние предмет-

ной области

2-я группа

разработчиков

Моделирова-

ние данных

Моделирова-

ние обработки

Автоматичес

кая

кодогенерация

Моделирова

ние

предметной

области

1-я группа

разработчиков

Моделирова-

ние данных

Моделирова-

ние обработки

Автоматичес

кая

кодогенерация

Сборка и

квалификаци-

онные

испытания

Временной

блок (60 дней)