МОДЕРНИЗАЦИЯ ПО

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

Как только ПО вводят в эксплуатацию, возникают новые требования к

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

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

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

Это предусматривает дополнительные вложения в эволюцию уже

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

Чаще всего используемый подход, заключается в изменении

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

Более радикальный подход, чем сопровождение ПО, так как предполагает

существенные изменения в программной системе.
1. Реинжиниринг программного обеспечения.

Кардинально отличается от других подходов, так как модернизация

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

Это исследование изменений в программной системе. Результатом стало

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

Изменения системы носят циклический характер:

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

системное окружение;

это формирует новые требования к системе и т.д.

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

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

Например, это может быть вызвано маркетингом, если существует

необходимость провести ряд модификаций системы в одной версии.

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