Описаниеконцепции сопровождения должно быть первым шагом при разработке политики сопровождения ПС. Она должна быть разработана при первом выпуске исходного программного продукта и отражать'.
область сопровождения и изменений программного продукта;
практическое применение (адаптацию) данного процесса;
определение предприятия и лиц, ответственных за сопровождение;
оценку стоимости и длительности сопровождения.
Область сопровождения должна определять обязанности сопроводителя и какую поддержку программному продукту он обязан обеспечить. Она зачастую определяется наличием соответствующих ресурсных и бюджетных ограничений и должна охватывать'.
типы допустимых изменений и процедур сопровождения;
обеспечиваемый уровень обучения персонала сопровождения;
обеспечение поставки модифицированных версий программного продукта;
возможность организации справочной службы — «горячей линии».
Концепция должна учитывать задачи сопровождения программного продукта после его поставки. Важной частью концепции сопровождения является определение ресурсов и специалистов (физических или юридических), отвечающих за сопровождение продукта. Это в равной степени справедливо и в случае внутреннего сопровождения в самой организации. При выполнении сопровождения по соглашению с третьей стороной это должно быть отмечено в концепции сопровождения. Выбор сопроводителя должен быть основан на ряде факторов '.
срок службы программного средства;
размер первичных и долгосрочных затрат на сопровождение;
знание сопроводителем предметной области применения программного продукта.
Должна быть проведена оценка условий финансирования и стоимости сопровождения. Стоимость зависит от размера области сопровождения. Дополнительными факторами, подлежащими учету, являются стоимость: обучения как сопроводителей, так и пользователей; среды программного инструментария, тестирования и их ежегодного сопровождения. При разработке концепции сопровождения стоимость оценивают на основе ограниченных исходных данных. В дальнейшем эти оценки должны быть уточнены.
Разработку и утверждение в концепции спецификаций требований к функциональным характеристикам и качеству программного продукта с учетом выполненных изменений целесообразно проводить итерационно. Полная и однократная формализация требований к характеристикам каждой крупной модификации в начале жизненного цикла ПС обычно невозможна, прежде всего, из-за разных представлений заказчика и разработчиков о деталях ее назначения, функций и возможностей реализации при доступных ресурсах. Чем крупнее и сложнее проект ПС и соответственно выше его стоимость, тем тщательнее следует разрабатывать требования к его характеристикам сопровождения и распределять ресурсы на их реализацию.
При первоначальном определении требований к функциональной пригодности и к конструктивным характеристикам заданные заказчиком ограничения ресурсов не всегда могут учитывать ряд особенностей сопровождения проекта, что обусловит недопустимое снижение (или завышение) требований к некоторым характеристикам модифицированного ПС. Кроме того, возможно, что некоторые характеристики или их изменения противоречивы или принципиально нереализуемы в данном проекте. В результате несбалансированные требования и доступные ресурсы проявятся в виде потерь в качестве или в потребности выделения дополнительных ресурсов.
В зависимости от сложности проекта окончательным результатом работ при прогнозировании изменений комплекса программ должны быть детализированные и утвержденные требования к номенклатуре, свойствам и значениям качества программного продукта, которые достаточны для его полноценного сопровождения и последующей эффективной эксплуатации. Эти требования закрепляются в концепции, контракте и техническом задании, по которым сопроводитель впоследствии должен отчитываться перед заказчиком при завершении модификаций. Однако на последующих этапах жизненного цикла и при конфигурационном управлении требования могут изменяться по согласованию между заказчиком и разработчиком, которые чаще всего приурочиваются к подготовке новой базовой версии ПС. Для этого необходим мониторинг функциональной пригодности, масштаба проекта, требований и реализаций характеристик в течение всего ЖЦ ПС.
Принципиальные и технические возможности, точность реализации свойств и измерения значений характеристик ПС, а также общие ресурсы конкретного проекта всегда ограничены в соответствии с их содержанием и возможностями заказчика и разработчиков. Это определяет рациональные диапазоны значений каждого изменения, которые могут быть выбраны в концепции сопровождения ПС на основе требований заказчика, здравого смысла, а также путем анализа пилотных проектов и прецедентов в спецификациях требований реализованных модификаций. При ограниченности ресурсов проекта крупного ПС распределение приоритетов должно становиться более строгим и могут снижаться приоритеты изменений характеристик, для реализации которых ресурсов недостаточно. В результате формируется полный набор требуемых функциональных и конструктивных характеристик качества в процессе сопровождения ПС.
Требования к функциональным характеристикам и качеству, утвержденные после проектирования концепции, могут быть закреплены в техническом задании как обязательные для детального и рабочего проектирования модификаций (см. рис. 15.1). Эти данные могут использоваться при последующем оценивании качества и при их сопоставлении с требованиями в процессе квалификационных испытаний, сертификации модификаций или новой базовой версии программного продукта.
Для заказчика и пользователей при сопровождении может иметь значение не только определение функциональной пригодности, но и оценка потенциального спроса на рынке конкретного программного продукта, а также его конкурентоспособности с другими аналогичными по функциям ПС с учетом его качества и стоимости. Это обстоятельство может определять необходимость контроля реализации и уточнения требований к отдельным характеристикам не только при сопровождении в ЖЦ ПС, но также для оценивания интегрального качества нового программного продукта, поставляемого на рынок.
Этапы и процедуры при сопровождении
программных средств
В соответствии с требованиями стандарта ISO 12207 по развитию и модификации программного продукта в жизненном цикле должен быть организован процесс его сопровождения (см. п. 5.5). Работы, обеспечивающие сопровождение ПС, включают:
подготовку процесса;
анализ проблем и изменений;
внесение изменений;
проверку и приемку при сопровождении;
перенос;
снятие с эксплуатации.
Эти разделы и соответствующие процессы детализированы в стандарте ISO 14764 и с рядом комментариев изложены ниже. После активизации процесса следует разработать план сопровождения и соответствующие процедуры, а также выделить конкретные ресурсы для сопровождения. После поставки заказчику программного продукта сопроводитель, в соответствии с договором и предложением о модификации или отчетом о дефекте, должен изменить соответствующие программы и документы. Исходные данные преобразуют или используют в работах по сопровожде
нию для получения выходных результатов — модифицированных версий программного продукта. Рекомендуется проводить регулярный контроль с целью проверки корректности выходных результатов конкретных работ по сопровождению.
Рис. 15.2
При подготовке процесса сопроводитель должен создать планы и определить процедуры, выполняемые при реализации сопровождения (рис. 15.2). План сопровождения целесообразно создавать параллельно с планом разработки первой, базовой версии ПС. При выполнении данной работы сопроводитель также должен определить необходимые организационные интерфейсы и взаимосвязи между специалистами и с другими предприятиями. Исходными данными для работ по подготовке процесса являются: старая (исходная) базовая версия программного продукта; системные документы; предложения о модификациях и отчеты о дефектах. Для обеспечения эффективной реализации процесса сопровождения сопроводителю следует разработать и документально оформить стратегию проведения сопровождения, один из ключевых факторов в применении и развитии ПС. При реализации этой деятельности сопроводитель должен: разработать планы и процедуры сопровождения; установить процедуры рассмотрения предложений о модификации и отчетов о дефектах; применить управление конфигурацией.
Сопроводитель должен разработать, документально оформить и выполнить планы и процедуры для проведения работ и решения задач процесса сопровождения. В плане сопровождения следует описать стратегию сопровождения системы, а в процедурах сопровождения должны быть определены подробности выполнения этапов и процессов сопровождения. Для обеспечения создания эффективных планов и процедур сопровождения сопроводитель должен:
выполнить оценку сопровождаемой системы;
гарантировать официальное подтверждение принятия на себя обязанностей сопроводителя программного продукта;
провести анализ доступных ресурсов для сопровождения;
оценить и согласовать с заказчиком финансирование и стоимость сопровождения;
установить требования к процессу передачи программного продукта сопроводителю;
определить подлежащие реализации процессы сопровождения;
документально оформить процесс сопровождения в виде планов и процедур, согласованных с заказчиком.