ГОСТ Р ИСО/МЭК 14764-2002. Информационная технология. Сопровождение программных средств

(принят и введен в действие Постановлением Госстандарта РФ от 25.06.2002 № 248-ст)

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

СОПРОВОЖДЕНИЕ ПРОГРАММНЫХ СРЕДСТВ

Information technology. Software maintenance

ГОСТ Р ИСО/МЭК 14764-2002

Группа П85

ОКСТУ 5001

1 июля 2003 года

Предисловие

1. Разработан Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России, Московским научно-исследовательским институтом (МНИЦ) Минсвязи России и Институтом радиотехники и электроники Российской академии наук (ИРЭ РАН).

Внесен Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России.

2. Принят и введен в действие Постановлением Госстандарта России от 25 июня 2002 г. № 248-ст.

3. Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 14764-99 «Информационная технология. Сопровождение программных средств».

4. Введен впервые.

Введение

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

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

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

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

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

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

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

1. Область применения

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

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

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

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

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

1.1. Назначение

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

1.2. Применение

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

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

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

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

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

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

1.3. Ограничения

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

В стандарте приведен ряд перечислений (списков). Однако ни одно из них не является исчерпывающим. Эти перечисления приведены в качестве примеров.

Этапы применения настоящего стандарта указаны в ГОСТ Р ИСО/МЭК ТО 15271.

2. Соответствие

Соответствие настоящему стандарту обеспечивают при выполнении требований ГОСТ Р ИСО/МЭК 12207.

3. Нормативные ссылки

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

ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению

ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств

ГОСТ Р ИСО/МЭК ТО 15271-2002. Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

ИСО/МЭК 2382-1-93 <*>. Информационная технология. Словарь. Часть 1. Основополагающие термины

ИСО/МЭК 2382-20-90 <*>. Информационная технология. Словарь. Часть 20. Разработка систем

ИСО 8402-94 <*>. Управление качеством и обеспечение качества. Словарь.

---

<*> Оригиналы международных документов ИСО/МЭК (ИСО) — во ВНИИКИ Госстандарта России.

4. Определения

В настоящем стандарте применены термины с соответствующими определениями по ИСО/МЭК 2382-1, ИСО/МЭК 2382-20, ИСО 8402 и ГОСТ Р ИСО/МЭК 12207, а также приведенные ниже:

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

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

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

Примечание. Иногда новую базовую линию рассматривают как новую версию (редакцию).

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

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

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

Примечание. План сопровождаемости готовит разработчик.

4.5. Сопровождаемая модернизация (maintenance enhancement): сопровождаемая модернизация является изменением программного средства, не связанным с корректировкой самого программного средства.

Примечание. Различают два типа модернизации программного средства: адаптивную и полную.

4.6. План сопровождения (maintenance plan): документ, излагающий соответствующие методы сопровождения, описывающий необходимые ресурсы и работы применительно к сопровождению программного продукта.

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

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

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

4.8. Программа сопровождения (maintenance program): организационная структура, обязанности, процедуры, процессы и ресурсы, используемые при выполнении плана сопровождения.

Примечание. Термин «программа» синонимичен термину «инфраструктура».

4.9. Предложение о модификации (ПР) (modification request [MR]): общий термин, используемый для определения предполагаемых изменений в сопровождаемом программном продукте.

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

Предложение о модификации [изменении (ПР)]

                             /\

                                /  \
                               /    \

<pre class="legal-pre">                   ┌───────────┐    ┌──────────────┐
Классификация      │ Коррекция │    │ Модернизация │
                   └───────────┘    └──────────────┘
                         /\                    /\
                        /  \                  /  \</pre>
              ┌─────────┐ ┌─────────┐ ┌───────┐ ┌────────┐
<pre class="legal-pre">      Тип     │ Коррек- │ │Профилак-│ │ Адап- │ │ Полное │
сопровождения │ тирующее│ │тическое │ │ тивное│ │        │</pre>
              └─────────┘ └─────────┘ └───────┘ └────────┘

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

4.10. Полное сопровождение (perfective maintenance): модификация программного продукта после поставки для повышения его рабочих характеристик или лишения сопровождаемости.

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

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

4.12. Отчет о проблеме (ОП) (problem report [PR]): термин, используемый для определения и описания проблем, обнаруженных в программном продукте.

4.13. Среда программной инженерии (СПИ) (software engineering environment [SEE]): набор автоматических инструментальных средств, программно-аппаратных и технических средств, необходимых для выполнения объема работ по программной инженерии.

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

