Организация и управление процессом сопровождения
Организация процесса сопровождения подразумевает выполнение следующих действий:
- определение цели и состава процессов сопровождения;
- определение причин и видов изменения программных средств в процессе сопровождения;
- организация процессов и передача на сопровождение разработанного программного средства;
- заключение договора между заказчиком и исполнителем на сопровождение программного средства;
- разработка концепции методов и процессов сопровождения программного продукта;
- разработка спецификации требований на модификации при сопровождении программного средства;
- утверждение заказчиком концепции, договора и технического задания на сопровождение программного продукта;
- организация контроля реализации концепции и договора на сопровождение программного продукта.
Данная последовательность действий рассматривается с позиции концепции сопровождения, в которой учитывается и область сопровождения изменений программной системы, выраженная в виде совокупности тех или иных видов работ.
Существует несколько подходов к организации процесса сопровождения. Один из них можно представить в виде схемы, изображен ной на рис. 25.4.
Рисунок 25.4. Организация процесса сопровождения.
Здесь пп. 1.1 – 1.4 фактически относятся к этапу разработки и подразумевают попытку предугадать направления будущих изменений требований к продукту и учесть их в плане. Пункт1.1 можно реализовать посредством применения соответствующих образцов проектирования. Пункт 1.2 легко реализуется через подробные комментарии и должное форматирование кода, облегчающее сопровождение. Пункт 2 предназначен для оценки объема и классификации работ на сопровождение.
Пункт 3 соответствует выбору службы поддержки: это может быть своя собственная служба или специальная сторонняя компания. План сопровождения (п. 4) регламентирует поток запросов на сопровождение внутри организации. Оценка затрат (см. п. 5 на рис. 25.4) более подробно будет рассмотрена далее. Типичный план сопровождения приведен на рис. 25.5, где жирной линией отмечена номинальная последовательность обработки запросов.
Рисунок 25.5. Типичная последовательность работ по сопровождению.
Отдел сопровождения получает от пользователей или заказчиков предложения и жалобы, которые оформляются как запросы на сопровождение. В дальнейшем разработчик принимает решение о последующей реализации запросов и присваивает каждому из них приоритет. Затем запросы обслуживаются техническим персоналом службы сопровождения. Тонкие линии означают другие последовательности появления и исчезновения запросов. В общем случае порядок и длительность работ определяется масштабами проекта, а сам процесс реализации запросов сопряжен с двумя проблемами: доставкой готового кода пользователям и борьбой с дефектами.
Для устранения дефектов можно применять так называемые исправления, или заплатки (patch), суть которых заключается в изменениях кода, позволяющих либо устранить дефект, либо обойти его. Возможный вариант работы с исправлениями приведен на рис. 25.6.
Рисунок 25.6. Сопровождение и исправление.
Преимущества и недостатки исправлений представлены в табл. 25.1. Исправления должны иметь временный характер: они используются до получений полноценной версии программного продукта с внесенными изменениями в рамках запроса на сопровождение.
Таблица 25.1. Преимущества и недостатки исправлений
| Преимущества | Недостатки |
| Быстрая удовлетворенность заказчиков | Дублирование работ: необходима реализация как временного, так и постоянного исправления |
| Возможность непрерывной работы и тестирования без широкого распространения дефектов | Иногда patch не заменяется соответствующей версией программного продукта |
| Исключено скрытие других дефектов | Затруднен выпуск постоянного исправления, предназначенного для устранения временного |
| Возможность тестировать исправление | Затруднен процесс документирования |
Обработка запросов на сопровождение (см. п. 6 на рис. 25.4) включает в себя все стадии разработки ПО, однако необходимым становится процесс анализа влияния изменений на артефакты системы. Согласно проведенным исследованиям, 19 % дефектов в приложении возникают на этапе определения требований, 52 % – на стадии проектирования и 7 % – в процессе программирования. Влияние устранения дефекта на артефакты иллюстрирует рис. 25.7.
Самый простейший случай соответствует внесению изменений в единственный артефакт (например, некорректное именование переменной или освобождение ресурсов после использования). Наиболее сложный случай характеризуется распространением изменений на все артефакты и этапы разработки (например, изменение требований).
Рисунок 25.7. Примеры влияния дефектов на сопровождение
(закрашены этапы, подвергшиеся влиянию дефекта.
Работы по сопровождению. Рассмотрим работы по сопровождению в контексте некоторых стандартов. В частности, стандарт IEEE 1219 определяет следующие работы: корректировка, адаптация и совершенствование состоит из семи стадий, которые приблизительно соответствуют стадиям процесса разработки. Это определение задачи, анализ, проектирование, реализация, системное тестирование, приемо-сдаточное тестирование и поставка. Каждая из стадий оперирует шестью одинаковыми артефактами (рис. 25.8).
Рисунок 25.8. Работы по сопровождению согласно IEEE 1219 и их атрибуты.
Стандарт ISO/IEC 14764 (Standard for Software Engineering) оперирует четырьмя составляющими:
1) корректирующее сопровождение– «реактивная» модификация программного продукта, выполняемая после передачи в эксплуатацию для устранения сбоев;
2) адаптирующее сопровождение– модификация программного продукта на этапе эксплуатации для обеспечения продолжения его использования с заданной эффективностью в условиях изменений бизнес–окружения, порождающих новые требования к системе;
3) совершенствующее сопровождение– модификация программного продукта на этапе эксплуатации для повышения характеристик производительности и удобства сопровождения;
4) профилактическое сопровождение– модификация программного обеспечения на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до их проявления в реальных сбоях.
Стандарт ISO/IEC 14764 классифицирует адаптивное и совершенствующее сопровождение как работы по расширению функциональности продукта, а корректирующую и профилактическую деятельности – как корректировку системы. Таким образом, согласно ISO/IEC 14764 все работы по сопровождению можно разбить на категории, реализующие «проактивный» и «реактивный» подходы (табл. 25.2).
Таблица 25.2. Виды сопровождения
| Подходы | Корректирующие работы | Работы по расширению |
| Проактивный | Профилактическое сопровождение | Совершенствующее сопровождение |
| Реактивный | Корректирующее сопровождение | Адаптирующее сопровождение |
Исследования показали, что 60 – 80 % объема работ относится к усовершенствованию приложения.
Стандарт ISO/IEC 14764 уточняет положения по сопровождению стандарта жизненного цикла 12207, а работы в нем, в отличие от IEEE1219, сгруппированы несколько иначе (рис. 25.9).
Рисунок 25.9. Процесс сопровождения по стандарту ISO/IEC.
Технические вопросы процесса сопровождения. Особое внимание следует уделить ряду технических вопросов, касающихся процесса сопровождения, которые можно разделить на следующие группы: ограниченное понимание ПС, тестирование, анализ влияния, возможность сопровождения. Рассмотрим подробнее некоторые из них.
Ограниченное понимание ПС связано в первую очередь с тем, что специалисты по сопровождению, как правило, не занимались разработкой сопровождаемого ПО. Поэтому до 60 % усилий может быть потрачено на анализ и понимание сопровождаемого программного продукта. На данном этапе определяющим фактором является наличие качественной (в плане соответствия реальному состоянию кода и полноте содержания) документации к программному продукту. Затраченные на понимание программной системы усилия можно уменьшить, если использовать соответствующие методологии (например, UML 2.0) или инструменты (например, обеспечивающие обратный инжиниринг для полного соответствия модели и программного кода). Важно также приводить документацию в соответствие с изменениями, внесенными при реализации запросов на сопровождение.
При работах по сопровождению возможно распространения так называемой «ряби», когда многочисленные незначительные изменения различных частей при определенных условиях приводят к неадекватной работе системы в целом. В этом случае есть смысл провести выборочное регрессионное тестирование.
Анализ влияния необходим для оценки всех возможных последствий и влияний изменений, вносимых в существующую систему. Для качественного анализа персонал сопровождения должен обладать как можно большей (в идеале – на уровне разработчиков) информацией о системе, ее специфике, содержании и структуре. При этом следует также учесть влияние изменений на окружение сопровождаемого продукта в виде других программных систем, функционирующих в том же операционном или системном пространстве.
Цели анализа влияния можно сформулировать следующим образом:
- определение содержания изменений для работ по планированию и реализации;
- получение максимально возможной оценки ресурсов, необходимых для проведения соответствующих работ;
- анализ стоимости и выгоды от внесения запрошенных изменений (обычно касается пожеланий запросов на расширение системы;
- обсуждение сложности вопросов, связанных с внесением соответствующих изменений.
Сложность реализации соответствующего запроса на сопровождение часто является основным фактором, определяющим сроки и способы решения проблемы. Если система изначально разрабатывалась с учетом дальнейшей поддержки (например, использовались соответствующие образцы проектирования), то осуществить анализ влияния значительно легче.
Возможность сопровождения в IEEE (стандарт 610.12 – 90, обновленный в 2002 г.) определяется как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований. Стандарт ISO/IEC 9126 – 01 определяет возможность сопровождения как одну из характеристик качества.
Для уменьшения стоимости дальнейшего сопровождения на протяжении всего цикла процесса разработки необходимо специфицировать, оценивать и контролировать характеристики, влияющие на возможность сопровождения. Одной из ключевых проблем сопровождения является отсутствие системной документации к программному продукту.
Управление процессом сопровождения. Управленческие вопросы можно разделить на следующие группы: согласование с организационными целями, кадровое обеспечение, организация процесса сопровождения, организационные аспекты сопровождения, аутсорсинг.
Согласование с организационными целями описывает, как осуществить возврат инвестиций от деятельности по сопровождению. Организационные цели сопровождения направлены на максимальное продление срока эксплуатации программного продукта, а деятельность по сопровождению есть обновление и расширение программной системы как отклик на изменяющиеся потребности пользователей. Такая постановка задачи приводит к трудности выявления прибыли на инвестированный капитал.
Проблемы кадрового обеспечения связаны с тем, что инженеры по сопровождению, как правило, считаются в компаниях–разработчиках специалистами «второго класса», поэтому часто возникают проблемы с удержанием квалифицированного персонала в отделах сопровождения.
Организация процесса сопровождения во многом схожа с организацией процесса создания программного обеспечения. В общем случае результатом итерации сопровождения является новая версия программного продукта, которая проходит практически все этапы разработки.
Организационные аспекты сопровождения связаны, в первую очередь, с тем, кто (какая организация) будет осуществлять сопровождение системы. Если сопровождение будет осуществляться силами разработчика, то необходимо определиться со структурными подразделениями, участвующими в этом процессе. Возможно также привлечение сторонних организаций. Преимуществами последнего подхода являются возможность выбора сопровождающей организации из нескольких альтернатив (что позволяет выбрать подходящую стоимость сопровождения), а также появление у разработчика возможности заниматься другими видами работ (не сопровождением).
Основным недостатком считается постепенная потеря разработчиками контроля над кодом созданной системы.
Аутсорсинг подразумевает полную передачу непрофильных работ сторонним организациям. Лишь незначительная часть крупных корпораций использует аутсорсинг и только для некритичных компонентов, выполняющих не очень важные бизнес–функции, поскольку они не хотят терять контроль над ассоциированными с этими системами данными или функциональностью. К тому же сама процедура передачи системы на внешнее сопровождение не отражена в стандартах, что затрудняет документальное определение предоставляемых аутсорсером сервисов.
Поскольку реализация запроса на сопровождение есть процесс, охватывающий практически все аспекты разработки, то применение общих (для всего жизненного цикла) метрик, разработанных SEICMU (Software Engineering Institute, Carnegie–Mellon University) считается адекватным. Эти метрики охватывают такие аспекты, как размер, усилия, расписание и качество.
Инструменты процесса сопровождения. Важным моментом при организации процесса сопровождения является выбор инструментов, поддерживающих работы по сопровождению.
Выделяют две категории инструментов сопровождения. Во–первых, инструменты облегчения понимания, которые помогают человеку в понимании программ. Примерами могут служить различные средства визуализации. Во–вторых, инструменты реинжиниринга, которые поддерживают деятельность по реинжинирингу.
Средства «обратного» инжиниринга помогают в процессе восстановления таких артефактов, как спецификация и описание дизайна(архитектуры) существующего ПО, которые в дальнейшем могут быть трансформированы для генерации нового продукта на основе функциональности существующего.
Следует заметить, что функциональность современных средств проектирования, поддерживающих анализ исходного кода (в случае объектно–ориентированных систем) и его визуализацию (в том числе и поведенческую, например, в виде соответствующих диаграмм UML), позволяет объединить упомянутые категории инструментов в единый класс «инструментов реинжиниринга». В то же время деятельность по сопровождению и поддержке, в частности касающаяся сбоев и исправления обнаруженных в ПО ошибок, требует, в определенной степени, отнесения к этой категории и средств конфигурационного управления (например, в части обработки запросов на изменения).
Особенностью инструментов реинжиниринга является сочетание в одной среде инструментов для специалистов двух областей: непосредственно реинжиниринга бизнес–процессов и разработчиков программного обеспечения, поддерживающего модифицируемый бизнес–процесс.
Для контроля изменений в рамках всего ЖЦ ПО используются средства управления запросами на изменение, которые также могут быть использованы для поддержки процесса реализации запроса на сопровождение, поскольку и устранение дефектов, и расширение функциональности связано с изменением многих артефактов продукта.
В общем случае любой из продуктов, поддерживающих процесс«понимания» программных систем и контроля изменений, можно использовать как инструмент сопровождения.
Весь процесс разработки программной системы можно назвать термином «инжиниринг», поскольку система отражает необходимую специфику предметной области, детально изученную разработчиками. Частью процесса эволюции программного продукта является его реинжиниринг
Существуют следующие подходы к определению реинжиниринга.
1. Реинжиниринг – это повторная реализация наследуемой системы с целью повышения удобства ее эксплуатации и сопровождения.
2. Реинжиниринг – это детальная оценка и перестройка ПО для формирования понимания, воссоздания (на уровне модели и, в ряде случаев, требований) и дальнейшей реализации его функциональности в новой форме. Сам реинжиниринг проводится не столько для улучшения возможностей сопровождения, сколько для замены старого ПО новыми версиями.
3. Реинжиниринг программного обеспечения в ряде случаев связывается с реинжинирингом какого–либо бизнес–процесса (BPR – Buisness Process Reengineering). Последний характеризуется совершенствованием внутренних процессов, протекающих внутри фирмы или ее структурных подразделений, что обязательно приведет к модификации обслуживающего их ПО.
В рамках первого подхода функциональность системы и ее архитектура не изменяются, а работы по сопровождению в рамках реинжиниринга касаются перевода системы на более современный язык программирования, ее повторного документирования, реорганизации и реструктуризации, модификации и модернизации структуры системы и системных данных. Поэтому есть смысл рассматривать реинжиниринг как один из способов сохранения наследуемых систем в эксплуатации, зарекомендовавших себя хорошо с коммерческих позиций, особенно если сама система обладает определенной коммерческой ценностью, а ее сопровождение дорого.
Значительными плюсами реинжиниринга являются снижение рисков (система не разрабатывается заново, поэтому все крупные риски уже учтены) и снижение затрат (реинжиниринг обходится дешевле разработки новой системы примерно в 4 раза). Основное различие между инжинирингом и разработкой новой системы связано со стартовой точкой начала работ (рис. 25.10).
Рисунок 25.10. Традиционная разработка и реинжиниринг.
Один из возможных вариантов организации реинжиниринга представлен на рис. 25.11, где выделены следующие основные этапы:
- перевод исходного кода – конвертирование программы со старого языка программирования на его новую версию или другой язык;
- анализ программы – документирование структуры и функциональных возможностей программы на основе их анализа;
- модификация структуры программы – изменение управляющей структуры программы для упрощения и наилучшего понимания;
- разбиение программы на модули – группировка взаимосвязанных частей программы в модули для устранения избыточности и оптимизации структуры, функциональности и интерфейса;
- изменение системных данных – приведение данных, с которыми работает программа, к виду, соответствующему нововведениям, например изменение типа базы данных, с которой работает система.
Рисунок 25.11. Процесс реинжиниринга.
Второй подход характеризуется перепланированием приложения, когда программные продукты, взятые за базу, перепроектируются в соответствии с изменившимися требованиями, например, адаптированная ролевая игра может являться частью системы для обучения менеджменту, выполняющей моделирование взаимодействия обучаемых в рамках тестовых примеров (рис. 25.12).
Рисунок 25.12. Реинжиниринг ролевой видеоигры для обучения менеджменту.
Третий подход рассматривает реинжиниринг как самостоятельный проект, включающий в себя формирование концепции, применение соответствующих инструментов и техник, анализ и использование опыта проведения реинжиниринга, оценку рисков и преимуществ, связанных с такими работами. В результате продукт реализуется в новом качестве при сохранении функциональности оригинального продукта.