Тема 4. Жизненный цикл пи (жцпи)

Обращается внимание на стадии и этапы ЖЦПИ, характеристику, содержание и средства выполнения основных работ и их технологическую последовательность на различных этапах ЖЦПИ. Стандартизация работ, этапов и стадий ЖЦПИ в соответствии с ГОСТ Р ИСО/МЭК 12207 «Процессы жизненного цикла программных средств» и ЕСПД. Из рекомендуемой литературы следует обратить внимание на материалы источников [3,4,9,17].

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

В настоящее время наиболее распространенным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes». Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО (его российский аналог ГОСТ Р ИСО/МЭК 12207-99 введен в действие в июле 2000 г). В данном стандарте процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.

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

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

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

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

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

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

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

Основными процессами являются:

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

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

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

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

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

Вспомогательные процессы

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

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

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

2. Процесс управления конфигурацией. Определяет работы по управлению конфигурацией программного продукта при реализации другого процесса.

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

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

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

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

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

8. Процесс решения проблемы. Определяет процесс анализа и устранения проблем (включая несоответствия), независимо от их характера и источника, которые были обнаружены во время осуществления разработки, эксплуатации, сопровождения или других процессов.

Рис.4.1. Организационные процессы жизненного цикла

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

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

2. Процесс создания инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.

3. Процесс усовершенствования. Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.

4. Процесс обучения. Определяет работы по соответствующему обучению персонала.

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

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель ЖЦ ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий создания ПО. Он описывает структуру процессов ЖЦ, не конкретизируя в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1) стадии;

2) результаты выполнения работ на каждой стадии;

3) ключевые события — точки завершения работ и принятия решений.

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

В ГОСТ Р ИСО/МЭК ТО 15271-2002 «Руководство по применению ГОСТ Р ИСО/МЭК 12207» отмечается, что существует множество моделей жизненного цикла, но три из них — фундаментальные. Этими фундаментальными моделями жизненного цикла являются:

• каскадная;

• инкрементная;

• эволюционная.

Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла. При этом конкретную модель жизненного цикла следует выбирать так, чтобы процессы, работы и задачи из ГОСТ Р ИСО/МЭК 12207 были связаны между собой и определены их взаимосвязи с предшествующими процессами, работами (видами деятельности) и задачами (заданиями). Три фундаментальные модели жизненного цикла с присущими им недостатками (аргументами против их применения) и преимуществами (выгодами) должны быть рассмотрены при выборе применяемой модели жизненного цикла для проекта.

- Каскадная модель

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

• установление потребностей пользователя;

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

• проектирование системы;

• изготовление системы;

• испытание;

• корректировка;

• поставка или использование.

При применении такого принципа разработки каждого программного объекта соответствующие работы и задачи процесса разработки обычно выполняют последовательно (см. рисунок 4.2). Однако они могут быть частично выполнены параллельно в случаях перекрытия последовательных работ.

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

Недостатки

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

а) требования к объектам определены недостаточно четко;

b) система обычно слишком велика, чтобы все работы по ее созданию выполнять однократно;

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

d) возможные текущие изменения требований к системе;

е) ограниченность ресурсов, например средств или персонала;

f) промежуточный продукт может быть непригоден для использования.

Рис.4.2

Преимущества

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

а) однократное представление всех возможностей (характеристик) системы;

b) необходимость только единственной фазы перехода от старой системы к новой.

- Инкрементная модель

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

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

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

Недостатки

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

а) требования к объектам определены недостаточно четко;

b) предусмотрены сразу все возможности системы;

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

d) возможные текущие изменения требований к системе;

е) привлечение ресурсов (средств или персонала) на длительный период ограничено.

Преимущества

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

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

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

с) естественное разделение системы на наращиваемые компоненты (инкременты);

d) возможности наращивания привлекаемого персонала и средств.

Рис.4.3

- Эволюционная модель

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

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

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

Недостатки

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

а) все возможности системы предопределены изначально;

Рис.4.4

Преимущества

b) ограниченные возможности долговременного привлечения ресурсов (средств или персонала).

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

а) изначальное определение возможностей системы;

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

с) естественное разделение системы на наращиваемые компоненты (инкременты);

d) привлечение персонала и средств по мере необходимости;

е) необходимая обратная связь с пользователем для полного понимания требований;

f) упрощение надзора за изменением технологии.

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

В середине 1980-х годов Барри Боэм предложил вариант итерационной модели под названием «спиральная модель» (spiral model) (рис. 4.5).

Принципиальные особенности спиральной модели:

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

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

• идентификация и анализ риска на каждой итерации;

• использование каскадной модели для реализации окончательного прототипа;

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

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

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

Рис.4.5

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

Достоинствами спиральной модели являются:

• ускорение разработки (раннее получение результата за счет прототипирования);

• постоянное участие заказчика в процессе разработки;

• разбиение большого объема работы на небольшие части;

• снижение риска (повышение вероятности предсказуемого поведения системы).

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

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

• сложность планирования (определения количества и длительности итераций, оценки затрат и рисков);

• сложность применения модели с точки зрения менеджеров и заказчиков (из-за привычки к строгому и детальному планированию);

• напряженный режим работы для разработчиков (при краткосрочных итерациях).

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

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

Контрольные вопросы:

1. Каково назначение основных процессов ЖЦПИ?

2. Каково назначение вспомогательных процессов ЖЦПИ?

3. Каково назначение организационных процессов ЖЦПИ?

4. В чем отличие каскадной модели ЖЦПИ от итерационной?

5. В чем суть инкрементной модели ЖЦПИ?