Определение жизненного цикла программного продукта

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

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

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

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

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

- различным типам ПО (ИС реального времени, бизнес-системы соответствовали различные требования;

- высокая динамика отрасли вела к быстрому устареванию стандартов;

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

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

Разрешением проблем стандартизации ЖЦ ПП явилась разработка и принятие в 1995 г. стандарта ISO/IEC 12207. В России он былпринят в 2000 г. под названием «ГОСТ Р ИСО/МЭК 12207 Процессы жизненного цикла программных средств.

Стандарт ISO/IEC 12207. Жизненный цикл ПП: структураи организация. Этот стандарт разрабатывался с учетом лучшего мирового опыта на основе ранее разработанных стандартов. Его основная идея состоит в том, что разработка и сопровождение ПП должныосуществляться так, как этого требует инженерная дисциплина. Следуя этой идее, был разработан каркас (framework), имеющий четкиесвязи с окружением системной инженерии – программным и техническим обеспечением, исполнителями и деловой практикой.

Основными результатамиразработки ISO 12207 являютсяединая терминология по разработке и применению ПП; разделениепонятий ЖЦ ПП и модели ЖЦ ПП; описание организации ЖЦ иего структуры (процессов); адаптация стандарта для построенияконкретных моделей ЖЦ.

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

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

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

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

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

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

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

Рисунок 2.1. Процессы жизненного цикла ПП (стандарт ISO/IEC).

 

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

Процесс приобретения инициирует ЖЦ ПП и определяет действия организации-покупателя (или заказчика), которая приобретает автоматизированную систему, программный продукт или сервис.

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

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

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

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

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

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

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

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

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

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

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

Адаптация стандарта ISO 12207. Адаптация стандарта подразумевает применение требований стандарта к конкретному проекту или проектам, например в рамках создания внутрикорпоративных регламентов ведения проектов ПО.

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

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

Необходимо отметить, что существует еще один стандарт жизненного цикла – ISO/IEC 15288 (выпущен в 2002 г.), освещающий вопросы организации процессов ЖЦ системного уровня (Life CycleProcesses – System) и включающий специальный процесс «Tailoring», т. е. настройку, адаптацию ЖЦ к конкретным требованиям и ограничениям, существующим или принятым в конкретной организации(подразделении) или для заданного проекта.

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

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

Альтернативой является формирование комплекса инструментальных средств под технологию, формализованную на базе одного изадаптированных стандартов ЖЦ ПП. Для снижения затрат и обеспечения качества выбранный стандарт ЖЦ следует адаптировать киндивидуальному проекту ПС. Должны быть определены характеристики окружения проекта, которые могут воздействовать на адаптацию. Этими характеристиками могут быть: функции ЖЦ информационной системы; требования системы и ПО; организационныеосновы коллективов специалистов, процедуры и стратегии их работы; размер, критичность и типы системы; число задействованногоперсонала и сторон-участников.

Применение требований ГОСТ Р ИСО/МЭК 12207 к конкретному проекту – адаптация стандарта – состоит из следующего видаработ:

- определение условий выполнения проекта;

- запрос исходных данных для адаптации;

- выбор процессов, работ и задач;

- документирование решений по адаптации и их обоснований.

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

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

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

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

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

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

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

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

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

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

3. Если процесс А вызван процессом В и только процессом В, тогда А принадлежит к В.

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

5. Должна быть возможность для проверки любого процесса, работы и задачи в модели ЖЦ.

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

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

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

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

Стандарт ISO 15504. Процессы ЖЦ ПП. Стандарт ISOразрабатывался 9 лет и достаточно быстро устарел. В 1998 г. ВышелновыйстандартISO/IECTR 15504: InformationTechnology–SoftwareProcess Assessment (Оценка процессов разработки ПО). В этом документе рассматриваются вопросы аттестации, определения зрелостии усовершенствования процессов жизненного цикла ПП. Один изразделов документа содержит новую классификацию процессов ЖЦПП, являющуюся развитием стандарта ISO.

Все процессы стандарта ISO 15504 принадлежат к одному из следующих типов:

- основной (процесс из 12207);

- расширенный (расширение процесса из 12207);

- новый (процесс, не описанный в 12207);

- составляющий (часть процесса из 12207);

- расширенный составляющий (расширенная часть процесса из 12207).

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

- потребитель-поставщик (категория CUS);

- инженерная (категория ENG).

Группа вспомогательных процессов представлена одной категорией:

- вспомогательная (категория SUP).

В группу организационных процессов введены две категории:

- управленческая (категория MAN);

- организационная (категория ORG).

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

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

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

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

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

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

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

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