4.14. Среда тестирования программного средства (СТПС) (software test environment [STE]): вспомогательное оборудование, технические и программные средства, программы, реализованные техническими средствами, процедуры и документы, необходимые для проведения квалификационных, а возможно, и других испытаний (тестирований) программного средства.

Примечание. Данный перечень может охватывать, но не ограничивать, средства моделирования, анализаторы кода, генераторы контрольных примеров и анализаторы ветвей (маршрутов), а также включать в себя элементы, использованные в среде программной инженерии (МИЛ-НДБК-347 [1]).

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

5. Применение настоящего стандарта

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

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

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

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

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

5.2. Структура настоящего стандарта

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

В разделе 6 рассмотрены сопровождение в целом и требования и ограничения, подлежащие учету при планировании сопровождения. В разделе 7 приведена исчерпывающая информация о планировании сопровождения. В разделе 8 описаны подробности процесса сопровождения, в том числе задачи и этапы их решения, необходимые для реализации данного процесса.

6. Соображения по сопровождению

6.1. Введение

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

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

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

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

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

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

6.2. Типы сопровождения

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

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

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

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

6.3. Соглашения при сопровождении

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

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

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

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

Данные процедуры должны охватывать:

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

6.4. Инструментальные средства для сопровождения

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

При выборе CASE-средств следует ознакомиться с ограничениями по их применению. Сопроводители должны тщательно планировать данные работы (ИСО/МЭК ТО 14471 [2]).

6.5. Оценка (измерение) характеристик программного средства

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

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

6.6. Документирование процесса

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

6.7. Своевременное вовлечение в разработку

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

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

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

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

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

6.8. Сопровождаемость

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

6.8.1 Сопровождаемость и процесс разработки

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

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

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

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

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

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

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

6.8.2 Сопровождаемость и конкретные работы в процессе разработки

6.8.2.1 Анализ требований к программным средствам

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

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

6.8.2.2 Проектирование программной архитектуры

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

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

6.8.2.3 Техническое проектирование программного средства

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

6.8.2.4 Программирование и тестирование программного средства

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

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

6.8.2.5 Квалификационные испытания программного средства

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

6.9. Передача программного средства

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

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

6.10. Документы

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

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

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

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

d) установить низшие приоритеты ПР или ОП.

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

7. Стратегия сопровождения программного средства

7.1. Введение

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

• концепцию сопровождения;
• план сопровождения;
• анализ ресурсов.

7.2. Концепция сопровождения

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

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

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

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

7.2.1 Область сопровождения

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

• типы выполняемого сопровождения;
• сопровождаемый уровень документов;
• реакцию (чувствительность) на сопровождение;
• обеспечиваемый уровень обучения персонала;
• обеспечение поставки продукта;
• организацию справочной службы («горячей линии»).

7.2.2 Практическое применение (адаптация) процесса

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

7.2.3 Определение ответственных за сопровождение

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

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

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

7.2.4 Оценка стоимости сопровождения

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

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

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

7.3. Планирование сопровождения

7.3.1 Введение

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

7.3.2 План сопровождения

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

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

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

7.3.3 Рекомендации по плану сопровождения

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

a) введение:

1. описание сопровождаемой системы;

2. определение исходных состояний программного средства;

3. описание уровня требуемой поддержки;

4. определение организации, проводящей сопровождение;

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

b) концепция сопровождения:

1. описание концепции;

2. описание уровня поддержки системы;

3. установление периода поддержки;

4. адаптация (практическое применение) процесса сопровождения;

c) организационные работы и работы по сопровождению:

1. роли и обязанности сопроводителя до поставки программного продукта:

I) реализация процесса;

II) определение инфраструктуры процесса;

III) установление процесса обучения;

IV) установление процесса сопровождения;

2. роли и обязанности сопроводителя после поставки программного продукта:

I) реализация процесса;

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

III) реализация (внесение) модификаций (изменений);

IV) рассмотрение и принятие модификаций (изменений);

V) перенос программного средства в новую среду;

VI) снятие программного средства с эксплуатации;

VII) решение проблем (включая справочную службу);

VIII) при необходимости — обучение персонала (сопроводителя и пользователя);

IX) усовершенствование процесса;

3. роль пользователя:

I) приемочные испытания;

II) взаимосвязи (интерфейсы) с другими организациями;

d) ресурсы:

1. персонал:

I) состав персонала для конкретного проекта;

2. программные средства:

I) определение программных средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);

3. технические средства:

I) определение технических средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);

