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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- аудит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2017-02-01