Наследуемые системы

Цели

Цель настоящей главы— ввести читателя В тему наследуемых систем и показать структуру таких систем Прочитав эту главу, вы должны:

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

□ знать общие структуры наследуемых систем

□ понимать принципы функционально - ориентированного проектирования, на котором основывается большинство стратегий по paзработке следуемых систем;

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

Содержание

26.1. Структуры наследуемых систем

26.2. Проектирование наследуемых систем

26.3. Оценивание наследуемых систем

Для приобретения программного обеспечения компании обычно должны выложить немалую сумму. Естественно, чтобы оправдать затраты, программные продукты должны находиться в использовании по крайней мере несколько лет. Жизненный цикл программ может быть самым разным, но, как правило, большие системы успешно функционируют и более десяти лет. Некоторые компании не отказываются и от таких систем, которым уже по 20 лет и более. От многих из них все еще зависит деятельность крупных компаний, и малейшая ошибка в системе приводит к сбою их деловой активности. Именно такие сис­темы и получили название наследуемых (legasy system).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для приобретения программного обеспечения компании обычно должны выложить немалую сумму. Естественно, чтобы оправдать затраты, программные продукты должны находиться в использовании по крайней мере несколько лет. Жизненный цикл программ может быть самым разным, но, как правило, большие системы успешно функционируют и более десяти лет. Некоторые компании не отказываются и от таких систем, которым уже ПО 20 лет и более. От многих из них все еще зависит деятельность крупных компаний, и малейшая ошибка в системе приводит к сбою их деловой активности. Именно такие сис­темы и получили название наследуемых (legasy system).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26.1. Структуры наследуемых систем

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

Логические составляющие наследуемых систем и взаимосвязи между ними перечислены ниже и показаны на рис. 26.1.

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

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

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

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

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

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

Рис. 26.1. Компоненты наследуемых систем,

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

На практике вмешательство в один уровень обязательно повлечет за собой изменения на других уровнях. Это происходит по нескольким причинам.

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

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

3. Сохранение интерфейсов аппаратных средств со временем часто становится
возможным, особенно в случае кардинальных изменений в аппаратном обеспечении. Такое может случиться с компанией, которая решит перейти от мэйнфреймов (больших ЭВМ) к системе клиент/сервер (см. главу 11), где, как правило, работают c разными операционными системами. В этом случае необходима серьезная модернизация прикладного программного обеспечения.

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

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

Рис. 26.3. Наследуемые прикладные системы

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

Рис. 26.4. Система с централизованной базой данных

Запросы на обновление информации могут поступать с различных терминалов и в разное время. Возьмем для примера банковскую систему, насчитывающую сотни терминалов, с которыми работают кассиры в филиалах и клиенты, пользующиеся банкоматами. Обра­ботка всех отдельных транзакций сконцентрирована в центральной базе данных счетов. Монитор дистанционной обработки (например, система CICS от IBM) может обрабатывать и помещать в буфер вводные данные из многих различных источников. В банковской системе он принимает транзакции от филиалов и банкоматов, при этом возможна пер­вичная обработка на месте. Затем транзакции помещаются в буфер и предоставляются в базу данных счетов в виде последовательного списка; база данных обновляет счета клиен­том и подтверждает завершение обработки транзакций. Эта процедура показана на рис. 26.5.

Рис. 26.5. Обработка транзакций с использованием монитора дистанционной обработки

Наследуемые системы с централизованными базами данных также имеют недостатки.

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

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

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

26.2. Проектирование наследуемых систем

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

Стратегия функционально-ориентированного проектирования ПО предусматривает декомпозицию программ на ряд функций и подпрограмм, взаимодействующих с централизованной совместно используемой памятью (рис. 26.6.). Информация о локальном состоянии функций обрабатывается только в процессе их исполнения. Такая стратегия является частью многих структурных методов, разработанных в конце 70-х— начале 80-х годов. Она получила название "нисходящее проектирование" и "структурное проектирование" [79, 250, 345, 12*, 24*]. Сотни тысяч прикладных программ разработаны с помощью этих методов и соответствующих CASE-средств.

