5-software_engineering_maintenance (1133545), страница 6
Текст из файла (страница 6)
Организация, ведущаясопровождение, должна определить метрики, по которым будут оцениваться соответствующиеработы. Стандарты IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 9126-01 (SoftwareEngineering – Product Quality – Part 1: Quality Model, 2001 г.) предлагают специализированныеметрики, ориентированные именно на вопросы сопровождения и соответствующие программы.Ниже представлены типичные метрики оценки работ по сопровождению, соответствующихраспространенной классификации эксплуатационных характеристик программного обеспечения: Анализируемость (Analyzability): оценка (в первую очередь, дополнительных) усилий илиресурсов, необходимых для диагностики недостатков или причин сбоев, а также дляидентификации тех фрагментов программной системы, которые должны бытьмодифицированы. Изменяемость (Changeability): оценка усилий, необходимых для проведения заданныхмодификаций. Стабильность (Stability): оценка случаев непредусмотренного поведения системы, включаяситуации, обнаруженные в процессе тестирования. Тестируемость (Testability): оценка усилий персонала сопровождения и пользователей потестированию модифицированного программного обеспечения.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru13Основы программной инженерии (по SWEBOK)Программная инженерия.
Сопровождение программного обеспечения.3. Процесс сопровождения (Maintenance Process)Вопросы организации процесса сопровождения напрямую связаны с соответствующимистандартами и de facto практиками реализации такого процесса. Тема “Работы по сопровождению”(Maintenance Activities) различает вопросы сопровождения и разработки и показывает взаимосвязь cдругими аспектами деятельности программной инженерии.Типичные и распространенные потребности в процессах программной инженерии подробно описаныи документированы в различных источниках. Одна из наиболее детально проработанных ираспространенных (на уровне стандарта de facto) процессных моделей, изначально созданных сориентацией на программное обеспечение – CMMI (Capability Maturity Model Integration –интегрированная модель зрелости), разработанная в Институте программной инженерииуниверситета Карнеги-Меллон (SEI CMU).
CMMI, в частности, уделяет специальное вниманиепроцессам сопровождения. Существуют и другие, менее распространенные, но тем не менееразвивающиеся модели.3.1 Процессы сопровождения (Maintenance Processes)Процессы сопровождения описывают необходимые работы и детальные входы/выходы этих работ.Эти процессы рассматриваются в стандартах IEEE 1219 (Standard for Software Maintenance) иISO/IEC 14764 (Standard for Software Engineering - Software Maintenance).Процесс сопровождения начинается по стандарту IEEE 1219 с момента передачи программнойсистемы в эксплуатацию (post-delivery stage) и касается таких вопросов, как планированиедеятельности по сопровождению (см. рисунок 2).Рисунок 2.
Работы в процессе сопровождения по стандарту IEEE 1219.Стандарт ISO/IEC 14764 уточняет положения, связанные с процессом сопровождения, стандартажизненного цикла 12207. Работы по сопровождению, описанные в этом стандарте аналогичныработам в IEEE 1219, за исключением того, что сгруппированы несколько иначе (см. рисунок 3).Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru14Основы программной инженерии (по SWEBOK)Программная инженерия. Сопровождение программного обеспечения.Рисунок 3. Процесс сопровождения по стандарту ISO/IEC 14764.Работы по сопровождению в стандарте 14764 разбиты на задачи: Process Implementation – реализация процесса Problem and Modification Analysis – анализ проблем и <необходимых> модификаций Modification Implementation –проведение модификаций (реализация изменений) Maintenance Review/Acceptance – оценка и принятие <проведенных работ> присопровождении Migration – миграция (на модифицированную или новую версию программного обеспечения) Software Retirement – вывод из эксплуатации (прекращение эксплуатации программногообеспечения)В представленных в SWEBOK источниках можно найти описание истории эволюциисоответствующих процессных моделей упоминаемых стандартов ISO/IEC и IEEE.
Кроме того,существует и общая (обобщенная) модель процессов сопровождения. Agile-методологии, активноразвивающиеся в последние годы, предлагают “облегченные” (light или lightweight) процессы, в томчисле, и для организации деятельности по сопровождению, например, Extreme maintenance (см.соответствующие источники, указанные в SWEBOK).3.2 Работы по сопровождению (Maintenance Activities)Как уже отмечалось, многие работы по сопровождению похожи на аспекты деятельности поразработке. В обоих случаях необходимо проводить анализ, проектирование, кодирование,тестирование и документирование.
Специалисты по сопровождению должны отслеживатьтребования так же, как и инженеры-разработчики и обновлять документацию по мере разработкии/или выпуска обновленных или новых релизов продукта. Стандарт ISO/IEC 14764 рекомендует,чтобы персонал или организации, отвечающие за сопровождение, в случае использованияэлементов процессов разработки в своей деятельности, адаптировали эти процессы <целиком> всоответствии со своими потребностями. В то же время, деятельность по сопровождению обладает иопределенными уникальными чертами, что приводит к необходимости использованияспециализированных процессов.3.2.1 Уникальные работы (Unique activities)Существует ряд процессов, работ и практик, уникальных для деятельности по сопровождению.SWEBOK приводит следующие примеры такого рода уникальных характеристик:Передача (Transition): контролируемая и координируемая деятельность по передачепрограммного обеспечения от разработчиков группе, службе или организации, отвечающейCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru15Основы программной инженерии (по SWEBOK)Программная инженерия.
Сопровождение программного обеспечения.за дальнейшую поддержку;Принятие/отклонение запросов на модификацию (Modification Request Acceptance/Rejection):запросы на изменения могут как приниматься и передаваться в работу, так и отклоняться поразличным обоснованным причинам – объему и/или сложности требуемых изменений, атакже необходимых для этого усилий. Соответствующие решения могут также приниматьсяна основе приоритетности, оценке обоснованности, отсутствии ресурсов (в том числе,отсутствия возможности привлечения разработчиков к решению задач по модификации, приреальном наличии такой потребности), утвержденной запланированности к реализации вследующем релизе и т.п..Средства извещения персонала сопровождения и отслеживания статуса запросов намодификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk):функция поддержки конечных пользователей, инициирующая работы по оценке (assessment,подразумевая в том числе оценку необходимости), анализу приоритетности и стоимостимодификаций, связанных с поступившим запросом или сообщенной проблемой.Анализ влияния (Impact Analysis): анализ возможных последствий изменений, вносимых всуществующую систему - рассматривался выше в теме 2.1.3.Поддержка программного обеспечения (Software Support): работы по консультированиюпользователей, проводимые в ответ на их информационные запросы (request for information),например, касающиеся соответствующих бизнес-правил (см.
область знаний “Требования кпрограммному обеспечению”), проверки, содержания данных и специфических (ad hoc)вопросов пользователей и их сообщений о проблемах (ошибках, сбоях, непредусмотренномуповедению, непониманию аспектов работы с системой и т.п.).Контракты и обязательства: к ним относятся классическое соглашение об уровнепредоставляемого сервиса - Service Level Agreement (SLA), а также другие договорныеаспекты, на основании которых, группа/служба/организация по сопровождению выполняетсоответствующие работы.На практике сложно провести грань между разделяемыми в SWEBOK функциями Help Desk иSoftware Support –эти функции, обычно, совмещены с процессной точки зрения.3.2.2 Дополнительные работы, поддерживающие процесс сопровождения (Support activities)Столь длинный перевод названия данной темы связан с содержанием соответствующих работ,описываемых SWEBOK, как работы персонала сопровождения, не включающие явноговзаимодействия с пользователями, но необходимые для осуществления соответствующейдеятельности.
К таким работам относятся: планирование сопровождения. Конфигурационноеуправление (software configuration management), проверка и аттестация (V&V – verification andvalidation), оценка качества программного обеспечения (software quality assessment), различныеаспекты обзора, анализа и оценки (reviews), аудит (audit) и обучение (training) пользователей.Также, к таким специальным (внутренним) работам относится обучение персонала сопровождения.В силу особой значимости (с точки зрения автора - обязательности) ряда упомянутых работ, импосвящены следующие под-темы данной секции области знаний по сопровождению программногообеспечения.3.2.3 Работы по планированию сопровождения (Maintenance planning activity)Планирование является более чем необходимым для адекватного проведения работ посопровождению и должно касаться связанных с этим вопросов с нескольких точек зрения: Бизнес-планирование (организационный уровень) Планирование непосредственных работ по сопровождению (уровень передачи программногообеспечения – см.