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

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

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

 

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

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

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

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

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

 

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

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