И. Соммервилл - Инженерия программного обеспечения (1133538), страница 144
Текст из файла (страница 144)
Модерниэация программного обеспечения 653 27.1. Динамика развития программ Под динамикой развития программ подразумеваетсл исследование изменений в программной системе. Основной работой в этой области является [21 Я) . Результатом этих исследований стало появление рлда "законов" Лемана (Еапшап), относящихся к модернизации систем.
Считал кя, что эти законы неизменны и применимы практически во всех случаях. Они сформулированы после исследования процесса создания и эволюции ряда больших программных систем. Эти законы (в сущности, ие законы, а гипотезы) приведены в табл.
27.1. Таблица 27.1. Законы Лемана Описание Закон Для программ, эксплуатируемых в реальных условиях, людерни- зация — это необходимость, иначе их полезность снижается Непрерывность мо- дернизации По мере развития программы становятся все более сложными. Лля упрощения или сохранения их структуры необходимы до. полн ител ьн ые затраты Процесс развития систем саморегулирусмый. Такие характери- стики системы, как размер, время между выпусками очередных версий и количество регистрируемых ошибок, для каждой вер- сии программы остаются практически неизменными Жизненный цика системы относительно стабилен, независимо от средств, выделяемых (или не выделяемых) на ее развитие За весь жизненный цикл системы количество изменений в каж- дой версии остается приблизительно одинаковым Возрастающая слож- ность Эволюция больших систем Организационная ста- бильность Стабильность количе- ства изменений Из первого закона вытекает необходимость постоянного сопровождения системы.
При изменении окружения, в котором работает система, появляются новые требования, и система должна неизбежно изменятьсл с тем, чтобы им соответствовать. Изменения сис. темы носят циклический характер, когда новые требования порождают появление новой версии системы, что, в свою очередь, вызывает изменения системного окружения; это на.
ходит отражение в формировании новых требований к системе и т.д. Второй закон констатирует нарушение структуры системы после каждой модифнка. ции. Это в полной мере демонстрируют наследуемые системы, которые рассматриваются в главе 26. Рдинственным способом избежать этого, по всей видимости, являетсл только профилактическое обслуживание, которое, однако, требует средств и вреиеии. При этом совершенствуется структура програииы без изменения ее функциональности. Поэтому в бюджете, предусмотренном на содержание системы, следует также учесть и эти дополнительные затраты. Самым спорным и, пожалуй, самым интересным законом Лемана является третий. Со. гласно этому закону, все большие системы имеют собственную динамику изменений, которая устанавливается на начальном этапе разработки системы. Этим определяются возможности сопровождения системы и ограничивается количество модификаций.
Предполагается, что этот закон является результатом действия фундаментальных структурных и организационных факторов. Как только система превышает определенный размер, она начинает действо. вать подобно некой инерционной массе. Размер становится препятствием для новых изменений, поскольку эти изменения с большой вероятностью стэн)т причиной ошибок в системе. которые снизят эффективность нововведений в новой версии системы.
554 Часть Ч11. Эволюция программного обеспечения Четвертый закон Лемана утверждает, что крупиыс проекты по разработке программноп> обеспечения действуют в режиме "насыщения". Это означает, что изменения рсгтрсов илн персонала оказывает незначительное влияние иа долгосрочное развитие системы. Это, правда, уже указано в третьем законе, который утверждает, что развитие программы не зависит от решений менеджмента. Этим законом также угверждается, что крупныс команды программистов неэффективны, так как время, потраченное па общение и внугрикомапдные связи, превьипает время непосредственной работы пал системой. Пятый закон затрагивает проблему > величания количества изменений с каждой новой версией програмл>ы.
Расширение функциональных возможностей системы каждый раз сопровождается новыми ошибками в системс. Такил> образом, масштабное расширение функциоиэльных возможностей в одной версии означает необходимость последуюигих доработок и исправления ошнб >к. Поэтому в след>ющей версии >же булут проведены незначительные модификации. Таким образом, менеджер, формируя бюджет ллл внесения крупных изменений в версию системы, нс должен забывать о иеоб>ходимости разработки следую>цей версии с исправленными ошибками ирсдылущей версии. В основном законы Лел>ана выгллдят весьма разумными и убедительными.
При планировании сопровождения онн обязательно должны )шить>ваться. Случается, что по коммерческим соображениям законами следует пренебречь. Например, это может быть обу словлено маркетингом, если существует необходимость провести ряд модификаций системы в одной версии. В результате все равно получится так, что одна или несколько слслующнх версий булут связаны с исправлением ошибок. Может показаться, что больп>ие различил между последовательными версиями одной и той же программы опроверги)т законы Лемана.!.1ап ример, М1 его>ой Уйогб яре врат>шась пз простой программы текстовой обработки, требующей 2б Кбайт памяти, в огромную систему с множеством функций.
Теперь, для того чтобы работать с этой программой, нужно много памяти и быстролействующий процессор. Эволюция этой программы противоречит четвертому и пятому законам Лемана. Однако я подозреваю, что это все-таки пе одна и та же программа, которал просто подверглась ряду изменений. Думаю, програм. иа бьша существенно переработана; по сути, была разработана новая программа, но в рекламных целях был сохранен единый логотип. 27.2.
Сопровождение программного обеспечения Сопровождение — это обычный процесс измсиеиил системы после сс поставки заказчику. Эти изменения могут быть как элементарно простыми (исправление ошибок программирования), так и более ссрьезиьв>и, связанными с корректировкой отдельных недоработок либо иривелснием в соответствие с новыми требованиями. Как упоминалось в вводной части главы, сопровождение пс свлзапо со значительным изменением архитектуры системы. При сопровождении тактика простая: изменение суя!сств>ющих компонентов системы либо добавление новых.
Существует три вида сопровождения системы. 1. Сал!>ееожденке е >!елью келрлвлеккл ошибок. Обычно ошибки в программировании достаточно легко устранимы, однако оп>ибки проектирования столт дорого и требуют корректировки илн перепрограммирования некоторых компонентов. Самые дорогие исправления связаны с ошибками в системных требованиях, так как здесь мо. жст поналобитьгл перепроектирование системы. 27. Модернизация программного обеспечения 555 2. Согфовождение с Вельт адаптации ПО к епенифи ~есхии условиям экспаутапдии. Это может потребоваться при изменении опрелсленных составляющих рабочего окр>жения системы, например аппаратных средств, операционной системы или про. граммных средств поддержки.
Чтобы адаптироваться к зтнм нзменениялг, система должна быть подвергнута определенным модификациям. $. Сопровождение с келью изпенения функциональных возяожкагаий систаны. В ответ па организационные илн деловые изменения в организации могут измениться требования к программным средствам. В таких случаях применяется данный тип гопровождспия.
Наиболее существенные изменения при атом претерпевает именно программное обеспечение. На практике однозначно четкое разграничение между различньщщ вилами сопровождения провести достаточно сложно. Ошибки в системе могут быть вьшвлспы в том случае, если, например, система использовалась непредсказуемым способом. Поэтому наилучший способ исправленил ошибок — расширение функциональных возможностей программы с тем, чтобы сделать работу с ней как можно проще. При адаптации программного обеспечения к новому рабочему окружению расширение 4>ункциоиальных возможностей системы будет способствовать >л> ппепию сс работы.
Также добавлсщн определенных функций в программу может оказаться полсзцым, если в случае ошибок был изменен шаблон ис. пользования системы н побочным действием при расширении функцнонаяьных возможностей будет удаление ошибок. Перечисленные тины соцровожления широко используются, хотя пм подчас д:иот разные названия. Сопровождение с целью исправления ошибок обычно называют корректирующим. Название "алаптивное сопровождение" может относиться как к адаптации к новому рабочему окружению, так и к новым требованиям.
Усовершенствование программного обеспечения может означать улучшение путем соответствия новым требованиям, а также усовершенствование структурга и производительности с сохранением фупкпнонаяьпых возможностей. Я намеренно не употребляю здесь все зтн названия, чтобы избежать излишней путаницы.
Рис 27.1. Расгфеделение тинов сопровождение 556 'Хасть У1х. Эволюция программного обеспечения Найти современные данные относительно того, как часто используется тот или иной тип сопровождения, будет нелегко. Согласно исследованиям (218), которые уже несколько устарели, 65% сопровождения связано с выполнением новых требований, 18% отводится на изменения системы с целью адаптации к новому окружению и 17% связано с исправлением ошибок (рис. 27.1.). Десятилетие спустя в работе (259) определены похожие соотношения. Из этого можно определить, что исправление ошибок не является самым распространенным видом сопровождения.
Модернизация системы в соответствии с новым рабочим окр>жением либо в соответствии с новыми требованиями более эффективна. Поэтому сопровождение само по себе является естественным процессом продолжения разработки системы со своими процессами проектирования, реализации и тестирования. Таким образом, спиральная модель, показанная на рис. 27.2, лучще представляет процесс развитив ПО, чем каскадная модель (см, рис. 3.1.), где сопровождение рассматривается как отдельный процесс. Рис 27 2. Сяир<ыъмлл мо<>гла)в<звитияПО Значительная часть бюджета большинства организаций уходит на сопровождение ПО, а пе на само использование программных систем.