Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обеспечения
Подождите немного. Документ загружается.
51
производства, затем передается заказчику как готовое изделие, изменение которого не
предусмотрено, хотя возможна замена на другое подобное изделие в случае
рекламации или некоторых ее деталей, вышедших из строя.
Определение требований
Проектирование системы
Реализация системы
Тестирование системы на
проверку правильности
(
верификация)
Тестирование системы
на
соответствие требованиям
Сопровождение
Рис. 2.1. Каскадная модель ЖЦ разработки программных систем
При таком подходе необходимо учитывать следующие факторы риска:
– требования недостаточно хорошо представлены;
– система слишком большая по объему, чтобы быть реализованной в целом;
– быстрые изменения в технологии и в требованиях;
– ограниченные ресурсы (людские, программные и др.);
– полученный продукт может оказаться непригодным для использования из-за
неправильного понимания требований или функций системы, а также недостаточного
тестирования.
Преимущества реализации системы с помощью каскадной модели следующие:
– все возможности системы реализуются одновременно;
– применяется в случае, если старая система должна быть полностью заменена.
Каскадную модель можно рассматривать как модель ЖЦ, пригодную для создания
первой версии ПО для проверки реализованных в ней функций. При сопровождении и
эксплуатации могут быть обнаружены разного рода ошибки, которые будут
исправляться разработчиком, начиная с первого процесса данной модели.
2.2. Инкрементная модель ЖЦ
Эту заложена еще называют нарастающей моделью, суть которой состоит в
возможности усовершенствования продукта (рис.2.2). Разработка начинается с
предоставления набора требований и реализации системы путем последовательного
конструирования и фиксации промежуточных продуктов (1, …, N) системы,
постепенно приближающейся к итоговой системе (рис.2.2).
Первая создаваемая промежуточная структура системы реализует часть требований, в
последующую структуру добавляют дополнительные требования и так до тех пор,
пока не будет окончательно согласованы требования и соответственно разработка
продукта системы. Над каждой промежуточной структурой выполняются
необходимые процессы, работы и задачи, например, анализ требований и создание
52
архитектуры могут быть выполнены одновременно. Процессы разработки
технического проекта ПС, его программирование и тестирование, сборка и
квалификационные испытания ПС выполняются при создании каждой последующей
структуре.
В данном примере используются следующие обозначения
– R (Requirements) требования,
– C/T (Coding/Testing) кодирование, тестирование,
– D (Design) проектирование,
– I/AS (Installation/acceptance) инсталляция, сопровождение.
В соответствии с данной моделью ЖЦ, процессы которой практически такие же, что и в
каскадной модели, ориентир делается на разработку некоторой законченной
промежуточной структуры, а задачи процесса разработки выполняются
последовательно или частично параллельно для ряда отдельных промежуточных
структур.
Работы и задачи процесса разработки могут выполняться неоднократно в той же
последовательности для всех промежуточных структур. Процессы сопровождения и
эксплуатации могут быть реализованы параллельно с процессом разработки путем
проверки частично реализованных требований в каждой промежуточной структуре и
так до получения законченного варианта системы. Вспомогательные и
организационные процессы обычно выполняются параллельно с процессом разработки
и концу разработки будут собраны данные, на основании которых может быть
устанавлен уровень надежности и качества изготовленной системы.
При применении данной модели необходимо учитывать следующие факторы риска:
– требования составлены непонятно для реализации;
– все возможности системы требуется реализовать с самого начала;
– быстро меняются технологии и требования к системе;
– ограничения в ресурсном обеспечении (люди, финансы), когда разработчики
реализуют систему в течение длительного времени.
R
D C/T I/AS
D C/T I/AS
D C/T
1
2
N
Рис.2.2. Пример инкрементной модели
I/AS
53
Данную модель разработки целесообразно использовать, в случае когда:
– желательно реализовать некоторые возможности системы быстро за счет создания
промежуточного продукта;
– система разделена на отдельные составные части структуры, которые можно
представлять как некоторый промежуточный продукт;
– возможно увеличение финансирования на разработку отдельных частей системы.
2.3. Спиральная модель
Исходя из возможности внесения изменений как в процесс, так и в создаваемый
промежуточный продукт была создана спиральная модель.
.
Реализация
Рис.2.3. Спиральная модель ЖЦ разработки программных систем
Это допущение ориентировано на удовлетворение потребности изменений сразу, как
только будет установлено, что созданные артефакты или элементы документации
(описание требований, проекта, комментариев различного вида и т.п.), не
соответствуют действительному состоянию разработки после внесения некоторых
изменений
Данная модель ЖЦ допускает анализ продута
на витке разработки, его проверку,
оценку его правильности и принятия решения двигаться на следующий виток или
опуститься на нижний для доработки.
Отличие этой модели от каскадной модели состоит в возможности спиральной модели
обеспечивать многоразовое возвращение к процессу формулирования требований и к
повторной разработке с любого процесса выполнения работ.
Версия 3 Версия 2 Версия1
Анализ требований
Тестирование
Проект
54
На изображенной спиральной модели (рис.2.3), каждый виток спирали соответствует
одной из версий разработки системы. При необходимости внесения изменений в
систему на каждом процессе витка для получения версии системы, обязательно
вносятся изменения в предварительно зафиксированные требования, после чего
происходит возврат на предыдущий виток спирали для продолжения реализации
новой версии системы с учетом изменений.
2.4.Эволюционная модель ЖЦ
В случае эволюционной модели система разрабатывается в виде последовательности
блоков структур (конструкций). В отличие от инкрементной модели ЖЦ,
подразумевается, что требования устанавливаются частично и уточняются в каждом
последующем промежуточном блоке структуры системы (рис.2.4.).
На данном рисунке модели используются следующие обозначения
– R (Requirements) требования,
– C/T (Coding/Testing) кодирование, тестирование,
– D (Design) проектирование,
– I/AS (Installation/acceptance) инсталляция, сопровождение.
Работы и задачи процесса разработки в соответствии с данной моделью выполняются
не однократно, но в той же последовательности, что для всех блоков структуры.
Так как промежуточные блоки структуры соответствуют реализации некоторых
требований, то соответственно их
реализацию можно проверять на процессе
сопровождения и эксплуатации, т.е. параллельно с процессом разработки блоков
структуры системы. При этом вспомогательные и организационные процессы могут
D
C/T I/AS
D C/T I/AS
D C/T
Рис.2.4. Пример эволюционной модели
Блок 1
R1
R2
Блок 2
Блок N
I/AS R3
55
выполняться параллельно с процессом разработки и накапливать сведения по данным
количественных и качественных оценок на процессах разработки.
При этом подходе учитываются такие факторы риска:
– реализация всех возможностей системы сразу;
– ограниченные ресурсы (людские, финансовые) заняты разработкой в течение
длительного времени.
Преимущества применения данной модели ЖЦ состоит в следующем:
– проведение быстрой реализация некоторых возможностей системы;
– промежуточный продукт может использоваться на следующем процессе;
– в системе выделяются отдельные части для реализации их в отдельности;
– возможность увеличения финансирования системы;
– обратная связь устанавливается с заказчиком для уточнения требований;
– упрощение внесения изменений.
Модель развивается в направлении привлечения к разработке новых разработчиков и
механизмов прототипирования для моделирования функциональности,
нефункциональных требований (несанкционированного доступа, аутентификации и
др.).
2.5. Стандартизованная модель системы
Типичный ЖЦ разработки системы начинается с формулировки идеи или потребности,
проходит все процессы разработки, производства, эксплуатации и сопровождения
системы. ЖЦ в практике программирования обычно делиться на этапы, процессы.
Каждый процесс характеризуется видами деятельности и задачами, которые
выполняются на нем. Переход от одного процесса к другому должен быть
санкционирован (определены входные и выходные данные).
Модель общего стандартизованного ЖЦ, как правило, включает в себя следующие
процессы:
– определение требований;
– разработка (проектирование);
– верификация, валидация, тестирование;
– изготовление;
– эксплуатация;
– сопровождение.
Данной модели соответствует все виды деятельности, которые начинаются с
разработки идеи проблемы или концепции программного продукта и кончая его
изготовлением. Стандарт ISO/IEC 12207 объединяет эти виды деятельности в
основные, организационные и вспомогательные процессы, которые и составляют ЖЦ
ПО.
Процессы ЖЦ приобретения, поставки и разработки используются для анализа и
определения системных требований, решений верхнего уровня проектирования
системы, и предварительного определения требований к компонентам системы,
включая ПО. Процесс разработки может быть использован для анализа, демонстрации,
валидации, тестирования, прототипирования требований и проектных решений.
На этом этапе проектирования разрабатывается техническое, программное,
организационное обеспечение системы, а также проектируются, разрабатываются,
56
интегрируются, тестируются и оцениваются компоненты системы. Результатом этого
процесса является система, которая соответствует нужному продукту.
Исходный стандарт разработан так, чтобы его можно было применить полностью или
частично. Процессы, действия и задачи основных процессов отбираются,
адаптируются и применяются для разработки или модификации ПО. Процесс
проектирования может включать одну или более итераций процесса разработки.
Результатом являются основные требования к ПО, проект и его реализация.
Если разрабатываемое ПО является частью системы, то могут понадобиться все
действия процесса разработки, а если – автономное ПО, то все действия на уровне
системы могут не понадобиться.
Во время процесса производство – изготовление спроектированная и разработанная
система изготавливается для заказчика или для покупателей. Целью процесса
является производство и установка работающей системы у заказчика для
сопровождения. Для ПО данный процесс заключается в копировании изготовленного
ПО и документации на соответствующие носители для различных пользователей. К
видам деятельности на процессе относится – управление реализацией и конфигурацией.
Другие вспомогательные процессы и действия могут применяться при необходимости.
Изготовленная система передается заказчику или продается покупателям. Период
развертывания системы начинается с поставки первой работающей ее версии
заказчику. Продажа системы начинается с первой версии системы, которая
поставляется всем покупателям и заканчивается изъятием с рынка. Другие процессы
(приобретения, поставки и разработки) могут использоваться при инсталляции и
проверки разработанной или модифицированной системы.
Процесс эксплуатации включает использование системы пользователями и
покупателями и заканчивается, когда система больше не удовлетворят пользователей и
она удаляется из эксплуатации.
Во время сопровождения система модифицируется, вследствие обнаруженных
ошибок и недостатков в ее разработке либо по требованиям пользователя, которому
желает ее адаптировать к новой среде или усовершенствовать отдельные функции
системы. Данный процесс включает обеспечение логической, технической и
программной документации пользователю.
Процесс удаление системы означает снятие ее с обслуживания, удаление ее архивов и
носителей кодов системы.
2.6. Сопоставление модели ЖЦ стандарта ISO/IEC 12207 и областей –
процессов SWEBOK
Каждая область знаний SWEBOK по существу соответствует отдельным процессам,
которые определены в стандарте 12207. В связи с этим проведен сравнительный анализ
модели областей (процессов) SWEBOK и модели процессов ЖЦ этого стандарта с
целью сопоставления задач процессов стандарта и основных задач областей знаний
SWEBOK. В этих целях рассмотрим сначала соответственно их процессы.
57
2.6.1. Характеристика процессов стандарта
Процессы данного стандарта разбиты по группам: основные, вспомогательные и
организационные процессы.
К основным процессам стандарта относятся:
– приобретения (acquisition),
– поставки (supply),
– разработки (development),
– эксплуатации (operation),
– сопровождения (maintenance).
Процесс приобретения инициирует ЖЦ ПО и определяет действия организации-
покупателя (или заказчика), которая приобретает автоматизированную систему,
программный продукт или сервис.
Процесс поставки определяет действия предприятия - поставщика, которое снабжает
покупателя системой, программным продуктом или сервисом.
Процесс разработки определяет действия предприятия - разработчика, которое
разрабатывает программный продукт.
Процесс эксплуатации определяет действия предприятия-оператора, которое
обеспечивает обслуживание системы (ПО) в процессе ее эксплуатации пользователями
(консультирование пользователей, изучение их потребностей с точки зрения
удовлетворения их системой и т.д.)
Процесс сопровождения определяет действия организации, выполняющей
сопровождение программного продукта (управление модификациями, поддержку
текущего состояния и функциональной пригодности, инсталляцию и удаление
программного продукта на вычислительной системе пользователя).
К вспомогательным процессам стандарта относятся стандарты:
– документирования (documentation),
– управления конфигурацией (configuration management),
– обеспечения качества (quality assurance),
– верификации (verification),
– валидации (validation),
– совместного анализа (оценки) (joint review),
– аудита (audit),процесс решения проблем (problem resolution).
Вспомогательные процессы поддерживают реализацию основных процессов и
обеспечивают требуемое качество ПО. Они инициируются другими процессами.
К организационным процессам стандарта относятся процессы:
– управления (management),
– создания инфраструктуры (infrastructure),
– усовершенствования (improvement),
– обучения (training).
За каждый процесс стандарта отвечает определенный участник разработки или
руководитель. Для каждого из процессов стандарта определены виды деятельности
(действия - activity) и задачи, которые в него входят, определена совокупность
результатов видов деятельности и задач, а также некоторые специфические
требования. В табл.1 приведено общее количество определенных в стандарте процессов
(17), действий (74) и задач (232).
Таблица 1
58
Общий перечень процессов ЖЦ стандарта 12207
Класс Процесс Действие Задача
Основные процессы 5 35 135
Вспомогательные процессы 8 25 70
Организационные процессы 4 14 27
Итого 17 74 232
Из этого множества стандартов далее будут сравниваться только те процессы, которые
имеют аналоги областям знаний в ядре знаний SWEBOK.
2.6.2. Характеристика модели процессов в ядре SWEBOK
В ядре знаний SWEBOK определено 10 областей знаний, пять из них по своим задачам
и выполняемым действиям соответствуют основным процессам ЖЦ стандарта.
Остальные пять областей ядра можно отнести к числу процессов обеспечения и
управления разработкой программного продукта, в части верификации, сбора данных
для оценки качества и др., начиная от разработки требований и кончая сопровождением
программного продукта. И хотя ядро знаний явно не содержит названий процессов,
функционально они соответствуют общепринятым процессам разработки и стандарту,
а именно отдельным основным, вспомогательным и организационным процессам.
Первые пять областей ядра знаний SWEBOK по своему содержанию соответствуют
следующим процессам:
– разработка требований;
– проектирование;
– конструирование;
– тестирования;
– сопровождение.
Эти процессы задают последовательность задач и действий при разработке разных
типов ПС с применением современных методов и средств, которые представлены в
ядре знаний.
В табл.2 приведен сопоставительный перечень основных процессов, их задач,
приведенных в SWEBOK и ЖЦ стандарте. При этом процессы приобретения и
поставки из состава основных процессов исключаются, поскольку они не относятся к
процессам разработки программных систем.
Остальные пять областей, которые определены в ядре знаний SWEBOK, по своим
функциям соответствуют отдельным вспомогательным и организационным процессам
ЖЦ стандарта:
– управление конфигурацией;
– управление инженерией;
– управление качеством
– процесс инженерии;
– методы и средства инженерии ПО;
– управление качеством.
59
Данные процессы предназначены для управления программным проектом,
конфигурацией и методами и средствами обеспечения инженерии программирования, а
именно оценки качества процессов, промежуточных результатов, полученных на
процессах, и конечного продукта.
Таблица 2
Задачи основных процессов в SWEBOK и ЖЦ
Области–
процессы
Задачи областей
SWEBOK
Задачи процессов ЖЦ
в стандарте
Разработка
Требований
Инженерия требований.
Выявления требований.
Анализ требований.
Спецификация требований.
Проверка требований.
Управления требованиями.
Подготовка заказа
Выявление требований
Анализ требований к системе
Анализ требований к ПО
Описание документа
.
Проектирование
ПО
Разработка архитектура
ПО
Структура ПО.
Нотация.
Анализ качества
проектирования.
Стратегия и методы
проектирования.
Проектирование архитектуры
системы
Проектирование архитектуры ПО
Детальное проектирование ПО.
Кодирование и тестирование ПО.
Конструирование
ПО
Снижение сложности.
Предупреждение
отклонений от стиля.
Структуризация системы
для проверок.
Использование внешних
стандартов.
Конструирование структуры
системы
Кодирование элементов
структуры и ПО
Интеграция элементов.
Применение стандартов
программной инженерии.
Тестирование ПО Уровни тестирования.
Техники тестирования.
Метрики тестирования.
Управления
тестированием.
Тестирование ПО.
Интеграционное тестирование.
Квалификационное тестирование.
Интеграция системы.
Системное тестирование.
Установка ПО.
Обеспечение приемки ПО.
Сопровождение
ПО
Процесс сопровождения.
Ключевые вопросы
сопровождения.
Техники сопровождения.
Инсталляция ПО
Внедрение процесса.
Анализ проблем и модификаций.
Реализация модификаций.
Анализ сопровождения.
Миграция (перемещение) ПО.
Удаление ПО.
Эксплуатация
системы
Методы обеспечения
эксплуатации системы
Внедрение процесса.
Функциональное тестирование.
Эксплуатация системы.
Поддержка пользователя.
60
Эти процессы определяют также задачи поиска, обнаружения ошибок и внесения
изменений в требования и продукты. В табл.3 приведен перечень областей ядра
SWEBOK, их задач и соответствующих задач организационных процессов ЖЦ
стандарта.
Таблица 3
Задачи организационных и дополнительных процессов в SWEBOK и ЖЦ
Области –
процессы
Задачи областей
SWEBOK
Задачи процессов ЖЦ
стандарта
Управление
конфигурацией
Процесс управления
конфигурацией.
Идентификация элементов.
Контроль конфигурации.
Учет статуса.
Аудит.
Управления версиями.
Внедрение процесса.
Определение конфигурации.
Контроль конфигурации.
Учет состояния конфигурации.
Оценка конфигурации.
Управление реализацией и
поставкой.
Управление
проектом
Организационное
управление.
Управления процессами и
проектом.
Планирование проектом.
Инженерия измерения ПО.
Управление риском.
Инициация и определение
области применения.
Планирование.
Выполнение и контроль.
Анализ управления проектом:
– технический анализ;
– аудит (ревизия).
Управление
качеством
Концепция качества ПО.
Определение и
планирование качеством.
Верификация и валидация.
Измерение в анализе
качества ПО.
Внедрение процесса.
Обеспечение производства.
Обеспечение качества.
Процесс верификации.
Процесс валидации.
Анализ и оценивание качества.
Методы и
средства
инженерии
Методы инженерии.
Инструменты инженерии.
Процесс усовершенствования:
– определение процесса;
– оценка процесса;
– улучшение процесса.
Процесс
инженерии ПО
Инфраструктура процесса.
Определения процесса.
Измерения процесса.
Анализ проекта.
Выполнения изменений.
Оценки стоимости и затрат.
Внедрение процесса.
Создание инфраструктуры.
Сопровождение
инфраструктуры.
Завершение.
Контрольные вопросы и задания
1. Охарактеризуйте понятие модели ЖЦ и назовите их виды.
2..Дайте характеристику каскадной модели.
3. Определите отличительную особенность спиральной модели ЖЦ.
4. Какие общие черты имеют инкрементная и эволюционная модели?
5. Дайте перечень процессов ЖЦ стандарта и назовите их назначение.
6. Как построить новую модель ЖЦ на основе стандарта?
7. Дайте классификацию процессов ЖЦ стандарта.