4. оборудование (аппаратура);

I) определение требований к оборудованию (аппаратуре) системы (помимо технических средств вычислительной техники);

5. документы:

I) план обеспечения качества;

II) план управления проектом;

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

IV) документы разработки;

V) руководства по сопровождению;

VI) план проведения верификации;

VII) план проведения аттестации (валидации);

VIII) план тестирования, процедуры тестирования и отчеты о тестировании;

IX) план обучения;

X) руководство(а) пользователя;

6. данные;

7. другие требования к ресурсам (при необходимости);

e) процесс (как должна быть выполнена конкретная деятельность):

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

2. процесс адаптации (практического применения сопровождения к условиям проекта);

f) обучение:

1. определение уровня обучения, необходимого для сопроводителя и пользователей;

g) протоколы и отчеты по сопровождению:

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

2. состояния запросов (предложений, отчетов) по категориям;

3. приоритеты запросов (предложений, отчетов);

7.4. Анализ ресурсов

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

7.4.1 Ресурсы персонала

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

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

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

7.4.2 Ресурсы среды

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

7.4.3 Финансовые ресурсы

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

• выплаты зарплаты персоналу;
• обучения персонала (2 — 3 недели в год на каждого человека);
• ежегодного возобновления лицензий на сопровождение программных средств;
• командировок;
• публикации (издания) соответствующих материалов;
• технических и программных средств СПИ и СТПС;

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

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

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

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

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

a) подготовку процесса;

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

c) внесение изменений;

d) проверку и приемку при сопровождении;

e) перенос;

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

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

Рисунок 2. Процесс сопровождения

8.1. Подготовка процесса

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

8.1.1 Исходные данные

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

• старая (исходная) базовая линия;
• системные документы;
• предложение о модификации (ПР) или отчет о проблеме (ОП).

8.1.2 Задачи

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

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

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

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Сопроводитель  должен  (см.  5.5.1.1  ГОСТ Р ИСО/МЭК  12207)│
│разработать,   документально   оформить   и  выполнить  планы  и│
│процедуры для проведения работ и задач процесса сопровождения.  │</pre>
└────────────────────────────────────────────────────────────────┘

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

a) помочь заказчику при разработке концепции сопровождения;

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

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

d) гарантировать официальное подтверждение принятия на себя обязанностей сопроводителя программного продукта;

e) провести анализ ресурсов;

f) оценить стоимость сопровождения;

g) выполнить оценку сопровождаемости системы;

h) установить требования к передаче программного продукта сопроводителю;

i) установить контрольные точки передачи программного продукта сопроводителю;

j) определить подлежащий реализации процесс сопровождения;

k) документально оформить процесс сопровождения в виде эксплуатационных процедур.

8.1.2.2 Процедуры рассмотрения ПР и ОП

┌────────────────────────────────────────────────────────────────┐
│    Сопроводитель  должен  (см.  5.5.1.2  ГОСТ Р ИСО/МЭК  12207)│
│определить процедуры для: получения, документирования и контроля│
<pre class="legal-pre">│отчетов  (сообщений)  о проблемах  и предложений  о модификациях│
│(изменениях)  от  пользователей;  обеспечения   обратной   связи│
│с  пользователями.  Каждая   возникающая  проблема  должна  быть│
│документально  оформлена  и  введена  в  процесс решения проблем│
│(6.8 ГОСТ Р ИСО/МЭК 12207).                                     │</pre>
└────────────────────────────────────────────────────────────────┘

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

a) разработать схему числового обозначения ПР и ОП;

b) разработать схему классификации и присвоения приоритетов для ПР и ОП;

c) разработать процедуры проведения целевых анализов;

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

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

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

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

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

8.1.2.3 Управление конфигурацией

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Сопроводитель  должен  (см.  5.5.1.3  ГОСТ Р ИСО/МЭК  12207)│
│реализовать       процесс        управления        конфигурацией│
│(6.2   ГОСТ  Р  ИСО/МЭК  12207)   для   управления   изменениями│
│существующей системы (или определить  организационный  интерфейс│
│с данным процессом).                                            │</pre>
└────────────────────────────────────────────────────────────────┘

Сопроводителю следует использовать процесс управления конфигурацией по ГОСТ Р ИСО/МЭК 12207.

8.1.3 Проверки

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

8.1.4 Обеспечение

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

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

8.1.5 Выходные результаты

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

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

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

8.2. Анализ проблем и изменений

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

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

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

8.2.1 Исходные данные

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

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

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

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

