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

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

4 – анализ рисков;

5 – требования к системе;

6 – логическое проектирование (проектирование системы);

7 – первая сборка;

8 – квалификационные испытания и оценка;

9 – требования к программным компонентам;

10 – проектирование программных компонентов;

11 – вторая сборка;

12 – квалификационные испытания и оценка;

13 – требования к модулям;

14 – программирование и тестирование модулей программных средств;

15 – конечная сборка;

16 – ввод в действие и обеспечение приемки;

17 – эксплуатация и сопровождение.

В этом варианте модели процесс разработки проекта разделен на четыре

следующих квадранта: «Анализ требований», «Разработка», «Сборка»,

«Оценка».

В квадранте «Анализ требований» выполняются действия, связанные с

разработкой требований к результатам очередного цикла модели.

В квадранте «Разработка» выполняются концептуальное проектирование,

проектирование системы, подсистем, программирование и тестирование

программных компонентов.

В квадранте «Сборка» выполняется сборка компонентов системы

различного уровня.

В квадранте «Оценка» осуществляется оценка рисков проекта (в начале

жизненного цикла), квалификационные испытания промежуточных версий

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

необходимости в переходе к следующему циклу разработки или повторению

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

К достоинствам рассмотренных выше упрощенных спиральных моделей

можно отнести:

1) данные модели упрощены по сравнению с базовой моделью Боэма; это

делает их более понятными как разработчику, так и заказчику;

2) несмотря на упрощения, большое внимание в данных моделях

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

повышает качество как процесса разработки, так и продуктов разработки,

упрощает прогнозирование сроков и стоимости разработки, повышает

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

Модель «win-win»

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

модели под названием «win-win» (взаимный выигрыш), разработанный Боэмом

[20]. Данная модель уделяет повышенное внимание участникам проекта

(пользователям, заказчикам, разработчикам, тестировщикам и т.д.) и, в первую

очередь, роли заказчика в жизненном цикле разработки. Модель основана на

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

Рисунок 2.20 – Спиральная модель «win-win»

Каждый цикл в модели разделен на шесть этапов:

I - планирование работ уровня (цикла), обновление всего плана

разработки и определение участников работ планируемого уровня;

II - определение условий, необходимых для успешного выполнения работ

участниками уровня;

III - согласование условий успешного выполнения работ; анализ целей,

ограничений и альтернативных вариантов уровня;

Анализ и

утверждение

результатов

уровня

Оценка

альтернатив

продукта и

процесса

Разработка продукта

текущего уровня

Аттестация

продукта и процесса

текущего уровня

Определение

участников работ

планируемого

уровня

Определение условий,

необходимых для успешного

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

уровня

Согласование

условий

успешного

выполнения работ

Анализ целей,

ограничений

и альтернатив

уровня

Устранение

рисков

Планирование

работ уровня,

обновление плана

разработки

III

IV - оценка альтернативных вариантов уровня (в отношении как

продукта, так и процесса), устранение или сокращение рисков;

V - разработка продукта текущего уровня;

VI - аттестация продукта и процесса текущего уровня; анализ и

утверждение результатов уровня.

К достоинствам спиральной модели "win-win" по отношению к другим

спиральным моделям можно отнести:

1) более быстрая разработка продуктов проекта благодаря содействию,

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

2) уменьшение стоимости продуктов проекта благодаря уменьшению

объема переделок и текущего сопровождения, а также ускорению разработки;

3) более высокий уровень удовлетворения со стороны участников

проекта;

4) как результат, более высокое качество разработанных продуктов.

Спиральная модель Консорциума по вопросам разработки

программного обеспечения

Рисунок 2.21 отражает структуру одного цикла модифицированной

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

программного обеспечения (Software Productivity Consortium).

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

1 – Определение проекта, в том числе:

· участники работ;

· анализ требований;

· альтернативы;

· ограничения.

2 – Определение рисков;

3 – Оценка рисков;

4 – Планирование разрешения рисков;

