Процессы эксплуатации и сопровождения

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

Процесс сопровождения и персонал сопровождения включаются:

- при сопровождении и поддержке программного продукта в эксплуатационной готовности и

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

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

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

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

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

Требования по управлению документами включают в себя планы, описанные в процессе документирования.

Реализация принципов управления качеством. В ГОСТ 12207 реализованы принципы управления качеством и сделано это тремя основными способами.

Интеграция качества в жизненный цикл. ГОСТ 12207 устанавливает требования к всеобъемлющему интегрированному набору процессов, охватывающих жизненный цикл программного средства. Этот стандарт обеспечивает для каждого процесса доступ к циклу «план — реализация — проверка — акт» (plan — do — check — act) с помощью процесса усовершенствования. При этом все работы, связанные с качеством трактуются как неотъемлемая часть жизненного цикла программного средства и входят в соответствующие процессы жизненного цикла. Таким образом, за каждым процессом и персоналом, отвечающим за его реализацию, в рамках заданного процесса закреплены работы, связанные с качеством.

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

Процесс усовершенствования. В ГОСТ 12207 определён процесс усовершенствования для дальнейшего повышения качества работ организации в целом, независимо от договорных обязательств.

Процессы, связанные с качеством. Особое внимание в ГОСТ 12207 уделено вспомогательным процессам жизненного цикла, связанным с качеством ПС. По ГОСТ 12207 это – следующие процессы:

- обеспечение качества;

- верификация;

- аттестация (валидация);

- совместный анализ;

- аудит.

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

- адаптация процессов, связанных с качеством, проведенная до начала реализации проекта, а также

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

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

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

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

Сопровождение ПС. Требования к процессу сопровождения программных систем уточняет стандарт ГОСТ Р ИСО/МЭК 14764-2002 Информационная технология СОПРОВОЖДЕНИЕ ПРОГРАММНЫХ СРЕДСТВ (Information technology. Software maintenance). В нём детализирован процесс сопровождения, кратко описанный в ГОСТ 12207. Основные термины понятия этого стандарта приводятся в Приложении Б.

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

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

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

Область применения и назначение. Область применения стандарта ГОСТ 14764 охватывает сопровождение (maintenance) различных программных сиситем, при использовании одинаковых ресурсов сопровождения.

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

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

Стандарт не описывает эксплуатацию программного средства и эксплуатационные функции, например резервирование, восстановление, системное администрирование, которые обычно выполняет персонал, эксплуатирующий программную систему. Заметим, что стандарта по эксплуатации программных средств пока нет, но программные системы, эффективно поддерживающие процесс эксплуатации уже существуют (например, линейка продуктов Unicenter от Computer Associates) и активно внедряются на корпоративных предприятиях.

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

Стандарт определяет также использование процесса сопровождения в процессах заказа и эксплуатации.

Настоящий стандарт не предназначен для временно или эпизодически используемых программных средств (продуктов).

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

Объектами сопровождения являются компьютерные программы, программы в машинных кодах, данные и соответствующие документы. В состав сопровождаемых продуктов могут входить тестовые программные средства, тестовые базы данных, среда тестирования программного средства (СТПС, STE) или среда программной инженерии (СПИ, SEE).

Стандарт используют во всей деятельности по сопровождению независимо от модели жизненного цикла программного средства (каскадной, инкрементной, эволюционной) или применительно к методу разработки (например, методам ускоренной разработки приложений (RAD), прототипирования, макетирования).

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

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

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

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

В процессе решения проблем (по ГОСТ 12207) анализируют и разрешают возникшие проблемы. В этом процессе также определяют, отражают ли представленные ПР и ОП возникшие проблемы (несоответствия) или потребности в модернизации продукта.

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

Рис. 2. Предложение о модификации (изменении) ПС

Сопровождение может быть востребовано независимо от модели жизненного цикла разработки (например, каскадной, инкрементной, эволюционной) или метода разработки (например, ускоренной разработки приложений (RAD), прототипирования, макетирования). Например, при выпуске новой усовершенствованной программной конструкции (инкремента) продолжается разработка продукта в целом, но может быть востребовано сопровождение для ввода данной конструкции в действие (инсталляции).

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

Типы сопровождения. Корректирующее сопровождение (corrective maintenance) – связано с изменениями, вызванными необходимостью устранения (исправления) фактических ошибок в программном продукте. Корректирующее сопровождение проводят в случае несоответствия программного продукта установленным требованиям.

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

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

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

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

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

Соглашения при сопровождении. Заказчик может:

- заключить соглашение с разработчиком оригинала программного средства о проведении им сопровождения данного средства,

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

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

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

