Transcript Международный опыт создания Систем Перс

Международный опыт
создания Систем
Персонального Учета
Населения
А.Данилин, Microsoft
Вопросы


Является ли задача создания национальной СПУН в
2004-2005 г.г. своевременной и реальной?
Готовы ли мы – ведомства и люди отвечающие за
информатизацию в ОГВ, поставщики решений и
технологий – к реализации этого межведомственного
по сути проекта?


Пока еще небольшой опыт и ресурсы по управлению
межведомственными проектами в рамках «Электронной
России»
Узкий круг организаций и специалистов на федеральном
уровне, которые до сих пор участвовали в процессе принятия
решений в области создания систем, связанных с различными
формами учета населения
Высокое
«Быстрый
Успех»
Низкое
Влияние на деятельность государства
СПУН на «матрице расстановки приоритетов»
Начинать
Здесь!
Шаг 2
«Низко-висящие
фрукты»
Системы, которые
обязаны быть
реализоавнными
Шаг 3
СПУН
Избегать
таких
проектов!
«Черная дыра» для
растраты бюджетных
средств
Высокая
Низкая
(сложно)
(легко)
Сложность реализации
Источник: e-Government Manual, Germany, BDI
СПУН необходимо рассматривать в контексте всей
Архитектуры Электронного Государства
Архитектура приложений
Архитектура Интеграции
(ОГИРы)
Архитектура Общих Сервисов
(Портал, Документооборот,
Сервер Электронных Форм,
Система Управления
Контентом, Платформа
Оплаты Услуг…)
Архитектура
информации (данных)
Технологическая Архитектура (системная
архитектура): аппаратное и программное
обеспечение, коммуникации
Методики описания государственных
функций и услуг, Процессы управления ИТ
Архитектура
государственных
функций и регламентов
(бизнес-архитектура)
СПУН и другие «горизонтальные» и «вертикальные»
прикладные системы электронного правительства

В настоящее время, похоже, отсутствует
достаточно полное описание всего
комплекса прикладных систем
«электронного правительства» в России
Общее видение
 Категоризация
 Полный перечень (портфель) прикладных систем

Жизненные эпизоды
Какая часть жизненных эпизодов должна быть отражена в СПУН?
Рождение
• Информация об учебе
• Инф-ция о школе/
• Свид-ство о рождении
• Усыновление
• Отцовство/материнство
• Изменение имен
Возможные
события
• Возм-ти по
трудоустр-ву
• Поиск работы
Образование • ….
• Фискальные данные
• Оценка ст-ти
недвижимости
• Возврат налогов
• Оплата налогов
Университе
• Критерии приема
• Рез-ты вст. экзам.
• Зачисление
• Пособия на обучение
• Учеба за границей
• Инф-ция о браке
• Св-во о браке
• Брак за рубежом
• Сертификат о месте
Транспорт
Работа
Налоги
проживания
Автомобиль
• Водит. школа
• Водит. тесты
• Врем. права
• Постоянные права
• Межд. права
• Регистрация
автомобиля
Обзщественный
транспорт
Семья
Дом
самотрудоустроившихся
• Лицензия на
строительство
• Право собственности
• Пособие на жилье
• Право на
реконструкцию
• Регист-ция Обязат. Мед. страхования
• Возврат затрат на лечение
• Платежи в Фонд Мед. Страхования
• Мед. Обслуживание
Культура и спорт
Путешествия
Здоровье
Запрос на место в доме
для престарелых
• Запрос на помощь на
дому
•
• Похороны
• Эксгумация
Пенсия
Смерть
Далеко не все страны Западной
Европы имеют СПУН

Страны, которые не имеют таких систем
 Испания
(информация на 2001 г.)
 Италия
 США:
Проект e-Vital (регистрация рождения
и смерти граждан) является одним из 24
приоритетных проектов «электронного
правительства» США. Находится только на
стадии реализации.
Подход США к созданию системы учета
рождения и смерти граждан (E-Vital)


Федеральная инициатива, которая должна создать
единообразный процесс, в рамках которого
информация о рождении и смерти граждан может
анализироваться, обрабатываться, собираться и
проверяться
Цель







Быстрый ответ на запросы клиентов (граждан и других
ведомств)
Возможности по быстрой и качественной идентификации
граждан (особенно в контексте инициатив в области
безопасности)
Возможность интеграции и пересылки информации в
электронной форме в системы других ведомств
Безбумажные процессы
Улучшенная безопасность
Улучшенное качество данных
Стандартизованные процессы
Описание исходной ситуации


