Добавлен: 25.10.2018
Просмотров: 6996
Скачиваний: 27
документации для решения возникающих проблем <при эксплуатации> или
реализации потребностей в улучшениях <тех или иных характеристик
продукта>. Задача состоит в модификации продукта при условии сохранения
его целостности. Международный стандарт ISO/IEC 14764 (Standard for
Software Engineering - Software Maintenance) определяет сопровождение
программного обеспечения в тех же терминах, что и стандарт 12207,
придавая особое значение работам по подготовке к деятельности по
сопровождению до передачи системы в реальную эксплуатацию, например,
вопросам планирования регламентов и операций по сопровождению.
Природа сопровождения (Nature of Maintenance)
Сопровождение
поддерживает
функционирование
программного
продукта на протяжении всего операционного жизненного цикла, то есть
периода его эксплуатации. В процессе сопровождения фиксируются и
отслеживаются запросы на модификацию (также называемые “запросами на
изменения” – change requests, в частности, в контексте конфигурационного
управления),
оценивается
влияние
предлагаемых
изменений,
модифицируется код и другие активы (артефакты) продукта, проводится
необходимое тестирование и, наконец, выпускается обновленная версия
продукта. Кроме того, проводится обучение пользователей и обеспечивается
их ежедневная поддержка при работе с текущей версией продукта. В
SWEBOK отмечается, что сопровождение, с точки зрения операций
отслеживания и контроля, обладает большим содержанием, чем разработка (в
общем понимании). С точки зрения автора, объем и активность операций по
контролю разработки в большой степени зависит от сложившихся практик,
внутрикорпоративных регламентов и требований, а также применяемых
методологий и концепции управления (в частности – проектного
менеджмента). Так или иначе, отслеживание и контроль – ключевые
элементы деятельности по сопровождению программного обеспечения (как и
других ИТ-активов предприятия).
Стандарт 12207 определяет понятие “maintainer” - в соответствующем
ГОСТ он именуется как “персонал сопровождения”, подразумевая
организацию, выполняющая работы по сопровождению. SWEBOK
использует данный термин, также, и в отношении лиц (individuals),
проводящих определенные работы по сопровождению, в отличие, например,
от разработчиков, занимающихся реализацией системы в программном коде.
Стандарт жизненного цикла 12207 также идентифицирует основные
работы по сопровождению: реализация процесса <сопровождения>, анализ
проблем и модификаций (изменений), реализаций модификаций, обзор
(оценка)/принятие <решений> по сопровождению, миграция (с одной версии
программного продукта на другую, с одного продукта на другой) и вывод
системы из эксплуатации. Эти работы описываются далее в теме 3.2 “Работы
по сопровождению” (Maintenance Activities).
Специалисты по сопровождению (персонал сопровождения) могут
получать знания
о
программном
продукте
непосредственно от
разработчиков. Взаимодействие с разработчиками и раннее привлечение этих
специалистов помогает уменьшить усилия, необходимые для адекватного
сопровождения программной системы. По мнению автора, передача знаний
персоналу сопровождения, его обучение, должно начинаться не позднее
начала опытной эксплуатации продукта. В противном случае, усилия на
одновременную
поддержку
прикладной
системы
и
обучение
соответствующих специалистов не только превысит реально допустимые
нормы загрузки персонала (как группы или службы сопровождения и
техподдержки, так и разработчиков системы), но снизит эффективность
поддержки пользователей на критически важном этапе первоначального
использования новой системы. По опыту автора и результатам обсуждения
этого вопроса с сотрудниками внутрикорпоративных ИТ-департаментов,
обычно, в зависимости от сложности системы, пик нагрузки на службу
сопровождения приходится в течении первых 2 - 6 недель, с момента
передачи системы в реальную эксплуатацию, тем более, при отказе от
использования старой системы или ее предыдущей версии. SWEBOK
отмечает, что, в некоторых случаях, инженеры (создававшие систему) не
могут быть привлечены к обучению и поддержке персонала сопровождения.
Особенно часто это касается тиражируемых или “коробочных” систем. Это
создает дополнительные трудности для специалистов, обеспечивающих
сопровождение. В то же время, инженеры, занимающиеся технической
поддержкой (несколько боле узкий круг в команде сопровождения,
включающей менеджеров, администраторов и других специалистов), должны
(в зависимости от типа продукта) иметь доступ к активам проекта (например,
описанию его внутренней архитектуры), включая код, документацию и т.п.
Именно таким образом начинает формироваться информационная
инфраструктура службы технической поддержки и сопровождения у
производителей программных продуктов.
Практика показывает, что инженеры по технической поддержке
производителя программного обеспечения (не только “коробочного”, но и
создаваемого и настраиваемого интеграторами, обладающими собственными
программными решениями) должны не просто иметь доступ ко всем
ключевым активам проекта (код, документация, спецификации требований,
внутренние модели и т.п.), но в их обязанности входит создание “патчей”
(patch – “заплата”), исправлений ошибок и, в особых случаях, такие
изменения, до выпуска новой версии продукта, создаются с привлечением
непосредственно разработчиков продукта (групп и подразделений R&D –
Research
and
Development).
При
этом,
разработчики
продукта
информируются о найденных ошибках и, в случае нахождения
соответствующих решений специалистами технической поддержки, такие
решения передаются разработчикам с тем, чтобы те либо включили такие
изменения в новую версию программного продукта (безусловно, в случае
успешного прохождения всех необходимых тестов), либо нашли более
адекватное решение в контексте новой функциональности либо тех
изменений, которые включены в новую версию продукта. В обязанности
инженеров службы сопровождения, в общем случае, входит: проверка
пользовательского сценария, приводящего к сбою; идентификация причин
сбоя, т.е локализация ошибки/причин ее появления; предоставление
соответствующих исправлений или, при невозможности создания таковых на
данном этапе либо в заданные сроки – предоставление обходного пути
решения проблемы для достижения требуемых бизнес-задач (такие обходные
пути, обычно, называют “workaround”); журналирование всех работ и
операций; помещение описания проблемы и ее решения в базу знаний
службы сопровождения; передача всей информации разработчикам;
своевременное информирование пользователя о статусе запроса и некоторые
другие работы, содержание которых может варьироваться, в зависимости от
регламентов и корпоративных стандартов в конкретной организации, либо
параметров контракта на сопровождение и техническую поддержку, если
таковой есть.
Потребность в сопровождении (Need for Maintenance)
Сопровождение необходимо для обеспечения того, чтобы программный
продукт на протяжении всего периода эксплуатации удовлетворяет
требованиям пользователей. Деятельность по сопровождению применима для
программного обеспечения, созданного с использованием любой модели
жизненного цикла и методологии разработки. На первый взгляд, это
утверждение SWEBOK может показаться тривиальным. Однако, обратитесь к
своему опыту разработки и использования различного программного
обеспечения. Наверняка, Вы найдете случаи из собственной практики или
практики коллег, когда столь очевидное утверждение хорошо бы донести до
разработчика того или иного программного продукта. Изменения
программной системы могут быть обусловлены как действиями по
корректировке ее поведения или несвязанные с необходимостью
корректировки (подразумевая уже не исправление ошибок, а, например,
повышение производительности или расширение функциональности).
В общем случае, работы по сопровождению должны проводиться для
решения следующих задач:
устранение сбоев;
улучшение дизайна;
реализация расширений (функциональных возможностей);
создание интерфейсов взаимодействия с другими (внешними)
системами;
адаптация (например, портирование) для возможности работы на
другой аппаратной платформе (или обновленной платформе),
применения новых системных возможностей, функционирования в
среде обновленной телекоммуникационной инфраструктуры и т.п.;
миграции унаследованного (legacy) программного обеспечения;
вывода программного обеспечения из эксплуатации.
Деятельность персонала сопровождения включает четыре ключевых
аспекта: поддержка контроля (управляемости) программного обеспечения в
течение всего цикла эксплуатации:
поддержка модификаций программных систем;
совершенствование существующих функций;
предотвращение падения производительности программной системы
до неприемлемого уровня.
Автор убежден, что говоря о предотвращении деградации
производительности, мы должны понимать, что это, при всем желании
совершенствования системы, может делаться и за счет обновления мощности
аппаратной
части
и/или
соответствующей
телекоммуникационной
инфраструктуры, если это более обосновано, чем модификация самой
программной системы. На самом деле это вопрос того, что окажется дешевле
(и менее рискованно), т.е. связано с затратами/ стоимостью соответствующих
работ, оборудования и поддержки обновленного системного окружения (что,
к сожалению, часто также не учитывается даже при более-менее
сложившейся практике сопровождения).
Приоритет стоимости сопровождения (Majority of Maintenance Costs)
Работы по сопровождению потребляют если не большую (как отмечает
SWEBOK), то значительную часть финансовых ресурсов жизненного цикла
программного
обеспечения.
Общее
понимание
сопровождения
подразумевает лишь устранение сбоев. Однако, исследования и опросы на
протяжении многих лет показывают, что более 80% усилий по
сопровождению связаны не столько устранением сбоев, сколько с другими
работами, не связанными с исправлением дефектов. Многие менеджеры по
сопровождению
объединяют
в
отчетности
вопросы
расширения
функциональности и исправления ошибок в поддерживаемых программных
системах. Такое смешение качественно различных работ приводит к
неправильному представлению о реальной, на самом деле, не столь высокой
стоимости сопровождения в части устранения дефектов. Понимание
различных категорий работ в рамках деятельности по сопровождению
помогает понять структуру реальных затрат. Кроме того, понимание
факторов, влияющих на возможности сопровождения системы, помогают не
только сохранять необходимый уровень затрат, но и снижать их.
Существуют как технические, так и другие (например,
организационные, являющиеся, по мнению автора, наиболее сильно
влияющими на объем затрат) факторы, оказывающие влияние на стоимость
сопровождения, в целом:
тип приложения;
новизна программного обеспечения;
наличие и квалификация персонала по сопровождению;
длительность использования программной системы;
характеристики и специфика аппаратной части (а также
телекоммуникационной инфраструктуры);
качество дизайна (например, модульность или масштабируемость),
кода, документации и соответствующих работ по тестированию
системы.
Эволюция программного обеспечения (Evolution of Software)
В 1969 году Леман (см. рекомендуемую литературу к данной секции
SWEBOK) впервые связал деятельность по сопровождению и вопросы
эволюции программного обеспечения. Результаты более чем 20-ти летних
исследований во главе с Леманом привели к формулированию ряда важных
положений, ключевое из которых утверждает, что деятельность по
сопровождению, по-сути, представляет собой эволюционную разработку
программных систем. Принятию тех или иных решений в процессе
сопровождения, помогает понимание того, что происходит с программной
системой в процессе ее эксплуатации. Существующее (особенно,
корпоративное) программное обеспечение никогда не бывает полностью
завершенным и продолжает эволюционировать в течение всего срока
эксплуатации. В процессе эволюционирования, программная система
становится все более сложной до тех пор, пока не предпринимаются
специальные усилия (в том числе, в рамках специального проекта по
модификации) по уменьшению его сложности.
В то же самое время, если можно выделить тенденции развития
программной системы и ее поведение достаточно стабильно, его
эволюционирование можно измерить. Последние годы делаются попытки
разработать соответствующие модели оценки усилий по сопровождению. В
результате уже создаются определенные средства (численные и
инструментальные) управления работами по сопровождению, ряд из которых
приводится в ссылках к данной секции SWEBOK.
Категории сопровождения (Categories of Maintenance)