- поставка модернизированных документов,

- обучение соответствующего персонала.

Поставщик должен:

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

- выполнять эти процедуры во время сопровождения и

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

Использование опытных данных по конкретным процедурам повышает эффективность их применения.

Должен быть составлен план сопровождения, где должны быть указаны:

- объекты сопровождения,

- процедуры сопровождения и

- период сопровождения каждого объекта.

Поставщик (сопроводитель) и заказчик должны изначально:

- заключить соглашение по сопровождению и

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

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

- основные правила, используемые для определения того, когда программное средство может быть локально корректировано, а когда необходима новая базовая линия с использованием для ее подготовки и инсталляции процесса разработки по ГОСТ 12207;

- описания типов редакций (версий, выпусков) в зависимости от частоты их появления или их влияния на эксплуатацию программного средства (например, экстренные редакции, периодические редакции);

- способы информирования заказчика о состояниях вносимых (текущих) или намечаемых изменений;

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

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

Инструментальные средства сопровождения. Потенциальными средствами, определяющими стоимость сопровождения программных систем, являются инструментальные CASE-средства. Данный инструментарий обеспечивает проведение работ по сопровождению. CASE представляют собой взаимосвязанный набор инструментальных средств, обеспечивающих все аспекты разработки и сопровождения программных систем. Взаимосвязанный набор CASE-средств должен быть скомпонован в виде среды программной инженерии (СПИ), представляющей собой методы, политики, руководства и стандарты, обеспечивающие проведение работ по сопровождению программных систем. Сопроводителю также должна быть указана среда тестирования программной системы (СТПС) для проведения тестирования модифицированной программной системы вне среды её эксплуатации. СПИ обеспечивает инструментарий для изначальной разработки и модификации программных систем. СТПС определяет среду тестирования.

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

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

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

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

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

Функции, выполняемые сопроводителем в процессе разработки программного продукта:

- планирование обеспечения всесторонней поддержки программного продукта;

- гарантирование всесторонней поддержки (supportability) программного продукта;

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

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

- участвовать в различных обсуждениях (анализах);

- анализировать тексты соответствующих программ;

- трассировать реализацию требований;

- проводить верификацию и аттестацию (валидацию).

Сопровождаемость. Сопровождаемость (maintainability) и сопровождение программной системы являются важными аспектами функциональной надежности (dependability) такой системы. Сопровождаемость является важной характеристикой программной системы для заказчика, поставщика и пользователя. По ГОСТ 12207 требования к сопровождаемости должны быть включены в работу «подготовка» из процесса заказа, а их выполнение следует оценивать в процессе разработки. Изменения в проекте должны быть отслежены при разработке с точки зрения их влияния на сопровождаемость. Для определения и оценки качества программной системы должны быть использованы различные показатели (метрики). При этом важны и качественные и количественные оценки. Сопровождаемость является характеристикой качества программной системы, отражающей скорость и легкость (простоту) внесения в неё изменений после её ввода в эксплуатацию (По ГОСТ 9126).

Сопровождаемость и процесс разработки. Сопровождаемость должна быть определена до разработки программной системы. Должно быть подготовлено соответствующее соглашение между заказчиком и поставщиком как часть работы «подготовка» из процесса заказа. Разработчик должен подготовить план сопровождаемости, в котором должны быть отражены:

- конкретные методы обеспечения сопровождаемости ПС,

- соответствующие ресурсы,

- последовательность работ.

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

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

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

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

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

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

- мобильность языка;

- удобочитаемость языка;

- стабильность языка;

- самодокументируемость;

- допустимость программных «уловок», понижающих читаемость программ;

- возможности структурирования программ;

- легкость создания новых редакций (версий);

- возможности структурирования данных;

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

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

- возможности тестирования во время компиляции и прогонов программ;

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

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

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

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

- требования к передаче технических и программных средств, данных и знаний (опыта) от разработчика к сопроводителю;

- задачи сопроводителя, необходимые для реализации стратегии сопровождения программного средства, например,

- создание документов по сопровождению (если их нет)

- комплектование персонала,

- обучение персонала,

- ввод в действие программного средства,

- распространение опыта по сопровождению.

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

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

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

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

- установить приоритеты ПР или ОП.

Сопроводители должны документально описать ПС в соответствии с при веденными выше рекомендациями. Должны быть обновлены или разработаны (при необходимости) следующие документы:

- технические требования (спецификации),

- руководства программиста по сопровождению,

- руководства пользователя и

- руководства по вводу в действие (инсталляции).