Многие Штаты использовали системы «Электронной
регистрации рождения» (EBS – Electronic Birth
Certificate) собственной разработки и работающие в
среде DOS
Факторы, требующие внедрения новой системы



Исторически существовала минимальная координация
между штатами в плане регистрации рождения
Высокая стоимость замены старых DOS-приложений на
новые
Технологические факторы:

Переход от закрытых прикладных систем к системам,
основанным на стандартах



Web-клиент
Технологии порталов
Доступность недорогих стандартных, готовых решений и продуктов
Система e-Vital связана с проблемой идентификации
личности


Стратегия - не полагаться на один способ идентификации
личности, а использовать несколько, в зависимости от целей
Две фазы в решении проблемы

Фаза 1: помощь федерального правительства штатам с точки зрения
обеспечения большей надежности выдаваемых идентификационных
документов (водительских прав, паспортов,…)



e-Vital рассматривается как важнейшая часть решения проблемы
Фаза 2: Биометрические и криптографические технологии
Проблемы
До 11.09.01 только 12 штатов (всего 57 штатов плюс федеральный
округ Колумбия) использовали Он-лайновую Систему Проверки
Номера Социального Страхования (SSOLV - Social Security Online
Verification System)
 На конец 2003 г. 24 штата использовали SSOLV
 Два режима доступа к SSOLV




В режиме реального времени
Пакетная обработка запросов с ответом в течении 24-48 часов
Проблемы использования 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

Результат: стандартизированная концепция
 Не
единая система для регистрации, внедряемая во
всех штатах, а системы на уровне штатов от
различных поставщиков, которые используют:

Одни и те же стандарты для фиксации одной и той же
информации в единообразной манере и в соответствии с
едиными бизнес-правилами
 Возможность
интеграции на национальном уровне
Архитектурный подход к проектированию системы
Методика Microsoft описания Архитектуры: матрица моделей
Бизнес
•Сценарии
Концептуальная
Архитектура
Физическая
Архитектура
(Дизайн)
Технологии
•Бизнес-процессы,
models
•Role Definition
•Схемы
данных и
спецификации документов
•Сообщения/Документы
•Versioned Data
•Взаимосвязи
сервисами
•Определения
сервисов
•Модели классов
типы
серверов: БД, почтовые
с-мы, транзакц. серверы,
messaging
•Мапирование сервисов
•Хостируемое ПО
•Process
•Схемы
•Код
•Физические
•WSDL
•Firewall
•Расписания
•Топология
specifications
•Manual procedures
•Quality standards
•Бизнес-сущности
Приложения
(ex.
“Гражданин”, “Налоговая
декларация”)
•Модели связей
•Модели бизнеспроцессовв
Использования
•Бизнес-модели
•Workflow
Логическая
Архитектура
Информация
БД
•Интерфейс репозиториев
•Код доступа к данным
поддерживаемые
ИТ
•Разбиение на
сервисы
между
процессов
•Код Workflow
•Детальный дизайн
•Архитектура
Центра
Обработки данных
•Нефункциональные
(операционные)
требования
•Распределение
сервисов
•Логические
Серверы
сети
•Мапирование продуктов
Разделение бизнес-моделей и моделей гос.услуг (которые меняются относит. медленно) и
ИТ-приложений и Инфраструктуры повышает продуктивность бизнес-аналитиков, системных
архитекторов и разработчиков, позволяя им легко обмениваться концепциями
Сквозной процесс анализа и
проектирования систем

