Организация и методы сопровождения программных средств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- определить проблемную область (тип программного продукта);

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

- изучить структуру и организацию программного продукта;

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

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

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

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

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

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

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

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

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

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

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

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

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

- определение и описание новых функций;

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

- интерфейсы (системные, компонентов и пользователей), особенно новые и перспективные интерфейсы;

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

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

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

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

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

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

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

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

- размер изменения, стоимость, время на реализацию изменения;

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

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

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

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

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

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

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

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

- типы допустимых изменений и процедур сопровождения;

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

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

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

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

- возможность организации справочной службы – «горячей линии».

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

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

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

- квалификация сопровождающего персонала;

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

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

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

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

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

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

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

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

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

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