Международный опыт создания Систем Персонального Учета Населения А.Данилин, Microsoft

Вопросы Является ли задача создания национальной СПУН в г.г. своевременной и реальной? Готовы ли мы – ведомства и люди отвечающие за информатизацию в ОГВ, поставщики решений и технологий – к реализации этого межведомственного по сути проекта? Пока еще небольшой опыт и ресурсы по управлению межведомственными проектами в рамках «Электронной России» Узкий круг организаций и специалистов на федеральном уровне, которые до сих пор участвовали в процессе принятия решений в области создания систем, связанных с различными формами учета населения

СПУН на «матрице расстановки приоритетов» Источник: e-Government Manual, Germany, BDI

СПУН необходимо рассматривать в контексте всей Архитектуры Электронного Государства

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

Жизненные эпизоды Какая часть жизненных эпизодов должна быть отражена в СПУН?

Далеко не все страны Западной Европы имеют СПУН Страны, которые не имеют таких систем Испания (информация на 2001 г.) Италия США: Проект e-Vital (регистрация рождения и смерти граждан) является одним из 24 приоритетных проектов «электронного правительства» США. Находится только на стадии реализации.

Подход США к созданию системы учета рождения и смерти граждан (E-Vital) Федеральная инициатива, которая должна создать единообразный процесс, в рамках которого информация о рождении и смерти граждан может анализироваться, обрабатываться, собираться и проверяться Цель Быстрый ответ на запросы клиентов (граждан и других ведомств) Возможности по быстрой и качественной идентификации граждан (особенно в контексте инициатив в области безопасности) Возможность интеграции и пересылки информации в электронной форме в системы других ведомств Безбумажные процессы Улучшенная безопасность Улучшенное качество данных Стандартизованные процессы

Описание исходной ситуации Многие Штаты использовали системы «Электронной регистрации рождения» (EBS – Electronic Birth Certificate) собственной разработки и работающие в среде DOS Факторы, требующие внедрения новой системы Исторически существовала минимальная координация между штатами в плане регистрации рождения Высокая стоимость замены старых DOS-приложений на новые Технологические факторы: Переход от закрытых прикладных систем к системам, основанным на стандартах Web-клиент Технологии порталов Доступность недорогих стандартных, готовых решений и продуктов

Система e-Vital связана с проблемой идентификации личности Стратегия - не полагаться на один способ идентификации личности, а использовать несколько, в зависимости от целей Две фазы в решении проблемы Фаза 1: помощь федерального правительства штатам с точки зрения обеспечения большей надежности выдаваемых идентификационных документов (водительских прав, паспортов,…) e-Vital рассматривается как важнейшая часть решения проблемы Фаза 2: Биометрические и криптографические технологии Проблемы До только 12 штатов (всего 57 штатов плюс федеральный округ Колумбия) использовали Он-лайновую Систему Проверки Номера Социального Страхования (SSOLV - Social Security Online Verification System) На конец 2003 г. 24 штата использовали SSOLV Два режима доступа к SSOLV В режиме реального времени Пакетная обработка запросов с ответом в течении часов Проблемы использования SSOLV Не смогла справиться с ростом числа подключений Высокая стоимость использования Источник: Creating a Trusted Information Network for Homeland Security. Second Report of the Markle Foundation task Force, December 2003

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

Преимущества такого подхода Существенное уменьшение времени и затрат на внедрение Денежных средств Людских ресурсов Стандартные требования к поставщикам решений Большая вероятность успеха на национальном уровне в целом Распределение рисков Распространение экспертизы и положительного опыта Улучшение качества данных Лучшая совместимость Легче находить финансирование Возможность поэтапного внедрения Постепенные обновления (up-grades) и простота модификации Удовлетворение уникальных потребностей каждого штата

