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

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

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

При разработке стандартов ЖЦ и их практическом применении возник целый ряд проблем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процессы жизненного цикла ПП (стандарт 150/1 ЕС 12207)

Рис. 2.1. Процессы жизненного цикла ПП (стандарт 150/1 ЕС 12207)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 1. Процесс должен быть своего рода модулем ЖЦ, т.е. каждый процесс должен выполнять только собственную функцию в ЖЦ, а интерфейсы между двумя любыми процессами должны быть минимальны.
  • 2. Каждый процесс должен быть привязан к архитектуре системы.
  • 3. Если процесс Л вызван процессом В и только процессом В, тогда Л принадлежит к В.
  • 4. Если работа или задача вызвана более чем одним процессом, тогда она сама становится процессом.
  • 5. Должна быть возможность для проверки любого процесса, работы и задачи в модели ЖЦ.
  • 6. Каждый процесс должен иметь внутреннюю структуру, установленную в соответствии с тем, что должно выполняться.

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

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

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

ISO 15504. Процессы ЖЦ ПП. Стандарт ISO 12207 разрабатывался девять лет и достаточно быстро устарел. В 1998 г. вышел новый стандарт ISO/IEC TR15504: Information Technology — Software Process Assessment (Оценка процессов разработки ПО). В этом документе рассматриваются вопросы аттестации, определения зрелости и усовершенствования процессов жизненного цикла ПП. Один из разделов документа содержит новую классификацию процессов ЖЦ ПП, являющуюся развитием стандарта ISO 12207.

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

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

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

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

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

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

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

  • • управленческая (категория MAN);
  • • организационная (категория ORG).

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

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

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

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

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

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

 
< Пред   СОДЕРЖАНИЕ     След >