Другие журналы

научное издание МГТУ им. Н.Э. Баумана

НАУКА и ОБРАЗОВАНИЕ

Издатель ФГБОУ ВПО "МГТУ им. Н.Э. Баумана". Эл № ФС 77 - 48211.  ISSN 1994-0408

Проблемы применения стандартов в проектах больших систем

#5 май 2004
автор: Артемьев В. И.

Проблемы применения стандартов в

Проблемы применения стандартов в проектах больших систем

 

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

 

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

Примеры проблем применения стандартов

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

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

Пример 2. Использование разных инструментальных средств в разных проектах, например, MS 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 и другой стандарт к своим потребностям. Своими силами это выполнить нереально, отечественные организации стандартизации этим занимаются в силу ряда причин, а рынка подобных услуг практически нет.

Заключение

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

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

 

                                                                                                                        Июнь 2001 г.


Тематические рубрики:
Поделиться:
 
ПОИСК
 
elibrary crossref ulrichsweb neicon rusycon
 
ЮБИЛЕИ
ФОТОРЕПОРТАЖИ
 
СОБЫТИЯ
 
НОВОСТНАЯ ЛЕНТА



Авторы
Пресс-релизы
Библиотека
Конференции
Выставки
О проекте
Rambler's Top100
Телефон: +7 (915) 336-07-65 (строго: среда; пятница c 11-00 до 17-00)
  RSS
© 2003-2018 «Наука и образование»
Перепечатка материалов журнала без согласования с редакцией запрещена
 Тел.: +7 (915) 336-07-65 (строго: среда; пятница c 11-00 до 17-00)