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

Модернизация программного обеспечения

План

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

2. Сопровождение программного обеспечения

3. Эволюция системной архитектуры

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

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

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

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

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

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

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

Разные стратегии могут также применяться к отдельным частям системы или к отдель­ным программам наследуемой системы. Сопровождение приемлемо для программ со ста­бильной и четкой структурой, не требующей особого внимания. Для других программ, ко­торые постоянно контактируют со многими пользователями, можно изменить архитекту­ру так, чтобы интерфейс пользователя запускался на машине клиента. Еще один компонент в этой же системе можно заменить аналогичной программой стороннего про­изводителя. Однако при реинжениринге обычно необходимо изменять все компоненты системы.

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

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

Под динамикой развития программ подразумевается исследование изменений в программ­ной системе. Результатом исследований в этой области стало появление ряда "законов" Лемана (Lehman), относящихся к модернизации систем. Счи­тается, что эти законы неизменны и применимы практически во всех случаях. Они сформули­рованы после исследования процесса создания и эволюции ряда больших программных систем. Эти законы (в сущности, не законы, а гипотезы) приведены в табл. 1.

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

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

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

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

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

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

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

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

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