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

КЛЮЧЕВЫЕ ПОНЯТИЯ

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

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

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

Наследуемые системы, работающие в деловой сфере, подразделяются на два типа: те, которые работают с транзакциями, и те, которые обрабатывают пакеты данных. Оба типа систем соответствуют структурной модели "вход-процесс-выход".

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

Бизнес-пригодность системы определяется ее возможностью содействовать выполнению бизнес – задач.

Качество системы зависимо от качества бизнес-процесса, качества прикладного ПО, а также качества аппаратных средств и программных средств поддержки.

26.1. Объясните, чем определяется важность наследуемых систем в деловой сфере.

26.2. Приведите три причины усложнения понимания системы вследствие участия многих специалистов в изменениях системы.

26.3. Какие проблемы могут возникнуть в случае программирования разных частей системы на различных языках?

26.4. Какова роль монитора дистанционной обработки при сборе системой данных от разных терминалов? Каким образом современные системы типа клиент/сервер снижают нагрузку на мониторы дистанционной обработки?

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

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

• Учетная запись о работнике содержит тарифный разряд, определяющий размер его заработной платы.

• Сверхурочная работа, если выплаты за нее ниже определенной суммы, оплачивается на уровне основной почасовой ставки. Тариф сверхурочных часов указан в учетных документах работа

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

26.7. Чем можно обосновать списание системы даже тогда, когда она имеет высокие оценки качества и бизнес-пригодности?

26.8. Предложите 10 вопросов, которые можно задать пользователям системы для оценки бизнес-процесса.

26.9. Объясните, почему проблемы с программным обеспечением поддержки могут стать причиной замены наследуемых систем.

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

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

программного

обеспечения

Цели

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

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

□ ориентироваться в принципах сопровождения ПО и понимать причины увеличения расходов на сопровождение систем.

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует три вида сопровождения системы.

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

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

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

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

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

Найти современные данные относительно того, как часто используется тот или иной тип сопровождения, будет нелегко. Согласно исследованиям [218], которые уже несколько устарели, 65% сопровождения связано с выполнением новых требований, 18% отводится на изменения системы с целью адаптации к новому окружению и 17% связано с исправлением ошибок (рис. 27.1.). Десятилетие спустя в работе [259] определены похожие соотношения.

Из этого можно определить, что исправление ошибок не является самым распространенным видом сопровождения. Модернизация системы в соответствии с новым рабочим окружением либо в соответствии с новыми требованиями более эффективна. Поэтому сопровождение само по себе является естественным процессом продолжения разработки системы со своими процессами проектирования, реализации и тестирования. Таким об­разом, спиральная модель, показанная на рис. 27.2, лучше представляет процесс развития ПО, чем каскадная модель (см. рис. З.1.), где сопровождение рассматривается как отдель­ный процесс.

Рис. 27.2. Спиральная модель развития ПО

Значительная часть бюджета большинства организаций уходит на сопровождение ПО, а не на само использование программных систем. В 1980-х годах было обнаружено [218], что во многих организациях по меньшей мере 50% всех средств, потраченных на программирование, идет на развитие уже существующих систем. В работе [235] опреде­лено похожее соотношение затрат на различные виды сопровождения, при этом от 65 до 75% средств общего бюджета расходуется на сопровождение. Так как предприятия заменяют старые системы коммерческим ПО, например программами планирования ресурсов, эти цифры никак не будут уменьшаться. Поэтому можно утверждать, что изменение ПО все еще остается доминирующим в статье затрат организаций на программное обеспечение.

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

надежности таких систем предполагают их жесткую структуру, которая трудно поддается модификации.

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

На рис. 27.3 показано, как снижается стоимость сопровождения хорошо разработанных систем. Здесь при разработке системы 1 выделено дополнительно $25 000 для обеспечения процесса сопровождения. В результате за время эксплуатации системы удалось сэкономить около $100 000. Из сказанного следует, что увеличение средств на разработку системы пропорционально снизит затраты на ее сопровождение.

Рис. 27.3. Расходы на разработку и сопровождение систем

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

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

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

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

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

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

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

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

27.2.1. Процесс сопровождения

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

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

также стоимость внедрения этих изменений. Если принимается я решение о модернизации системы, начинается этап планирования новой версии системы. Во время планирования анализируется возможность реализации всех необходимых изменений, будь то исправление ошибок, адаптация или расширение функциональных возможностей системы. Только после этого принимается окончательное решение о том, какие именно изменения будут внесены в систему. Когда изменения реализованы, выходит очередная версия системы. На рис. 27.4, заимствованном из книги [13], представлен весь процесс модернизации.

Рис. 27.4. Схема процесса модернизации

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

Рис. 21.5. Выполнение модернизации

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

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

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

• Неожиданные изменения в деловой сфере организации (из-за действий конкурентов или из-за введения нового законодательства).

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

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

Рис. 27.6. Процесс экстренной модернизации системы

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

27.2.2. Прогнозирование сопровождения

Менеджеры терпеть не могут сюрпризов, особенно если они выливаются в непредсказуемо высокие затраты. Поэтому лучше предусмотреть заранее, какие изменения возмож­ны в системе, с какими компонентами системы будет больше всего проблем при сопрово­ждении, а также рассчитать общие затраты на сопровождение в течение определенного периода времени. На рис. 27.7 представлены различные типы прогнозов, связанные с со­провождением, и показано, на какие вопросы они должны ответить.

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