Имеется ряд факторов, влияющих на создание или обновление документов. Некоторыми из них являются:

- доступ к исходным программам,

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

- наличие среды тестирования ПС (СТПС).

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

- концепцию сопровождения;

- план сопровождения;

- анализ ресурсов сопровождения.

Концепция сопровождения. Описание концепции сопровождения должно быть первым шагом при разработке политики сопровождения ПС. Концепция сопровождения должна быть разработана сразу же при первом выпуске исходного ПС.

Концепция сопровождения должна отражать:

- область сопровождения ПС;

- практическое применение (адаптацию) данного процесса;

- определение организаций (лиц), ответственных за сопровождение;

- оценку стоимости сопровождения.

Концепцию сопровождения документально оформляют в плане сопровождения.

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

- типы выполняемого сопровождения;

- сопровождаемый уровень документов;

- реакцию (чувствительность) на сопровождение;

- обеспечиваемый уровень обучения персонала;

- обеспечение поставки продукта;

- организацию справочной службы («горячей линии»).

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

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

Назначение (выбор) сопроводителя должно быть основано на ряде факторов, включая:

- срок службы программного средства;

- размер долгосрочных затрат;

- размер первоначальных затрат;

- наличие соответствующего места;

- квалификацию персонала;

- работоспособность программной системы;

- программу (график) сопровождения;

- знание предметной области применения ПС.

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

- проезда до места расположения пользователя;

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

- СПИ и СТПС и их ежегодного сопровождения;

- персонала (зарплата и премии).

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

Планирование сопровождения. Целью планирования сопровождения является:

- подготовка плана работ по сопровождению и

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

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

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

План сопровождения должен определять:

- причины необходимости сопровождения;

- исполнителей данных работ;

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

- как должны быть выполнены данные работы;

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

- место проведения сопровождения;

- время начала сопровождения.

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

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

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

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

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

Финансовые ресурсы. Третьим и последним аспектом ресурсов являются финансовые ресурсы. Для обеспечения эффективного сопровождения программного продукта сопроводитель должен получить финансирование для:

- выплаты зарплаты персоналу;

- обучения персонала (2—3 недели в год на каждого человека);

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

- командировок;

- публикации (издания) соответствующих материалов;

- технических и программных средств СПИ и СТПС;

- модернизации технических и программных средств СПИ и СТПС.

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

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

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

Процесс сопровождения охватывает следующие работы:

1. подготовка процесса;

2. анализ проблем и изменений (модификаций);

3. внесение изменений;

4. проверка и приемка при сопровождении;

5. перенос;

6. снятие с эксплуатации.

Исходные данные преобразуют или используют в работах по сопровождению для получения выходных результатов. Рекомендуется проводить соответствующий контроль с целью проверить корректность выходных результатов конкретной работы по сопровождению. Выходными результатами являются соответствующие данные или объекты, создаваемые при выполнении конкретной работы по сопровождению. Для обеспечения работ по сопровождению используют вспомогательные и организационные процессы (по ГОСТ 12207). Общая структура процесса сопровождения показана на рис. 3.

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

Рис. 3. Процесс сопровождения

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

- разработать планы и процедуры сопровождения;

- установить процедуры рассмотрения ПР и ОП;

- применить управление конфигурацией.

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

- должны быть установлены и документально оформлены критерии проведения испытаний (тестирования), оценки их результатов и измененных и неизмененных объектов (программных модулей, компонентов и элементов конфигурации) системы;

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

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

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

- документирования;

- обеспечения качества;

- совместного анализа.

- Выходными результатами данной работы являются:

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

- обновленные документы;

- измененные исходные программы;

- отчетность о тестировании;

- показатели, характеризующие внесенные изменения.

Обновленные документы должны включать в себя:

- обновленные документы на изменение (модификацию);

- подробный отчет о проведенном анализе;

- обновленные требования;

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

- обновленные учебные материалы.

Анализ проблем и изменений. При выполнении работы по анализу проблем и изменений (модификаций) сопроводитель:

- анализирует ПР и (или) ОП;

- дублирует или проверяет проблему;

- разрабатывает варианты реализации изменения (модификации);

- документально оформляет: ПР и (или) ОП, результаты их рассмотрения и варианты реализации изменений;

- проводит согласование выбранного варианта изменений.

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

Исходными данными для проведения работы по анализу проблем и изменений должны быть:

- ПР или ОП;

- базовая линия;

- информационный архив программного средства;

- системные документы

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

Исходными данными для проведения работы по внесению изменений должны быть:

- базовая линия;

- согласованное ПР или ОП;

- согласованные документы на изменение.

- Базовая линия должна включать в себя:

