Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Верификация и сопровождение ИС.doc
Скачиваний:
91
Добавлен:
19.12.2018
Размер:
1.42 Mб
Скачать

1.14.6.2.. Особенности этапа завершения

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

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

2. Сопровождение информационных систем

2.1. Введение

Положение темы настоящей главы в контексте разработки программного обеспе­чения иллюстрирует рис. 2.1.

Рис. 2.1. Схема разработки программы: тема главы 1

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

По различным оценкам сопровождение программы составляет от 40 до 90 % стоимости всего жизненного цикла приложения (например, [31], [89]). Можно возразить, что в указанное выше определение сопровождения включены усовер­шенствования, которые лучше было бы считать дополнительными разработками. В любом случае объем работ по сопровождению программ обычно достаточно велик. Наиболее значительные усилия в области сопровождения были затраче­ны на решение проблемы 2000 года (Y2K). Изменение приложений для работы с датами, относящимися к новому тысячелетию, потребовало огромного труда. Эти работы относятся именно к сопровождению программ, потому что их целью было сохранение функциональности существующих приложений.

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

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

♦ Проблемы управления:

♦ трудность выявления прибыли на инвестированный капитал.

♦ Проблемы обработки:

♦ для обслуживания потока запросов на сопровождение требуется жест­ кая координация.

♦ Проблемы технического характера:

  • трудность учета всех результатов изменений;

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

Руководство обычно гораздо сильнее интересуется процессом поставки при­ложений. Кроме того, затраты на сопровождение программы трудно классифи­цировать как прибыль на инвестированный капитал.

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

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

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