Функциональные требования к системе фиксируются в форме
анализа Сценариев Использования (Use Cases), что позволяет
создавать модели и шаблоны проектирования информационной
системы
Функциональные
требования
Анализ
Сценариев
Использования
(Use Case)
Проектирование
Шаблоны
Реализация
Процесс анализа и проектирования систем
Сквозной процесс анализа и проектирования систем: от
функциональных требований – к готовым системам
Динамические
модели
System
UseCase1
«extends»
*
Object1
Object2
Object3
Object4
Actor3
Message5
Message6
Message7
Message9
UseCase2
*
**
UseCase4
Message8
*
Message10
Actor1
UseCase3
Message1
*
Component1
Message3
Диаграммы
последовательности
Component3
Прототип
пользовательского
интерфейса
Модели Вариантов
Использования
(Use case)
Message2
Message4
Actor2
Component2
Component4
Диаграммы
кооперации
«datatype»
DataType3
«datatype»
DataType1
Статические
модели
«datatype»
DataType2
Модели
Предметных
областей
Class1
Class4
1 *
Class2
Class3
Диаграммы
классов
Пример: UML-диаграмма классов для Общей
Модели Гос.услуг Великобритании (GCIM)
GCIM является справочной информационной моделью описания
деятельности государственных органов и моделью описания
функциональных требований к разработке электронных услуг,
основанных на интегрированных административных процессах
идентифицирует
Субъект
Пример Сервисного Взаимодействия:
“Уведомление о смене места жительства”
Идентификатор
назначен
идентифицирует
имеет в качестве
участников
Местоположение
Услуга
осуществляется в
происходит в
Сервисное
Взаимодействие
регулируется
Правило
имеет результатом
Результат
Источник: ” e-Services Development Framework”, UK Office of e-Envoy
имеет необходимую
информацию
Свидетельство
Различные UML модели, использованные в «Методике
разработки электронных услуг» Великобритании
Диаграмма Последовательности
Заявитель
Поставщик
Услуги
Ответственное
Ведомство 1
Ответственное
Ведомство 2
Диаграмма Деятельности
Заявитель
Первоначальное
уведомление
Поставщик Услуги
Уведомление
Ответсвенное
Ведомсство
Уведомление
Отчет
Первоначальное
Заявление
Отчет
Принять
Отчет
Диаграмма Классов для “Смены Места Жительства”
«субъект»
Заявитель
имя
телефон
email
основной_язык
«субъект»
ПоставщикУслуги
идентификатор_организации
«местопроложение»
СтарыйАдрес
Отформатировать
и послать
Принять
адрес
дата_выписки
телефон
Проверить и
обновить
«сервисноеВзаимодействие»
Уведомление о Смене
Места Жительства
дата переезда
статус
«местопроложение»
НовыйАдрес
адрес
дата_прописки
телефон
Принять отчет и
обновить
информацию
Послать отчет
Заявителю
«субъект»
ПереезжающийЧеловек
имя_человека
дата_рождения_человека
пол_человека
семейный_статус
Проверить
«идентификатор»
Идентификатор Человека
ОрганизацииПолучателя
идентификатор
«субъект»
ОрганизацияПолучатель
идентификатор_организации
Послать
отчет
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)
Государственные ведомства
Федеральные
Business
Entry Point
Государственные
Web-сервисы

Первоначально была концепция создания единой
точки присутствия в Интернет, через которую
бизнес/граждане могли бы получать доступ ко
ВСЕМ государственным услугам (на всех уровнях)
для выполнения необходимых транзакций. Это
видение было реализовано в форме BEP
(Business Entry Point)
Регионы
(штаты)
Местные

Фаза 1
Этапы проекта ABR
Web-регистрация на основе технологий
Microsoft
 Регистрация для получения нового
Регистрационного Номера Организации
(ABN) – Web, телефон, бланк заявления
 Проект выполнялся Министерством
Налогов Австралии (ATO – Australian
Taxation Office), но был доступен через BEP
 Более 2 млн. зарегистрированных юр.лиц и
2 млн. просмотров через Web ежемесячно
(в 2003 г.)


Фаза 2 – ABR .NET




Межведомственный проект
Предоставление доступа к ABR в режиме он-лайн другим ведомствам
Классический вариант использования технологий Web-сервисов
Защита частной информации: надведомственный механизм, поддерживаемый
Минналогов в интересах всех ведомств



Интеграционное ПО пром. слоя Control Layer (COLA), основанное MS BizTalk Server
Распределенная Системная Среда (DSE - Distributed Systems Environment)


Агентства используют ABR так, что поставляется только та информация, которая требуется
для предоставления услуги для бизнеса
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
Новые регистрации ABN
Апрель 2002 -50%
2001 - 35%
40%
20%
Май 2000 - 17%
3%
Планируемое использование в 1999
янв 2002
июл 2001
янв 2001
июл 2000
янв 2000
0%
июл 1999
% регистр. он-лайн
60%
Дополнительная информация

Архитектура, методики, шаблоны





http://msdn.microsoft.com/architecture
http://msdn.microsoft.com/practices
http://msdn.microsoft.com
http://www.gotdotnet.com
http://www.microsoft.com/rus/msdn/msf - Методика создания прикладных
систем Microsoft Solutions Framework (на русском)
 http://www.gotdotnet.ru (на русском)
 http://www.microsoft.com/net/
 http://www.saclub.ru - Клуб системных архитекторов (на русском)

Ресурсы по ИТ в госорганах (на русском)



http://www.microsoft.com/rus/government
http://www.e-govcompetence.ru – Центр Компетенции по электронному
правительству при Американской Торговой палате
Российское сообщество по SQL Server

http://www.sql.ru/