- описания системной архитектуры;

- документы конкретного предложения о модификации (изменении);

- исходные программы.

Согласованные документы на изменение должны включать в себя:

- отчет об анализе влияния изменений;

- выходные результаты работы по анализу проблем и изменений.

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

- определены элементы в существующей системе, подлежащие изменению;

- определены элементы конкретного интерфейса, затрагиваемые данным изменением;

- определены документы, подлежащие обновлению;

- обновлен комплект документов разработки ПС (КДРПС).

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

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

Исходными данными для проведения работы по проверке и приемке при сопровождении являются:

- измененное программное средство;

- результаты тестирования внесенных изменений.

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

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

Контроль за рассматриваемой работой проводится с помощью вспомогательного процесса совместного анализа.

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

- обеспечения качества;

- верификации;

- аттестации (валидации);

- совместного анализа;

- аудита.

Выходными результатами данной работы являются:

- новая базовая линия, включающая в себя принятые изменения;

- отклоненные изменения;

- отчет о приемке;

- отчеты об обзорах (проверках) и аудитах;

- отчет о квалификационном тестировании программной системы.

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

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

- выполнить соответствующие действия,

- разработать и документально оформить этапы реализации переноса.

Задачи, решаемые сопроводителем для этой работы:

- проводит перенос в соответствии с ГОСТ 12207,

- разрабатывает план переноса,

- извещает пользователей,

- проводит обучение персонала,

- выдает предупреждение о завершении переноса,

- оценивает влияние новой среды и

- архивирует соответствующие данные.

Должны быть выполнены следующие этапы решения этих задач:

1. определены все добавляемые или изменяемые программные системы или данные;

2. проверено соответствие конкретных задач ГОСТу 12207.

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

В содержание плана должны быть включены:

- анализ и установление требований к переносу;

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

- настройка программного продукта и данных к новым условиям эксплуатации;

- выполнение переноса;

- верификация переноса;

- последующая поддержка прежней среды.

Уведомление о намерениях. Сразу же после завершения сопроводителем планирования переноса пользователям должно быть направлено уведомление о планах и работах по переносу объекта. Сопроводитель должен также представить пользователям план, процедуры и график (программу) переноса.

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

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

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

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

- возможность сохранения устаревшей технологии;

- переход на новую технологию путем создания новой ПС;

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

- разработка новой ПС для упрощения сопровождения;

- разработка новой ПС для обеспечения стандартизации;

- разработка новой ПС для обеспечения независимости продавца.

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

- определить необходимые для этого действия,

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

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

Сопроводитель, выполняющий снятие ПС эксплуатации в соответствии с ГОСТ 12207, должен решить следующие задачи:

1. разработать план снятия с эксплуатации,

2. уведомить пользователей об этом,

3. провести соответствующее обучение персонала,

4. уведомить всех заинтересованных субъектов о завершении снятия системы с эксплуатации

5. архивировать соответствующие данные.

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

1. сроки прекращения полной или частичной поддержки;

2. требования по архивации ПС и соответствующих документов;

3. обязательства по любым оставшимся вопросам поддержки;

4. сроки перехода, при необходимости, к новой ПС;

5. требования по доступу к архивным копиям данных.

Как часть указанной задачи сопроводитель должен выполнить следующие этапы:

1. анализ требований к снятию с эксплуатации;

2. определить влияние снятия ПС на всю систему;

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

4. разработать график (программу) снятия ПС с эксплуатации;

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

6. определить и документировать все действия по снятию с эксплуатации.

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

1. описание заменяющего или модернизированного объекта с указанием даты его доступности для пользователей;

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

3. описание других доступных вариантов поддержки в случае прекращения поддержки прежнего объекта.

Как часть указанной задачи сопроводитель должен выполнить следующие этапы:

1. определить все объекты (и их местоположения), затрагиваемые при данной работе;

2. определить специфику каждого абонента;

3. опубликовать соответствующий график (программу) снятия;

4. отработать обратную связь с абонентами.

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

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

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

1. сохранить старые программные средства и данные, полученные при решении предыдущих задач;

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

3. хранить соответствующие носители в безопасном месте.

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

- документирование;

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

- обеспечение качества;

- совместный анализ;

- аудит;

- обучение.

Выходные результаты. Выходными результатами данной работы являются:

1. план снятия с эксплуатации;

2. уведомление о намерениях по снятию с эксплуатации;

3. результаты, полученные при выполнении снятия ПС средства с эксплуатации;

4. обученный персонал;

5. снятая с эксплуатации программная система;

6. уведомление о завершении снятия с эксплуатации;