О программном сопровождении

Приведенный список факторов не включил обычно приводимое качество: возможность сопровождения (maintainability). Чтобы понять почему, мы должны поближе взглянуть на лежащее в его основе понятие: сопровождение (maintenance) . Сопровождение начинается с момента поставки ПО пользователям.

Обсуждения методологии создания ПО обычно сосредоточивается на фазе разработки; то же находим и во вводных курсах по программированию. Но широко известно, что 70% стоимости ПО приходится на его сопровождение. Никакое изучение качества ПО не может быть удовлетворительным, если оно игнорирует этот аспект.

Что означает сопровождение для ПО? Если на минуту задуматься, то становится ясно, что этот термин употребляется неправильно: ПО не изнашивается от постоянного использования, и ему не требуется такое "обслуживание", как автомобилю или телевизору. Специалисты по программным продуктам используют это слово для описания уважаемых (noble) и не очень уважаемых функций сопровождения. К уважаемой, достойной части работы можно отнести модификацию системы. Поскольку спецификации компьютерных систем меняются, отражая изменения во внешнем мире, должны меняться и сами системы. Наименее уважаемая часть - это запоздалая отладка: удаление ошибок, которых не должно было быть в начале.

Рис. 1.5. Распределение расходов на сопровождение. Источник: [Лиенц, 1980]

Вышеприведенная диаграмма, взятая из ключевого исследования Лиенца и Свонсона, проливает некоторый свет на то, что на самом деле значит включающий разнообразные понятия термин "сопровождение". Исследование рассмотрело 487 систем, разрабатывающих ПО разного рода; возможно, оно немного устарело, но более поздние публикации подтверждают те же общие результаты. Оно показывает долю стоимости, приходящуюся на каждый идентифицированный авторами вид работ по сопровождению.

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

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

Другая известная проблема - Millenium - переход компьютеров на даты нового тысячелетия.

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

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

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

Это так не только потому, что она производится в короткие сроки, но и потому, что она прерывает плановый процесс выпуска новых (безошибочных) вариантов и может дать новые ошибки.

Еще одно интересное наблюдение в распределении затрат по видам деятельности - это сравнительно низкая доля (5,5%) стоимости документации. Помните, что это - стоимость задач, решаемых в период эксплуатации. Наблюдение здесь - или скорее, догадка, при отсутствии более точных данных - таково: проект должен либо заботиться о том, чтобы создание документации стало частью разработки, либо совсем не делать этого. Мы научимся использовать стиль построения, в котором большая часть документации действительно встроена в ПО, и есть специальные инструменты для ее извлечения.

Последние два вида работ дают очень малую долю:

Первый - это улучшение эффективности; похоже, предполагается, что когда система работает, менеджеры проекта и программисты неохотно прерывают ее работу с целью улучшения производительности, предпочитая не трогать довольно хорошую систему. (При рассмотрении принципа "сначала сделай ее хорошо, а потом сделай ее быстрой" многие проекты, возможно, вполне довольствуются первым шагом.)
Небольшие средства тратятся и на "переход к новой аппаратной среде". Из-за отсутствия более детальных данных можно высказать лишь некоторое предположение. Все системы относятся к двум крайним случаям, промежуточные варианты практически отсутствуют. В первом случае системы изначально строятся как переносимые, и потому для них этот вид затрат невелик. Другие настолько тесно привязаны к своей первоначальной платформе и перенос был бы так труден, что разработчики даже не пытаются делать что-то в этом направлении.

Содержание раздела