8.2.2 Задачи (задания)

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

8.2.2.1 Анализ ПР или ОП

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Сопроводитель  должен  (см.  5.5.2.1  ГОСТ Р ИСО/МЭК  12207)│
│проанализировать  отчет  (сообщение)  о проблеме или предложение│
│(заявку)  о  модификации  (внесении  изменений)  по  их  влиянию│
│на организационные вопросы,  существующую систему и интерфейсные│
│связи с другими системами по следующим аспектам:                │
│    a) типу, например, корректировка, модернизация, профилактика│
│или адаптация к новым условиям (среде);                         │
│    b) области (объему), например, размеру изменения, стоимости,│
│времени на реализацию изменения;                                │
│    c) критичности,  например, влиянию на рабочие характеристики│
│(производительность), безопасность или защиту.                  │</pre>
└────────────────────────────────────────────────────────────────┘

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

d) определить наличие у себя соответствующего персонала, способного реализовать предлагаемое изменение;

e) определить наличие соответствующего финансирования для реализации предлагаемого изменения в программе;

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

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

h) определить влияние изменений на безопасность и защиту (возможно, не следует реализовывать ОП);

i) определить единовременные и долгосрочные затраты (возможно, не следует реализовывать ОП);

j) определить преимущества (выгоды), получаемые после проведения модификации;

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

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

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

8.2.2.2 Верификация

Сопроводитель должен (см. 5.5.2.2 ГОСТ Р ИСО/МЭК 12207) продублировать или верифицировать возникшую проблему.

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

a) разработать стратегию тестирования для проверки (верификации) конкретной проблемы;

b) реализовать управление конфигурацией представленной версии программного средства;

c) ввести в действие (инсталлировать) представленную версию;

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

e) документально оформить результаты тестирования.

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

8.2.2.3 Варианты

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    На  основе  проведенного  анализа  сопроводитель должен (см.│
│5.5.2.3  ГОСТ Р ИСО/МЭК 12207)  разработать  варианты реализации│
│изменения (модификации).                                        │</pre>
└────────────────────────────────────────────────────────────────┘

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

a) присвоить соответствующий приоритет ПР или ОП;

b) установить наличие возможностей (средств) для решения проблемы. Эти возможности (при их наличии) должны быть предоставлены для использования оператором или пользователем. (Данный этап не реализуется при адаптивном или полном сопровождении);

c) установить жесткие требования к конкретному изменению (модификации);

d) оценить объем и трудоемкость данной модификации (изменения);

e) разработать, по крайней мере, три варианта реализации конкретного изменения;

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

g) выполнить анализы риска для каждого варианта.

8.2.2.4 Документы

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Сопроводитель  должен  (см.  5.5.2.4  ГОСТ Р ИСО/МЭК  12207)│
│документально   оформить:  отчет   (сообщение)  о  проблеме  или│
│предложение   (заявку)  о  модификации   (внесении   изменений);│
│результаты их анализа и варианты реализации изменений.          │</pre>
└────────────────────────────────────────────────────────────────┘
Сопроводитель должен выполнить следующие этапы решения данной задачи:

a) проверить актуальность всех проектных документов и документов результатов анализа. Если какие-либо документы отсутствуют, их следует разработать;

b) определить правильность предложенной политики и графика (программы) тестирования;

c) определить правильность оценок ресурсов;

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

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

8.2.2.5. Согласование
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    До внесения  изменений  в систему  сопроводитель должен (см.│
│5.5.2.5 ГОСТ Р ИСО/МЭК 12207)  получить  согласование выбранного│
│варианта изменения в соответствии с договором.                  │</pre>
└────────────────────────────────────────────────────────────────┘

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

a) представить результаты анализов на согласование в соответствующие группы по управлению конфигурацией;

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

c) обновить, после согласования, состояние (статус) предложения о модификации;

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

8.2.3 Проверки

Контроль за рассматриваемой работой проводится посредством процесса совместного анализа (6.6 ГОСТ Р ИСО/МЭК 12207).

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

8.2.4 Обеспечение

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

• документирования;
• обеспечения качества;
• решения проблем.

8.2.5 Выходные результаты

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

• анализ влияния изменения(й);
• рекомендуемый вариант изменения;
• согласованное изменение;
• обновленные (исправленные) документы.

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

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

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

• политику (стратегию) тестирования;
• обновленные документы по тестированию, включая план и процедуры тестирования и отчет о тестировании;

• обновленные требования.

8.3. Внесение изменений

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

8.3.1 Исходные данные

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

