При выполнении переводов должны также рассматриваться возможность и необходимость локализации, то есть уточнения отдельных положений стандарта с учетом национальной специфики. При локализации должен использоваться расширительный подход, то есть вновь вводимые требования и положения не должны изменять базовых требований оригинального стандарта, порождая несовместимые с ним реализации.
Определения раздела:
Идентичный перевод спецификации – перевод иностранной (международной) технической спецификации на русский язык с сохранением всех содержащихся в ней условий, требований и параметров с точностью до общепринятых терминологических эквивалентов.
Локализованный перевод спецификации – перевод иностранной (международной) технической спецификации на русский язык с одновременно корректировкой (уточнением) ее отдельных условий, требований и параметров в соответствии с национальной технической, организационной или иной спецификой.
Основными задачами создания архитектурной модели ПО электронного государства являются:
· Совместимость на уровне функций, административных процессов: общие методы описания, общие принципы выполнения операций и принятия решений, единое понимание логики процессов.
· Совместимость на уровне информации: общая терминология, определения и структура информации, а также общие сервисы, позволяющие использовать согласованные структуры и форматы.
· Технологическая совместимость: общие методы и способы коммуникаций, хранения, обработки и представления информации.
3.1 Использование эталонных моделей
При описании и разработке программного обеспечения электронного государства следует придерживаться общепринятых, стандартизованных на международном уровне схем и методик, использовать единый для той или иной предметной области язык и терминологическую систему. Перечень наиболее востребованных в различных областях деятельности стандартизированных эталонных моделей приведен в таблице.
Таблица 3.3.
| Наименование эталонной модели | Обозначение | Спецификация | |||
| модель | подмодель | ||||
| Эталонная модель для открытой распределенной обработки. | ODP RM | ITU-T Rec. 902|ISO/IEC 10746-2:1995, Reference Model for Open Distributed Processing – Reference Model: Foundation. ITU-T Rec. 903|ISO/IEC 10746-3:1995, Reference Model for Open Distributed Processing – Reference Model: Architecture Спецификации ITU-T серии X.900 | |||
| Язык спецификации интерфейсов объектов | ODP IDL | ISO/IEC DIS 14750:1999, Information technology – Open Distributed Processing Interface Definition Language | |||
| Архитектура открытого распределенного управления | ODMA | ISO/IEC 13244:1998, Information technology – Open Distributed Management Architecture | |||
| Эталонная модель окружения открытых систем | OSE RM | ISO/IEC 7498:1996, Information processing systems – Open Systems Interconnection – Basic Reference Model ITU-T Rec. X.200 (1994) | |||
| Эталонная модель управления данными | DM RM | DIS 9075:1992, Information technology – Reference Model for Data Management | |||
| Эталонная модель машинной графики | CG RM | ISO/IEC 11072:1992, Information Technology – Computer Graphics – Computer Graphics Reference Model | |||
| Эталонная модель открытой архитектуры документов и обмена форматами | ODA RM | ISO/IEC 8613/1:1994, Information technology – Open Document Architecture (ODA) and Interchange Format – Introduction and general principles. [ITU-T Rec. T.411(1993)] | |||
| Эталонная модель управления качеством и обеспечения качества | ISO 9000 | ISO 9000-3 Quality management and quality assurance standards – Part 3: Guidelines for the application of ISO 9001 to the development, supply, installation and maintenance of computer software | |||
| Эталонная модель обеспечения качества при проектировании, разработке, производстве, установке и обслуживании. | ISO 9001 Quality systems – Model for quality assurance in design, development, production, installation and servicing | ||||
| Эталонная модель обеспечения качества при производстве, установке и обслуживании. | ISO 9002 Quality systems – Model for quality assurance in production, installation and servicing | ||||
| Эталонная модель обеспечения качества при финальных проверках и тестировании | ISO 9003 Quality systems – Model for quality assurance in final inspection and test | ||||
| Эталонная модель управления качеством | ISO 9004-1 Quality management and quality system elements – Part 1: Guidelines | ||||
| Эталонная модель жизненного цикла программного обеспечения | ISO/IEC 12207 Information technology – Software life cycle processes | ||||
| Методы тестирования конформности | ISO/IEC DIS 13210, Information Technology – Test methods for measuring conformance to POSIX | ||||
| ISO/IEC 9646-1: 1994/ITU-T X.290, ISO/IEC DIS 13210 | |||||
| Эргономика программных продуктов | ISO/IEC 9241. Ergonomic Standards for Computer Products | ||||
| Управление безопасностью | ISO/IEC 7498, Information processing systems – Open Systems Interconnection – Basic Reference Model. Part 2: Security Architecture [ITU-T Rec. X.800 (1991)] ISO/IEC DTR 10181-1, Information processing systems – Open Systems Interconnection – Security frameworks in open systems: Security frameworks overview ISO/IEC DTR 13335-1: 1996 – Information Technology Guidelines for the Management of IT Security (GMITS) | ||||
3.2 Базовая функциональная модель ODP-RM
Поскольку архитектура программного обеспечения электронного государства описывает главным образом взаимодействие между системами (или независимыми компонентами этих систем), и опирается на идеологию открытых систем, естественным выглядит принятие в качестве базовой эталонной модели распределенную открытую обработку (ODP). Применение RM-ODP в описании приложений для электронного государства настоятельно рекомендуется АПО, но не является обязательным. Наиболее подходящая к тому или иному приложению модель может быть выбрана из таблицы в предыдущем разделе.
Среди прочего, модель RM-ODP определяет пять точек зрения на систему:
· организационная точка зрения описывает постановку цели, области применения, способы и правила применения;
· информационная точка зрения описывает выражение (проявление) и семантику обрабатываемых системой данных, форматы и модели данных;
· компонентная (вычислительная) точка зрения описывает разделение приложения на функциональные модули и определяет их интерфейсы;
· инженерная точка зрения представляет распределение отдельных элементов системы по физическим ресурсам, а также их связи;
· технологическая точка зрения описывает технологии, используемые при реализации системы.
При помощи этих пяти точек зрения могут быть как описаны существующие системы, так и смоделированы новые системы и приложения. Описание по пяти точкам зрения (разрезам) использовано в следующем разделе для структуризации общих архитектурных требований АПО и рекомендуется в качестве основы таксономии каталога спецификаций Главного профиля АПО.
4 Архитектурные требования и рекомендации
4.1 Организационная точка зрения
Организационная точка в АПО определяет два основополагающих элемента: организационную структуру программного обеспечения электронного государства в целом и организационные модели приложений. Здесь описывается совокупная среда системы и её назначение. При создании новых информационных систем для нужд электронного государства их проектная документация должна содержать описанные с точки зрения организаций требования к выполняемым действиям, политикам обработки данных, процедурам, правилам, участникам процедур и их ролям в процессе.
Основное внимание при описании систем с организационной точки зрения должно уделяется описанию процессов взаимодействия с внешними пользователями системы, в качестве которых могут выступать как физические лица (кроме персонала системы и ведомственных пользователей), так и смежные информационные системы. Информационные услуги (сервисы), предоставляемые системой, должны быть описаны в форме моделей процессов в соответствии с нотацией, определенной для данной области применения в Главном профиле АПО (или локальном профиле, если он существует для конкретной задачи). В модели должны быть рассмотрены все рабочие этапы от запроса “заказчика” (гражданин, организация, другие ведомства и т. д.) до получения результата.
Основным организационным требованием к программному обеспечению электронного государства является наличие встроенных средств (возможностей подключения внешних модулей) придания внутренним статусам системы (состояниям документов, данных, транзакций) юридической значимости:
· Нотаризации (наделения правомочностью агентов).
· Журналирования (архивирования и неизменяемости).
· Транзакционности (определенности статусов).
· Внешнего доступа к внутренним статусам (наличие стандартного интерфейса).
При моделировании административных процессов разработчики должны включать в модели явные указания на точки смены и фиксации внутренних состояний системы. Документация системы должна четко и однозначно описывать способы реализации указанных требований.
Для определения уровней взаимодействия и отслеживания динамики развития информационных систем рекомендуется использовать совместимую с методикой Европейского союза классификацию фаз развития электронного взаимодействия:
1. Предоставление информации. Система может предоставить по запросам внешних пользователей хранящуюся в ее информационной базе информацию, предназначенную для раскрытия.
2. Одностороннее действие: получение форм. Система может получить от пользователя запрос для последующей обработки.
3. Двустороннее взаимодействие. Система обеспечивает обработку полученных от внешних пользователей форм и запросов в рамках установленного административного регламента, и извещение пользователя о результатах этой обработки.