Эксплуатация и сопровождение

С учетом затрат на эксплуатацию и сопровождение временные затраты на разработку программной системы можно представить так (рис. 2.5):

1) анализ требований;

2) определение спецификаций;

3) проектирование;

4) кодирование;

5) автономное тестирование;

6) комплексное тестирование;

7) сопровождение.

Рис. 2.5 — Временные затраты на реализацию этапов жизненного цикла программного обеспечения

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

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

2. Могут быть обнаружены ошибки, пропущенные при тестировании.

3. Могут потребоваться специальные модификации системы для частных условий функционирования, связанные с различными применениями.

4. Сопровождение многочисленных компонентов системы.

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

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

Пусть некоторая система содержит компоненты A, B, C и установлена у потребителей I, II, III (рис. 2.6).

Рис. 2.6 — Исходные системы потребителей

В процессе эксплуатации системы потребитель I обнаружил ошибку и сообщил об этом разработчику. Последний корректирует ее и направляет исправленный модуль A’ всем пользователям системы. Опыт применения надежного программного обеспечения показывает, что большинство потребителей ведет себя осторожно в отношении внесенных изменений. Поэтому потребители II и III, не встречаясь с задачами, решаемыми потребителем I, продолжают использовать первоначальный вариант системы, поддерживая принцип «если система работает, не вмешивайся». Спустя некоторое время потребители I и II обнаружили другую ошибку в модуле A. Разработчик должен определить, являются ли обе обнаруженные ошибки одной и той же, поскольку использовались различные версии модуля A. Исправление ошибки ведет к корректировке модуля A и A’, в результате чего в эксплуатацию вводятся модули A’’ и A’’’. Теперь функционируют уже три версии системы (рис. 2.7).

Рис. 2.7 — Система после исправления двух ошибок

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

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