• базовая линия;
• согласованное ПР или ОП;
• согласованные документы на изменение.

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

• описания системной архитектуры;
• документы конкретного предложения о модификации (изменении);
• исходные программы.

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

• отчет об анализе влияния изменения(й);
• выходные результаты работы по анализу проблем и изменений.

8.3.2 Задачи (задания)

Сопроводитель должен выполнить анализ на предмет использования процесса разработки по ГОСТ Р ИСО/МЭК 12207 при внесении изменений.

8.3.2.1 Анализ

┌────────────────────────────────────────────────────────────────┐
│    Сразу  же после согласования ПР  или ОП сопроводитель должен│
│(см. 5.5.3.1 ГОСТ Р ИСО/МЭК 12207) провести анализ и определить,│
<pre class="legal-pre">│какие   документы,  программные   модули  и  их  версии  требуют│
│изменения.  Полученные  результаты   должны  быть  документально│
│оформлены.                                                      │</pre>
└────────────────────────────────────────────────────────────────┘
Результаты такого дополнительного анализа должны быть документально оформлены в комплекте(ах) документов разработки программного средства (КДРПС). При реализации данной деятельности должны быть выполнены следующие этапы решения задачи:

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

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

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

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

8.3.2.2. Процесс разработки
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Сопроводитель  должен  (см.  5.5.3.2  ГОСТ Р ИСО/МЭК  12207)│
│использовать  процесс  разработки (5.3 ГОСТ Р ИСО/МЭК 12207) для│
│внесения   (реализации)   изменений.   Требования   к   процессу│
│разработки должны быть дополнены следующим образом:             │
│    a)  должны  быть   установлены  и  документально   оформлены│
│критерии   проведения   испытаний   (тестирования),   оценки  их│
│результатов  и  измененных  и неизмененных объектов (программных│
│модулей,  компонентов  и  элементов  конфигурации)  системы [см.│
│5.5.3.2, перечисление a) ГОСТ Р ИСО/МЭК 12207];                 │
│    b) должны быть обеспечены  полнота и правильность реализации│
│новых  и  измененных  требований.  Также должно быть обеспечено,│
│чтобы   исходные,   неизмененные   требования   не   изменились.│
│Результаты  испытаний  должны  быть документально оформлены [см.│
│5.5.3.2, перечисление b) ГОСТ Р ИСО/МЭК 12207].                 │</pre>
└────────────────────────────────────────────────────────────────┘

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

8.3.3 Проверки

Контроль за рассматриваемой работой должен быть проведен посредством процесса совместного анализа (6.6 ГОСТ Р ИСО/МЭК 12207).

8.3.4 Обеспечение

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

• документирования;
• обеспечения качества;
• совместного анализа.

8.3.5 Выходные результаты

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

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

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

• обновленные документы на изменение (модификацию);
• подробный отчет о проведенном анализе;
• обновленные требования;

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

8.4. Проверка и приемка при сопровождении

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

8.4.1 Исходные данные

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

• измененное программное средство;
• результаты тестирования внесенного изменения(й).

8.4.2 Задачи (задания)

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

8.4.2.1 Проверки (обзоры)

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Сопроводитель  должен  (см.  5.5.4.1  ГОСТ Р ИСО/МЭК  12207)│
│провести    проверку(и)    внесенного    изменения     совместно│
│с  организацией,  утвердившей  изменение  в целях  подтверждения│
│целостности (работоспособности) измененной системы.             │</pre>
└────────────────────────────────────────────────────────────────┘

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

a) отслеживание реализованности ПР или ОП от требований к объекту до проекта и программных кодов;

b) проверка тестируемости текста (кодов) программы;

c) проверка соблюдения стандартов на программирование;

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

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

f) контроль обновления документов;

g) проведение тестирования;

h) выпуск отчета о тестировании.

8.4.2.2 Согласование

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Сопроводитель  должен  (см.  5.5.4.2  ГОСТ Р ИСО/МЭК  12207)│
│получить  согласование  (подтверждение)  того,   что   внесенное│
│изменение удовлетворяет требованиям, установленным в договоре.  │</pre>
└────────────────────────────────────────────────────────────────┘

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

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

a) получено согласование посредством вспомогательного процесса обеспечения качества (6.3 ГОСТ Р ИСО/МЭК 12207);

b) проверено выполнение данного процесса;

c) проведен аудит функциональной и физической конфигурации.

8.4.3 Проверки

Контроль за рассматриваемой работой проводят посредством процесса совместного анализа (6.6 ГОСТ Р ИСО/МЭК 12207).

