ТРПО_теория / Lect_trpo / lavrishcheva_petrukhin

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

Определение требований

Проектирование системы Реализация системы

Тестирование системы на проверку правильности ( верификация)

Тестирование системы на соответствие требованиям

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

Рис. 2.1. Каскадная модель ЖЦ разработки программных систем

При таком подходе необходимо учитывать следующие факторы риска:

–требования недостаточно хорошо представлены;

–система слишком большая по объему, чтобы быть реализованной в целом;

–быстрые изменения в технологии и в требованиях;

–ограниченные ресурсы (людские, программные и др.);

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

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

–все возможности системы реализуются одновременно;

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

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

2.2. Инкрементная модель ЖЦ

Эту заложена еще называют нарастающей моделью, суть которой состоит в возможности усовершенствования продукта (рис.2.2). Разработка начинается с предоставления набора требований и реализации системы путем последовательного конструирования и фиксации промежуточных продуктов (1, …, N) системы, постепенно приближающейся к итоговой системе (рис.2.2).

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

51

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

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

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

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

2.3. Спиральная модель

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

.

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

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

Проект

Версия 3 Версия 2 Версия1

Реализация

Рис.2.3. Спиральная модель ЖЦ разработки программных систем

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

оценку его правильности и принятия решения двигаться на следующий виток или опуститься на нижний для доработки.

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

53

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

2.4.Эволюционная модель ЖЦ

В случае эволюционной модели система разрабатывается в виде последовательности блоков структур (конструкций). В отличие от инкрементной модели ЖЦ, подразумевается, что требования устанавливаются частично и уточняются в каждом последующем промежуточном блоке структуры системы (рис.2.4.).

Блок 1

R1 D C/T I/AS

Блок 2

R2 D C/T I/AS

Блок N

Рис.2.4. Пример эволюционной модели

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

–R (Requirements) требования,

–C/T (Coding/Testing) кодирование, тестирование,

–D (Design) проектирование,

–I/AS (Installation/acceptance) инсталляция, сопровождение.

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

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

54

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

При этом подходе учитываются такие факторы риска:

–реализация всех возможностей системы сразу;

–ограниченные ресурсы (людские, финансовые) заняты разработкой в течение длительного времени.

Преимущества применения данной модели ЖЦ состоит в следующем:

–проведение быстрой реализация некоторых возможностей системы;

–промежуточный продукт может использоваться на следующем процессе;

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

–возможность увеличения финансирования системы;

–обратная связь устанавливается с заказчиком для уточнения требований;

–упрощение внесения изменений.

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

2.5. Стандартизованная модель системы

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

Модель общего стандартизованного ЖЦ, как правило, включает в себя следующие процессы:

–определение требований;

–разработка (проектирование);

–верификация, валидация, тестирование;

–изготовление;

–эксплуатация;

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

Данной модели соответствует все виды деятельности, которые начинаются с разработки идеи проблемы или концепции программного продукта и кончая его изготовлением. Стандарт ISO/IEC 12207 объединяет эти виды деятельности в основные, организационные и вспомогательные процессы, которые и составляют ЖЦ ПО.

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

На этом этапе проектирования разрабатывается техническое, программное, организационное обеспечение системы, а также проектируются, разрабатываются,

55

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

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

Если разрабатываемое ПО является частью системы, то могут понадобиться все действия процесса разработки, а если – автономное ПО, то все действия на уровне системы могут не понадобиться.

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

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

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

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

Процесс удаление системы означает снятие ее с обслуживания, удаление ее архивов и носителей кодов системы.

2.6. Сопоставление модели ЖЦ стандарта ISO/IEC 12207 и областей – процессов SWEBOK

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

56

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

57

Общий перечень процессов ЖЦ стандарта 12207

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

2.6.2. Характеристика модели процессов в ядре SWEBOK

В ядре знаний SWEBOK определено 10 областей знаний, пять из них по своим задачам и выполняемым действиям соответствуют основным процессам ЖЦ стандарта. Остальные пять областей ядра можно отнести к числу процессов обеспечения и управления разработкой программного продукта, в части верификации, сбора данных для оценки качества и др., начиная от разработки требований и кончая сопровождением программного продукта. И хотя ядро знаний явно не содержит названий процессов, функционально они соответствуют общепринятым процессам разработки и стандарту, а именно отдельным основным, вспомогательным и организационным процессам.

Первые пять областей ядра знаний SWEBOK по своему содержанию соответствуют следующим процессам:

–разработка требований;

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

–конструирование;

–тестирования;

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

Эти процессы задают последовательность задач и действий при разработке разных типов ПС с применением современных методов и средств, которые представлены в ядре знаний.

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

Остальные пять областей, которые определены в ядре знаний SWEBOK, по своим функциям соответствуют отдельным вспомогательным и организационным процессам ЖЦ стандарта:

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

–управление инженерией;

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

–процесс инженерии;

–методы и средства инженерии ПО;

–управление качеством.

58

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

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

Таблица 3 Задачи организационных и дополнительных процессов в SWEBOK и ЖЦ

Контрольные вопросы и задания

1. Охарактеризуйте понятие модели ЖЦ и назовите их виды. 2..Дайте характеристику каскадной модели.

3.Определите отличительную особенность спиральной модели ЖЦ.

4.Какие общие черты имеют инкрементная и эволюционная модели?

5.Дайте перечень процессов ЖЦ стандарта и назовите их назначение.

6.Как построить новую модель ЖЦ на основе стандарта?

7.Дайте классификацию процессов ЖЦ стандарта.

60