Этап описания требований к системе e-Vital Стало понятно, что 85-90% требований к процессу регистрации во всех органах и территориях одинаковы Разработка национальной Модели Системы Электронной Регистрации Актов гражданского состояния Этап 1: Разработка функциональных и бизнес- требований Модели языка UML: Сценарии Использования (Use Case) и вспомогательные модели (Диаграммы Сценариев Использования), описания бизнес-правил Описание «Потока событий», Акторов, Пред- и После-условий, Специальных условий 57 различных Сценариев Использования «Создать запись о рождении», «Создать запись подтверждения об отцовстве», «Обновить запись», «Сравнить записи о рождении и смерти», …

Результаты Сценарии использования и модели послужили основой для описания концептуальной и логической архитектуры и моделей данных Уточненная модель данных (RIM – Refined Information Model) для всех основных электронных сообщений, связанных с «жизненными эпизодами» в формате XML Результат: стандартизированная концепция Не единая система для регистрации, внедряемая во всех штатах, а системы на уровне штатов от различных поставщиков, которые используют: Одни и те же стандарты для фиксации одной и той же информации в единообразной манере и в соответствии с едиными бизнес-правилами Возможность интеграции на национальном уровне

Архитектурный подход к проектированию системы БизнесИнформацияПриложенияТехнологии Концеп- туальная Архитектура Сценарии Использования Бизнес-модели Бизнес-сущности (ex.Гражданин, Налоговая декларация) Модели связей Модели бизнес- процессовв Бизнес-процессы, поддерживаемые ИТ Разбиение на сервисы Архитектура Центра Обработки данных Нефункциональные (операционные) требования Распределение сервисов Логическая Архитектура Workflow models Role Definition Схемы данных и спецификации документов Сообщения/Документы Versioned Data Взаимосвязи между сервисами Определения сервисов Модели классов Логические типы серверов: БД, почтовые с-мы, транзакц. серверы, messaging Мапирование сервисов Хостируемое ПО Физическая Архитектура (Дизайн) Process specifications Manual procedures Quality standards Схемы БД Интерфейс репозиториев Код доступа к данным Код WSDL Расписания процессов Код Workflow Детальный дизайн Физические Серверы Firewall Топология сети Мапирование продуктов Разделение бизнес-моделей и моделей гос.услуг (которые меняются относит. медленно) и ИТ-приложений и Инфраструктуры повышает продуктивность бизнес-аналитиков, системных архитекторов и разработчиков, позволяя им легко обмениваться концепциями Методика Microsoft описания Архитектуры: матрица моделей

Сквозной процесс анализа и проектирования систем Функциональные требования к системе фиксируются в форме анализа Сценариев Использования (Use Cases), что позволяет создавать модели и шаблоны проектирования информационной системы Функциональные Функциональныетребования Анализ АнализСценариев Использования Использования (Use Case) Проектирование Шаблоны Реализация Проектирование Шаблоны Реализация Процесс анализа и проектирования систем

Модели Вариантов Использования (Use case) Диаграммы кооперации Диаграммы последовательности Прототип пользовательского интерфейса Модели Предметных областей Диаграммы классов Динамические модели Статические модели Сквозной процесс анализа и проектирования систем: от функциональных требований – к готовым системам Код

Пример: UML-диаграмма классов для Общей Модели Гос.услуг Великобритании (GCIM) GCIM является справочной информационной моделью описания деятельности государственных органов и моделью описания функциональных требований к разработке электронных услуг, основанных на интегрированных административных процессах Пример Сервисного Взаимодействия: Уведомление о смене места жительства Источник: e-Services Development Framework, UK Office of e-Envoy

Различные UML модели, использованные в «Методике разработки электронных услуг» Великобритании Диаграмма Последовательности Диаграмма Деятельности Диаграмма Классов для Смены Места Жительства

