Понимание программных систем (Program Comprehension)

Техники сопровождения (Techniques for Maintenance)

Данная секция вводит некоторые общепринятые техники, используемые в процессе сопровождения программных систем.

Для реализации изменений программисты тратят значительную часть времени на чтение и формирование понимания программного продукта. Средства работы с кодом являются ключевым инструментом для решения этой задачи. Четкая, однозначная и лаконичная документация обеспечивает адекватное понимание программных систем.

4.2 Реинжиниринг* (Reengineering)

Реинжиниринг определяется как детальная оценка (examination) и перестройка программного обеспечения для формирования понимания, воссоздания (на уровне модели и, в ряде случаев, требований) и дальнейшей реализации его <функций> в новой форме (например, с использованием новых технологий и платформ, при сохранении существующей и расширением и облегчением возможностей добавлений новой функциональности). Отмечается, что в индустрии существуют различные позиции в отношении реинжиниринга – одни считают, что реинжиниринг является наиболее радикальной и затратной формой изменений программных систем, другие, что такой подход может применяться и для не столь кардинальных изменений (например, как смена платформы или архитектуры). Реинжиниринг, обычно, провидится не столько для улучшения возможностей сопровождения (maintainability), сколько для замены устаревшего программного обеспечения. В принципе, реинжиниринг можно рассматривать как самостоятельный проект, включающий в себя, как отмечает SWEBOK, формирование концепции, применение соответствующих инструментов и техник, анализ и приложения опыта проведения реинжиниринга, а также оценку рисков и преимуществ, связанных с такими работами.

Необходимо отметить, что реализация продукта в новом качестве (форме) при сохранении основной функциональности оригинального продукта, является неотъемлемой и определяющей частью реинжиниринга, в отличие от обратного инжиниринга, рассматриваемого ниже и являющегося важной составной частью реинжиниринга.

4.3 Обратный инжиниринг* (Reverse engineering)

“Обратный” инжиниринг (часто путаемый с реинжинирингом, в том числе, в понимании SWEBOK) или это процесс анализа программного обеспечения с целью идентификации программных компонент и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме (уже, в процессе реинжиниринга). Обратный инжиниринг является пассивным, предполагая отсутствие деятельности по изменению или созданию нового программного обеспечения. Обычно, в результате усилий по обратному инжинирингу создаются модели вызовов (call graphs) и потоков управления (control flow graphs) на основе исходного кода системы. Один из типов обратного инжиниринга – создание новой документации на существующую систему (redocumentation). Другой из распространенных типов – восстановление дизайна системы (design recovery).

К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также относятся работы по рефакторингу (см. работы Мартина Фаулера, впервые систематизировавшего и описавшего рефакторинг). Рефакторинг – трансформация программного обеспечения, в процессе которой программная система реорганизуется (не переписываясь) с целью улучшения структуры, без изменения поведения. Сохранение “формы” (платформы, архитектурных и технологических решений) существующей программной системы позволяет рассматривать рефакторинг как один из вариантов обратного инжиниринга.

* для обеих тем – 4.2 и 4.3 возможно применение слова реконструкция, в зависимости от контекста, означающее как полную перестройку или воссоздание чего-либо, идентичного по определенным характеристикам оригинальному образцу, так и восстановление какой-либо сущности по сохранившимся и/или доступным внешним признакам, где восстановление может подразумевать опять-таки создание нового образца или представления об оригинальной сущности.

В принципе, возможно объединение тем данной секции, включая реинжиниринг и обратный инжиниринг, в общую тему 4.1 “Reverse and Re-engineering” данной области знаний “Сопровождение”, с дальнейшей детализаций в виде “под-тем” 4.1.x. Такой подход соответствует структуре SWEBOK. При этом, соответствующая структура может быть организована, например, следующим образом:

• 4.1.1 Формирование представления об эксплуатируемой/сопровождаемой системе: включает восстановление, в первую очередь, бизнес- и функциональных требований к системе;
• 4.1.2 Восстановление детального дизайна системы: включает идентификацию всех компонентов системы и создание модели вызовов и других связей между компонентами;
• 4.1.3 Рефакторинг: как возможный процесс структурных изменений, вносимых в систему, в частности для улучшения возможностей по ее дальнейшему сопровождению (включая модификацию, связанную с расширением функциональности);
• 4.1.4 Переработка системы: создание нового релиза/версии системы в той же форме (например, с использованием той же технологической платформы), что и текущая (эксплуатируемая) версия;
• 4.1.5 Создание новой системы: рассматривает текущую версию и систему в целом, как устаревшую – legacy.

5. Сопровождение программного обеспечения
(Software Maintenance по SWEBOK)

Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK.
Содержит перевод описания области знаний SWEBOK “Software Maintenance”, с замечаниями и комментариями.

