1 методика проведения выбора программного обеспечения и
advertisement
ЗАКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО «АУДИТОРСКО-КОНСУЛЬТАЦИОННАЯ ГРУППА «РАЗВИТИЕ БИЗНЕС-СИСТЕМ» УДК УТВЕРЖДАЮ № госрегистрации Директор департамента государственного консалтинга Инв. № _____________________ М.Ю. Иванков «__» __________ 2010 г. МЕТОДИКА ПРОВЕДЕНИЯ ВЫБОРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ПОТЕНЦИАЛЬНОГО ПОСТАВЩИКА Директор проекта (руководитель темы) – Заместитель директора Департамента государственного консалтинга ___________________ А.Ю. Чудинов подпись, дата Москва 2010 Деятельность ЗАО «АКГ «РБС» сертифицирована в соответствии со стандартом ISO 9001:2000 СОДЕРЖАНИЕ ПЕРЕЧЕНЬ ПРИНЯТЫХ СОКРАЩЕНИЙ ........................................................................... 3 1 МЕТОДИКА ПРОВЕДЕНИЯ ВЫБОРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ПОТЕНЦИАЛЬНОГО ПОСТАВЩИКА ДЛЯ АИС АНАЛИТИЧЕСКАЯ СИСТЕМА ОПТИМИЗАЦИИ ......................................................................................................................... 4 1.1. МЕТОДИКА ПРОВЕДЕНИЯ АНАЛИЗА ................................................................................. 4 1.1.1 ПРИНЦИПЫ ФОРМИРОВАНИЯ ПЕРЕЧНЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ПОТЕНЦИАЛЬНЫХ ПОСТАВЩИКОВ ПО ......................................................................................... 6 1.1.2 ПОДХОД К РАЗРАБОТКЕ КРИТЕРИАЛЬНОЙ МАТРИЦЫ ......................................................... 7 1.1.3 ПОДХОД К ОЦЕНКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ....................................................... 10 1.1.4 ПОДХОД К ОЦЕНКЕ СТОИМОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ .................................. 12 1.1.5 ПОДХОД К ОЦЕНКЕ ПОТЕНЦИАЛЬНЫХ ПОСТАВЩИКОВ ПО ............................................. 12 1.1.6 ПОДХОД К ОЦЕНКЕ КОММЕРЧЕСКИХ ПРЕДЛОЖЕНИЙ/ЗАЯВОК, ПРЕДОСТАВЛЕННЫХ ПОТЕНЦИАЛЬНЫМИ ПОСТАВЩИКАМИ ПО .................................................................................. 13 1.1.7 ПОЛУЧЕНИЕ ИТОГОВОЙ ОЦЕНКИ .................................................................................... 14 1.1.8 ПРОВЕДЕНИЕ АНАЛИЗА ЧУВСТВИТЕЛЬНОСТИ .................................................................. 14 1.2. ТРЕБОВАНИЯ К ПОТЕНЦИАЛЬНОМУ ПОСТАВЩИКУ ПО ................................................. 15 1.3. ТРЕБОВАНИЯ К КОММЕРЧЕСКИМ ПРЕДЛОЖЕНИЯМ/ЗАЯВКАМ ПОТЕНЦИАЛЬНЫХ ПОСТАВЩИКОВ ........................................................................................................................... 16 1.3.1 ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ПРЕДЛОЖЕНИЙ .............................................................. 16 1.3.2 ТРЕБОВАНИЯ К СОСТАВУ ПРЕДПОЛАГАЕМЫХ РАБОТ ....................................................... 17 1.3.3 ТРЕБОВАНИЯ К ПРОЕКТНОЙ КОМАНДЕ ............................................................................ 17 1.3.4 ТРЕБОВАНИЯ К СРОКАМ ВЫПОЛНЕНИЯ РАБОТ ................................................................ 17 1.4. БАЗОВЫЕ ТРЕБОВАНИЯ К СИСТЕМЕ ................................................................................ 17 1.5. ДЕТАЛЬНЫЕ КРИТЕРИИ ДЛЯ ОЦЕНКИ И ВЫБОРА СИСТЕМЫ ........................................... 18 1.5.1 ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ ДЛЯ ОЦЕНКИ И ВЫБОРА СИСТЕМЫ ............................ 18 1.5.2. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ ......................................................................... 31 1.5.2.1 Общие требования .............................................................................................. 31 1.5.2.2 Требования к надежности .................................................................................. 32 1.5.2.3 Требования к информационной безопасности ................................................ 32 1.5.2.4 Требования к эргономике и технической эстетике ......................................... 34 1.5.2.5 Требования к программному обеспечению ..................................................... 35 1.5.2.6 Требования к аппаратному обеспечению ........................................................ 35 1.5.2.7 Требования к средствам разработки ................................................................. 36 1.5.2.8 Требования к документации .............................................................................. 37 1.5.2.9 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами ....................................................................................................... 37 2 ПЕРЕЧЕНЬ ПРИНЯТЫХ СОКРАЩЕНИЙ АРМ Автоматизированное рабочее место АПК Аппаратно-программный комплекс БД База данных НПА Нормативно-правовые акты ИС Информационная система ПК Персональный компьютер СЗИ Средства защиты информации Система, ГАС ОГФУ Автоматизированная информационная система «Аналитическая система оптимизации государственных (муниципальных) функций и услуг как инструмента совершенствования государственного управления и местного самоуправления» ОГФУ Оптимизация государственных функций и услуг ЛВС Локальная вычислительная сеть ЛПР Лицо, принимающее решение ОПО Общее программное обеспечение ОС Операционная система ПО Программное обеспечение ПТС Программно-технические средства ХД Хранилище данных СПО Специальное программное обеспечение СУБД Система управления базами данных ТЗ Техническое задание ФОИВ Федеральные органы исполнительной власти ЦХД Централизованное хранилище данных 3 1 МЕТОДИКА ПРОВЕДЕНИЯ ВЫБОРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ПОТЕНЦИАЛЬНОГО ПОСТАВЩИКА ДЛЯ АИС АНАЛИТИЧЕСКАЯ СИСТЕМА ОПТИМИЗАЦИИ Настоящая методика предназначена для оценки соответствия готовых программно-технологических решений функциональным, технологическим, информационным требованиям, на базе которых должно осуществляться создание (разработка, настройка и внедрение) будущей системы, а также для оценки поставщиков ПО. Данная методика применяется к программно-технологическим решениям как российских, так и зарубежных производителей систем, продуктивно функционирующих на российском рынке. 1.1. МЕТОДИКА ПРОВЕДЕНИЯ АНАЛИЗА Выбор ПО осуществляется в несколько этапов, первый этап служит для первоначального формирования списка систем, которые соответствуют базовым требованиям к Автоматизированная информационная система «Аналитическая система оптимизации государственных (муниципальных) функций и услуг как инструмента совершенствования государственного управления и местного самоуправления». ПО несоответствующее этим требованиям, стоит исключить из рассмотрения. Последующие этапы предназначены для сравнения систем между собой и выделения наиболее подходящих систем для создания Системы . Этапы работ по оценке программно-технологических решений: Этап 1 1.1.Формирование базовых требований к программному обеспечению Системы1; Базовые требования к Системе сформированы в рамках ТЗ на систему, на основании ТЗ на систему в методике представлены детальные критерии выбора программной платформы для АИС АНАЛИТИЧЕСКАЯ СИСТЕМА ОПТИМИЗАЦИИ (п.1.5.). 1 4 1.2.Обзор потенциальных поставщиков и программного обеспечения для Системы ; 1.3.Формирование короткого списка потенциально пригодного программного обеспечения и поставщиков. Этап 2 2.1. Формирование детальных критериев выбора программной платформы для Системы : – Формирование общих требований; – Формирование функциональных требований к Системе; – Формирование требований к техническим характеристикам Системы; – Формирование требований к поставщику ПО; – Формирование стоимостных требований; 2.2. Разработка критериальной матрицы; 2.3. Установление весовых значений критериев. Этап 3 3.1. Сбор информации по программным платформам и поставщикам ПО; – Подготовка запроса потенциальным поставщикам ПО, согласование с заказчиком; – Передача запроса потенциальным поставщикам; – Встречи, переговоры, презентации ПО, консультации с потенциальными поставщиками; 3.2. Заполнение критериальных матриц. Этап 4 4.1. Расчет интегральных оценок соответствия систем и потенциальных поставщиков детальным критериям выбора ПО для Системы; 4.2. Оценка вариантов стоимости систем для программного обеспечения Системы; 4.3. Формирование итоговых оценок программного обеспечения и поставщиков; 5 для определения пригодного 4.4. Анализ полученных результов. Этап 5 5.1. Формирование рекомендаций по выбору программного обеспечения и потенциального поставщика для Системы . Разработанные критерии оценки и ранжирования информации должны обеспечивать нижеследующее: – Обеспечивать проведение оценки соответствия программного из рассмотрения программное обеспечения требованиям к Системе; – Обеспечивать исключение обеспечение, не отвечающее2 базовым требованиям; – Обеспечивать ранжирование программного обеспечения по степени соответствия требованиям; – Обеспечивать ранжирование программного обеспечения по степени защиты размещений и инвестиций3; – Обеспечивать ранжирование программного обеспечения на соответсвие экспертной оценки значимости отдельных параметров для целей создания Системы. 1.1.1 Принципы формирования перечня программного обеспечения и потенциальных поставщиков ПО Перед проведением исследования готовых программных продуктов с применением разработанной критериальной матрицы должен быть сформирован предварительный перечень программного обеспечения и потенциальных поставщиков, требующий последующего анализа («короткий список»). Предварительный перечень программного обеспечения для проведения исследования формируется с учетом специфики деятельности Заказчика и целей и задач, стоящих перед Системой . Перечень программного обеспечения формируется Т.е. базовые требования не могут быть обеспечены либо в стандартной конфигурации, либо за счет допустимых настроек или последующих доработок программного пакета. 3 Возможность развития системы (по функциональности, мощности и т.п.) за счет перенастройки или доработки уже установленной функциональности и дополнения новой с выполнением соответствующего комплекса работ. 2 6 с применением базовых требований, перечисленных в пункте 1.2. и 1.4. настоящего отчета. 1.1.2 Подход к разработке критериальной матрицы Критериальная матрица является инструментом, применяемым для сбора и анализа информации о соответствии исследуемого программного обеспечения и потенциальных поставщиков ПО требованиям Системы . Она используется для последующей обработки собранной информации. Критерии в критериальной матрице разрабатываются в соответствии с определенными и формализованными целями, назначением и основными требованиями к системе и представляют иерархический список, разбитый по тематике оцениваемых параметров. Критерии в критериальной матрице разносятся по следующим группам (Таблица 1). Таблица 1. Группы критериев для оценки Название группы критериев Описание Требования к потенциальному В группе требований к поставщику находятся требования к поставщику ПО организации, проводящей разработку программного продукта. Успех проекта, превращающего стандартный пакет в решение для конкретного предприятия, во многом зависит от постановки задачи и разработчика продукта. Возможности компании разработчика оцениваются в этом разделе. Требования к коммерческим В этой группе требований оцениваются коммерческие предложениям/заявкам предложения/заявки, потенциальных поставщиков поставщиками. Требования включают следующие разделы: Функциональные требования к представленные потенциальными Содержание коммерческих предложений; Состав планируемых работ; Состав проектной команды; Сроки внедрения. В группу функциональных требований включаются все 7 Название группы критериев Описание системе требования, относящиеся к функциональным возможностям Системы. Эта группа требований формируется на основании потребностей Заказчика, формализованных по результатам обследования предприятия. Технические требования к системе К техническим связанные со требованиям способом функциональности и Системы. относятся требования, средствами реализацией Это – требования к техническим возможностям и архитектуре программного продукта. Сюда также относятся требования к аппаратному и программному обеспечению, необходимому для развертывания продукта. Выделяются следующие подразделы: Общие требования; Надежность; Информационная безопасность; Эргономика и техническая эстетика; Требования к программному обеспечению; Требования к аппаратному обеспечению; Средства разработки; Документация; Интеграция. Для каждого критерия ставится в соответствие весовой коэффициент в пределах от 1 до 10, определяемый в зависимости от оценки необходимости наличия данной функции или качества в системе описываемой критерием. Выставляемая оценка по каждому пункту, умножается на этот коэффициент для получения результирующей оценки выбранного критерия. Чем ниже установлен весовой коэффициент, тем меньше он будет влиять на итоговую оценку по своему разделу, тематике. Установление весовых коэффициентов проводится экспертами на основании уровня приоритетности выполнения данного критерия для Заказчика (Таблица 2). 8 Таблица 2. Уровни приоритетности критериев и весовые коэффициенты при оценке функциональных и технических требований к системе Уровень критерия Описание Вес Отсекающий критерий Это концептуальное свойство системы. Оно пронизывает 10 многие ее элементы. Работа многих людей требует наличия этого качества/свойства в системе. Обходные процедуры при отсутствии данного свойства, потребуют неприемлемых затрат или чрезмерно усложнят процесс (сделают его трудно управляемым). Критичное требование При отсутствии данное свойство в системе в принципе 8 может быть доработано или имеются альтернативные решения, восполняющие этот недостаток, адекватные по цене. Это качество или свойство системы явно необходимо для эффективного функционирования Системы. При отсутствии данного свойства не было бы смысла внедрять данную программу в этой области. Рабочее требование Это является рабочим требованием. 5 Выполнение данного требования было бы желательно. Компенсация отсутствия данного свойства не будет требовать существенных затрат или существенного усложнения рабочего процесса. Пожелание Отсутствие этого свойства не снижает эффективности 2 работы в целом. Данным пожеланием можно пренебречь или же оно достаточно легко «дорабатывается, настраивается» или обеспечивается обходной процедурой. Для получения количественной оценки соответствия систем и поставщиков используются правила присвоения весов критериям оценки: – Критерии оценки должны быть разделены на 4 группы: требования к потенциальному поставщику ПО, 9 требования к коммерческим предложениям/заявкам потенциальных поставщиков, функциональные требования к системе, технические требования к системе. – Каждой из групп присваивается вес, который выражен в % и зависит от важности для компании каждой из групп – В сумме веса всех групп составляют 100%. – Каждая группа состоит из подгрупп выделенных по определенному признаку (надежность, интеграция и т.д.). Присвоение весов каждой из подгрупп проводится аналогично присвоению весов группам. – Каждая подгруппа состоит из критериев, имеющих веса. Для оценки критериев, входящих в состав подгрупп, предлагается использовать шкалу приоритетов, состоящую из 4 уровней значимости критериев (Таблица 2) – Значимость групп, подгрупп и критериев определяется в зависимости от их влияния на возможность реализовать целевое, желаемое состояние Системы . Для заполнения критериальной матрицы используется информация, полученная: – от разработчиков и поставщиков программного обеспечения; – от заказчиков, использующих аналогичное программно-технологическое решение в режиме промышленной эксплуатации; – по публикациям в СМИ; – по результатам исследований специализированных экспертно- аналитических агентств. 1.1.3 Подход к оценке программного обеспечения Оценка программного обеспечения каждой позиции критериальной матрицы производится по пятибалльной шкале (от 0 – «полное несоответствие», до 4 – «полное соответствие» требованиям). 10 В зависимости от темы рассматриваемой в критерии, качество может оцениваться как наличие необходимого функционала отвечающего по полноте реализации обозначенным потребностям Заказчика. В Таблице 3 представлены характеристики балльной оценки. Таблица 3. Шкала баллов ХАРАКТЕРИСТИКА ОЦЕНКИ БАЛЛ функция (качество) отсутствует, реализовать ее невозможно функция (качество) отсутствует, но ее возможно реализовать путем 1 0 доработки (донастройки) системы похожие, но отличные от требуемых, функции или качества системы 2 находятся в стадии разработки реализованы похожие, но несколько отличные от требуемых, функции 3 или качества системы функция или качество безоговорочно реализовано 4 Порядок установки баллов – Балл выставляется на основании ответов на вопросы критериальной матрицы и мнения экспертов о заявленных характеристиках предлагаемого программного обеспечения. – Отсутствие ответа или несоответствие ответа приведенному комментарию оценивается как «полное несоответствие» («0» баллов). – Противоречивые ответы на различные вопросы, связанные между собой по смыслу, оцениваются как «полное несоответствие» по всем вопросам («0» баллов). – Заявленные требования реализуются одной версией программного обеспечения. В случае указания в комментариях различных версий программного обеспечения, предпочтение отдается последней. Ответы, ссылающиеся на предыдущую версию, не принимаются и оцениваются как «полное несоответствие» («0» баллов). 11 1.1.4 Подход к оценке стоимости программного обеспечения Отдельно следует оценить стоимость лицензий для каждого программного продукта. Стоимость будет оцениваться по действующему прайс-листу компанийразработчиков, исходя из 100 рабочих мест пользователей. Диапазон оценки составляет от 0 до 4 баллов, программному продукту с наименьшей стоимостью лицензий будет присвоено «4» балла, с наибольшей стоимостью лицензий – «0» баллов. 1.1.5 Подход к оценке потенциальных поставщиков ПО Оценка потенциальных поставщиков ПО производится по четырехбальной шкале (от 0 – «полное несоответствие», до 3 – «полное соответствие» требованиям). Для количественных критериев, оценка будет вычисляться пропорционально установленному количественному параметру в рассматриваемом критерии к количеству указанному поставщиком. Поставщику с наибольшим пропорциональным соотношением будет поставлена наибольшая оценка. В Таблице 4 представлены характеристики балльной оценки для разработанных критериев. Таблица 4. Шкала баллов ХАРАКТЕРИСТИКА ОЦЕНКИ БАЛЛ полное несоответствие требованию 0 значительное несоответствие требованию 1 частичное несоответствие требованию 2 полное соответствие требованию 3 Порядок установки баллов – Балл выставляется на основании ответов на вопросы критериальной матрицы и мнения экспертов о характеристиках или возможностях компаниипоставщика. 12 – Отсутствие ответа или несоответствие ответа приведенному требованию оценивается как «полное несоответствие» («0» баллов). – Противоречивые ответы на различные вопросы, связанные между собой по смыслу, оцениваются как «полное несоответствие» по всем вопросам («0» баллов). Оценка средней ставки специалистов Диапазон оценки составляет от 0 до 3 баллов, Поставщику, указавшему наименьшую ставку специалистов будет присвоено «3» балла, наибольшую – «0» баллов. Получение итоговой оценки На основе выставленных оценок и весовых коэффициентов по каждому критерию будет получен итоговый балл. Анализ итоговых оценок позволит сделать предварительные выводы о компаниях-поставщиках. 1.1.6 Подход к оценке Коммерческих предложений/Заявок, предоставленных потенциальными поставщиками ПО Оценка коммерческих предложений/заявок проводится с целью разработки рекомендаций по выбору компании-поставщика ПО, удовлетворяющей всем требованиям Заказчика и Системе. Подход к оценке состава и содержания КП аналогичен подходу к оценке потенциальных поставщиков, т.е. определяется соответствие/несоответствие описания, разработанным требованиям (Таблица 4). Отдельно следует оценить сроки внедрения. Для данного параметра устанавливается следующая шкала оценки: Оценка сроков внедрения Диапазон оценки составляет от 0 до 3 баллов, поставщику, указавшему в КП наименьшие сроки внедрения будет присвоено «3» балла, наибольшие – «0» баллов. 13 1.1.7 Получение итоговой оценки На основе выставленных оценок и весовых коэффициентов по каждому критерию будет получен итоговый балл. Критериальная матрица представляет собой иерархический список итоговых результат всех критериев относящихся к данному параметру. Таким образом, поскольку иерархия критериев разбивает оценки на темы, мы можем сравнивать различные аспекты реализации программных продуктов на общем и детальном уровне. 1.1.8 Проведение анализа чувствительности Любые методики, основанные на экспертных (субъективных) оценках не являются математическими и не могут считаться абсолютно точными. Поэтому при расчете итоговых оценок необходимо применить различные техники анализа, например, анализ чувствительности. Анализ чувствительности проводится различными способами. Для более взвешенной оценки рассчитывается результирующая оценка, при изменении первоначально установленных весов: присваиваем всем критериям равные веса, обнуляем веса некоторых критериев. Это позволяет проанализировать устойчивость полученных результатов и нивелировать слабость метода многокритериального анализа – случайные оценки (например, полученные поставщиком за блестящий ответ на какую-нибудь одну группу вопросов с высоким весом). 14 1.2. ТРЕБОВАНИЯ К ПОТЕНЦИАЛЬНОМУ ПОСТАВЩИКУ ПО Для проведения углубленного анализа к потенциальным поставщикам ПО для Системы применяются следующие базовые требования: 1. Надежность и стабильность поставщика ПО: a. количество полных лет на российском рынке информационных технологий – не менее 5 лет; b. наличие практики (проектного опыта и сертифицированных специалистов) по осуществлению работ по проектированию и пуско-наладке программно-аппаратного обеспечения; c. масштаб реализованных ИТ-проектов; 2. Количество успешных проектов внедрения информационных систем (внедрение нескольких систем - разные контуры) – 6 и более в течение последних 3х лет; 3. Наличие опыта интеграции предлагаемого ПО с различными информационными системами; 4. Наличие опыта ИТ-проектов в государственном секторе; 5. Наличие устойчивых перспектив по развитию ПО; 6. Количество сертифицированных специалистов в областях, требуемых для проекта/ управления проектом - 3 и более; 7. Средняя ставка специалистов; 8. Наличие подразделений, специализирующихся на: a. инсталляции ПО; b. системной настройке; c. внедрении программного обеспечения; d. обучении и сертификации пользователей; 9. Наличие выделенной службы технической поддержки; 10. Стоимость корпоративного обучения по системе; 11. Наличие в Компании методик управления, организации, ведения и сопровождения проектов (ГОСТ, другие). 15 ТРЕБОВАНИЯ 1.3. К КОММЕРЧЕСКИМ ПРЕДЛОЖЕНИЯМ/ЗАЯВКАМ ПОТЕНЦИАЛЬНЫХ ПОСТАВЩИКОВ Коммерческие предложения/заявки, полученные от потенциальных поставщиков ПО необходимо оценивать по следующим параметрам: – Содержание коммерческих предложений/заявок; – Состав планируемых работ; – Состав проектной команды; – Сроки внедрения. 1.3.1 Требования к содержанию предложений Предложение должно содержать: – Общую информацию о Компании, включая: – Описание структуры Компании – Описание количества сертифицированных специалистов в областях, требуемых для проекта, управления проектом, внедрения информационных систем; – Описание ключевых преимуществ Компании, в рамках вышеуказанных услуг; – Описание используемой методологии реализации работ (ГОСТ, другие); – Указание сроков проведения работ (на основании опыта выполнения аналогичных проектов); – Состав проектной команды (роли, резюме); – Указание ставки специалиста (1 человеко/день); – Стоимость работ, возможности получения скидок; – Указание даты готовности к выполнению работ; – Перечень успешно реализованных аналогичных проектов Компании. 16 1.3.2 Требования к составу предполагаемых работ При внедрении решений для Системы, поставщик ПО должен использовать комплекс российских стандартов (ГОСТов), либо другие стандарты в области качества и управления проектами. 1.3.3 Требования к проектной команде В коммерческом предложении/заявке должны быть указан состав проектной команды, включая роли членов проектной команды, их загрузку на проекте, а также резюме членов проектной команды. 1.3.4 Требования к срокам выполнения работ Сроки выполнения работ должны быть указаны по каждому этапу предполагаемых работ. 1.4. БАЗОВЫЕ ТРЕБОВАНИЯ К СИСТЕМЕ Формирование списка потенциально пригодного программного обеспечения для Системы производится путем проведения анализа соответствия программных продуктов предварительного списка базовым требованиям к системе, выступающим в качестве критериев, по которым производится отбор решений списка. Ниже приведен перечень базовых требований, который используется в данном проекте для формирования списка программного обеспечения. Базовые принципы, применимые к ПО: 1. Использование современных технологических решений; 2. Существующие в ПО средства интеграции с внешними системами 3. Достаточная статистика продуктивных внедрений (не менее 6 законченных полнофункциональных внедрений); 17 4. Русифицированная версия системы; 5. Возможность удаленного доступа к системе; 6. Наличие средств поддержки разграничения полномочий пользователей, аудита действий пользователей и т.д.; 7. Развитая функциональность системы (наличие ключевых функций для обеспечения задач Системы, в том числе: сбор, актуализация, хранение данных; формирование аналитической отчетности; сценарное моделирование; оптимизация: и другие функции, обозначенные в разделе 1.5.1. 1.5. ДЕТАЛЬНЫЕ КРИТЕРИИ ДЛЯ ОЦЕНКИ И ВЫБОРА СИСТЕМЫ 1.5.1 Функциональные требования для оценки и выбора системы Функции ввода и верификации данных Функции ввода и верификации данных: – Функции ввода, редактирования, удаления данных через web-формы; – Функции ввода, редактирования, удаления данных через интерфейс к базе данных (БД); – Функции проверки исходных данных на соответствие типу и диапазону допустимых значений; – Функции задания диапазона допустимых значений данных; – Функции проверки данных на повторяемость; – Функции семантической проверки данных; – Функции поиска. Функции ввода, редактирования, удаления данных через web-формы Ввод, редактирование и удаление данных посредством web-форм должен позволять для заполнения форм использовать классификаторы, предварительно созданные в Системе, а также предоставлять возможность заполнения полей разных типов. Формы быть удобными с точки зрения пользователя и должны обеспечивать на уровне интерфейсов поддержку выбора релевантных объектов окружения для 18 вводимой информации о функциях и процедурах органов исполнительной власти и органов местного самоуправления. Функции ввода, редактирования, удаления данных через интерфейс к базе данных (БД) Ввод, редактирование и удаление данных через интерфейс к базе данных должен позволять для заполнения форм использовать предварительно созданные в Системе, а также классификаторы, предоставлять возможность заполнения полей разных типов. Формы быть удобными с точки зрения пользователя и должны обеспечивать на уровне интерфейсов поддержку выбора релевантных объектов окружения для вводимой информации о функциях и процедурах органов исполнительной власти и органов местного самоуправления. Функции проверки исходных данных на соответствие типу и диапазону допустимых значений Функция обеспечивает невозможность ввода информации иного типа, чем определено для поля, а также осуществляет контроль данных на соответствие определенному для поля диапазону. Функция является служебной функцией для функций 3.1.1. и 3.1.1. Функции задания диапазона допустимых значений данных Функция задания диапазона значений обеспечивает возможность задания диапазонов для полей, являющихся числовыми и датой. Функция является служебной функцией для функций 3.1.1. и 3.1.2. Функции проверки данных на повторяемость Функция осуществляет проверку на повторяемость для полей, являющихся справочниками. Функция является служебной функцией для функций 3.1.1 и 3.1.2. Функции семантической проверки данных Функция осуществляет проверку на использование запрещенных символов. Состав запрещенных символов определяется настройкой параметров Системы. Функция является служебной функцией для функций 3.1.1 и 3.1.2. 19 Функции поиска Функция обеспечивает возможность контекстного поиска по любому из полей формы. Функции структурных графических описаний и моделирования описаний и моделирования административно-управленческих процессов Функции структурных графических административно-управленческих процессов: – Функция формирования визуальных графических представлений структуры органов исполнительной власти; – Функция формирования описания органов исполнительной власти (атрибуты); – Функция описания структуры полномочий органов исполнительной власти; – Функция графического описания функций и административных процедур; – Функция описания ролевых назначений органов исполнительной власти; – Функция формирования бюджета органов исполнительной власти (до детализации по подразделениям); – Функции моделирования административно-управленческих процессов; – Функция печати структурных графических описаний. Алгоритмы функций должны соответствовать следующим методическим рекомендациям: – методические основы идентификации функции в Системе; – методика процессно-ориентированного описания функции; – методика анализа процесса исполнения функции и оптимизации (реинжиниринга) административных процессов. Требования к подсистеме формирования композитных услуг Подсистема формирования композитных услуг должна обеспечить реализацию формирования композитных услуг, согласно методике: – Методика моделирования композитных услуг. 20 Подсистема формирования композитных услуг должна включать следующие функции: – Функции ручного режима построения композитной услуги; – Функции автоматического построения композитной услуги. Функции ручного режима построения композитной услуги Функции ручного режима построения композитной услуги предоставляют инструментарий для создания связей в формате визуального представления между графическими представлениями информационных объектов. Функции включают: поддержку различных вариантов увязки процессов (по идентичным входящим/исходящим документам, исполняющим организациям, ресурсам и пр.), поддержку интерактивных инструментов оперативной корректировки образуемых взаимосвязей процессов при построении композитной услуги (визуализации ситуаций, где в автоматизированном режиме не достаточно данных для определения взаимосвязи процессов, формирование интерактивных подсказок по создание взаимосвязей процессов и пр.). Функции автоматического построения композитной услуги Функции автоматического построения композитной услуги осуществляют построение композитной услуги за счет увязки шагов процессов (функций) в сквозную цепочку в автоматическом режиме. Пример представлен на Рис.1. Обе следующих процедуры имеют на входе один и тот же документ (по названию), о чем система уведомляет для разрешения возможной неоднозначности Формирование и выдача расписки в приеме документов Присвоение кадастрового номера объекту учета Государственная функция (1) Государственная функция (2) Формирование реестрового дела Государственная функция (3) Рис. 1 21 Функции включают проверку по критериям взаимосвязанности (сопоставимости) функций, исполняемых государственными и муниципальными органами, позволяющие объединить их в единый контур композитной услуги, в предоставлении которой участвуют разные органы власти разных уровней управления. Функции автоматизированной обработки введенной информации позволяют производить формирование композитных услуг путем автоматического нахождения точек взаимосвязи процессов и строить логические целостные модели с предоставлением аналитикам информации для дальнейшего совершенствования созданных таким образом моделей (т.е. указание возможных неоднозначностей, либо нехватки исходных данных для автоматического принятия решений). Функции подсистемы поддержки принятия решений Функции поддержки принятия решений: – Функции построения и отображения аналитических отчетов (генератор отчетов); – Функции построения многомерных и многокритериальных отчетов с использованием OLAP-технологии; – – Функции построения причинно-следственных связей; Функции экспорта выходных документов в наиболее распространенные форматы (xls, pdf, другие); – Функции печати отчетов. Функции построения и отображения аналитических отчетов (генератор отчетов) Функция обеспечивает отображение аналитических отчетов на основе данных ЦХД, поступающих от подсистем-поставщиков данных. Функция обеспечивает реализацию следующих возможностей: – Возможности интерактивного изменения параметров отчета: фильтрация, сортировка, детализация агрегированных значений (drill-down) и свертка (roll-up); 22 – Настройка вида отчета (возможность включения логотипов, схем и т.д., изменение расположения полей: ширина, высота). Функции построения многомерных и многокритериальных отчетов с использованием OLAP-технологии Функция обеспечивает возможность построения многомерных отчетов с использованием OLAP-технологии с возможностью задания нескольких критериев. Обеспечиваются табличные, графические и картографические форматы (ГИСинформация). Функция обеспечивает возможность создания отчетов и экранных представлений информации, состоящих одновременно из различных типов данных: – плоские таблицы; – кросс-таблицы; – плоские и трехмерные графики; – текст; – сетевые графики; – изображения; – иерархические деревья показателей и структур; – геоинформационные представления. Функции построения причинно-следственных связей Функция обеспечивает возможность построения причинно-следственных диаграмм. Функции экспорта выходных документов в наиболее распространенные форматы (xls, pdf, другие) Функция обеспечивает возможность экспорта отчетов в наиболее распространенные форматы (xls, pdf, другие). Функции печати отчетов Функция обеспечивает возможность вывода на печать отчетов. Функции подсистемы оценки показателей результативности, эффективности и ресурсного обеспечения Подсистема включает следующие функции: 23 – расчет распределения штатной численности и бюджетного обеспечения по категориям исполняемых функций и реализуемых полномочий «пилотных» федеральных органов исполнительной власти; – расчет стоимости и трудоемкости исполнения каждой функции «пилотного» федерального органа исполнительной власти, а также каждого документа или юридического факта, являющегося результатом исполнения функции; – расчет количества связей функции по линиям входа и выхода; – формирование комплексной модели предоставления сложных государственных услуг, в предоставлении которых участвуют различные органы власти и организации как единый процесс взаимосвязанных функций, показать количество и состав задействованных органов власти, порядок их взаимодействия, входящие, формируемые «внутри» процесса и итоговые документы, последовательность и сроки реализации отдельных административных процедур; – выявление избыточных, неэффективных и дублирующих функций и на этой основе оптимизация процесса предоставления комплексной услуги, а также расчет реального эффекта от оптимизации процесса, как для заявителей, так и для бюджета; – расчет суммарной трудоемкости и стоимости процесса оказания услуги для заявителя и для бюджета; – расчет эффективности исполнения «пилотными» федеральными органами исполнительной власти государственных функций и представление наиболее эффективных путей оптимизации деятельности органов власти, сокращения штатной численности и бюджетных расходов, оптимизации подведомственной сети. – расчета стоимости каждой функции органа власти, а также каждого документа или юридического факта, являющегося результатом исполнения функции, – расчета эффективности исполнения органами исполнительной власти государственных функций. 24 Функции подсистемы сценарного моделирования Функции подсистемы сценарного моделирования должны предоставлять средства для осуществления сценарного моделирования, согласно разработанной в проекте методики: – методика моделирования и оценки вариантов оптимизации государственных (муниципальных) функций; типовые механизмы оптимизации показателей эффективности исполнения государственных (муниципальных) функций. Функции имитационного моделирования и проведения анализа типа «что будет, если» Посредством имитационного моделирования осуществляются: – определение границ эффективности процессов по различным показателям; – поддержка решений по необходимым преобразованиям процессов; – визуализация влияния ресурсных, временных и прочих ограничений; – анализ влияния соотношения ручного/автоматизированного выполнения операций на эффективность процесса в целом. Пример: выявление административных процедур в функции, где при определенном уровне загрузки (количестве поступающих заявок в день) реализующие эти процедуры ресурсы перестают справляться. Функции централизованного хранилища данных и НСИ Система должна обеспечивать выполнение следующих функций хранилища данных: – властных Хранение и доступ к структурированному исчерпывающему перечню полномочий органов государственной власти (органов местного самоуправления), являющихся совокупностью прав и обязанностей органа государственной власти, органа местного самоуправления, необходимых для осуществления целей и задач функционирования, закрепленные законодательными актами Российской Федерации, законодательными актами субъекта Российской Федерации, уставом муниципального образования; 25 – Хранение и доступ к описанию государственных и муниципальных функций, реализуемых соответствующими органами власти или уполномоченными учреждениями; – Хранение и доступ к описанию органов государственной власти и органов местного самоуправления, включая описания уполномоченных учреждений; – Хранение и доступ к объектам декомпозиции государственных (муниципальных) функций (в том числе описание отдельных административных процедур) с указанием следующей информации: – «входа» и «выхода» по каждой функции, реализуемой государственным или муниципальным органом и подведомственными им организациями, оказывающими услуги, связанные с государственными (муниципальными) функциями; – взаимосвязь «входов» и «выходов» функций, отдельных административных процедур между собой для увязки в композитную услугу; – платность (бесплатность) услуги, размер платы, методика расчета стоимости услуги; – форма исполнения функции (предоставления услуги, совершения отдельных административных многофункциональном муниципальных центре функций, процедур) – электронная предоставления непосредственно в форма, государственных государственном в и или муниципальном органе и др.; – сведения об информационных системах, используемых при исполнении государственной (муниципальной) функции. – Хранение и доступ к схемам процессов исполнения государственных или муниципальных функций. – Хранение и доступ к информации по ресурсному обеспечению исполнения государственных (муниципальных) функций, а именно: – численность государственных и федеральных органов исполнительной муниципальных органов (для власти - с разбивкой по территориальным органам); 26 – финансирование исполнения функций, предоставления услуг государственными и муниципальными органами. – Хранение и доступ к информации по показателям эффективности деятельности государственных и муниципальных органов по исполнению функций: – – в разрезе по функциям и отдельным административным процедурам; – в целом по государственному или муниципальному органу. Функции НСИ. Функции НСИ осуществляют подготовку, ведение и предоставления нормативно-справочной информации о предметной области, в том числе о нормативных, учетных и статистических данных, содержит функции, которые позволяют: – Классифицировать информацию; – Кодировать информацию; – Описывать для закодированной информации необходимые атрибуты и реквизиты; – Обеспечивать сопоставимость показателей на уровнях сбора, обработки и использования; – Поддерживать информационную совместимость наименований, кодов и типов данных для группировок и массивов классификаторов; – Обеспечивать унифицированный доступ к закодированной информации и всем ее атрибутам и реквизитам; – Осуществлять поиск информации по коду, атрибутам и реквизитам; – Поддерживать изменения атрибутов и реквизитов закодированной информации во времени. Функциональность сервисных компонент по визуализации информации Функциональность сервисных компонент содержит визуальные средства для работы с информацией: списочные формы, графические представления услуг, панели управления (информационные панели руководителей), картографические представления, OLAP-представления. Пример картографического представления приведен на Рис. 2. 27 Рис. 2. Для аналитических целей функциональность сервисных компонент обеспечивающая наглядную поддерживает следующие виды и форматы: – информационная панель руководителя, информационную картину в рамках нескольких экранов в оперативном режиме; – информационная панель аналитика, обеспечивающая наглядную информационную картину с возможностью детализации информации («дриллдаун») в рамках нескольких экранов в оперативном режиме. – Сервисные компоненты должны обеспечивать наглядный и удобный для использования интерфейс, включать графические представления объектов. Пример графического представления приведен на рис. 3. 5. Проведение государственного кадастрового учета земельного участка Заявитель подал документы, необходимые для проведения ГКУ Заявление о постановке участка на кадастровый учет Межевой план Документ, подтверждающий оплату гос.пошлины 5.1. Прием документов для проведения ГКУ Специалист Росреестра Росреестр 5.2. Проверка представленных заявителями документов 5.3. Описание зем. участков в ЕГРЗ и отражение на дежурной кадастровой карте 5.4. Присвоение земельному участку кадастрового номера 5.5. Изготовление кадастрового плана земельного участка 5.6. Формирование кадастровых дел Специалист Росреестра Специалист Росреестра Специалист Росреестра Специалист Росреестра Специалист Росреестра Кадастровый паспорт Заявителю кадастровый паспорт выдан Рис. 3. Функции администрирования Функции администрирования: – ведение реестра пользователей Системы; – управление учетными записями пользователей Системы – управление правами пользователей на выполнение функций Системы; 28 – управление системными параметрами и системными справочниками. Функции информационной безопасности Функции информационной безопасности: – авторизация всех пользователей Системы; – протоколирование действий пользователей Системы; – разграничение доступа к данным; – разграничение доступа к функциям пользовательского интерфейса. Функции интеграции с внешними системами Подсистема интеграции с внешними системами включает: – Функции настройки загрузки – Функции извлечения данных – Функции выявление ошибок – Функции преобразования данных – Функции формирования расписаний загрузки – Функции загрузки Функции настройка загрузки Настройка правил и структур первичной и повторной загрузки. При этом обеспечиваются интерфейсы для работы с различными типами источников данных, таких как форматированные текстовые файлы, XML и т.д. Функции извлечения данных Данные извлекаются из внешнего источника и загружаются в промежуточный слой ETL в соответствии с правилами загрузки данных. Функции выявления ошибок Данные проходят проверку на соответствие ранее установленным правилам и структурным требованиям, для заключения о готовности к загрузке в формате ГАС ОГФУ. Должны быть предусмотрены следующие типы проверки, и затем реализованы алгоритмы дальнейших действий: – критичные ошибки (данные, не соответствующие этому критерию, не могут быть загружены в ГАС ОГФУ: например, числовое выражение, содержащее букву). 29 – некритичные ошибки (если загруженные в ГАС ОГФУ данные не являются качественными, в этом случае должно быть выдано предупреждение об ошибке: например, пустое (NULL) значение в поле имени). – качественные данные. Данные загружаются в ГАС ОГФУ без предупреждения об ошибке. По информационным объектам должны проводиться следующие проверки: – уникальные значения первичных и альтернативных ключей; – корректность форматов и представлений данных; – полное описание связей; – полнота данных; – соответствие данных аналитическим требованиям. Функции преобразования данных Данные источника фильтруются, группируются, при необходимости распределяются, выполняются вычисления промежуточных показателей для загрузки в Систему. Преобразование данных должно сводиться к следующим элементарным операциям: – вычисления (произвольные формулы); – агрегация (вычисление сумм, средних, средневзвешенных и т.д.); – расчет статистических показателей. Функции формирования расписаний загрузки Задают для настройки различные правила получения данных из источников: – по событию в источнике; – по событию в приемнике; – по жестко определенному графику; – по требованию пользователя. Функции загрузки Автоматизированный контроль процесса для очищенных и переформатированных данных, которые передаются в Систему. 30 1.5.2. Технические требования к системе 1.5.2.1 Общие требования Программное обеспечение для Систему должно удовлетворять следующим критериям: – Использовать клиент-серверную архитектуру; – Поддерживать высокие эксплуатационные параметры, такие как быстродействие, надежность и масштабируемость информационной системы на его основе; – Соответствовать принципам открытых информационных систем, позволяющих решать задачи интеграции готовых приложений с программными продуктами третьих фирм; – Иметь модульную архитектуру, основанную на унифицированных компонентах; – Обеспечивать совместимость программных продуктов в части используемых технических средств, системного программного обеспечения; – Быть русифицированным и иметь эксплуатационную документацию на русском языке; – Возможность внесения изменений в систему путем настроек без изменения программного кода. Допускается дополнительное программирование экранных форм и отчетов, а также создание дополнительных функций программного продукта; – Наличие конструктора отчетов; – Наличие возможностей «drill-down» («вызов данных») в отчетах, где это необходимо; – Наличие встроенных процедур контроля, сводящих к минимуму возможные ошибки; – Наличие современных методов анализа и OLAP технологий с учетом реализации методов моделирования. 31 – Наличие графических средств для создания бизнес-процессов и их редактирования 1.5.2.2 Требования к надежности Требования к обеспечению целостности данных – Наличие средств проверки целостности данных; – Транзакционность изменения данных; – Контроль целостности данных должен происходить в процессе выполнения операций на уровне СУБД; Требования к резервному копированию данных и восстановлению после сбоев – Наличие встроенных средств резервного копирования; – Возможность проведения резервного копирования без остановки обычной работы пользователей в системе; – Наличие средств планирования процедур резервного копирования; – Наличие средств восстановления системы после сбоев, в том числе инструментов анализа сбоев. Требования к процессу обновления системы – Возможность установки обновлений без остановки системы; – Наличие средств сохранения настроек и доработок системы при обновлении. 1.5.2.3 Требования к информационной безопасности Подсистема обеспечения целостности – Обеспечение своевременного выявления нарушений целостности критичных файлов и их оперативное восстановление. Доступ пользователей к системе – Обязательная идентификация пользователей; 32 – Подтверждение идентификации пользователя личным паролем; – Контроль прав доступа ко всем объектам системы включая модули, экранные формы, элементы меню, элементы экранных форм; – Контроль прав доступа как на уровне пользователей так и на уровне групп пользователей; – Поддержка ролевой модели прав пользователей; – Хранение и передача паролей в зашифрованном формате; – Возможность самостоятельной смены пароля пользователем; – Отсутствие возможности прочтения администратором (или другим привилегированным пользователем) пароля пользователя; – Возможность ограничения количества разрешенных открытых сессий для пользователя; – Возможность наложения ограничений на использование паролей, в частности контроль формата, длины, срока действия, количества неудачных попыток ввода; – Обеспечение защиты журналов событий от несанкционированной модификации. Аудит действий пользователей – Наличие журналов событий; – Хранение информации о действиях пользователей в журнале событий; – Хранение информации об изменении объектов системы пользователями включая информацию об объекте до и после изменения; – Возможностью настройки списка журналируемых объектов; – Возможность построения отчетов по журналу событий; – Возможность настройки механизмов анализа и оповещения о действиях пользователей, подлежащих контролю с точки зрения информационной безопасности; – Возможность настройки интервала бездействия для автоматического блокирования открытой сессии; – Возможность автоматического архивирования журналов событий. 33 1.5.2.4 Требования к эргономике и технической эстетике Требования к интерфейсу – Наличие графического многооконного режима; – Настраиваемость графических элементов интерфейса, в том числе цветового оформления, в пределах возможностей операционной системы и технических средств. – Система должна предоставлять удобный и интуитивно понятный интерфейс для пользователя, который хорошо знает свою предметную область и не является специалистом в области информационных технологий. – Система должна предоставлять возможности настройки интерфейсов под пользователя; – Система должна иметь интерфейс на русском языке. Исключения могут составлять только системные сообщения, не подлежащие русификации. – Интерфейс должен предоставлять возможность быстрой навигации по экранам и полям без помощи манипулятора мышь («горячие» клавиши, табуляция) Требования к системе помощи – В системе должна присутствовать встроенная система помощи на русском языке; – В системе помощи должен присутствовать контекстный поиск; Требования к НСИ – Система должна поддерживать возможность контекстного поиска по справочникам и классификаторам; – Система должна поддерживать контроль дублирования значений справочников; – Система должна предоставлять возможность ведения истории значений справочников. 34 1.5.2.5 Требования к программному обеспечению Требования к СУБД – Система должна быть платформонезависимой (с точки зрения СУБД) и поддерживать работу на СУБД промышленного масштаба (ORACLE, MS SQL, DB2, Sybase и др.). Требования к общему программному обеспечению Эксплуатация Системы предполагает использование следующих видов общего программного обеспечения: а) для сервера баз данных: 1) операционная система MS Widows 2003 Server St. Ed. и выше; 2) система управления базами данных: MS SQL 2005, Oracle 10g St. Ed. и выше. б) для сервера приложений: 1) операционная система MS Widows 2003 Server St. Ed. и выше; 2) Microsoft Internet Information Services. в) для рабочих станций пользователей: 1) операционная система клиентского места: MS Widows ХР Professional SP2 и выше; 2) Microsoft Internet Explorer 6.0 и выше; 3) клиентское программное обеспечение Oracle 9i и выше. 1.5.2.6 Требования к аппаратному обеспечению Общие требования – Возможность размещения компонентов системы на кластере серверов. Требования к рабочим станциям – Система должна работать без потери качества на рабочих станциях в конфигурации с 512 МБ оперативной памяти и 10 ГБ свободного места на жестком диске 35 Требования каналам связи – Нормальная работа удаленных пользователей возможна на каналах с пропускной способностью 64 кБит/с; – Система не должна отказывать в работе удаленным пользователям при снижении пропускной способности каналов связи ниже требуемых; – Поддержка протокола TCP\IP; – Требования к системе по скорости обмена данными между центральными серверами не должно быть выше 100 Мбит/с. 1.5.2.7 Требования к средствам разработки Требования к средствам разработки – Система должна предоставлять полный API для работы с объектами; – В системе должны присутствовать средства разработки экранных форм, полей, объектов и процедур на доступном, документированном языке программирования; – Система должна поставляться с исходным кодом. Требования к генератору отчетов – В системе должен присутствовать генератор отчетов, рассчитанный на использование широким кругом пользователей; – Должна быть предусмотрена возможность выгрузки отчетов в форматах Microsoft Office (XLS, DOC и т.п.), HTML, PDF; – В системе должна быть предусмотрена возможность ограничения доступа пользователей к формированию отчетов и созданию новых шаблонов отчетов; – Должна быть предусмотрена возможность формирования отчетов с графической информацией (графики, диаграммы, картограммы). 36 1.5.2.8 Требования к документации Система должна поставляться с документацией на русском языке в следующем составе: – Общее описание системы и подсистем; – Руководство пользователя системы; – Руководство администратора системы; – Рабочие инструкции, содержащие методики выполнения типовых прикладных задач, решаемых с помощью системы. – 1.5.2.9 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами Система должна предоставлять универсальные механизмы интеграции. 37
