2.2. Организация процесса сопровождения

Блок-схема организации процесса сопровождения приведена на рис. 2.2. Пункты \а-\д фактически относятся к этапу разработки. «Разработка с учетом сопровождения» подразумевает попытку предугадать, в каких направ­лениях будут развиваться требования к продукту, и учесть это в плане. С этой целью часто применяются, например, образцы проектирования. «Удобство под­держки» в пункте \б означает возможность эффективного сопровождения. Для этого в код должны включаться подробные комментарии. Персонал, занимаю­щийся сопровождением, имеет обычно не столь специализированные знания, как разработчики, потому что сопровождение требует работы с гораздо большим объемом кода. Тем не менее служба сопровождения должна быть способна после внимательного изучения кода прийти к пониманию смысла каждой инструкции. Только после этого допустимо внесение изменений. Удобство поддержки гаран­тируется постоянным уровнем качества кода.

Рис. 2.2. Схема организации процесса сопровождения

Пункт 2 состоит в принятии решения о масштабах затрат на сопровождение: главным образом речь идет о том, следует ли относить усовершенствования к ра­ботам по сопровождению.

Согласно пункту 3, вам предстоит выбрать, своими или наемными силами вы­полнять работы по сопровождению. Заключение контракта на сопровождение про­граммы обладает преимуществами конкурентоспособной цены и дает возмож­ность владельцу приложения сосредоточиться на других задачах. Недостаток в том, что ваши сотрудники постепенно теряют контроль над кодом приложения.

Следует различать работы по сопровождению, направленные на устранение дефектов (fixing) и на усовершенствование (enhancing) приложения. Различные исследования показали, что 60-80 % работ обычно относится к усовершенствова­нию приложения, а не к исправлению его недостатков.

Лиенц, Свенсон и др. дополняют иерархию работ, разбивая каждую из опре­деленных выше категорий на две (рис. 2.3).

Рис. 2.3. Виды работ по сопровождению

Приспособление, или адаптация (adaptive maintenance), относится к исправ­лению недостатков, потому что функциональность приложения в результате не изменяется и никакого усовершенствования не происходит.

Необходимость упреждающего сопровождения (preventive maintenance) сле­дует из наблюдений Лемаша: без специальных поправок структура сопровождаемой программы постепенно усложняется и со временем становится настолько сложной, что стоимость ее изменения становится неприемлемой.

2.3. Методы сопровождения

2.3.1. Анализ влияния факторов

Последовательность обработки запросов на сопровождение состоит из анали­за, проектирования и реализации, точно так же, как и обычная разработка. Суще­ственным отличием является необходимость анализа влияния изменений на артефакты. Согласно исследованию Вейсса, 19 % дефектов в приложени­ях образуются на этапе определения требований, 52 % – на этапе проектирова­ния и 7 % – в процессе программирования. Многие другие авторы утверждают, что доля дефектов, вызванных неправильной формулировкой требований, долж­на быть значительно выше. Влияние устранения дефекта на артефакты иллю­стрирует рис. 2.4.

В случае минимального влияния изменения вносятся в один-единственный артефакт. Это происходит, например, при нарушении программистом стандарта именования локальных переменных или при удалении неиспользованной пере­менной из программы. Напротив, в худшем случае изменения распространяются на все этапы процесса. Даже для дефекта, возникшего на уровне кода (то есть де­фекта, связанного лишь с неправильным кодированием), степень влияния может быть как малой, так и весьма значительной. Кажущееся простым изменение, на­пример увеличение размера статического массива в C++, может вызвать силь­ную «рябь» по всему приложению.

Рис. 2.4. Влияние дефекта на сопровождение