Oracle - Приложение A. Готовые пакеты прикладных программ

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

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

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

Примечание

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

В этом приложении мы рассмотрим некоторые вопросы и возможности, связанные с приобретением готовых программных систем и компонентов.

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

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

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

Конечно, не все оцениваемые продукты могут быть построены на основе базы данных Oracle. Однако здесь мы предполагаем, что ваша организация выбрала Oracle как базовую технологию СУБД и, следовательно, ее поддержка является обязательным условием. Если пакет работает с разными серверами БД, то, вероятно, стоит проверить, насколько хорошо он использует возможности Oracle.

Давайте рассмотрим, какие качества продукта должен анализировать проектировщик.

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

Прежде всего нужно определить аппаратную платформу (платформы) и операционную систему (системы), на которых должно работать рассматриваемое приложение. Если продукт в качестве базы данных использует Oracle, то это еще не означает, что он обладает такой же переносимостью, как сама Oracle. Кроме того, никогда не следует исходить из предположения, что функциональные возможности пакета на всех платформах одинаковы. Например, есть много продуктов на базе Oracle, работающих только под управлением Unix, а среди них есть такие, которые работают только с определенными разновидностями этой ОС. Есть также продукты, работающие как с Unix, так и с патентованными операционными системами, например VMS или Windows NT.

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

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

Некоторые продукты предъявляют специальные требования к сети, и эти требования необходимо сопоставить с возможностями и пропускной способностью работающих у вас сетей. Обязательно проверьте все параметры, учитывая при этом, что большинство продавцов пользуются для демонстраций и эталонных тестов высокопроизводительными машинами. Например, в демонстрациях для среды клиент-сервер клиенты обычно имеют минимум 32 Мбайт памяти и взаимодействуют с серверами по сети Ethernet. Если вы можете позволить себе такую конфигурацию на промышленном уровне — прекрасно. Однако не удивляйтесь, если реальная производительность клиентов на базе 486 процессора с 8 Мбайт оперативной памяти при работе в глобальной сети будет на несколько порядков ниже, чем у системы, демонстрация которой убедила президента вашей фирмы утвердить заказ.

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

Давайте рассмотрим, как некоторые из этих механизмов работают на практике. Допустим, вы приобретаете пакет Sales Ledger (Регистр продаж) или Accounts Payable (Кредиторы). Вполне вероятно, что в базе данных в таком пакете будет таблица покупателей (Customer). Однако вряд ли эта таблица будет похожа на таблицу покупателей, которая у вас уже есть (мы имеем в виду столбцы или общую структуру). Конечно, лучше обойтись без сопровождения двух таблиц покупателей и связанных с этим проблем, поэтому вы решаете реплицировать данные из одной таблицы в другую. Сначала вам придется назначить одну из них (надеемся, исходную таблицу) главной, в которую будут вноситься все изменения, а затем обеспечить перенос всех изменений в подчиненную таблицу. Теоретически это просто, но на практике существуют некоторые сложности.

Первая проблема, с которой приходиться столкнуться, связана с тем, насколько хорошо производитель пакета описал структуру своей базы данных. Конечно, можно воспользоваться средствами SQL*Plus и выполнить операцию DESCRIBE над этими таблицами, но в результате будут получены только имена столбцов и типы их данных. Эти имена могут быть совершенно неинформативными, поэтому назначение столбцов придется угадывать (например, что такое в таблице покупателей NOT_CUST_PARENT_FLAG или еще хуже: что такое С012 в Т047?). Следующая проблема состоит в том, как заполнить в подчиненной таблице обязательные столбцы, отсутствующие в главной таблице? Возможно, для представления значения "еще не известно" придется использовать какое-то специальное значение (очевидно, не нулевое).

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

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

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

В Oracle Designer/2000 есть набор API, реализованных как набор пакетов PL/SQL. Они позволяют выполнять функции, которые не обязательно реализованы в Repository Object Navigator или иных инструментальных средствах и которые в предыдущих версиях нужно было выполнять путем непосредственного обновления репозитария.

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

Действительно мощное приложение должно позволять встраивать учетный "объект", например набор бухгалтерских книг, счет или проводку, в строку базы данных (в столбце типа LONG или LONG RAW). Этот встроенный объект должен иметь ряд доступных методов и свойств. Это даст возможность, например, корректировать проводку, изменяя ее свойство "сумма", или открывать окно со сводкой данных по счету.

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

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

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

Вспомните наше замечание из предыдущего раздела о том, что лучший метод расширения возможностей — использование набора API-подпрограмм, предоставляемых изготовителем продукта. Если же API нет, то что делать? Конечно, вы всегда можете читать и обновлять базовые таблицы и представления приложения непосредственно, но мы не рекомендуем это делать. Тому есть ряд очевидных причин:

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

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

Некоторые изготовители пытаются сделать свои продукты более гибкими не с помощью API, а другими средствами. Например, в Oracle Financial есть такое понятие, как гибкие поля (flex fields). Это запасные столбцы в некоторых главных таблицах приложения, которые можно адаптировать под свои нужды. Их можно использовать как ссылки на другие таблицы, но, по сути, они предназначены только для ввода в таблицу дополнительных описательных полей. Кроме того, многие инструментальные средства разработки их совершенно не поддерживают.

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

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

Решая проблему адаптации, нужно сначала определить, в какой степени вам необходимо настроить продукт. Хотите ли вы изменить только его внешний вид или же требуется настроить базовые функции? Может быть, вы собираетесь просто добавить в продукт некоторые элементы, чтобы восполнить дефицит функциональных возможностей. Если это так, то являются ли эти дополнения данными, функциями или и тем, и другим? Конечно, стоит спросить у изготовителя продукта или продавца о том, не хотели бы они сейчас или в будущем учесть ваши требования в базовом продукте. Если они ответят положительно, то вы, возможно, решите избавить себя от хлопот, особенно если при Moscow-анализе (см. главу 1) эти требования были классифицированы как желательные или возможные, а не как необходимые. Однако не забывайте, что приобретение пакета с целью получения еще не реализованной функции противоречит главной цели приобретения готового приложения — получить что-то, что уже работает.

Подводя итоги, опишем проблемы, связанные с внесением изменений в интегрируемое ПО:

Как мы уже говорили, сейчас приложения уже нельзя сравнивать с островками в океане. Чтобы обеспечить интероперабельность (еще одно громкое словечко 90-х годов), аналитики (и в меньшей степени проектировщики) создают корпоративные модели данных. Раньше в большинстве организаций в каждом приложении были свои определения данных (их часто называли моделями, ориентированными на приложения). Например, в приложении Sales была одна таблица Customer, в приложении Billing — еще одна, в Support — третья и т.д.

Один из авторов когда-то работал с фирмой, у которой было семь разных моделей данных о покупателях! В результате эти данные были несогласованными, а структура таблиц отличалась. Форматы адресов были настолько разными, что было практически невозможно с помощью почтового адреса обнаружить, что Serious Cybernetics Corporation в одном приложении — это та же компания, что и Serious Cybernetics Corporation в другом! В результате фирма теряла деньги, бесплатно обслуживая оборудование покупателей, так как просто не могла определить, стоит ли это оборудование на гарантии (эта информация находилась в базе данных Sales).

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

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

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

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

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