5 – Оценка разрешения рисков;

6 – Оценка альтернатив, предложенных в первой работе, с участием

оценки разрешения рисков;

7 – Планирование и разработка графиков проекта;

8 – Разработка и верификация продукта;

9 – Мониторинг (надзор) и оценка продукта;

10 – Управление конфигурацией версии;

11 – Приемочные испытания уровня;

12 – Обновление спирального плана проекта.

Рисунок 2.21 – Спиральная модель Консорциума по вопросам разработки

программного обеспечения

В данной модели каждый цикл разделен на пять этапов:

I - Определение проекта;

II - Анализ рисков;

III - Разработка плана проекта;

IV - Разработка продукта текущего уровня;

V - Управление и планирование;

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

Содержание работ каждого этапа указано в соответствующем секторе спирали.

Утверждение

результатов

уровня

Версия

системы

План

разработки

Стратегия

разрешения

рисков

Результаты

определения

I. Определение

проекта

II. Анализ

рисков

III.

Разработ-

ка плана

проекта

IV. Разработка

продукта

текущего

уровня

V. Управление и

планирование

Компонентно-ориентированная спиральная модель

Рисунок 2.22 представляет вариант спиральной модели, называемый

компонентно-ориентированной моделью [19]. В этой модели основное

внимание уделяется процессу разработки. Модель ориентирована на повторное

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

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

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

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

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

повторно. Если таких кандидатов не выявлено, разрабатываются и включаются

в библиотеку новые компоненты.

К достоинствам компонентно-ориентированной спиральной модели

относятся:

1) сокращение длительности разработки конечного продукта;

2) уменьшение стоимости разработки конечного продукта.

Достоинства упрощенных спиральных моделей

Обобщая написанное выше об упрощенных спиральных моделях, можно

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

1) Существенное упрощение по сравнению с базовой спиральной

моделью Боэма, что делает данные модели интуитивно более понятными

заказчикам, разработчикам и администраторам проекта, а также уменьшает

стоимость проектов;

2) Повышенное внимание во всех упрощенных спиральных моделях

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

рисков, планирование, работа с персоналом и т.п.). Непосредственная

разработка в моделях занимает не более одного сектора цикла модели. Это

обеспечивает более высокое качество процесса разработки и продукта в целом,

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

заказчика результатами разработки.

Рисунок 2.22 – Вариант компонентно-ориентированной спиральной модели

I. Планирование

II. Риск

IV. Заказчик III. Разработка

Разработка

N-ой версии

системы

Извлечение

существующих

компонентов

из библиотеки

Разработка

новых

компонентов

Включение

новых

компонентов

в библиотеку

Содержание

разработки

Кандидат

найден

Кандидат не

найден

Идентификация и поиск

в библиотеке кандидатов

в компоненты

РАЗДЕЛ 3. ВЫБОР МОДЕЛИ

ЖИЗНЕННОГО ЦИКЛА

ДЛЯ КОНКРЕТНОГО

ПРОЕКТА

3.1. Классификация проектов

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

и систем

Существуют различные схемы классификации проектов.

В ГОСТ Р ИСО/МЭК ТО 12182-2002 - Информационная технология.

Классификация программных средств [5] - приведена схема классификации

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

классы. Данная классификация имеет общий характер и в целом не может

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

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

Институтом качества программного обеспечения SQI (Software Quality

Institute, США) специально для выбора модели жизненного цикла разработана

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

[20]. Основу данной классификации составляют четыре категории критериев.

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

класса.

Критерии классификации проектов, предложенные институтом SQI для

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

в следующие категории:

1) Характеристики требований к проекту.

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

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

программному средству (свойств разрабатываемой системы или ПС).

2) Характеристики команды разработчиков.

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

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

сформировать до выбора модели жизненного цикла.

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

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

успешную реализацию проекта.

3) Характеристики пользователей (заказчиков).

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

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

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

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

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

пользователей в процессе разработки.

4) Характеристики типов проектов и рисков.

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

