3.3. Технологический цикл построения открытых систем

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

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

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

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

Стадия 1. Определение целей деятельности.

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

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

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

Стадия 2. Идентификация требований к прикладной системе.

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

Стадия 3. Подготовка профиля для описания набора свойств среды, требуемых для поддержки приложения.

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

Стадия 4. Приобретение или создание программного обеспечения, которое соответствует выбранному профилю.

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

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

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

Стадия 5. Проверка приложения на соответствие характеристикам открытых систем.

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

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

Стадия 6. Проверка на соответствие целям деятельности.

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

Стадия 7. Повторение последовательности действий.

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

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

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

Наборы тестов для проверки платформ на соответствие требованиям открытых систем разрабатываются многими организациями.

Во-первых, такие тесты создаются самими производителями.

Во-вторых, такие организации, как COS, SPAG, POSI, MAP/TOP, NIST и INTAP совместно работают над тестами всеобщего распространения.

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

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

Многие формальные стандартные интерфейсы, включают в себя стандарты, специально разработанные для описания тестов на соответствие, например, стандарт POSIX 1003.3 представляет стандарт на тест для POSIX 1003.1.