Возраст и структура программы

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

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

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

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

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

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

В качестве примера можно привести Window XP компании Microsoft. Длительность фазы поддержки для программных продуктов фирмы, как правило, 5 лет с момента реализации продукта. В ходе фазы обычной поддержки Microsoft выпускает доработанные обновления, доступные всем желающим. В ходе фазы расширенной поддержки обновления безопасности также доступны всем пользователям, а иные обновления – лишь компаниям, которые подпишут с Microsoft контракт на поддержку. Online поддержка доступна как минимум 12 месяцев с момента окончания поддержки. Но Windows XP поддерживается рекордно долгое время в связи с тем, что многие пользователи не желали переходить на Windows Vista в ожидании Windows 7. Таким образом обычная поддержка уже истекла 14 апреля 2009г., а расширенная закончится только 8 апреля 2014.

Еще один пример: сопровождение продукта Лабораторией Касперского осуществляется в течение 36 месяцев с момента коммерческого релиза используемой всеми версии продукта.

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

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

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

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

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

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

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