Введение
Сопровождение информационных систем
Особенности этапа завершения
Влияние несогласованности документации на процесс разработки. Трассировка изменений на программный код. Первичная инспекция проектной документации, как правило, проводится тогда, когда сама программная система еще не написана. Однако при проведении инспекции изменений в требованиях к уже работающей системе (например, при обновлении ее версии), может потребоваться комплексная одновременная инспекция документации и созданного на ее основе программного кода. При этом может возникнуть ситуация, когда изменения, которые требуется внести в документацию по результатам инспекции, требуют соответствующего изменения в программном коде. Решение этой проблемы достигается использованием трассировочных таблиц.
Несколько иная ситуация возникает в случае, когда комплексная инспекция проводится не после изменения требований, а после завершения всей цепочки изменений – после изменения функциональных требований, архитектуры, низкоуровневых требований и программного кода. В этом случае при обнаружении противоречивых требований необходимо выявить все части программной системы, которые реализуют эти требования. В случае, если разработка этих частей выполнялась разными людьми, могла различаться и трактовка противоречивых требований. В этом случае ликвидация противоречивости может повлечь за собой «волну изменений» в проектной документации и исходных текстах системы. Для того, чтобы избежать «волн изменений» по завершению инспекций рекомендуется проводить ее поэтапно до начала следующего этапа жизненного цикла или до разработки документов следующего уровня детализации.
Положение темы настоящей главы в контексте разработки программного обеспечения иллюстрирует рис. 2.1.
Рис. 2.1. Схема разработки программы: тема главы 1
Сопровождение программного продукта включает в себя все действия, выполняемые с приложением после поставки продукта заказчику. В словаре IEEE сопровождение программы определяется как процесс изменения программной системы или компонента после поставки с целью исправления ошибок, повышения производительности или иных параметров, а также для адаптации к изменившимся условиям.
По различным оценкам сопровождение программы составляет от 40 до 90 % стоимости всего жизненного цикла приложения (например, [31], [89]). Можно возразить, что в указанное выше определение сопровождения включены усовершенствования, которые лучше было бы считать дополнительными разработками. В любом случае объем работ по сопровождению программ обычно достаточно велик. Наиболее значительные усилия в области сопровождения были затрачены на решение проблемы 2000 года (Y2K). Изменение приложений для работы с датами, относящимися к новому тысячелетию, потребовало огромного труда. Эти работы относятся именно к сопровождению программ, потому что их целью было сохранение функциональности существующих приложений.
Лехман предложил «закон», заключающийся в том, что любая программа, адаптацией которой к изменяющимся условиям никто не занимается, с течением времени неизбежно теряет свою ценность. Другими словами, если приложение остается неизменным, польза от него постепенно убывает.
Чтобы представить, какие проблемы возникают при сопровождении программ, вообразите приложение настолько большое, что ни один человек не может знать всех его функций и особенностей. Большую проблему в сопровождении таких программ создает «эффект ряби», возникающей при внесении изменений. Когда множество относительно безвредных изменений производятся одновременно в «удаленных уголках» больших приложений, эти изменения могут приводить к повреждению приложения как целого. Беннетт упорядочил проблемы, связанные с сопровождением программ, разделив их на три категории.
♦ Проблемы управления:
♦ трудность выявления прибыли на инвестированный капитал.
♦ Проблемы обработки:
♦ для обслуживания потока запросов на сопровождение требуется жест
кая координация.
♦ Проблемы технического характера:
♦ трудность учета всех результатов изменений;
♦ высокая стоимость тестирования по сравнению с пользой от отдельных изменений: идеальным было бы сосредоточенное тестирование, но оно стоит дорого. Невозможно полностью исключить регрессионное тестирование.
Руководство обычно гораздо сильнее интересуется процессом поставки приложений. Кроме того, затраты на сопровождение программы трудно классифицировать как прибыль на инвестированный капитал.
Если бы мы имели дело с одним конкретным изменением, проблемы были бы еще не так велики. Обычно организации сталкиваются с непрерывным потоком запросов на сопровождение. Большое количество изменений позволяет снизить стоимость каждого из них, но поток запросов создает повышенные требования к системе обработки. Усилия программистов, тестеров и разработчиков документации нужно координировать. В любом случае согласованность документации и исходного кода будет время от времени нарушаться. Без внимательного руководства эти кратковременные, казалось бы, несоответствия начнут размножаться, в результате чего документация перестанет соответствовать реальным функциям приложения, и никто не будет знать, что же на самом деле творится с приложением.
Суть в том, чтобы сделать изменения понятными и даже элегантными. Элегантность хорошо иллюстрирует следующий пример: можно увеличить полезное пространство в доме, пристроив к нему сарай, а можно сохранить цельность здания, увеличив его объем искусными архитектурными приемами. Пристройка может ухудшить внешний вид и структуру всего здания, а хороший архитектор всегда постарается этого избежать.
Тестирование – еще одна важная техническая проблема. Даже сосредоточенное тестирование измененных или добавленных компонентов отнимает достаточно времени, потому что для этого часто приходится разрабатывать специальные планы. Но сосредоточенного тестирования недостаточно, потому что возможность распространения «ряби», вызванной изменениями, требует проведения регрессионного тестирования, которое могло бы исключить ухудшение имевшейся функциональности приложения. Затраты на тестирование составляют значительную долю общих затрат на сопровождение программы.