Гарантийные обязательства Исполнителя по выполненным работам должны соответствовать требованиям, указанным в настоящей Части.
РАЗДЕЛ II.2. « ТРЕБОВАНИЯ К РАБОТАМ»
1. ОБЩИЕ СВЕДЕНИЯ
1.1. Полное наименование прикладного программного обеспечения и ее условное обозначение
Автоматизированная комплексная система исполнения сметы органами казначейства на платформе. Net Framework – АКСИОК. Net (далее – Система).
1.2. Сокращения и обозначения
Аббревиатура/ сокращение | Расшифровка |
АИФД | Администратор источников финансирования дефицита федерального бюджета |
АРМ | Автоматизированное рабочее место |
БА | Бюджетные ассигнования |
БД | База данных |
БН | Бюджетные назначения |
БП | Бюджетополучатель |
ВКР | Восстановление кассового расхода |
ВС | Вышестоящая организация |
ВТС | Ведомственная транспортная сеть |
ГРБС | Главный распорядитель бюджетных средств |
ИБ | Информационная безопасность |
ИПБС | Иной получатель бюджетных средств |
ИФД ФБ | Источники финансирования дефицита федерального бюджета |
КБК | Код бюджетной классификации, является группировкой доходов, расходов и источников финансирования дефицитов бюджетов бюджетной системы Российской Федерации, используемой для составления и исполнения бюджетов, составления бюджетной отчетности |
КБП | Код бюджетополучателя по реестру получателей бюджетных средств |
КЗ | Комплекс задач |
КП | Клиентское приложение |
КР | Кассовый расход |
КСА | Комплекс средств автоматизации |
КТС | Комплекс технических средств |
ЛБО | Лимиты бюджетных обязательств |
ЛВС | Локальная вычислительная сеть |
ЛС | Лицевой счет |
МФ РФ | Министерство финансов Российской Федерации |
НО | Начальник отдела |
НС | Нижестоящая организация |
НСД | Несанкционированный доступ |
НСИ | Нормативно-справочная информация |
ОБА | Объемы бюджетных ассигнований |
ОО | Операционный отдел |
ОрФК | Органы Федерального казначейства, включая центральный аппарат Федерального казначейства, управления Федерального казначейства по субъектам Российской Федерации, отделения управлений Федерального казначейства по субъектам Российской Федерации |
ОС | Операционная система |
ОУ ФК | Операционное управление Федерального казначейства (структурное подразделение центрального аппарата Федерального казначейства) |
ОФ | Объемы финансирования расходов |
ОФК | Отделение Управления Федерального казначейства по субъекту Российской Федерации |
ПБС | Получатель бюджетных средств |
ПИБ | Подсистема информационной безопасности |
ПИВ | Подсистема информационного взаимодействия |
ПО | Программное обеспечение |
ППО | Прикладное программное обеспечение |
ПНСИ | Подсистема ведения и использования классификаторов, кодификаторов, словарей, справочников и реестров |
ПТС | Программно-технические средства |
РБС | Распорядитель бюджетных средств |
РПБС | Реестр получателей бюджетных средств |
Рук | Руководитель, курирующий заместитель руководителя |
РФ | Российская Федерация |
СП | Сервер приложений |
Стенд оператора | Набор программно-технических средств, необходимых для отладки ППО (с характеристиками, согласно пунктам 4.1.9 и 4.1.10 настоящего раздела) |
СУБД | Система управления базами данных |
ТАИФД | Территориальный администратор источников финансирования дефицита федерального бюджета |
ТЗ | Техническое задание |
ТОФК | Территориальный орган Федерального казначейства |
УФК | Управление Федерального казначейства по субъекту Российской Федерации |
ФК | Федеральное казначейство |
ФУ ФК | Финансовое управление Федерального казначейства (структурное подразделение центрального аппарата Федерального казначейства) |
ЦА ФК | Центральный аппарат Федерального казначейства |
ЭВТ | Электронно-вычислительная техника |
ЭД | Электронный документ Системы, аналог бумажного документа в системе документооборота организации, имеющий строго оговоренные функции (в зависимости от класса документа), несущий только определенный набор информации (поля) и обладающий жестко установленным жизненным циклом (система статусов или статусы документа) |
ЭОД | Электронный образ документа, аналог бумажного документа, размещенный в файле утвержденного формата |
1.3. Границы применимости документа
ТЗ определяет требования к Системе и является первым и основным документом в комплекте документации Системы. Все остальные документы, разработанные в ходе модернизации Системы, должны быть согласованы с данным документом.
Документ предназначен для:
· Разработчиков ППО ОрФК.
· Заказчика, в качестве документа, в котором учтены все требования для разработки ППО ОрФК.
1.4. Порядок контроля и приемки Системы
Работы по модернизации Системы должны осуществляться в сроки, указанные в Разделе II.1. «Заказ на работы» Части II. «Технические требования». Сдача-приемка выполненных работ по модернизации подсистем Системы осуществляется по актам, подписанным ФК (далее также – Заказчик) и исполнителем по государственному контракту, заключенному по результатам проведения открытого конкурса № ФК2008/10/ОК-19 «Выполнение работ по модернизации подсистем комплекса «Автоматизированная комплексная система исполнения сметы органами казначейства» (АКСИОК) для функционирования в технологии единого трехуровневого приложения с сохранением имеющегося функционала, с конвертацией остатков и иных возможных к переносу данных» (далее – Исполнитель и Контракт). Порядок сдачи-приемки определяется Контрактом.
2. НАЗНАЧЕНИЕ И ЦЕЛИ МОДЕРНИЗАЦИИ СИСТЕМЫ
2.1. Назначение Системы
Назначением Системы является комплексная автоматизация управления бюджетной и административно-хозяйственной деятельностью главного распорядителя, распорядителя и получателя бюджетных средств на основе единого правового, методологического и информационного пространства в структуре Федерального казначейства.
2.2. Объекты автоматизации
Объектом автоматизации является внутренняя деятельность (в рамках бюджетного процесса, определенная действующими нормативными правовыми актами в бюджетной сфере) ЦАФК, УФК и ОФК как ГРБС, РБС и ПБС соответственно.
2.3. Объекты внедрения
Объектами внедрения Системы являются:
· на этапе пилотного внедрения: выбранные для пилотного внедрения ОФК, УФК и ЦА ФК;
· на этапе промышленной эксплуатации: функциональные подразделения ОФК, УФК и ЦА ФК, осуществляющие деятельность ГРБС, РБС и ПБС как участников бюджетного процесса;
· для пилотного внедрения требуется: Стенд оператора – для отладки ППО, моделирования сетевой архитектуры, информационного обмена, испытания вносимых изменений и проведение приемочных испытаний Системы и изменений, вносимых в Систему.
2.4. Цели разработки Системы
В настоящий момент программный комплекс АКСИОК, предназначенный для решения задач, стоящих перед Федеральным казначейством в рамках обеспечения своей деятельности, состоит из отдельных подсистем.
Целью модернизации программного комплекса АКСИОК является объединение всех действующих задач/работ в единую Систему, разработанную на современной платформе на уровне УФК с предоставлением доступа к ней ОФК и позволяющее, в случае принятия решения о ведении централизованного бухгалтерского учета, осуществить переход на него без дополнительной доработки программного продукта.
2.5. Предлагаемое решение
Необходимо разработать Систему как наращиваемое приложение, состоящее из функциональных модулей (подсистем). Функциональные модули должны быть созданы как независимые друг от друга программные модули, способные выполнять свои функции без инсталляции на объекте внедрения других подсистем. Средства настройки Системы должны обеспечивать формирование функциональных рабочих мест за счет подключения (и/или предоставления права доступа) необходимых функций и задач, а также настроек. Настройки Системы должны осуществляться в привязке к объектам внедрения.
Каждый объект внедрения может выполнять одновременно функции ГРБС, РБС и ПБС.
3. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ЗАДАНИЮ
Разработка ТЗ осуществляется Исполнителем.
ТЗ должно соответствовать следующим требованиям:
· ТЗ должно быть разработано Исполнителем в ходе проведения Исполнителем обследования пилотных объектов по перечню, указанному в Таблице № 2 Раздела II.1. «Заказ на работы» настоящей Части;
· ТЗ должно включать в себя методику внедрения ППО. Требования к составлению и пример составления ТЗ, в части описания методики внедрения ППО, приведены в документе «Методика внедрения» (Код документа: ФК. ПРОЕКТ.15.02), размещенном в ФАП ФК и передаваемого Исполнителю по запросу на оптическом носителе (CD-Rom);
· ТЗ должно быть разработано Исполнителем с соблюдением требований соответствующих ГОСТ и передано на утверждение Заказчику. ТЗ передается на утверждение в бумажном (2 экземпляра) и в электронном виде.
· ТЗ, после утверждения, может уточняться Исполнителем и Заказчиком по мере необходимости по инициативе Заказчика. В этом случае Исполнитель обязан произвести такое уточнение в срок не более 10 (десяти) календарных дней или мотивированно отклонить такую просьбу.
4. ТРЕБОВАНИЯ К МОДЕРНИЗАЦИИ СИСТЕМЫ
4.1. Общие требования к Системе
4.1.1. Требования к решению
Предлагаемое решение должно:
· базироваться на единой БД MS SQL;
· обеспечивать реализацию функциональных модулей. Допустима реализация нескольких функциональных модулей в пределах одного программного модуля, или реализация одного функционального модуля несколькими программными модулями;
· обеспечивать взаимодействие с существующим и планирующимся к внедрению в ФК ППО на период гг.;
· обеспечивать возможность поэтапного наращивания как производительности, так и функционального состава;
· иметь открытые интерфейсы для развития и интеграции;
· иметь возможность дублировать все задачи по импорту документов в Систему задачами, обеспечивающими ввод данных документов вручную;
· обеспечивать увеличение количества одновременно работающих пользователей.
Предлагаемое решение должно обладать следующими свойствами:
· возможностью структурной и параметрической настройки функций и задач;
· возможностью изменений процессов, связанных с процедурными изменениями и/или с изменениями в законодательстве, путем настроек без изменения программного кода. Допускается дополнительное программирование экранных форм и отчетов, а также создание дополнительных модулей программного продукта (база настроек, привязанная ко времени);
· совместимость программных продуктов в части используемых технических средств, системного программного обеспечения в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену.
4.1.2. Требования к структуре и функционированию
Система должна быть основана на уже реализованных и прошедших апробацию на неоднократных установках надежных программных средствах. Система должна иметь модульную открытую архитектуру, обеспечивающую достаточные возможности для масштабирования, повышения производительности и расширения функциональных возможностей.
4.1.3. Требования к архитектуре
В Системе должна использоваться трехуровневая клиент-серверная архитектура, подразумевающая наличие, помимо сервера баз данных, выделенного сервера приложений, инкапсулирующего в себе часть бизнес-логики Системы.
Данная архитектура должна обеспечивать оптимизацию нагрузки на оборудование, гибкую масштабируемость и информационную безопасность Системы.
· Уровень базы данных (СУБД) – должен обеспечивать реализацию необходимой архитектуры данных (хранение всех данных, предназначенных для функционирования ППО).
· Уровень приложения (Сервер Приложений СП) – должен обеспечивать связанную с бизнес-логикой обработку информации и взаимосвязь между уровнем клиента и уровнем базы данных.
· Уровень клиента (Клиентское Приложение КП) – должен обеспечивать доступ пользователя к пользовательскому интерфейсу, для отображения необходимой информации и ввода данных.
4.1.3.1. Требования к взаимодействию сервера БД и сервера приложений
Взаимодействие СУБД и СП должно осуществляться по протоколам, определенным в СУБД, и настраиваться передачей корректной строки подключения (при инициализации) в СП. Все дальнейшие подключения клиентов к БД должны происходить от имени одного пользователя, полученного СП в строке подключения.
4.1.3.2. Требования к серверу приложений
Для обеспечения работы СП с момента старта ОС до ее завершения, а также для управления СП посредством стандартной оснастки «Управление сервисом» и для записи истории работы СП в системный журнал событий, точкой входа для СП должен являться системный сервис. Ядро программного комплекса (основа СП), должно предоставлять разработчикам функциональных модулей:
· администрирование типов, экземпляров и методов бизнес-объектов;
· поддержку (при помощи механизма транзакций и блокировок) целостности данных в многопользовательской среде.
4.1.3.3. Требования к клиентскому приложению
КП должно обеспечивать подключение к СП.
Взаимодействие КП с СП должно осуществляться по протоколу TCP\IP, по порту, определенному в файле конфигурации СП, передача данных должна происходить в бинарном формате.
КП должны реализовывать два типа взаимодействия с СП:
· полнофункциональное КП, используемое в условиях связи с СП по каналу ВТС с пропускной способностью (выделенной для КП) не менее 1Mbit/sec или в одной ЛВС;
· терминальное КП, используемое в условиях связи с СП по каналу ВТС с пропускной способностью (выделенной для КП) не менее 8Kbit/sec. В частности, терминальное КП должно обеспечивать устойчивое функционирование при использовании существующих спутниковых каналов.
4.1.3.3.1. Требования к полнофункциональному клиентскому приложению
Полнофункциональное КП должно обеспечивать:
· динамическое получение необходимых библиотек и ресурсных файлов от СП;
· отображение результатов запросов информации, справочных, аналитических и статистических данных в интерфейсе пользователя;
· ввод, изменение и удаление данных в условиях предоставления справочной и аналитической информации в формах ввода интерфейса пользователя;
· доступность средств (регламентированных правами доступа) для совершения полного цикла документооборота;
· хранение персональных настроек пользователя.
4.1.3.3.2. Требования к терминальному клиентскому приложению
Терминальное клиентское приложение должно обеспечивать:
· ввод данных в Систему в формах ввода интерфейса пользователя, с использованием необходимых справочных данных.
4.1.4. Требования к интерфейсу пользователя
Интерфейс должен обеспечивать:
· преемственность от интерфейса программного комплекса АКСИОК;
· общение с пользователем на русском языке, включая меню и сообщения Системы;
· единообразный, простой, гибкий и дружественный интерфейс пользователя по всем программным модулям;
· персональное пользовательское меню (в соответствии с набором функций, доступных пользователю);
· персональные настройки пользователя связанные с бизнес логикой приложения;
· персональные настройки пользователя связанные с отображением элементов пользовательского интерфейса;
· возможность работы персонала без дополнительного обучения.
4.1.5. Требования к переносу информации
Имеющаяся в базах данных программного комплекса АКСИОК информация должна быть, по возможности, наиболее полно перенесена в консолидированную базу данных Системы. При невозможности осуществить перенос учетных и расчетных документов, данные в Систему переносятся путем расчета и ввода остатков (оборотов). Объем и номенклатура информации, подлежащей переносу, должен определяться ТЗ и позволить УФК провести перенос данных собственными силами в течение года. Исполнитель в рамках опытной эксплуатации осушествляет поддержку переноса данных в пилотных УФК.
4.1.6. Требования к модернизации подсистем и модулей
4.1.6.1. Требования к технологическим модулям
4.1.6.1.1. Ядро Системы
Ядро Системы должно предоставлять разработчикам функциональных модулей подсистем унифицированные методы работы с различными типами БД, возможность администрирования типов, экземпляров и методов бизнес – объектов, поддержку целостности данных, механизм транзакций и блокировок.
4.1.6.1.2. Рабочий стол пользователя
Рабочий стол пользователя (графическая пользовательская среда) должен обеспечивать доступ к документам, справочникам, операциям и отчетам, к их экземплярам и методам, для всех задач (подсистем), разрешенных администратором Системы.
Личные настройки Рабочего стола (профиль пользователя) должны сохраняться на сервере приложений, при этом, пользователь, входя в Систему с разных АРМ должен получать одинаково настроенную среду.
4.1.7. Общие требования к функциям
Функции, реализуемые в ППО, для целей настоящего ТЗ должны быть объединены в группы по сходным функциям:
· учетные функции: должны обеспечивать ввод, корректировку и обработку документов;
· функции хранения информации;
· контрольные функции: должны обеспечивать прямой и перекрестный контроль при вводе, корректировке, обработке и изменении состояния документов;
· отчетные функции: должны обеспечить выдачу отчетной информации.
4.1.7.1. Требования к учетным функциям
Учетные функции должны обеспечивать:
· учет всех поступающих и исходящих документов и пакетов документов;
· однократный ввод данных и многократное их использование;
· ввод обязательных для заполнения атрибутов документов, проверку этих атрибутов на соответствие форматам ввода. Ввод необязательных атрибутов документов должен производиться по усмотрению пользователя;
· возможность исправления допущенных персоналом ошибок;
· обработку поступающих документов и формирование наборов данных, подлежащих регистрации в ППО в ручном и автоматизированном режиме;
· одновременную поддержку планирования, учета исполнения и отчетов по нескольким бюджетам (планирование бюджета будущего года, учет исполнения бюджета текущего года, формирование отчетов об исполнении бюджета прошлого года);
· обеспечение ведения учета операций в разных валютах;
· формирование регистров аналитического учета.
4.1.7.2. Требования к функциям хранения информации
Функции хранения информации должны обеспечивать:
· организацию и ведение базы данных, в том числе хранение, обновление и восстановление данных;
· одновременное хранение учетной и прогнозной информации по нескольким бюджетам (планируемого, текущего, отчетного).
4.1.7.3. Требования к контрольным функциям
Контрольные функции должны обеспечивать:
· логический контроль непротиворечивости данных на этапах ввода, загрузки, корректировки, обработки документов;
· поддержание целостности учетной информации;
· проверку состояний (статуса) для каждого электронного документа, правил и условий изменения состояния, разрешенных действий;
· соответствие значений полей документов внутрисистемным справочникам и классификаторам.
4.1.7.4. Требования к отчетным функциям
Отчетные функции должны обеспечивать:
· формирование регламентированной ведомственными и нормативными актами оперативной отчетности в режиме реального времени;
· формирование и выполнение регламентированных сложных оперативных запросов (по двум и более атрибутам) на поиск информации по экранным формам;
· изменение содержания отчета в зависимости от набора параметров;
· регламентированную и определяемую пользователем сортировку данных;
· формирование отчетов как нарастающим итогом с начала финансового года, так и за требуемый период времени;
· регламентированное управление формой и содержанием отчетов;
· выполнение отчетов в режиме реального времени и в режиме фонового исполнения;
· задание масштаба валюты отчета (тысячи, рубли, копейки);
· стандартный математический механизм округления для чисел с дробной частью.
4.1.8. Требования к платформе
Предлагаемое решение должно базироваться на кроссплатформенной технологии , обеспечивающей:
· повторное использование существующего кода;
· перенос локальных приложений в WEB - среду или совмещение нескольких изолированных систем;
· использование различных языков программирования;
· возможность работы приложений на разном аппаратном обеспечении;
· интеграцию со всеми продуктами Windows, MS Office и с XML-совместимыми приложениями;
· контроль версий (version control), для избегания конфликтов разных версий одного и того же приложения;
· функционирование в не зависимости от архитектуры процессора аппаратных средств.
4.1.9. Требования к аппаратному обеспечению
ППО должно функционировать и обеспечивать требования к временным характеристикам на аппаратном обеспечении следующей минимальной конфигурации, либо на конфигурации аппаратного обеспечения, сопоставимого по производительности:
· Сервер баз данных и сервер приложений:
Intel Pentium 4 HT CPU 2,80 ГГц, 2 Гб Озу, HHD - 220 Гб.
· Кластер серверов баз данных:
o Один сервер на каждые 100 пользователей.
· Кластер серверов приложений:
o Один сервер на каждые 200 пользователей.
· Рабочая станция: Pentium IV 2,5 ГГц, 1 Гб ОЗУ, HDD – 40 Гб.
· Локальная сеть пропускная способность от 10 Mbit/s.
· Канал ВТС (характеристики указаны в пункте 4.1.12 настоящего Раздела).
4.1.10. Требования к информационной и программной совместимости
4.1.10.1. Требования к совместимости СУБД
· Сервер на платформе ОС MS Microsoft (Windows Server 2003 SP2 и выше).
· MS SQL Server 2000 SP4 и выше.
4.1.10.2. Требования к совместимости СП
· Сервер на платформе ОС MS Microsoft (Windows Server 2003 SP2 и выше).
4.1.10.3. Требования к совместимости КП
· Рабочая станция ОС MS Windows XP SP2 и выше.
· MS Office 2003 и выше.
· Все дополнительные компоненты, необходимые для функционирования Системы, должны поставляться Исполнителем.
4.1.11. Требования к временным характеристикам
Предлагаемое решение должно обеспечивать следующие временные характеристики на операции:
· среднее время реакции (от момента ввода запроса до появления первой реакции) – не более 3 миллисекунд;
· среднее время реакции (от момента ввода запроса до появления первой реакции) при использовании существующего спутникового канала связи – не более 15 миллисекунд;
· среднее время получения справки с оперативной информацией – не более 15 секунд;
· среднее время решения расчетной или аналитической задачи на сервере – не более 30 минут;
· время формирования резервной копии или восстановления с резервной копии базы данных – не более 90 минут.
4.1.12. Требования к физической схеме прикладной архитектуры системы
Предлагаемое решение должно обеспечивать возможность функционирования ППО в следующих условиях:
· При расположении сервера БД и сервера приложений в одной ЛВС с полнофункциональным клиентским приложением.
· При расположении сервера БД и сервера приложений на удалённой территории в УФК с использованием канала ВТС не менее 256 Kbit/s при использовании пользовательского трафика типа Best Effort (прочий трафик) для связи с полнофункциональным клиентским приложением в ОФК.
· При расположении сервера БД и сервера приложений на удалённой территории в УФК с использованием канала ВТС (включая спутниковый) не менее 8 Кbit/s при использовании пользовательского трафика типа Best Effort (прочий трафик) для связи с терминальным клиентским приложением в ОФК при использовании технологического режима централизованной бухгалтерии.
4.1.13. Требования к масштабируемости
Категория ОрФК | Количество конечных пользователей ППО | Состав технических средств |
Крупные ОрФК | более 100 | · кластер серверов СУБД; · кластер серверов приложения; · ЛВС; · рабочие станции пользователей |
Средние ОрФК | 30-100 | · выделенный сервер СУБД; · выделенный сервер приложения; · ЛВС; · рабочие станции пользователей; |
Малые ОрФК | 1-30 | · сервер СУБД и приложения; · ЛВС; · рабочие станции пользователей |
ОФК в технологическом режиме централизованной бухгалтерии | 1-100 | · Канал ВТС; · рабочие станции пользователей |
4.1.14. Требования к обеспечению информационной безопасности
4.1.14.1. Общие требования к безопасности
Система должна соответствовать требованиям руководящих документов Гостехкомиссии (ФСТЭК России) по защите информации от несанкционированного доступа в отношении обрабатываемых в системе персональных данных.
4.1.14.2. Требования к обеспечению безопасности доступа
Система должна обеспечивать:
· индивидуальную аутентификацию и авторизацию пользователей при попытках доступа к ресурсам ППО;
· формирование реакции (регистрация в протоколе, информирование администратора системы) на попытки НСД;
· регистрацию и протоколирование обращений (успешных и неуспешных) к ресурсам ППО;
· централизованный учет и контроль профилей пользователей ППО;
· ведение профилей пользователей, включая данные пользователя (идентификатор, пароль) и группы полномочий пользователя;
· ограничение доступа к ведению профилей пользователей;
· хранение пароля в виде, не допускающем его восстановление в исходный вид (необратимые преобразования);
· контролируемый, централизованно управляемый доступ пользователей к ресурсам ППО в соответствии с условиями разграничения доступа;
· доступ пользователей к функциям Системы в соответствии с их полномочиями;
· доступ пользователей к бизнес - объектам Системы, их методам и экземплярам в соответствии с их полномочиями.
4.1.15. Требования к надежности
4.1.15.1. Общие требования к надежности
· Программные модули Системы и данные не должны быть повреждены в результате отключения питания (при наличии источников бесперебойного питания аппаратных средств).
· Работоспособность Системы должна быть восстановлена без потери целостности данных при возобновлении питания.
· Система должна позволять отслеживать аварийные (нештатные) ситуации путем вывода предупреждающих сообщений или сообщений об ошибке.
4.1.15.2. Общие требования к отказоустойчивости
Архитектура системы должна обеспечивать возможность применения отказоустойчивых многомашинных комплексов (кластеров), с разнесением серверов в пределах одного здания до нескольких десятков метров. В случае отказа основного сервера (серверов) комплекса работоспособность Системы должна быть восстановлена не более чем через 1 час.
4.1.15.3. Резервное копирование и восстановление
Система должна обеспечивать:
· средства для автоматического запуска плановых процедур резервного копирования;
· средства для запуска процедур резервного копирования вручную по мере необходимости;
· полное и корректное восстановление Системы и данных.
4.1.16. Требования к маркировке и упаковке
· Разрабатываемое программное обеспечение должно быть промаркировано согласно требованиям действующего законодательства, а так же требованиям Государственного заказчика.
· Каждая версия системы и документация к ней должны иметь регистрационный номер и шифр, присваиваемый исполнителем.
· Упаковка должна обеспечивать сохранность носителей от повреждений. На упаковке должно быть указано: наименование системы, Заказчик, исполнитель, дата создания, регистрационный номер и шифр, присвоенные исполнителем.
4.1.17. Требования к транспортированию и хранению
· Требования к транспортировке не предъявляются.
Контрольные экземпляры дистрибутива и обновлений системы должны передаваться Заказчику в порядке, определенном Положением о Фонде алгоритмов и программ Федерального казначейства, утвержденным приказом Федерального казначейства от 01.01.01 г. № 000.
5. ТРЕБОВАНИЯ К ВНЕДРЕНИЮ СИСТЕМЫ ДЛЯ ПРОВЕДЕНИЯ ОПЫТНОЙ ЭКСПЛУАТАЦИИ
Для проведения опытной эксплуатации, Исполнитель должен обеспечить внедрение модернизированной Системы в пилотных объектах по перечню указанному в Таблице № 2 «Места выполнения Работ» Раздела II.1. «Заказ на работы» настоящей Части. Внедрение должно проводиться согласно описанной в ТЗ методике внедрения ППО.
Внедрение должно включать в себя:
· установку модернизированного ППО АКСИОК на техническом обеспечении ФК, соответствующем п. 4.1.10, 4.1.11 настоящего Раздела;
· обучение пользователей и администраторов в порядке, определенном ТЗ;
· опытную эксплуатацию модернизированного ППО АКСИОК (не менее 15 (пятнадцати) календарных дней);
· конвертацию данных;
· подписание Заказчиком Протокола проведения опытной эксплуатации модернизированного ППО АКСИОК.
По результатам проведения опытной эксплуатации и при наличии соответствующих требований Заказчика, ТЗ должно быть уточнено Исполнителем в соответствии с настоящими техническими требованиями, в том числе с осуществлением необходимых доработок ППО. Исполнитель также может выступить инициатором уточнения ТЗ.
Протокол проведения опытной эксплуатации ППО должен отражать факт полной замены существующего функционала и сдачу отчетности за 9 месяцев 2009 года с января по сентябрь включительно, по управлению Федерального казначейства по Рязанской области в режиме распределенных БД, по управлению Федерального казначейства по Архангельская обл." href="/text/category/arhangelmzskaya_obl_/" rel="bookmark">Архангельской области в режиме централизованной БД, используя функционал модернизированного ППО.
6. ГАРАНТИЙНЫЕ ОБЯЗАТЕЛЬСТВА
В рамках действия Контракта Исполнитель своими силами и средствами проводит исправления обнаруженных в процессе эксплуатации ошибок в сданном в промышленную эксплуатацию ППО.
РАЗДЕЛ II.3. «ОПИСАНИЕ КОНТРОЛЬНОГО ПРИМЕРА ДЛЯ МОДЕРНИЗАЦИИ ППО»
Настоящий контрольный пример используется только в целях оценки заявок на участие в открытом конкурсе № ФК2008/10/ОК-19 «Выполнение работ по модернизации подсистем комплекса «Автоматизированная комплексная система исполнения сметы органами казначейства» (АКСИОК) для функционирования в технологии единого трехуровнего приложения с сохранением имеющегося функционала, с конвертацией остатков и иных возможных к переносу данных» и не является техническими требованиями к доработке прикладного программного обеспечения.
1.1 Термины и обозначения
Термин | Определение |
АС | Автоматизированная система |
БД | База данных |
БК | Бюджетная классификация |
ГРБС | Главный распорядитель бюджетных средств |
Заказчик | Федеральное казначейство |
КБК | Код бюджетной классификации, является группировкой доходов, расходов и источников финансирования дефицитов бюджетов бюджетной системы Российской Федерации, используемой для составления и исполнения бюджетов, составления бюджетной отчетности |
Комиссия | Конкурсная комиссия по открытому конкурсу № ФК2008/10/ОК-19 «Выполнение работ по модернизации подсистем комплекса «Автоматизированная комплексная система исполнения сметы органами казначейства» (АКСИОК) для функционирования в технологии единого трехуровнего приложения с сохранением имеющегося функционала, с конвертацией остатков и иных возможных к переносу данных» |
ПБС | Получатель бюджетных средств |
ППО | Прикладное программное обеспечение |
РБС | Распорядитель бюджетных средств |
РПБС | Код распорядителя/получателя бюджетных средств |
ТОФК | Территориальный орган Федерального казначейства |
УФК | Управление Федерального казначейства по субъекту Российской Федерации |
ФБ | Федеральный бюджет |
ФИО | Фамилия, имя, отчество |
ФК | Федеральное казначейство |
ЦА ФК | Центральный аппарат Федерального казначейства |
2.1. Контрольный пример для модернизации ППО
2.1.1 Краткое описание контрольного примера
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 |
