Процесс сопровождения

Процессы сопровождения могут быть самыми разными, что зависит от типа про­граммного обеспечения, технологии его разработки, а также от специалистов, которые непосредственно занимались созданием системы. Во многих организациях сопровожде­ние носит неформальный характер. В большинстве случаев разработчики получают ин­формацию о проблемах системы от самих пользователей в устной форме. Другие же ком­пании имеют формальный процесс сопровождения со структурированной документацией на каждый его этап. Но на самом общем уровне любые процессы сопровождения имеют общие этапы, а именно: анализ изменений, планирование версий, реализация новой вер­сии системы и поставка системы заказчику.

Процесс сопровождения начинается при наличии достаточного количества запро­сов на изменения от пользователей, менеджеров или покупателей. Далее оцениваются возможные изменения с тем, чтобы определить уровень модернизации системы, а также стоимость внедрения этих изменений. Если принимается решение о модернизации системы, начинается этап планирования новой версии системы. Во время планирова­ния анализируется возможность реализации всех необходимых изменений, будь то ис­правление ошибок, адаптация или расширение функциональных возможностей систе­мы. Только после этого принимается окончательное решение о том, какие именно из­менения будут внесены в систему. Когда изменения реализованы, выходит очередная версия системы. На рис. 4, представлен весь процесс модернизации.

Рис.4. Схема процесса модернизации

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

Рис.5. Выполнение модернизации

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

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

• Изменение рабочего окружения системы с непредусмотренным влиянием на систему.

• Неожиданные изменения в деловой сфере организации (из-за действий конкурен­тов или из-за введения нового законодательства).

В таких случаях быстрая реализация изменений имеет большую важность, чем четкое следование формальностям процесса модернизации системы. Вместо того чтобы изме­нять требования или структуру системы, лучше быстро внести коррективы в программ­ный код (рис. 6). Однако этот подход опасен тем, что требования, системная архитектура и программный код постепенно теряют целостность. Этого трудно избежать, если принять во внимание необходимость быстрого выполнения задания, когда тщательная доработка системы откладывается на потом. Если разработчик, который изменил код, внезапно уходит из команды, то его коллеге будет сложно привести в соответствие сде­ланным изменениям спецификацию и структуру системы.

Рис.6. Процесс экстренной модернизации системы

Еще одна проблема срочных изменений системы состоит в том, что из-за дефици­та времени из двух возможных решений будет принято не самое лучшее (в аспекте со­хранения структуры системы), а то, которое можно быстрее и эффективнее реализо­вать. В идеале после срочной коррекции кода системы запрос на изменения должен все еще оставаться в силе. Поэтому после тщательного анализа изменений можно от­менить внесенные изменения и принять более оптимальное решение для модерниза­ции системы. Однако на практике такая возможность используется крайне редко, ча­ще всего в силу субъективных причин.