8.4.4 Обеспечение

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

• обеспечения качества;
• верификации;
• аттестации (валидации);
• совместного анализа;
• аудита.

8.4.5 Выходные результаты

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

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

• отчет о квалификационном тестировании программного средства.

8.5. Перенос

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

8.5.1 Исходные данные

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

• старая среда;
• новая среда;
• старая базовая линия;
• новая базовая линия.

8.5.2 Задачи (задания)

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

8.5.2.1 Перенос

┌────────────────────────────────────────────────────────────────┐
│    Если  систему  или  программный   продукт   (включая данные)│
│переносят из прежней в новую эксплуатационную среду, должно быть│
<pre class="legal-pre">│обеспечено  (см.  5.5.5.1  ГОСТ Р ИСО/МЭК  12207),  чтобы  любой│
│программный  продукт  или  данные  были созданы или изменены при│
│переносе в соответствии с ГОСТ Р ИСО/МЭК 12207.                 │</pre>
└────────────────────────────────────────────────────────────────┘
Должны быть выполнены следующие этапы решения этой задачи:

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

b) проверено соответствие конкретных задач ГОСТ Р ИСО/МЭК 12207.

8.5.2.2. План переноса
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Для соответствующего контроля переноса системы  должен  быть│
│(см. 5.5.5.2 ГОСТ Р ИСО/МЭК  12207)   разработан,  документально│</pre>
│оформлен и выполнен план переноса объекта. К планируемым работам│
<pre class="legal-pre">│должны быть привлечены пользователи. В содержание  плана  должны│
│быть включены:                                                  │
│    a) анализ и установление требований к переносу;             │
│    b)  разработка   инструментальных   средств  для  выполнения│
│переноса;                                                       │
│    c) настройка программного продукта и данных к новым условиям│
│эксплуатации;                                                   │
│    d) выполнение переноса;                                     │
│    e) верификация переноса;                                    │
│    f) последующая поддержка прежней среды.                     │</pre>
└────────────────────────────────────────────────────────────────┘

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

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

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

c) установить график проведения переноса;

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

e) определить и документально оформить работы (деятельность) по переносу;

f) определить и уменьшить возможный риск;

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

h) определить степень последующей поддержки для старой среды;

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

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

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

l) преобразовать программные продукты и данные;

m) перенести программные продукты и данные в новую среду;

n) провести параллельную эксплуатацию (в новой и старой средах);

o) верифицировать перенос путем тестирования;

p) проводить последующую поддержку для старой среды.

8.5.2.3 Уведомление о намерениях

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Сразу  же  после  завершения   сопроводителем   планирования│
│переноса    пользователям     должно    быть     (см.    5.5.5.3│
│ГОСТ Р ИСО/МЭК 12207)  направлено уведомление о планах и работах│
│по  переносу  объекта.  В  содержание  уведомления  должны  быть│
│включены:                                                       │
│    a) объяснение  того,  почему  прежнюю  среду  нельзя  больше│
│поддерживать;                                                   │
│    b) описание  новой  среды  с указанием  даты, с которой  она│
│доступна для пользователей;                                     │
│    c) описание  других  доступных  вариантов поддержки в случае│
│прекращения поддержки прежней среды.                            │</pre>
└────────────────────────────────────────────────────────────────┘
Сопроводитель должен также представить пользователям план, процедуры и график (программу) переноса. Сопроводитель должен выполнить следующие этапы решения этой задачи:

a) определить все объекты, затрагиваемые переносом;

b) отработать обратную связь с абонентами;

c) определить специфику абонента;

d) опубликовать график (программу) переноса.

8.5.2.4. Реализуемые операции и обучение
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Для плавного перехода в новую среду  параллельно  могут быть│
│выполнены  работы  в  прежней  и  новой  среде.  В течение этого│
│периода     обеспечивают    необходимое    обучение    персонала│
│в   соответствии    с   условиями    договора    (см.    5.5.5.4│
│ГОСТ Р ИСО/МЭК 12207).                                          │</pre>
└────────────────────────────────────────────────────────────────┘

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

a) провести обследование абонента;

b) установить соответствующее оборудование;

c) установить соответствующие программные средства;

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

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

f) собрать данные о новых и старых продуктах;

g) выполнить преобразование данных и их анализ.

Сопроводитель должен выполнить следующие этапы работ по обучению персонала:

a) определить требования по обучению при переносе;

b) запланировать реализацию требований по обучению при переносе;