Сопровождение программного обеспечения (Software Maintenance)
1. Основы сопровождения программного обеспечения (Software Maintenance Fundamentals)
1.1 Определения и терминология (Definitions and Terminology)
1.2 Природа сопровождения (Nature of Maintenance)
1.3 Потребность в сопровождении (Need for Maintenance)
1.4 Приоритет стоимости сопровождения (Majority of Maintenance Costs)
1.5 Эволюция программного обеспечения (Evolution of Software)
1.6 Категории сопровождения (Categories of Maintenance)
2. Ключевые вопросы сопровождения программного обеспечения (Key Issues in Software Maintenance)
2.1 Технические вопросы (Technical Issues)
2.2 Управленческие вопросы (Management Issues)
2.3 Оценка стоимости сопровождения (Maintenance Cost Estimation)
2.4 Измерения в сопровождении программного обеспечения (Software Maintenance Measurement)
3. Процесс сопровождения (Maintenance Process)
3.1 Процессы сопровождения (Maintenance Processes)
3.2 Работы по сопровождению (Maintenance Activities)
4. Техники сопровождения (Techniques for Maintenance)
4.1 Понимание программных систем (Program Comprehension)
4.2 Реинжиниринг* (Reengineering)
4.3 Обратный инжиниринг* (Reverse engineering)

Результат усилий по разработке программного обеспечения состоит в передачи в эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. Соответственно, в процессе эксплуатации продукт будет изменяться или эволюционировать. Связано это с обнаружением при реальном использовании скрытых дефектов, изменениями в операционном окружении, необходимостью покрытия новых требований и т.п.

Фаза сопровождения в жизненном цикле, обычно, начинается сразу после приемки/передачи продукта и действует в течение периода гарантии или, чаще, технической поддержки. Однако, сама деятельность, связанная с сопровождением, начинается намного раньше.

Сопровождение программного обеспечения является составной частью жизненного цикла. К сожалению, так сложилось, что вопросам сопровождения уделяется существенно меньше внимания, чем другим фазам жизненного цикла. Исторически, в большинстве организаций, разработка программных систем явно в фаворе, по сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний ITIL* – IT Infrastructure Library, уделяющей особое внимание вопросам поддержки и сопровождения инфраструктуры информационных технологий). В большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций организаций непосредственно в разработку программных систем, с целью увеличения сроков использования уже существующего и применяемого ПО. Конечно, с точки зрения автора, это не единственная причина. Скорее вопросы постоянно изменяющихся бизнес-потребностей, динамика бизнеса и желание повысить отдачу от уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения программного обеспечения и естественной интеграции такой деятельности в бизнес-процессы подразделений информационных технологий.

* ITIL, в частности, определяет три аспекта управления жизненным циклом приложений – определение требований, проектирование и разработку, и, наконец, сопровождение. Все это, в контексте программного обеспечения, относится к деятельности по управлению приложениями – Application Management в ITIL ICT Infrastructure Management (ICT - Information and Communications Technology).

Если проблема 2000 года, в свое время, оказала особое влияние на изменение отношения к сопровождению на Западе, то расширение применения продуктов Open Source во всем мире и связанная с ним волна надежд на получение дешевого решения существующих задач привела к тому, что вопросы сопровождения вышли для многих организаций на первый план. Ситуация во многих ИТ-подразделениях показывает, что такие надежды оправдались только частично. Использование продуктов Open Source не стало дешевой альтернативой и, в ряде случаев, привело даже к бОльшим проектным затратам именно в силу недостаточно проработанной политики эксплуатации и сопровождения построенных на их основе прикладных решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”. Это означает только, что игнорирование оценки стоимости сопровождения привело к превышению бюджетов, недостатку ресурсов и, в конце концов, частому провалу инициатив по использованию таких продуктов в корпоративной среде. Неготовность рассматривать жизненный цикл во времени как продолжающийся и после передачи системы в эксплуатацию, непроработанность соответствующих процедур корректировки продукта после его выпуска – основная беда и в бизнесе-среде, для которой программное обеспечение лишь инструмент, и в компаниях-интеграторах, “забывающих” о необходимости развития успеха после внедрения системы у заказчика, и у независимых поставщиков программных продуктов, которые, выпуская новую версию лучшего в своем классе продукта, начинают работать над новой версией, уделяя недостаточное внимание поддержке и обновлению уже существующих версий.

Сопровождение программного обеспечения в SWEBOK определяется как вся совокупность деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки программных систем. Эти работы выполняются как перед вводом системы в эксплуатацию, так и после этого. Предварительные работы включают планирование деятельности по сопровождению системы, а также организацию перехода к ее полнофункциональному использованию. Если новая система должна заменить старую систему, предназначенную для решения тех же задач, просто на новом уровне эффективности, стоимости использования, новых функциональных возможностей, в этом случае важно обеспечить плавный переход со старой системы на новую, максимально естественный для пользователей. С этим связано не только планирование, например, переноса информации, хранимой в соответствующих базах данных, но и обучение пользователей, подготовка, настройка и проверка “боевой” конфигурации, определение последовательности операций, организация и обучение службы поддержки (help-desk) и т.п.

Область знаний “Сопровождение программного обеспечения” связана с другими аспектами программной инженерии. По-сути, описание этой области знаний непосредственно пересекается со всеми другими дисциплинами.

Рисунок 6. Область знаний “Сопровождение программного обеспечения” [SWEBOK, 2004, с.6-2, рис. 1]