Методика создания Портала органов власти субъекта Российской Федерации и органов местного самоуправления на основе типового решения
| Вид материала | Книга |
- Методические рекомендации по обеспечению перехода органов исполнительной власти субъектов, 995.14kb.
- Методические рекомендации по обеспечению перехода органов исполнительной власти субъектов, 998.76kb.
- Примерные темы курсовых работ, 195.77kb.
- Правительство российской федерации распоряжение от 31 августа 2002 г. N 1225-р, 264.28kb.
- Статья Основные понятия, 170.92kb.
- Московская финансово-юридическая академия, 22.97kb.
- Законопроект, 181.46kb.
- Основы законодательства, 673.89kb.
- Регламент по энергосбережению для предприятий омской области омск 2010, 688.58kb.
- Согласно ст. 46 Конституции РФ решения и действия (или бездействие) органов государственной, 240.97kb.
6.Организация работ по созданию Регионального портала
6.1Принципы проведения проектных работ
Проект по созданию типового решения Портала органов власти субъектов Российской Федерации организован в соответствии с методологией RAD (Rapid Application Development) (см. Рис. 7.1), а именно:
- Разработка приложений осуществляется итерационно (с использованием пилотных проектов и очередей создания системы);
- Вовлечение пользователей в процесс разработки системы;
- Необходимое применение CASE-средств (Computer Aided System Engineering) и методологий, обеспечивающих высокое качество системы и снижение временных затрат на разработку;
- Использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;
- Тестирование и развитие проекта, осуществляемые одновременно с разработкой;
- Ведение разработки немногочисленной хорошо управляемой командой профессионалов;
- Четкое планирование и руководство разработкой системы, руководство контролем выполнения работ.
Рис. 7.1. Спиральная модель разработки систем по методологии RAD.
К основным достоинствам данного подхода можно отнести:
- Ускорение запуска в эксплуатацию работоспособного варианта системы;
- Участие Заказчика в процессе разработки;
- Существенное снижение проектных рисков.
6.2Организация пилотных проектов
Термин «пилотный проект» весьма близок по смыслу термину «первая очередь». Пилотный проект – это, как правило, первая итерация в создании системы после реализации макета (прототипа) системы с учетом специфики спиральной модели процесса разработки.
Пилотность проекта означает наличие организационных и функциональных ограничений при его реализации. Организационные ограничения позволяют реализовать систему для ограниченной группы пользователей или внедрить «пилот» системы в одном конкретном подразделении заказчика.
Функциональные ограничения позволяют сузить функциональность системы до базовых возможностей для того, чтобы отработать технологии и на следующем этапе создания системы и расширить ее функциональность.
6.3Использование CASE-средств при создании системы
В соответствии с принципами RAD-методологии, заложенными в проведение проектных работ, разработку Правительственного Портала планируется осуществлять, используя современные CASE-средства.
6.4Общесистемные принципы, заложенные в разрабатываемую систему
Основные принципы, заложенные в разрабатываемую систему:
- Принцип соответствия
Архитектура ИС РП должна соответствовать текущим и перспективным целям и функциональным задачам создаваемой системы.
- Открытость
Для обеспечения перспективы развития проекта необходимо предусматривать возможность интеграции гетерогенных вычислительных компонент и различных приложений.
- Принцип модульности
Архитектура типового решения должна быть достаточно гибкой и допускать относительно простое, без коренных структурных изменений, развитие и наращивание функций и ресурсов системы в соответствии с расширением сфер и задач ее применения. Этот принцип также позволяет проводить отладку, удаление, добавление компонент системы без потери работоспособности работающих компонент.
- Принцип индивидуализации
Необходимо обеспечить максимально удобный индивидуальный доступ к Правительственному Порталу для всех потенциальных групп пользователей с функциональностью, соответствующей задачам, решаемым этими группами пользователей.
- Принцип управляемости
Необходимо предоставить гибкие, полнофункциональные механизмы управления типовым решением на всех уровнях его архитектуры, а именно: на уровне инфраструктуры (администратором), на функциональном уровне (администратором), на уровне представления (пользователем).
- Принцип системности
Архитектура системы должна быть построена таким образом, чтобы все взаимосвязанные подсистемы строились по единой методологии и отвечали единым принципам взаимодействия, надежности и управления.
- Принцип безопасности и надежности
Должны быть обеспечены безопасность функционирования информационной системы и надежная защита данных от ошибок, от преднамеренного разрушения или потери информации, а также авторизация пользователей, управление рабочей нагрузкой, резервированием и оперативным восстановлением функционирования информационной системы после сбоев.
7.Методика создания и внедрения Регионального портала
7.1Методика создания типового решения
Процесс разработки типового решения включает в себя восемь этапов. Связь этих этапов с ГОСТ 34.601-90 (Стадии создания автоматизированных систем) представлена в Таблице 3.1.
Таблица 3.1. Этапы разработки типового решения
| № этапа | Методика разработки Типового решения | ГОСТ 34.601-90 Стадии создания автоматизированных систем |
| | Функциональный анализ | Формирование требований к АС |
| | Определение информационных сервисов (на основе референтной модели сервисов), покрывающих выбранную функциональность | Разработка концепции АС |
| | Выбор технических компонентов для реализации информационных сервисов портала | Техническое задание |
| | Разработка прототипа | Эскизный проект |
| | Тестирование прототипа, устранение замечаний | |
| | Разработка Типового решения (на основе прототипа) | Технический проект |
| | Тестирование Типового решения. Устранение замечаний | |
| | Подготовка документации | Рабочая документация |
7.1.1Функциональный анализ
Результат функционального анализа – функциональная модель. Учитывая специфику специализированной информационной системы «Региональный информационный портал», функциональная модель может быть упрощена до трехуровневой классификации функций. Пример верхнего уровня такой классификации применительно к региональному порталу Органов Власти Субъекта Федерации представлен ниже:
- Поддержка открытости деятельности ОВСФ (официальное информирование);
- Предоставление государственных услуг («социальные сервисы»);
- Поддержка закупок для государственных нужд (электронные закупки);
- Интеграция региональных информационных ресурсов (единая точка входа);
- Интеграция с другими государственными порталами (ПП и Ведомственными);
- Управление порталом (Эксплуатация);
- Обеспечение ИБ информационных ресурсов и систем портала.
7.1.2Определение информационных сервисов
Определение информационных сервисов осуществляется на основе референтной модели сервисов, покрывающих выбранную функциональность. Референтная модель сервисов разработана на основе аналогичной модели Офиса Управления Программами Архитектуры Федерального Предприятия США (FEAPMO). Верхний уровень модели представлен на рисунке 3.1.
Рисунок 3.1. Верхний уровень референтной модели сервисов.
- К сервисам ИБ относятся:
- Идентификация и аутентификация;
- Контроль доступа;
- Шифрование;
- Обнаружение несанкционированных вторжений;
- Проверка подлинности;
- Цифровая подпись;
- Управление пользователями;
- Управление ролями и правами;
- Мониторинг использования приложений и систем и анализ.
- К сервисам представления информации относятся:
- Доступ к информации;
- Категоризация информации;
- Интерфейс представления информации (Web-формы);
- Средства навигации.
- К транзакционным сервисам и сервисам управления потоком работ (workflow) относятся:
- Обмен данными и сообщениями;
- Определение форматов данных и сообщений;
- Постановка сообщений в очередь.
- К аналитическим сервисам относятся:
- Извлечение, обработка и хранение данных;
- Отчетность;
- Анализ, статистика;
- Моделирование;
- Прогнозирование;
- Интеллектуальный анализ;
- Визуализация;
- К сервисам управления информацией относятся:
- Управление данными;
- Управление контентом;
- Управление документами;
- Управление формами документов;
- Управление знаниями;
- Управление архивами.
- К вычислительным сервисам относятся аппаратные ресурсы: серверы, рабочие станции, персональные компьютеры.
- К коммуникационным сервисам относятся:
- Компьютерная и телефонная интеграция;
- Управление рабочими группами (groupware);
- Управление событиями и новостями;
- Аудио- и видео-конференции.
Необходимый набор информационных сервисов определяется на основе маппирования референтной модели сервисов на функциональную модель. Ниже представлен пример маппирования одной из составляющих функции «Обеспечение открытости деятельности ОВСФ» в части правительственного информирования.
Таблица 3.2. Пример маппирования функций на информационные сервисы
| Функция (2-й уровень) | Информационные сервисы (1-й уровень) | Информационные сервисы (2-й уровень) | Информационные сервисы (3-й уровень) |
| Ф1. Официальное информирование граждан, представителей бизнес-сообщества и общестенных организаций | С1. Сервисы представления информации | С1.1. Настройка клиентских предпочтений | С1.1.1. Персонализация, подписка С1.1.2. Автоматические уведомления С1.1.3. Управление профилем пользователя |
| С1.2. Поддержка по запросу клиента | С1.2.1. On-line помощь С1.2.2. Регистрация С1.2.3. Многоязыковая поддержка | ||
| С2. Сервисы управления потоком работ | С2.1. Планирование мероприятий | С2.1.1 Планирование выхода публикаций | |
| С3. Сервисы управления информацией | С3.1. Управление контентом | С3.1.1. Подготовка материалов С3.1.2. Коррекция и утверждение материалов С3.1.3 Публикация | |
| С3.2. Управление архивами | С3.2.1 Классификация материалов С3.2.2. Формирование архивов публикаций | ||
| С3.3. Управление данными | С3.3.1. Обмен данными С3.3.2. Управление метаданными С3.3.3. Автоматическая коррекция данных С3.3.4. Архивирование данных С3.3.5. Восстановление данных С3.3.6. Классификация данных | ||
| | С4. Аналитические сервисы | С4.1. Анализ и статистика | С4.1.1. Анализ статистики доступа к материалам |
| | С4.2. Визуализация | С4.2.2. Поддержка графиков и диаграмм | |
| | С4.3. Отчеты о востребованности материалов портала | С4.3.1 Динамические отчеты С4.3.2 Стандартные отчеты |
7.1.3Выбор технических компонентов
Для реализации информационных сервисов портала необходим набор технологических компонентов Архитектуры. Выбор технологических компонентов также как и сервисов (из сервисной референтной модели) осуществляется на основе референтной технической модели.
Верхний уровень технической референтной модели представлен следующими информационными сервисами (Таблица 3.3.).
Таблица 3.3. Верхний уровень технической референтной модели
| Доступ и доставка сервисов | Платформа и инфраструктура |
|
|
| Структурные компоненты сервиса | Интерфейсы и интеграция |
|
|
Существует два основных варианта выбора Технологических компонентов. Первый вариант заключается в выборе низкоуровневых компонентов и в последующей нарезке совокупности этих компонентов на приложения. Второй вариант заключается в выборе промышленных компонентов, реализующих набор информационных сервисов, а затем интеграцию этих компонентов в единое Решение. Типовое решение регионального портала разрабатывалось по второму варианту. За основу была выбрана платформа (и компоненты) Компании Microsoft.
Один из возможных вариантов выбора компонентов для портального решения представлен на схеме (рисунок 3.2.).
Рисунок 3.2. Выбор технологических компонентов для портального решения.
7.1.4Разработка прототипа, тестирование, устранение замечаний
Идея разработки прототипа отражает некоторые аспекты применения спирального подхода к разработке программного обеспечения: на каждом витке процесс разработки проходит одни и те же стадии, только для разного уровня решения. Учитывая специфику решения, подобный подход можно существенным образом упростить. На стадии разработки прототипа можно без ущерба для проекта отказаться от постановки задачи на создание прототипа, разработки ТЗ и т.п. документов. Достаточно определить ограниченный набор функций (и соответственно, информационных сервисов), которые должны быть реализованы в прототипе.
Таким образом, прототип реализует лишь ограниченный набор функций Типового решения. Функции для реализации в прототипе выбираются по следующему принципу:
- Функция относится к основной функциональности решения;
- Функция может быть быстро реализована;
- Реализация функции существенным образом влияет на выбор технологических компонентов (качественная реализация позволяет аргументировать выбор);
- Реализация функций не требует полного набора компонентов аппаратно-технического обеспечения Решения (т.е. функция может быть реализована на ограниченном наборе аппаратных средств).
На данном этапе также разрабатывается программа тестирования прототипа. Ошибки и замечания, выявленные на этапе тестирования, оформляются в виде отчета и затем устраняются.
7.1.5Разработка Типового решения, Тестирование, Устранение замечаний
Типовое решение разрабатывается на основе работающего прототипа. Реализуется полный набор функций.
Параллельно с разработкой программно-аппаратного обеспечения Типового решения разрабатывается пакет документации, включающий программу тестирования Типового решения. Выявленные на этапе тестирования Типового решения ошибки и замечания оформляются в виде отчета и затем устраняются.
7.1.6Подготовка документации
С учетом специфики задачи для типового решения разрабатывается полный набор документации, включающий следующие пакеты документов:
- Документацию Технического проекта;
- Эксплуатационную документацию.
7.1.7Документация технического проекта
- Ведомость технического проекта;
- Пояснительная записка к техническому проекту (содержит: описание информационного обеспечения, описание комплекса технических средств, описание программного обеспечения).
7.1.8Эксплуатационная документация
- Общее описание Системы;
- Руководство системного администратора;
- Описание структуры баз данных;
- Руководства пользователей;
- Формуляр, включающий:
общие сведения;
основные характеристики;
комплектность;
свидетельство о приемке;
гарантийные обязательства;
сведения о состоянии Системы;
сведения о рекламациях.
Общее программное обеспечение и технические средства снабжаются документацией, входящей в поставляемый производителем комплект.