c) выполнить проверку обучения при переносе;

d) обновить планы обучения.

8.5.2.5 Уведомление о завершении переноса

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    После   выполнения  запланированного  переноса  должно  быть│
│послано  соответствующее   уведомление   всем   заинтересованным│
│сторонам.  Все  связанные  с  прежней  средой документы, журналы│
│регистрации   и  программы   должны   быть  помещены  в   архивы│
│(см. 5.5.5.5 ГОСТ Р ИСО/МЭК 12207).                             │</pre>
└────────────────────────────────────────────────────────────────┘
Как часть указанной задачи сопроводитель должен выполнить следующие этапы:

a) опубликовать изменения к графику (программе) переноса;

b) документально зафиксировать специфику абонента и соответствующие решения;

c) архивировать старые программные средства и данные;

d) снять старое оборудование.

8.5.2.6. Итоговый анализ
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    После  завершения  переноса  должен  быть  выполнен итоговый│
│анализ для оценки влияния перехода  к новой  среде  на различные│
│аспекты эксплуатации перенесенного объекта.  Результаты  анализа│
│должны  быть разосланы соответствующим заинтересованным сторонам│
│для   информации,   руководства   и   использования   в   работе│
│(см. 5.5.5.6 ГОСТ Р ИСО/МЭК 12207).                             │</pre>
└────────────────────────────────────────────────────────────────┘
Как часть указанной задачи сопроводитель должен выполнить следующие этапы:

a) проанализировать результаты параллельной эксплуатации систем;

b) определить области потенциального риска;

c) определить специфику абонентов;

d) документально зафиксировать любые извлеченные уроки;

e) создать и опубликовать отчет по анализу влияния переноса.

8.5.2.7. Архивные данные
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Данные,  использованные  или  связанные  с  прежней  средой,│
│должны  быть   доступными  для  защиты  и  аудиторской  проверки│
│в    соответствии    с    условиями     договора    (см. 5.5.5.7│
│ГОСТ Р ИСО/МЭК 12207).                                          │</pre>
└────────────────────────────────────────────────────────────────┘

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

a) сохранить старые программные средства и данные;

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

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

8.5.3 Проверки

Контроль за рассматриваемой работой проводят посредством процесса совместного анализа (6.6 ГОСТ Р ИСО/МЭК 12207).

8.5.4 Обеспечение

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

• документирования;
• управления конфигурацией;
• обеспечения качества;
• верификации;
• аттестации (валидации);
• совместного анализа;
• аудита;
• решения проблем;
• обучения.

8.5.5 Выходные результаты

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

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

• архивные данные.

8.6. Снятие программного средства с эксплуатации

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

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

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

8.6.1 Исходные данные

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

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

8.6.2 Задачи

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

8.6.2.1 План снятия с эксплуатации

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Должен быть  (см. 5.5.6.1 ГОСТ Р ИСО/МЭК 12207)  разработан,│
│документально  оформлен  и реализован план снятия с эксплуатации│
│при прекращении  активной  поддержки  объекта эксплуатирующими и│
│сопровождающими организациями. К запланированным работам  должны│
│быть  привлечены  пользователи.  В содержание  плана должны быть│
│включены:                                                       │
│    a) сроки прекращения полной или частичной поддержки;        │
│    b)  требования   по   архивации   программного   продукта  и│
│соответствующих документов;                                     │
│    c) обязательства по любым оставшимся вопросам поддержки;    │
│    d) сроки перехода, при необходимости,  к новому программному│
│продукту;                                                       │
│    e) требования по доступу к архивным копиям данных.          │</pre>
└────────────────────────────────────────────────────────────────┘
Как часть указанной задачи сопроводитель должен выполнить следующие этапы;

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

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

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

d) разработать график (программу) снятия программного продукта с эксплуатации;

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

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

8.6.2.2. Уведомление о намерениях
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Пользователи  должны  (см. 5.5.6.2  ГОСТ  Р  ИСО/МЭК  12207)│
│получить   уведомление   о   планах   и    работах   по   снятию│
│с эксплуатации. В содержание уведомления должны быть включены:  │
│    a)  описание  заменяющего  или  модернизированного   объекта│
│с указанием даты его доступности для пользователей;             │
│    b)  объяснение  того,  почему  прежний  программный  продукт│
│нельзя больше поддерживать;                                     │
│    c)  описание  других  доступных вариантов поддержки в случае│
│прекращения поддержки прежнего объекта.                         │</pre>
└────────────────────────────────────────────────────────────────┘
Как часть указанной задачи сопроводитель должен выполнить следующие этапы:

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

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

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

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