Visual Studio.NET 2003 Enterprise Architect Использование UML для описания архитектуры и функциональности приложений Полный цикл разработки, включая концептуальные, логические и физические модели данных, что позволяет совместно работать бизнес-аналитикам и проектировщикам баз данных Графическое оркестрирование бизнес-процессов, спецификации которых могут использоваться сервером Microsoft ® BizTalk ® для исполнения Три группы средств проектирования Дизайнер приложений Дизайнер логической архитектуры центра обработки данных Дизайнер хостинга систем (мапирование модели приложения на логическую архитектуру ЦОДа) Доступ к лучшему опыту с использованием Корпоративных Шаблонов (Enterprise Templates) Template Description Language (Язык Описания Шаблонов) может быть использован для четкого определения правил разработки и руководств, которые помогают разработчикам в создании надежных приложений

Новые технологические тенденции, которые необходимо учесть в архитектуре СПУН Существующие документы по ГРН (Концепция) сформулированы в терминах «клиент-сервер» При этом неявно предполагается использование СУБД одного поставщика, одного и того же сервера приложений и т.д. Сервис-ориентированная Архитектура (Service-Oriented Architecture) является основой проектирования информационных систем нового поколения Включая возможности технологий Web-сервисов Возможность свободного связывания большого количества модулей информационных систем (сервисов), работающих на разных платформах, доступных в режиме «запрос-ответ» посредством стандартных и четких интерфейсов доступа XML, WSDL, SOAP, UDDI

Связь с проблемой «управления записями» В ГРН не предусматривалось хранение первичных документов Если это будет в СПУН, то необходимо рассмотреть весь комплекс вопросов, связанных с «управлением записями» Записи – это электронные документы, на которые наложены определенные обязательства, в том числе юридические, с точки зрения срока хранения, защиты, архивирования, классифицирования, истории документа, информации о действиях с этим документом и уничтожения Практически не отработанная в России тема Примеры: отсутствие стандартов на государственные метаданные, минимальный опыт в создании электронных архивов

Австралийский бизнес-регистр (ABR) и Единая Точка Доступа для Бизнеса (BEP -Business Entry Point) Первоначально была концепция создания единой точки присутствия в Интернет, через которую бизнес/граждане могли бы получать доступ ко ВСЕМ государственным услугам (на всех уровнях) для выполнения необходимых транзакций. Это видение было реализовано в форме BEP (Business Entry Point) Государственные Web-сервисы Business Entry Point Федеральные Регионы(штаты) Местные Государственные ведомства

Этапы проекта ABR Фаза 1 Web-регистрация на основе технологий Microsoft Регистрация для получения нового Регистрационного Номера Организации (ABN) – Web, телефон, бланк заявления Проект выполнялся Министерством Налогов Австралии (ATO – Australian Taxation Office), но был доступен через BEP Более 2 млн. зарегистрированных юр.лиц и 2 млн. просмотров через Web ежемесячно (в 2003 г.) Фаза 2 – ABR.NET Межведомственный проект Предоставление доступа к ABR в режиме он-лайн другим ведомствам Классический вариант использования технологий Web-сервисов Защита частной информации: надведомственный механизм, поддерживаемый Минналогов в интересах всех ведомств Агентства используют ABR так, что поставляется только та информация, которая требуется для предоставления услуги для бизнеса Интеграционное ПО пром. слоя Control Layer (COLA), основанное MS BizTalk Server Распределенная Системная Среда (DSE - Distributed Systems Environment) 150 серверов, 2.5 Тбайт систем хранения Продукты и технологии Microsoft Microsoft.NET Framework, Microsoft BizTalk Server 2000, Microsoft Operations Manager 2000, Microsoft SQL Server 2000, Microsoft Visual Studio.NET 2002, XML Web Services

Использование ABR Май % Апрель % % 3% Планируемое использование в 1999

Дополнительная информация Архитектура, методики, шаблоны Методика создания прикладных систем Microsoft Solutions Framework (на русском) (на русском) Клуб системных архитекторов (на русском) Ресурсы по ИТ в госорганах (на русском) – Центр Компетенции по электронному правительству при Американской Торговой палате Российское сообщество по SQL Server