Модернизация ПО

Невозможно создать систему, которая не потребует изменений в будущем.

Þ Как только программное обеспечение вводится в эксплуатацию, возникают новые требования к системе, обусловленные непрерывным развитием бизнес-процессов и все возрастающими общими требованиями к программным системам.

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

Все это требует дальнейшего развития системы после ее ввода в эксплуатацию.

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

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

Существует несколько стратегических подходов к процессу модернизации ПО.

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

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

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

Разные стратегии могут также применяться к отдельным частям системы или к отдельным программам наследуемой системы.

· Сопровождение приемлемо для программ со стабильной и четкой структурой, не требующей особого внимания.

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

· Еще один компонент в этой же системе можно заменить аналогичной программой стороннего производителя.

· Однако при реинжениринге обычно необходимо изменять все компоненты системы.

Изменения в ПО служат причиной появления многочисленных версий системы и ее компонентов.

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

Динамика развития программ

Под динамикой развития программ подразумевается исследование изменений в программной системе.

Результатом исследований динамики развития стало появление ряда "законов" Лемана (Lehman), относящихся к модернизации систем.

Считается, что эти законы неизменны и применимы практически во всех случаях. Они сформулированы после исследования процесса создания и эволюции ряда больших программных систем.

Эти законы (в сущности, не законы, а гипотезы) приведены в табл. 27.1.

Таблица 27.1. Законы Лемана

Закон	Описание
1. Непрерывность модернизации	Для программ, эксплуатируемых в реальных условиях, модернизация - это необходимость, иначе их полезность снижается
2. Возрастающая сложность	По мере развития программы становятся все более сложными. Для упрощения или сохранения их структуры необходимы дополнительные затраты
3. Эволюция больших систем	Процесс развития систем саморегулируемый. Такие характеристики системы, как размер, время между выпусками очередных версий и количество регистрируемых ошибок, для каждой версии программы остаются практически неизменными
4. Организационная стабильность	Жизненный цикл системы относительно стабилен, независимо от средств, выделяемых (или не выделяемых) на ее развитие
5. Стабильность количества изменений	За весь жизненный цикл системы количество изменений в каждой версии остается приблизительно одинаковым

 

Из первого закона вытекает необходимость постоянного сопровождения системы.

При изменении окружения, в котором работает система, появляются новые требования, и система должна неизбежно изменяться с тем, чтобы им соответствовать.

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

Второй закон констатирует нарушение структуры системы после каждой модификации. Это в полной мере демонстрируют наследуемые системы.

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

Самым спорным и, пожалуй, самым интересным законом Лемана является третий. Согласно этому закону,

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

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

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

Четвертый закон Лемана утверждает, что крупные проекты по разработке программного обеспечения действуют в режиме "насыщения". Это означает,

что изменения ресурсов или персонала оказывает незначительное влияние на долгосрочное развитие системы.

Это, правда, уже указано в третьем законе, который утверждает,

что развитие программы не зависит от решений менеджмента.

Этим законом также утверждается, что

крупные команды программистов неэффективны, так как время, потраченное на общение и внутри командные связи, превышает время непосредственной работы над системой.

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

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

Поэтому в следующей версии уже будут проведены незначительные модификации.

Таким образом, менеджер, формируя бюджет для внесения крупных изменений в версию системы, не должен забывать о необходимости разработки следующей версии с исправленными ошибками предыдущей версии.

В основном законы Лемана выглядят весьма разумными и убедительными. При планировании сопровождения они обязательно должны учитываться.

Случается, что по коммерческим соображениям законами следует пренебречь.

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

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

Может показаться, что большие различия между последовательными версиями одной и той же программы опровергнут законы Лемана. Например, Мicrоsоft Word превратилась из простой программы текстовой обработки, требующей 25 Кбайт памяти, в огромную систему с множеством функций. Теперь, для того чтобы работать с этой программой, нужно много памяти и быстродействующий процессор. Эволюция этой программы противоречит четвертому и пятому законам Лемана.

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