
Липаев В.В. Программная инженерия
.pdfЛекция 15. Сопровождение и мониторинг программных средств
организационные процессы, существующую систему и интерфейсные свя зи с другими системами и установить:
—корректировку, модернизацию, профилактику или адаптацию к новым условиям;
—размер изменения, стоимость, время на реализацию изменения;
—критичность, влияние на основные функции, производительность, безопасность или защиту.
На основе проведенного анализа персонал сопровождения должен разработать варианты реализации процессов изменения и документально оформить: сообщение о дефекте или заявку на модификацию; результаты их анализа и требования к реализации изменений. Следует согласовать с заказчиком выбранные варианты изменений в соответствии с договором. Сопроводитель должен провести анализ и определить, какие документы, программные модули, компоненты или их версии требуют изменения. Полученные результаты должны быть документально оформлены.
Описание концепции сопрово:исдения должно быть первым шагом при разработке политики сопровождения ПС. Она должна быть разработа на при первом выпуске исходного программного продукта и отражать:
—область сопровождения и изменений программного продукта;
—практическое применение (адаптацию) данного процесса;
—определение предприятия и лиц, ответственных за сопровождение;
—оценку стоимости и длительности сопровождения.
Область сопровождения должна определять обязанности сопроводи теля и какую поддержку программному продукту он обязан обеспечить. Она зачастую определяется наличием соответствующих/7^cj;/7c«wjc и бюд-
жетных ограничений и должна охватывать:
—типы допустимых изменений и процедур сопровождения;
—уровень качества сопровождаемых документов;
—реакцию (чувствительность) пользователей на сопровождение;
—обеспечиваемый уровень обучения персонала сопровождения;
—обеспечение поставки модифицированных версий программного продукта;
—возможность организации справочной службы — «горячей линии». Концепция должна учитывать задачи сопровождения программного
продукта после его поставки. Важной частью концепции сопровождения является определение ресурсов и специалистов (физических или юриди-
470
15.1. Организация и методы сопровождения программных средств
ческих), отвечающих за сопровождение продукта. Это в равной степени справедливо и в случае внутреннего сопровождения в самой организации. При выполнении сопровождения по соглашению с третьей стороной это должно быть отмечено в концепции сопровождения. Выбор сопроводите ля должен быть основан mi ряде факторов:
—срок службы программного средства;
—размер первичных и долгосрочных затрат на сопровождение;
—квалификация сопровождающего персонала;
—функциональная пригодность и работоспособность исходной, ба зовой версии программного продукта;
—программа (график) модификаций и сопровождения;
—знание сопроводителем предметной области применения программ ного продукта.
Должна быть проведена оценка условий финансирования и стоимо сти сопровождения. Стоимость зависит от размера области сопровожде ния. Дополнительными факторами, подлежащими учету, являются сто имость: обучения как сопроводителей, так и пользователей; среды про граммного инструментария, тестирования и их ежегодного сопровождения. При разработке концепции сопровождения стоимость оценивают на осно ве ограниченных исходных данных. В дальнейшем эти оценки должны быть уточнены.
Разработку и утверждение в концепции спецификаций требований к
функциональным характеристикам и качеству программного продук та с учетом выполненных изменений целесообразно проводить итераци онно. Полная и однократная формализация требований к характеристикам каждой крупной модификации в начале жизненного цикла ПС обычно невозможна, прежде всего, из-за разных представлений заказчика и разра ботчиков о деталях ее назначения, функций и возможностей реализации при доступных ресурсах. Чем крупнее и сложнее проект ПС и соответ ственно выше его стоимость, тем тщательнее следует разрабатывать тре бования к его характеристикам сопровождения и распределять ресурсы на их реализацию.
При первоначальном определении требований к функциональной при годности и к конструктивным характеристикам заданные заказчиком ог раничения ресурсов не всегда могут учитывать ряд особенностей сопро вождения проекта, что обусловит недопустимое снижение (или завыше-
471
Лекция 15. Сопровождение и мониторинг программных средств
ние) требований к некоторым характеристикам модифицированного ПС. Кроме того, возможно, что некоторые характеристики или их изменения противоречивы или принципиально нереализуемы в данном проекте. В результате несбалансированные требования и доступные ресурсы про явятся в виде потерь в качестве или в потребности выделения дополни тельных ресурсов.
В зависимости от сложности проекта окончательным результатом ра бот при прогнозировании изменений комплекса программ должны быть детализированные и утвержденные требования к номенклатуре, свойствам и значениям качества программного продукта, которые достаточны для его полноценного сопровождения и последующей эффективной эксплуа тации. Эти требования закрепляются в концепции, контракте и тех ническом задании, по которым сопроводитель впоследствии должен от читываться перед заказчиком при завершении модификаций. Однако на последующих этапах жизненного цикла и при конфигурационном управ лении требования могут изменяться по согласованию между заказчиком и разработчиком, которые чаще всего приурочиваются к подготовке новой базовой версии ПС. Для этого необходим мониторинг функциональной пригодности, масштаба проекта, требований и реализаций характеристик в течение всего ЖЦ ПС.
Принципиальные и технические возможности, точность реализации свойств и измерения значений характеристик ПС, а также общие ресурсы конкретного проекта всегда ограничены в соответствии с их содержанием и возможностями заказчика и разработчиков. Это определяет ра1<«^«аль-
ные диапазоны значений каждого изменения, которые могут быть вы браны в концепции сопровождения ПС на основе требований заказчика, здравого смысла, а также путем анализа пилотных проектов и прецеден тов в спецификациях требований реализованных модификаций. При ограни ченности ресурсов проекта крупного ПС распределение приоритетов долж но становиться более строгим и могут снижаться приоритеты изменений характеристик, для реализации которых ресурсов недостаточно. В резуль тате формируется полный набор требуемых функциональных и конст
руктивных характеристик качества в процессе сопроволсдения ПС.
Требования к функциональным характеристикам и качеству, утвер жденные после проектирования концепции, могут быть закреплены в техническом задании как обязательные для детального и рабочего проек-
472
15.2. Этапы и процедуры при сопровождении программных средств
тирования модификаций (см. рис. 15.1). Эти данные могут использоваться при последующем оценивании качества и при их сопоставлении с требо ваниями в процессе квалификационных испытаний, сертификации моди фикаций или новой базовой версии программного продукта.
Для заказчика и пользователей при сопровождении может иметь зна чение не только определение функциональной пригодности, но и оценка потенциального спроса на рынке конкретного программного продукта, а также его конкурентоспособности с другими аналогичными по функци ям ПС с учетом его качества и стоимости. Это обстоятельство может определять необходимость контроля реализации и уточнения требований к отдельным характеристикам не только при сопровождении в ЖЦ ПС, но также для оценивания интегрального качества нового программного про дукта, поставляемого на рынок.
15.2. Этапы и процедуры при сопровождении программных средств
в соответствии с требованиями стандарта ISO 12207 по развитию и модификации программного продукта в жизненном цикле должен быть организован процесс его сопровождения (см. п. 5.5). Работы, обеспечива ющие сопровождение ПС, включают:
—подготовку процесса;
—анализ проблем и изменений;
—внесение изменений;
—проверку и приемку при сопровождении;
—перенос;
—снятие с эксплуатации.
Эти разделы и соответствующие процессы детализированы в стан дарте ISO 14764 и с рядом комментариев изложены ниже. После активиза ции процесса следует разработать план сопровождения и соответствую щие процедуры, а также выделить конкретные ресурсы для сопровожде ния. После поставки заказчику программного продукта сопроводитель, в соответствии с договором и предложением о модификации или отчетом о дефекте, должен изменить соответствующие программы и документы. Ис ходные данные преобразуют или используют в работах по сопровожде-
473
Лекция 15. Сопровождение и мониторинг программных средств
НИЮ для получения выходных результатов — модифицированных версий программного продукта. Рекомендуется проводить регулярный контроль с целью проверки корректности выходных результатов конкретных работ по сопровождению.
Подготовка процессов и спецификаций требований на сопровождение программного средства
I
Определение стратегии сопровождения программного средства
I |
1 = |
Разработка плана этапов и процедур сопровождения программного средства
Анализ выявленных дефектов и предложений модификаций для корректировки программного средства
Определение процессов реализации изменений и мониторинга программного средства
Совместный анализ с заказчиком и утверждение корректировок версии программного продукта
Квалификационное тестирование, приемка корректировок и подтверждение удовлетворения требований договора на сопровождение программного продукта
I
Документирование модификаций, отчетов о процессах и результатах сопровождения программного продукта
Внедрение для применения и эксплуатации новой базовой версии программного продукта
Обучение пользователей применению новой базовой версии программного продукта
Снятие с эксплуатации, архивация и прекращение сопровождения версии программного продукта
Рис. 15.2
При подготовке процесса сопроводитель должен создать планы и определить процедуры, выполняемые при реализации сопровождения (рис. 15.2). План сопровождения целесообразно создавать параллельно с пла ном разработки первой, базовой версии ПС. При выполнении данной ра-
474
15.2. Этапы и процедуры при сопровождении программных средств
боты сопроводитель также должен определить необходимые организаци онные интерфейсы и взаимосвязи между специалистами и с другими пред приятиями. Исходными данными для работ по подготовке процесса явля ются: старая (исходная) базовая версия программного продукта; систем ные документы; предложения о модификациях и отчеты о дефектах. Для обеспечения эффективной реализации процесса сопровождения сопрово дителю следует разработать и документально оформить стратегию про ведения сопровождения, один из ключевых факторов в применении и развитии ПС. При реализации этой деятельности сопроводитель должен: разработать планы и процедуры сопровождения; установить процедуры рассмотрения предложений о модификации и отчетов о дефектах; приме нить управление конфигурацией.
Сопроводитель должен разработать, документально оформить и вы полнить планы и процедуры для проведения работ и решения задач про цесса сопровождения. В плане сопровождения следует описать стратегию сопровождения системы, а в процедурах сопровождения должны быть определены подробности выполнения этапов и процессов сопровождения. Для обеспечения создания эффективных планов и процедур сопровожде ния сопроводитель должен:
—выполнить оценку сопровождаемой системы;
—гарантировать официальное подтверждение принятия на себя обя занностей сопроводителя программного продукта;
—провести анализ доступных ресурсов для сопровождения;
—оценить и согласовать с заказчиком финансирование и стоимость сопровождения;
—установить требования к процессу передачи программного про дукта сопроводителю;
—определить подлежащие реализации процессы сопровождения;
—документально оформить процесс сопровождения в виде планов и процедур, согласованных с заказчиком.
Стратегия сопровождения должна быть ориентирована на людские
иматериальные ресурсы, необходимые и доступные для обеспечения раз вития и модификаций программного продукта. Политика сопровождения ПС должна охватывать следующие основные компоненты: концепцию со провождения; план сопровождения; анализ ресурсов. Процесс разработки изменений включает в себя ряд работ, связанных с планированием сопро-
475
Лекция 15. Сопровождение и мониторинг программных средств
вождения ПС. Эти виды деятельности должны быть определены в стра тегии сопровождения программного продукта: определена пороговая ве личина изменения в стоимостном выражении, позволяющая вносить со ответствующее изменение в ПС без пересмотра конкретного договора с заказчиком; соглашения по интерфейсам для всего проекта в части посто янных проблем, связанных с неясностью, неточностью, изменчивостью или непроверяемостью требований заказчика и спецификаций.
Целью планирования сопровождения является подготовка плана ра бот по сопровождению и обеспечение ресурсов, необходимых для прове дения этих работ после передачи программного продукта на сопровожде ние. Планирование начинается после определения концепции сопровож дения ПС и завершается разработкой плана сопровождения, используемого в качестве основы при сопровождении. Общий план сопровождения дол-
лсен определять:
—причины необходимости сопровождения;
—состав исполнителей работ по сопровождению;
—роли и обязанности каждого субъекта, вовлеченного в сопровож
дение;
—как должны быть выполнены основные процессы и работы;
—какие имеются и необходимы ресурсы для сопровождения;
—методы и средства организации работ по управлению, выпуску продукта и синхронизации работ;
—перечень всех проектных результатов и продуктов, подлежащих поставке заказчику;
—критерии завершения соответствующей деятельности, работ и задач;
—состав отчетных материалов по этапам, затратам и графикам про ведения работ;
—периодичность и способы выдачи отчетных материалов;
—состав отчетных материалов по проблемам и устраненным дефек
там;
—время начала и длительность сопровождения.
Рекомендуется сопроводителям формализовать конкретный план сопровождения ПС из представленного общего состава процессов ЖЦ, который уточнить и адаптировать с учетом объема и особенностей проек та, содержащий разделы:
476
15.2.Этапы и процедуры при сопровождении программных средств
—описание сопровождаемой системы, в которую входит ПС;
—концепция сопровождения комплекса программ; описание уровня сопровождения системы и ПС; установление длительности процессов со провождения; адаптация стандартизированных процессов сопровождения;
—организационные работы по сопровождению, роли и обязанности специалистов;
—ресурсы: состав специалистов; инструментальные средства; техни ческие средства; документы и планы;
—процессы — как должна быть выполнена конкретная деятельность;
—определение уровня обучения, необходимого для сопроводителей
идля пользователей;
—протоколы и отчеты по сопровождению; контрольные данные, собранные при работах по сопровождению.
Проектирование архитектуры модификаций определяет функции и компоненты модифицированного программного средства. Основными особенностями данной работы среди процессов ЖЦ ПС, влияющими на сопровождаемость, являются выбор структуры программы, разбиение ее на компоненты (модули) и поток данных, циркулирующий между ними. При модификациях важно использовать знания коллектива специалистов по обработке данных, относящиеся к возможности использования частей существующих программ или библиотек, доказавших высокое функцио нальное качество. Основными средствами, способствующими обеспече нию требований сопровождаемости, являются модульная архитектура в сочетании с нисходящим анализом и соответствующие документы, в кото рые при необходимости могут быть внесены дополнения.
При проектировании ПС создаются версии каждого компонента про граммного средства, интерфейсов и баз данных. Составляются точные, подробные описания каждой функции для реализации предложенных из менений. Сопровождаемость программного средства может быть улучше на при учете характеристик качества, регламентированных в стандарте ISO 9126. Сопроводителю следует определить процедуры для: получения, документирования и контроля отчетов о дефектах и предложений о моди фикациях от пользователей; обеспечения обратной связи с пользователя ми. Каждая возникающая проблема и дефект должны быть документально оформлены и введены в процесс анализа изменений, для чего следует:
477
Лекция 15. Сопровождение и мониторинг программных средств
—разработать схему классификации и присвоения приоритетов для предложенных модификаций и описаний дефектов;
—разработать процедуры проведения целевых анализов изменений;
—определить процедуры представления предложенных модифика ций и описаний дефектов оператором;
—определить организацию обратной связи с пользователями при анализе изменений;
—определить, как пользователей будут обслуживать в период реали зации сопровождения;
—определить, как будут введены предлагаемые модификации в базу данных учета состояний изменений и используемых ресурсов.
Анализ дефектов и модификаций в стандарте ISO 14764 рекоменду ется реализовать в следующем порядке:
—анализируются предложения о модификации и отчеты о дефектах;
—дублируется или проверяется реальность каждого дефекта;
—разрабатываются варианты реализации изменения;
—документально оформляются: предложения о модификации и от четы о дефектах, результаты их рассмотрения и варианты реализации из менений;
—проводится согласование выбранного варианта реализации изме нения с заказчиком.
До внесения изменений в систему и ПС сопроводитель должен: про анализировать возможные изменения с точки зрения их влияния на дея тельность предприятия, существующую систему и взаимосвязанные с ней системы; разработать и документально оформить рекомендуемые альтер нативные решения по внесению корректировок и согласовать принятое решение по внесению изменений с заказчиком. Сопроводителю необходи мо проанализировать отчет о проблеме — дефекте или предложение о модификации по их влиянию на организационные вопросы, существую щую систему и интерфейсные связи с другими системами по типу: коррек тировка, модернизация, профилактика или адаптация к новым условиям или среде; по масштабу: размеру изменения, стоимости, времени на реали зацию изменения; по критичности: влиянию на рабочие характеристики и производительность, безопасность или защиту продукта.
Для обеспечения реализации представленного предложения на изме нение сопроводитель должен определить:
478
15.2.Этапы и процедуры при сопровождении программных средств
—наличие соответствующего персонала, способного реализовать предлагаемое изменение;
—наличие достаточного финансирования для реализации предлагае мого изменения в программе;
—наличие соответствующих ресурсов ЭВМ и степень влияния моди фикации на реализуемую или уже реализованные версии программного продукта;
—влияет ли отсутствие предполагаемых изменений на требования к системным интерфейсам, ожидаемый срок службы системы, приоритеты;
—влияние изменений на безопасность и защиту системы при эксплу
атации;
—единовременные и долгосрочные затраты на корректировку;
—преимущества, получаемые после проведения модификации;
—влияние реализации изменений на графики проведения работ по версии программного продукта;
—необходимые процессы верификации, тестирования и оценки ха рактеристик системы и программного продукта после внесения корректи ровки.
Для того чтобы подтвердить актуальность представленных отчетов о дефектах, сопроводитель должен продублировать и верифицировать воз никшие проблемы — дефекты, выполнив следующие этапы решения дан ной задачи: разработать стратегию верификации и квалификационного тестирования для проверки устранения конкретной проблемы — дефекта; провести тестирование для проверки наличия проблемы — дефекта; доку ментально оформить результаты квалификационного тестирования. Если конкретная проблема не может быть повторена сопроводителем, он дол жен проверить правила, политики и документы обеспечения ЖЦ ПС на предприятии. На основе проведенного анализа сопроводитель должен раз работать варианты реализации изменения:
—присвоить соответствующий приоритет проблеме (дефекту) или предложению о модификации;
—установить наличие возможностей и средств для решения проб
лемы;
—оценить масштаб и трудоемкость данной модификации;
—разработать варианты реализации конкретного изменения;
479