Рис. 26.6. Функционально-ориентированный

подход к проектированию ПО

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

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

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

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

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

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

Обе системы (пакетной обработки данных и обработки транзакций) действуют в соответствии с моделью "вход-процесс-выход", показанной на рис. 26.7. Системы осуществ­ляют ввод данных из одного или нескольких источников, обрабатывают их и выдают вы­ходные данные, которые в той или иной степени связаны с входными. В качестве примера можно рассмотреть систему телефонных счетов, где входными данными являются записи о звонках клиента и информация со счетчика коммутатора АТС, которые затем обрабаты­ваются компьютером, в результате на выходе системы — счета за пользование телефоном.

Рис. 26.7. Модель "вход-процесс-выход"

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

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

2. В компонент обработки может входить получение транзакции из очереди (вход), подсчет данных, создание новой записи по результатам подсчета (процесс) и помещение новой записи в очередь на печать (выход).

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

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

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

Рис. 26.8. Потоковая диаграмма системы выплаты зарплат

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

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

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

Удачным примером системы обработки транзакций является система, контролирующая сеть банкоматов. На услуги, предоставляемые пользователям, не влияют предварительные операции, поэтому они могут рассматриваться как отдельные транзакции. В листинге 26. 1 приведена упрощенная версия такой системы. Следует заметить, что вместо языка программирования Java я использовал функционально- ориентированный язык. Java — объектно-ориентированный язык программирования, поэтому не подходит для им.inn» функционально-ориентированных систем.

ЛИСТИНГ 26.1. Описание системы управления банкоматами

метод

loop

repeat

Печать_сообщение("Добро пожаловать! Вставьте Вашу карточку") until Карточка_ввод Счет номер:= Считывание_карточка;

Получение_счет (PIN_код, Счет_баланс, Наличность_доступность);

ПРОЦЕСС

if карточка_недействительна (PIN _код)_% then Задержать_карточку;

Print ("Карточка задержана - пожалуйста, свяжитесь с Вашим ");

else,

repeat

Печать_операция_выбор_сообщение; Кнопка:= Получение_кнопка;

case Получение_кнопка is

when Наличность_только =>

Выдача_наличность_(Наличность_доступна, Сумма_выдача); when Печать_остаток =>

Печать__клиент_остаток (Счет_остаток); when Отчет =>

Заказ отчет (Счет номер); when Чековая_книжка =>

Заказ__чековая_книжка (Счет_номер); end case;

Print ("Нажмите ПРОДОЛЖИТЬ для других операций либо СТОП"); Кнопка:= Получение_кнопка;

until Кнопка = СТОП,

ВЫХОД

Извлечь_карточку;

Print ("Пожалуйста, извлеките Вашу карточку"); Обновление_счет (Счет_номер, Счет_выдача);

id loop;

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

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

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

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

Хотя функционально-ориентированный подход во многом считается устаревшим, объектно-ориентированное проектирование в подобных ситуациях не будет оправданным. Таким образом, перед нами стоит интересная задача: обеспечить совместную работу двух подходов К программированию — объектно-ориентированного и функционально-ориентированного.

26.3. Оценивание наследуемых систем

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

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

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

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

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

Естественно, нет однозначного решения данной проблемы — к системе,состоящей из нескольких отдельных программ, можно применить несколько различных подходов.

При оценивании наследуемую систему нужно рассматривать под разными углами зрения [339]. С коммерческой точки зрения необходимо провести оценку полезности и при­годности системы для бизнеса. Что же касается перспективы дальнейшей работы систе­мы, нужно в первую очередь оценить качество прикладного ПО, а также программных и аппаратных средств поддержки данной системы. Комбинация двух оценок— бизнес-пригодность и качество — поможет решить, что же делать с наследуемой системой дальше.

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

