С учетом затрат на эксплуатацию и сопровождение временные затраты на разработку программной системы можно представить так (рис. 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 — Система после исправления двух ошибок
Во многих случаях большая часть усилий разработчиков затрачивается на повторное обнаружение ошибок, выявленных ранее в других версиях. Чтобы исключить лавинообразное нарастание версий, системы обычно корректируются в определенные промежутки времени, называемые периодами обновления.
Многочисленные проблемы, возникающие на этапе сопровождения системы, должны решаться с привлечением концепции «базы данных системы». Формирование такой концепции начинается на этапе определения спецификаций. Эта база данных должна учитывать требования различных заказчиков и включать средства индикации, тестирования и устранения ошибок, применяемые для корректировки систем.