8.6.2.3. Реализация параллельной эксплуатации и обучение
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Для плавного перехода к новой  системе  должна  (см. 5.5.6.3│
│ГОСТ Р ИСО/МЭК 12207) быть проведена  параллельная  эксплуатация│</pre>
│прежнего и нового программных продуктов. В течение этого периода│
<pre class="legal-pre">│обеспечивают необходимое обучение  пользователей  в соответствии│
│с условиями договора.                                           │</pre>
└────────────────────────────────────────────────────────────────┘

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

a) провести обследование абонента;

b) установить оборудование;

c) установить программный продукт;

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

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

f) собрать данные о новых и старых продуктах;

g) выполнить преобразование данных и их анализ.

8.6.2.4 Уведомление о завершении снятия

┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    После  выполнения  запланированного  снятия  с  эксплуатации│
│должно  быть  (см.  5.5.6.4   ГОСТ  Р  ИСО/МЭК  12207)   послано│
│соответствующее  уведомление всем заинтересованным сторонам. Все│
│связанные  с  прежним  объектом  документы  разработки,  журналы│</pre>
│регистрации и программы должны быть, при необходимости, помещены│
│в архивы.                                                       │
└────────────────────────────────────────────────────────────────┘
Как часть указанной задачи сопроводитель должен выполнить следующие этапы:

a) опубликовать изменения к графику (программе) снятия;

b) документально зафиксировать специфику абонента и соответствующие решения;

c) архивировать старые программные средства и данные;

d) снять старое оборудование.

8.6.2.5. Архивные данные
┌────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│    Данные,    использованные    или    связанные    со   снятым│
│с эксплуатации программным продуктом,  должны быть  (см. 5.5.6.5│
│ГОСТ Р  ИСО/МЭК  12207)  доступными  для  защиты  и  аудиторской│
│проверки в соответствии с условиями договора.                   │</pre>
└────────────────────────────────────────────────────────────────┘

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

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

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

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

8.6.3 Проверки

Контроль за рассматриваемой работой проводят посредством процесса совместного анализа (6.6 ГОСТ Р ИСО/МЭК 12207).

8.6.4 Обеспечение

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

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

8.6.5 Выходные результаты

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

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

И ГОСТ Р ИСО/МЭК 12207

Таблица A.1

Пункт настоящего стандарта	Пункт ГОСТ Р ИСО/МЭК 12207
1.2	1.2
4.2	3.5
5.1	4.1.1.1 - 4.1.1.3
6.1	5.5, 6.2, 6.8
6.3	5.1.3
7.2.3	5.1, 5.2
8	5.5
8.1	5.5.1
8.1.2.1	5.5.1.1
8.1.2.2	5.5.1.2
8.1.2.3	5.5.1.3
8.1.3	6.6
8.2	5.5.2
8.2.2.1	5.5.2.1
8.2.2.2	5.5.2.2
8.2.2.3	5.5.2.3
8.2.2.4	5.5.2.4
8.2.2.5	5.5.2.5
8.2.3	6.6
8.3	5.5.3
8.3.2.1	5.5.3.1
8.3.2.2	5.3, 5.5.3.2
8.3.3	6.6
8.4	5.5.4
8.4.2.1	5.5.4.1
8.4.2.2	5.5.4.2
8.4.3	6.6
8.5	5.5.5
8.5.2.1	5.5.5.1
8.5.2.2	5.5.5.2
8.5.2.3	5.5.5.3
8.5.2.4	5.5.5.4
8.5.2.5	5.5.5.5
8.5.2.6	5.5.5.6
8.5.2.7	5.5.5.7
8.5.3	6.6
8.6	5.5.6
8.6.2.1	5.5.6.1
8.6.2.2	5.5.6.2
8.6.2.3	5.5.6.3
8.6.2.4	5.5.6.4
8.6.2.5	5.5.6.5
8.6.3	6.6

Приложение B (справочное)

БИБЛИОГРАФИЯ

1. МИЛ-НДБК-347-94. Программное обеспечение вычислительных ресурсов оборонительных систем

2. ИСО/МЭК ТО 14471-99 <*>. Информационная технология. Программная инженерия. Руководство по адаптации CASE-средств

3. ГОСТ 19.701-90 (ИСО 5807-85). Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения.

--------------------------------

<*> Оригинал международного стандарта ИСО/МЭК — во ВНИИКИ Госстандарта России.

------------------------------------------------------------------