управление рисками. В других моделях управление рисками вообще не

предусматривается.

Критерии данной категории отражают сложность проекта, достаточность

ресурсов для его исполнения, учитывают график проекта и т.д. С учетом этого

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

Примеры критериев каждой из категорий приведены в подразд. 3.2.

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

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

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

Использование данной классификации и предложений по выбору модели

жизненного цикла для небольших проектов может привести к чрезмерному

увеличению графика проекта, дополнительным затратам и дополнительным

рискам.

Таким образом, руководитель проекта должен чётко представлять себе

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

жизненного цикла в соответствии с рассматриваемыми критериями.

3.2. Процедура выбора модели

жизненного цикла разработки

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

Для выбора приемлемой модели жизненного цикла разработки

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

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

SQI.

Данная процедура базируется на применении таблиц вопросов. Каждый

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

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

проектов (см. подразд. 3.1).

Рассматриваемая процедура состоит из следующей последовательности

шагов.

1-й шаг процедуры. Проанализировать отличительные категории проекта

по критериям, представленным в виде вопросов. Таблица 3.1 – таблица 3.4

отражают данные вопросы.

2-й шаг процедуры. Ответить на вопросы (см. таблица 3.1 – таблица 3.4)

по анализируемому проекту, отметив слова "да" или "нет" в соответствующих

строках таблиц. Если слов «да» или «нет» в строке несколько, необходимо

отметить все из них (все «да» или все «нет»).

3-й шаг процедуры. Расположить по степени важности категории

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

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

цикла.

4-й шаг процедуры. Выбрать из моделей (см. таблица 3.1 – таблица 3.4)

ту модель, которая соответствует столбцу с наибольшим количеством

отмеченных ответов с учетом их степени важности (с наибольшим количеством

отмеченных ответов в верхней части приоритетных таблиц). Выбранная модель

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

Таблица 3.1 – Выбор модели жизненного цикла на основе характеристик

требований

№ п/п

Критерии категории

требований

Каскад

ная

V-

образ-

ная

RAD

Инкре-

мент-

ная

Эволю

цион-

ная

Спира-

льная

1 Являются ли требования к

проекту легко

определимыми и/или

хорошо известными?

Да Да Да Нет Нет Нет

2 Могут ли требования быть

сформулированы в начале

жизненного цикла?

Да Да Да Да Нет Нет

3 Будут ли изменяться

требования на протяжении

жизненного цикла?

Нет Нет Нет Нет Да Да

Нужно ли демонстрировать

требования с целью их

определения?

Нет Нет Да Нет Да Да

5 Требуется ли проверка

концепции?

Нет Нет Да Нет Да Да

№ п/п

Критерии категории

требований

Каскад

ная

V-

образ-

ная

RAD

Инкре-

мент-

ная

Эволю

цион-

ная

Спира-

льная

6 Будет ли формулирование

требований зависеть от

роста сложности системы в

жизненном цикле?

Нет Нет Нет Да Да Да

Таблица 3.2 – Выбор модели жизненного цикла на основе характеристик

команды разработчиков

№ п/п

Критерии категории

команды разработчиков

проекта

Каскад

ная

V-

образ-

ная

RAD

Инкре-

мент-

ная

Эволю

цион-

ная

Спира-

льная

1 Являются ли проблемы

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

проекта новыми для

большинства

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

Нет Нет Нет Нет Да Да

2 Являются ли технологии

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

проекта новыми для

большинства

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

Да Да Нет Да Нет Да

3 Являются ли

инструментальные

средства, используемые в

проекте, новыми для

большинства

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

Да Да Нет Нет Нет Да

4 Изменяются ли роли

участников проекта на

протяжении жизненного

цикла?

Нет Нет Нет Да Да Да

5 Могут ли разработчики

проекта пройти обучение?

Нет Да Да Да Нет Нет

6 Является ли структура

разрабатываемых систем в

жизненном цикле более

значимой для

разработчиков, чем

Да Да Нет Да Нет Нет