Липаев В.В. Программная инженерия

Л Е К Ц И Я 15

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

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

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

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

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

—корректируемые компоненты зачастую разрабатывались в прошлом

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

461

Лекция 15. Сопровождение и мониторинг программных средств

наковой полнотой документирования, что усложняет освоение их содер­ жания при внесении изменений и устранении дефектов;

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

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

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

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

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

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

462

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

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

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

иобеспечение сохранности документации и физических носителей — рис.

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

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

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

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

463

Лекция 15. Сопровождение и мониторинг программных средств

качественные и количественные стандартизированные метрики в соответ­ ствии с ISO 9126.

Рис. 15.1

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

464

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

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

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

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

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

465

Лекция 15. Сопровождение и мониторинг программных средств

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

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

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

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

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

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

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

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

466

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

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

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

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

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

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

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

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

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

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

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

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

467

Лекция 15. Сопровождение и мониторинг программных средств

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

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

Спецификация требований на изменения программного средства

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

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

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

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

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

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

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

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

468

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

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

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

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

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

469