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

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

Валерий Артемьев

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

Примеры проблем

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

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

Пример 2. Использование в разных проектах разных инструментальных средств, например Visual Basic и Delphi, может усложнить настройку среды для их совместной эксплуатации и снизить эффективность работы, так как в одном случае используются модули доступа Jet, DAO или ADO с драйверами ODBC или OLE/DB, а в другом — BDE и, как правило, с драйверами SQL-Link.

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

Пример 4. При позадачной организации проектов зачастую дублируются реализации процедур подготовки и сбора данных, что в итоге приводит к многообразию форматов обмена данными (например, EDIFACT, DBF, Excel, Word), к использованию в источниках информации различных АРМов, выполняющих сходные технологические функции для разных задач, а значит, к усложнению эксплуатации и сопровождения систем.

О комплексности внедрения стандартов

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

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

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

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

Унификация и типизация проектных решений и средств

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

Согласно РД 50-682-89, унификация — это совокупность действий (комплекс мероприятий), заключающаяся в установлении единых правил и требований, выполнение которых обеспечивает:

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

Типовое проектное решение [ГОСТ 34.003-90] — проектное решение, предназначенное для повторного использования. Типизация представляет собой совокупность действий (комплекс мероприятий), направленных на повторное использование проектного решения или средства.

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

Направлениями унификации и типизации являются:

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

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

Исходя из эталонной модели OSE/RM можно выделить следующие объекты стандартизации, унификации и типизации в проектах интегрированных систем:

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

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

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

Эффект централизации и интеграции

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

При этом требуются организационные мероприятия, направленные на централизацию и интеграцию при выполнении следующих работ:

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

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

Несколько слов относительно использования рамочных стандартов (framework). Концептуально это вещь нужная, но специалистами до конца не понятая. На фоне прежних более жестких и конкретных стандартов и с учетом привычки рассматривать ГОСТы как руководство к действию - многие рамочные стандарты выглядят легковесно. Так, например, стандарт ИСО/МЭК 12207, несомненно, дает достаточно ясную картину состава, содержания процессов и структуры жизненного цикла программной системы. Однако с его помощью трудно квалифицировать процедуры администрирования, мониторинга и управления системами. Говорят, в некоем другом стандарте это подробно изложено, но он на английском языке. Дело за малым: достать его, перевести, понять, кроме того, адаптировать ИСО/МЭК 12207 и тот, другой стандарт к собственным потребностям. Своими силами это выполнить нереально, отечественные организации стандартизации этим не занимаются в силу ряда причин, а рынка подобных услуг практически нет. (Прошедшая 17-18 апреля этого года I Всероссийская конференция по стандартам показала, что необходимость в таком рынке существует и что процесс его формирования начался. — Прим. ред.)

Заключение

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

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

Валерий Иванович Артемьев — советник директора Главного центра информатизации Банка России, art@gci.cbr.ru