Рис. 26.9. Бизнес-пригодность и качество систем

На рис. 26.9 видно четыре группы систем, которые определяются следующими оценками.

1. Низкое качество, низкая бизнес-пригодность. Решение оставить такие системы в действии дорого обойдется, а отдача в бизнесе будет незначительной. Такие системы — прямые кандидаты на списание.

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

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

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

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

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

26.3.1. Оценка бизнес - пригодности

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

1. Точка зрения конечного пользователя системы. Насколько эффективна данная система для поддержки работы пользователя? Какой процент использования функциональных возможностей системы?

2. Точка зрения заказчиков. Является ли работа системы ясной и понятной для заказчика? Имеются ли ограничения при взаимодействии заказчика с системой?

3. Точка зрения менеджеров. Какое влияние оказывает система на деятельность их подразделения? Оправданы ли средства, потраченные на сопровождение системы? Насколько важными для работы подразделения являются данные, обрабатываемые системой?

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

5. Точка зрения руководства компании. Насколько зависит от системы достижение коммерческих целей компании и решение бизнес - задач?

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

26.3.2. Оценка качества системы

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

Оценка окружения

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

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

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

Таблица 26.1. Факторы системного окружения

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

Окончание

Фактор	Вопросы для оценки фактора
Возраст аппаратных средств и	Каков "возраст" аппаратного и программного обеспечении Даже если оно работает без сбоев, переход к новым системам может оказаться экономически выгодным
Производительность	Насколько производительность системы соответствует требованиям современных бизнес-процессов? Испытывают ли пользователи неудобства, связанные с проблемами производительности системы?
Необходимость в средствах поддержки	Какие средства поддержки требуются для сопровождение программного и аппаратного обеспечения? Если на сопровождение уходит значительное количество средств, то может разумнее заменить систему?
Стоимость эксплуатации	Насколько велика стоимость эксплуатации аппаратных средств и затраты на закупку лицензий на программные средства поддержки? Затраты на сопровождение устаревшей техники могут быть несравнимо выше, чем на содержание более современной техники. Кроме того, ежегодное обновление лицензий на ПО может также дорого обходиться
Способность к взаимодействию с другими системами	Возникают ли проблемы, связанные с интерфейсом между данной и другими системами? Можно ли использовать компиляторы или другие средства с текущей версией операционной системы? Требуется ли эмуляция аппаратных средств?

Оценка прикладного ПО

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

Таблица 26.2. Факторы, используемые при оценке качества прикладного

Фактор	Вопросы для оценки фактора
Возраст аппаратных средств и	Каков "возраст" аппаратного и программного обеспечении Даже если оно работает без сбоев, переход к новым системам может оказаться экономически выгодным
Производительность	Насколько производительность системы соответствует требованиям современных бизнес-процессов? Испытывают ли пользователи неудобства, связанные с проблемами производительности системы?

	Окончание табл. 26.
Фактор	Вопросы для оценки фактора
Данные	Есть ли четкая модель данных, используемых в системе? Дублируются ли данные в разных файлах системы?
Производительность	Соответствует ли качество выполнения системы современным требованиям? Влияет ли производительность системы на работу пользователей?
Язык программирования	Есть ли современные компиляторы для языка программирования, с помощью которого создавалась система? Используется ли этот язык для создания современных систем?
Управление конфигурацией	Распространяется ли действие системы управления конфигурацией на все версии всех частей системы? Есть ли четкое описание всех версий системных компонентов?
Тестовые данные	Имеются ли тестовые данные? Есть ли записи о тестированиях, проведенных после введения в систему новых компонентов?
Обслуживающий персонал	Реально ли найти специалистов для обслуживания данной системы? Много ли профессионалов, способных разобраться с этой системой?

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

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

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

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

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