5. Эволюция программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 26.6. Функционально-ориентированный подход к проектированию ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Листинг 26.1. Описание системы управления банкоматами вход

loop

repeat

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

Получение_счет (Р1Ы_код, Счет_баланс, Наличность_доступность); ПРОЦЕСС

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

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

Печать_операция_выбор_сообщение;

Кнопка:= Получение_кнопка; case Получение_кнопка is

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

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

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

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

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

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

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

Print ("Пожалуйста, извлеките Вашу карточку");

Обновление_счет (Счет_номер, Счет_выдача); end loop;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оценка бизнес-процесса

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

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