1. Количество и сложность системных интерфейсов. Чем больше системных интерфейсов
и чем более сложными они являются, тем выше вероятность изменений в будущем.

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

3. Бизнес-процессы, в которых используется данная система. По мере развития бизнес-
процессы приводят к появлению новых требований к системе.

Чтобы корректно спрогнозировать процесс сопровождения, нужно знать количество и типы взаимосвязей между разными компонентами системы, а также учитывать сложность этих компонентов. Различные виды сложности систем изучались в работах [151, 232]. Другие исследования посвящены взаимосвязям между сложностью систем и процессом сопровождения [18, 195]. Все эти исследования показали, что, чем выше сложность системы и ее компонентов, тем более дорогостоящим окажется сопровождение, чего и следовало ожидать.

Рис. 27.7. Прогнозирование сопровождения

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

1. Количество и сложность системных интерфейсов. Чем больше системных интерфейсов и чем более сложными они являются, тем выше вероятность изменений в будущем.

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

3. Бизнес-процессы, в которых используется данная система. По мере развития бизнес
процессы приводят к появлению новых требований к системе.

Чтобы корректно спрогнозировать процесс сопровождения, нужно знать количество и типы взаимосвязей между разными компонентами системы, а также учитывать сложность этих компонентов. Различные виды сложности систем изучались в работах [151, 232]. Другие исследования посвящены взаимосвязям между сложностью систем и процессом сопровождении [195]. Все эти исследования показали, что, чем выше сложность системы и ее компонентов, тем более дорогостоящим окажется сопровождение, чего и следовало ожидать.

В работе [18] проведено исследование ряда коммерческих программ, написанных языке COBOL, с использованием разных методик измерения сложности, включая раз

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

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

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

1. Количество запросов на корректировку системы. Возрастание количества отчетов о
сбоях в системе означает увеличение количества ошибок, подлежащих исправлению при сопровождении. Это говорит об ухудшении удобства сопровождения.

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

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

4. Количество незавершенных запросов на изменения. С возрастанием количества таких запросов затрудняется сопровождение системы.

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

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

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

Перечислим основные причины перехода от централизованных к распределенным системам.

1. Слтшмшни, аппаратных средств. З акупка и сопровождение распределенных системклиент/сервер обойдется гораздо дешевле, чем покупка мэйнфрейма эквивалентной мощности.

2. Усовершенствование пользовательских интерфейсов. Многие из наследуемых систем, основанных на мэйнфремах, имеют текстовые интерфейсы, основанные на формах. Сегодня пользователям привычнее графические интерфейсы и более простое взаимодействие с системами. Такого рода интерфейсы требуют большего количества локальных вычислений и более эффективно работают в системах клиент/сервер.

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

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

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

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

Рис. 27.8. Идеальная и реальная структуры сист

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

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

Рис. 27.9. Преобразование наследуемой системы в

Несмотря на интеграцию интерфейса пользователя и предоставляемых наследуемой системой сервисов, все-таки при планировании децентрализации лучше рассматривать их в качестве отдельных логических уровней (рис. 27.10).

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

2. Уровень проверки данных связан с управлением вводом-выводом данных, осущест­вляемым конечными пользователями.

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

4. Уровень сервисов приложения отвечает за выполнение основных вычислений приложением.

5. Уровень базы данных отвечает за хранение и управление данными приложения.

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

Рис. 27.10. Многоуровневая модель системы

Рис. 27.11. Варианты распределенных систем

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

27.3.1. Распределение интерфейсов пользователя

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

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

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

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

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

Рис. 27.12. Распределение пользовательских интерфейсов

Промежуточное ПО управления экранами (окнами), показанное на рис. 27.12, осуществляет связь с приложением и действует точно так же, как терминал пользователя. Это программное обеспечение использует описание каждого экрана для интерпретации и вы­вода данных на экран. В таком виде данные пересылаются на машину клиента, где они представляются с помощью графического интерфейса. В настоящее время процесс описания структуры интерфейса можно реализовать с помощью языка XML [326]. В этом случае не обязательно изменять наследуемую систему. Нужно только создать промежуточное ПО управления экранами и программной поддержки интерфейса на машине клиента.

Для реализации распределения пользовательских интерфейсов используются две стратегии.

1. Реализация интерфейса с помощью системы управления окнами, установленной на
машине клиента и осуществляющей связь с сервером.

2. Реализация интерфейса пользователя с помощью Web-броузера.

В первом случае интерфейс создается с помощью подходящего языка программирования, например Java, или с помощью языка сценариев Visual Basic. Для реализации интер­фейса на машине пользователя выполняются запросы к функциям операционной системе. Во втором случае для создания интерфейса на основе Web-страниц применяется язык HTML и Web-броузеры. Каждый подход имеет свои преимущества и недостатки, которые представлены в табл. 27.2.

Таблица 27.2. Преимущества и недостатки стратегий реализация распределенных пользовательских интерфейсов

Стратегия	Преимущества	Недостатки
Реализация с помощью системы управления окнами	Доступ ко всем функциям интерфейса пользователя. Улучшенная работа ин­терфейса пользователя	Зависимость от аппаратной платформы. Трудности согласования интерфейсов
Реализация с по¬мощью Web-броузера	Независимость от аппаратной платфор­мы. Снижение затрат на обучение работе с интерфейсом (интерфейс Web-броузера знаком всем). Легче добиться согласова­ния интерфейсов	Более низкая производительность интерфейса. Возможмости дизайна интерфейса ограничены возможностями Web-броузера

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

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