close

Вход

Забыли?

вход по аккаунту

?

ПРОЕКТ ДОГОВОРА

код для вставкиСкачать
Приложение 4
к конкурсной документации
ПРОЕКТ ДОГОВОРА
1
Договор № ____________________
на выполнение работ
г. Москва
«____» ______________ 201_ г.
Государственная корпорация «Банк развития и внешнеэкономической деятельности
(Внешэкономбанк)», именуемая в дальнейшем «Заказчик», в лице ______________,
действующего на основании ______________, с одной стороны, и ______________,
именуемое в дальнейшем «Исполнитель», в лице ______________, действующего на
основании ______________, с другой стороны, вместе именуемые «Стороны», заключили
настоящий Договор (далее - «Договор») о нижеследующем:
1.
Сокращения и определения, используемые в Договоре
АСУЗД, Система
–
Представитель
Исполнителя
–
Представитель
Заказчика
–
ППО
СТП
ФТР
ПСИ
ОПЭ
ПЭ
–
–
–
–
–
–
Автоматизированная
система
управления
закупочной
деятельностью Государственной корпорации «Банк развития и
внешнеэкономической деятельности (Внешэкономбанк)».
уполномоченное лицо Исполнителя, указанное в пункте 14.7
Договора, через которое поддерживается связь между Сторонами и
которое несет ответственность за координацию всей деятельности
Исполнителя по Договору.
уполномоченное лицо Заказчика, указанное в пункте 14.8 Договора,
через которое поддерживается связь между Сторонами и которое
несет ответственность за координацию всей деятельности Заказчика
по Договору.
прикладное программное обеспечение АСУЗД.
документ «Спецификация требований пользователя».
документ «Функционально-технические решения».
приемо-сдаточные испытания.
опытно-промышленная эксплуатация.
промышленная эксплуатация.
2.
Предмет Договора
2.1. Исполнитель по заданию Заказчика обязуется выполнить работы по созданию АСУЗД и
ее вводу в ПЭ (далее – Работы) в порядке и на условиях, предусмотренных настоящим
Договором, Техническим заданием (Приложение 1) и Календарным планом Работ и их
стоимостью (Приложение 2), являющимися неотъемлемой частью Договора. Заказчик
обязуется принять и оплатить Работы.
3.
Стоимость Договора
3.1. Общая стоимость выполнения Работ по Договору определена в Приложении 2 и
составляет ______________ (______________) рублей __ копеек, в том числе НДС (18%) –
______________ (______________) рублей __ копеек.
3.2. Стоимость Работ включает в себя все расходы по обязательным платежам, в том числе
расходы на уплату налогов, сборов и других обязательных платежей, которые Исполнитель
должен выплатить в связи с выполнением обязательств по Договору в соответствии с
законодательством Российской Федерации.
4.
4.1. Исполнитель обязуется:
Права и обязанности Сторон
2
4.1.1. выполнить Работы с надлежащим качеством, в полном объеме в срок, указанный в
Календарном плане (Приложение 2) и передать Заказчику результаты Работ, свободные от
прав третьих лиц;
4.1.2. согласовать
с
Заказчиком
необходимость
использования
объектов
интеллектуальной
собственности.
Согласованные
объекты
интеллектуальной
собственности предоставляются Заказчиком;
4.1.3. незамедлительно уведомить Заказчика в письменном виде о любых известных
Исполнителю событиях или условиях, которые могут отрицательно сказаться, повлиять
или привести к задержкам сроков выполнения Работ, а также предоставить подробное
объяснение причин и мер, предлагаемых для исправления ситуации;
4.1.4. Исполнитель обязан провести Работы лично, привлечение третьих лиц допускается
только по письменному согласованию с Заказчиком, при этом Исполнитель будет нести
ответственность за действия привлеченных лиц, как за свои собственные;
4.2. Исполнитель имеет право:
4.2.1. Получать от Заказчика имеющиеся у него документы и информацию, необходимые
для надлежащего исполнения своих обязательств по Договору, в случае наличия
соответствующих документов и информации у Заказчика.
4.3. Заказчик обязуется:
4.3.1. принять и оплатить выполненные Исполнителем Работы в соответствии с
условиями Договора;
4.3.2. своевременно обеспечивать Исполнителя информацией и документами,
необходимыми для выполнения Работ, в случае наличия у него соответствующих
документов и информации;
4.3.3. предоставить доступ работникам Исполнителя на свою территорию для
исполнения обязательств по Договору. Допуск представителей Исполнителя на
территорию Заказчика осуществляется в соответствии с режимными требованиями,
установленными на предприятии Заказчика.
4.4. Заказчик имеет право:
4.4.1. в любое время проверять ход и качество Работ, выполняемых Исполнителем, не
вмешиваясь в его хозяйственную деятельность.
5.
Порядок и сроки выполнения Работ
5.1. Работы выполняются в соответствии с Техническим заданием (Приложение 1). Работы
выполняются поэтапно в сроки указанные в Календарном плане работ (Приложение 2).
5.2. Разрабатываемая Исполнителем по Договору документация (Приложение 2),
предоставляется Заказчику в одном печатном экземпляре и на материальных носителях
(CD/DVD диски) в виде файлов формата Microsoft Office.
5.3. СТП и ФТР разрабатываются в соответствии с требованиями к разработке СТП
(Приложение 3) и требованиями к разработке ФТР (Приложение 4), являющимися
неотъемлемой частью Договора, и предоставляются Заказчику в одном печатном экземпляре
и на материальных носителях (CD/DVD диски) в виде файлов формата MS-Word.
5.4. ППО разрабатывается в соответствии с согласованными СТП и ФТР.
3
5.5. ППО, разработанное Исполнителем по Договору, включая электронные версии
эксплуатационной документации, предоставляется Заказчику на материальных носителях
(CD/DVD диски). Кроме того, эксплуатационная документация предоставляется Заказчику в
одном печатном экземпляре.
5.6. ППО, разработанное на условиях Договора, устанавливается на технических средствах
Заказчика.
5.7. ПСИ и ОПЭ АСУЗД, проводятся в соответствии с соответствующими программамиметодиками испытаний, разработанными на условиях Договора.
5.8. Инструктаж сотрудников Заказчика по работе с АСУЗД осуществляется на территории
Заказчика.
5.9. Гарантия на Работы, выполненные по Договору – 180 (сто восемьдесят) календарных
дней с даты подписания Акта сдачи-приемки выполненных Работ. В гарантийный период
Исполнитель обеспечит Заказчику в режиме «горячей линии» консультации по вопросам,
связанным с эксплуатацией АСУЗД и устранение выявленных в ходе гарантийного периода
замечаний к АСУЗД. Консультации и устранение выявленных в ходе гарантийного периода
замечаний к АСУЗД осуществляются без дополнительной оплаты со стороны Заказчика.
6.
Порядок сдачи-приёмки Работ по Договору
6.1. По согласованию с Заказчиком допускается досрочное выполнение Работ и сдача их
Заказчику.
6.2. По завершению 1, 2 и 3 этапов Работ Исполнитель предоставляет Заказчику Протокол
выполнения Работ по этапу в двух подписанных со своей Стороны экземплярах. Заказчик в
течение 10 (десяти) рабочих дней со дня получения Протокола выполнения Работ по этапу
подписывает его или в тот же срок направляет Исполнителю мотивированный письменный
отказ.
6.3. В случае мотивированного отказа Заказчика (пункт 6.2 Договора), Сторонами
составляется двухсторонний акт с перечнем замечаний и сроков их устранения. Все
согласованные Сторонами замечания устраняются Исполнителем без дополнительной
оплаты со стороны Заказчика. После устранения Исполнителем замечаний проводится
повторное оформление Протокола выполнения Работ по этапу.
6.4. По выполнению полного объема Работ Исполнитель предоставляет Заказчику Акт
сдачи-приемки Работ в двух подписанных со своей Стороны экземплярах. Заказчик в течение
10 (десяти) рабочих дней со дня получения Акта сдачи-приёмки Работ подписывает его или в
тот же срок направляет Исполнителю мотивированный письменный отказ от приёмки Работ.
6.5. В случае мотивированного отказа Заказчика от приемки выполненных Работ,
Сторонами составляется двухсторонний акт с перечнем замечаний и сроков их устранения.
Все согласованные Сторонами замечания устраняются Исполнителем без дополнительной
оплаты со стороны Заказчика. После устранения Исполнителем замечаний проводится
повторное оформление Акта, указанного в пункте 6.4 Договора.
6.6. Датой приемки Работ, выполненных по Договору, считается дата подписания
Сторонами Акта сдачи-приёмки Работ (пункт 6.4 Договора).
7.
Порядок расчетов
7.1. Платежи по данному Договору осуществляются на основании счетов, в течение 10
(десяти) рабочих дней с даты получения правомерно выставленного Исполнителем счета
Заказчиком. В счете должны быть указаны номер и дата Договора и предназначение платежа.
4
7.2. Датой платежа считается дата списания суммы платежа с корреспондентского счета
Заказчика.
7.3. Оплата Работ, выполняемых по Договору, осуществляется следующим образом:
7.3.1. Первый платёж за Работы осуществляется в виде авансового платежа за этап 1 Работ
(Приложение 2) в размере 40% (сорок процентов) от стоимости Работ по этапу 1 Работ
(Приложение 2), что составляет ____________ (____________) рублей __ копеек, в том
числе НДС (18%) в размере____________ (____________) рублей __ копеек. Счет на
платёж предоставляется Исполнителем Заказчику в течение 5 (пяти) рабочих дней с
даты подписания Сторонами Договора.
7.3.2. Второй платёж за Работы осуществляется в виде авансового платежа за этап 2 Работ
(Приложение 2) в размере 40% (сорок процентов) от стоимости Работ по этапу 2 Работ
(Приложение 2), что составляет ____________ (____________) рублей __ копеек, в том
числе НДС (18%) в размере____________ (____________) рублей __ копеек. Счет на
платёж предоставляется Исполнителем Заказчику в течение 5 (пяти) рабочих дней с
даты подписания Сторонами Протокола выполнения Работ по этапу 1 (пункт 6.2
Договора).
7.3.3. Третий платёж за Работы осуществляется в виде авансового платежа за этап 3 Работ
(Приложение 2) в размере 40% (сорок процентов) от стоимости Работ по этапу 3 Работ
(Приложение 2), что составляет ____________ (____________) рублей __ копеек, в том
числе НДС (18%) в размере____________ (____________) рублей __ копеек. Счет на
платёж предоставляется Исполнителем Заказчику в течение 5 (пяти) рабочих дней с
даты подписания Сторонами Протокола выполнения Работ по этапу 2 (пункт 6.2
Договора).
7.3.4. Четвертый платёж за Работы осуществляется в виде авансового платежа за этап 4
Работ (Приложение 2) в размере 40% (сорок процентов) от стоимости Работ по этапу 4
Работ (Приложение 2), что составляет ____________ (____________) рублей __ копеек,
в том числе НДС (18%) в размере____________ (____________) рублей __ копеек.
Счет на платёж предоставляется Исполнителем Заказчику в течение 5 (пяти) рабочих
дней с даты подписания Сторонами Протокола выполнения Работ по этапу 3 (пункт
6.2 Договора).
7.3.5. Пятый платёж осуществляется в виде окончательного платежа за выполненные
Работы в размере 60% (шестьдесят процентов) от полной стоимости Работ по
Договору (пункт 3.1 Договора), что составляет ____________ (____________) рублей
__ копеек, в том числе НДС (18%) в размере____________ (____________) рублей __
копеек. Счет на платёж предоставляется Исполнителем Заказчику в течение 5 (пяти)
рабочих дней с даты приемки Работ (пункт 6.6 Договора).
8.
Права на интеллектуальную собственность
8.1. После подписания Сторонами Акта сдачи-приемки Работ по Договору Исполнитель
становится владельцем исключительных прав на интеллектуальную собственность,
возникшую в ходе выполнения Работ по Договору, а Заказчик получает неисключительные,
бессрочные права (все права за исключением права продажи третьим лицам без согласования
с Исполнителем) на документы и ППО, разработанные по Договору.
8.2. Исполнитель гарантирует, что возместит Заказчику весь документально
подтвержденный ущерб, понесенный им в случае возникновения обоснованных претензий со
стороны третьих лиц и связанный с нарушением их прав на интеллектуальную
собственность, возникшие по вине Исполнителя.
5
9.
Ответственность Сторон
9.1. За неисполнение или ненадлежащее исполнение обязательств по Договору Стороны
несут ответственность, предусмотренную действующим законодательством Российской
Федерации.
9.2. В случае несоблюдения сроков оплаты, указанных в разделе 7 Договора, Исполнитель
вправе письменно потребовать от Заказчика выплаты пени, а Заказчик обязан в этом случае
выплатить Исполнителю пеню в размере 0,1% (одной десятой процента) от несвоевременно
оплаченной суммы за каждый день просрочки, но не более 20% (двадцати процентов) от
несвоевременно оплаченной суммы.
9.3. В случае несоблюдения Исполнителем установленных настоящим Договором сроков
выполнения Работ, Заказчик вправе письменно потребовать от Исполнителя выплаты пени, а
Исполнитель обязан в этом случае выплатить Заказчику пени в размере 0,1% (одной десятой
процента) от общей стоимости Работ по Договору (пункт 3.1 Договора) за каждый день
просрочки, но не более 20% (двадцати процентов) от стоимости Работ.
9.4. В случае взыскания пени в соответствии с пунктами 9.2, 9.3 Договора взыскивающая
Сторона направляет другой Стороне соответствующее письменное требование в течение 35
(тридцати пяти) рабочих дней с даты исполнения обязательств Стороной, нарушившей свои
обязательства по Договору. В случае, если письменное требование не будет предъявлено в
указанный срок, пеня не взыскивается.
9.5. Счет на уплату пени выставляется в рублях на сумму, рассчитанную в соответствии с
пунктами 9.2, 9.3 Договора.
9.6. Уплата пени производится в течение 15 (пятнадцати) рабочих дней с даты
предоставления соответствующего счета взыскивающей Стороной.
9.7. Уплата пени не освобождает Стороны от исполнения своих обязательств по Договору.
10.
Обстоятельства непреодолимой силы
10.1. Сторона, не исполнившая или ненадлежащим образом исполнившая свои обязательства
по Договору, несёт ответственность, если не докажет, что надлежащее исполнение
обязательств оказалось невозможным вследствие непреодолимой силы, т.е. чрезвычайных и
непредотвратимых при данных условиях обстоятельствах.
10.2. Если любое из обстоятельств непреодолимой силы непосредственно влияет на
своевременное исполнение обязательств по Договору, срок их исполнения продлевается на
период действия обстоятельств непреодолимой силы.
10.3. В случае возникновения обстоятельств непреодолимой силы Сторона, лишенная
возможности исполнить свои обязательства, в течение 7 (семи) рабочих дней после
наступления соответствующих обстоятельств в письменном виде уведомляет другую
Сторону о наступлении, предполагаемом сроке действия и прекращении этих обстоятельств.
Несвоевременное уведомление о возникновении обстоятельств непреодолимой силы лишает
соответствующую Сторону права ссылаться на них в будущем.
10.4. В случае если обстоятельства непреодолимой силы продлятся для какой-либо Стороны
более 10 (десяти) рабочих дней, другая Сторона имеет право расторгнуть настоящий Договор
в одностороннем порядке, письменно уведомив об этом другую Сторону за 10 (десять)
рабочих дней до предполагаемой даты расторжения.
6
11.
Конфиденциальность
11.1. Стороны договариваются хранить как коммерческую тайну всю информацию,
полученную ими от другой Стороны с пометкой «Конфиденциально». Стороны относят
информацию к информации, составляющей коммерческую тайну, в соответствии с
действующим законодательством. Данная информация не может быть использована без
письменного разрешения другой Стороны ни для каких других целей, кроме как для
выполнения Договора.
11.2. Стороны договариваются не разглашать конфиденциальную информацию в ходе работ
по Договору и в течение трёх лет после прекращения его действия, а также принять все
меры, чтобы предохранить такую информацию от разглашения.
11.3. Стороны договариваются, что в случае нарушения одной из Сторон условий
конфиденциальности нарушившая Сторона возместит потерпевшей Стороне возникшие в
связи с этим убытки.
12.
Урегулирование споров
12.1. Все возникающие по Договору споры и/или разногласия Стороны будут разрешать в
Арбитражном суде города Москвы в соответствии с нормами действующего законодательства
Российской Федерации.
13.
Срок действия Договора
13.1. Настоящий Договор вступает в силу с даты подписания его обеими Сторонами
действует по полного исполнения Сторонами своих обязательств по Договору.
13.2. Настоящий Договор может быть расторгнут по взаимному письменному соглашению
Сторон, а также в случаях, предусмотренных законодательством Российской Федерации. В
случае расторжения Договора Стороны произведут взаимные расчеты в течение 10 (десяти)
рабочих дней до даты расторжения в соответствии с положениями Договора и нормами
действующего законодательства Российской Федерации.
14.
Прочие условия
14.1. Заказчик по согласованию с Исполнителем путем подписания соответствующего
дополнительного Соглашения вправе не более чем на 10% (десять процентов) изменить
объем выполняемых по Договору Работ. При этом общая сумма Договора изменяется не
более чем на 10% (десять процентов) от первоначальной стоимости Договора.
14.2. Изменения и дополнения к Договору действительны лишь в том случае, если они
совершены в письменной форме и подписаны уполномоченными лицами обеих Сторон.
14.3. Все приложения, изменения и дополнения к Договору будут являться его неотъемлемой
частью.
14.4. В случае привлечения Исполнителем третьих лиц к исполнению Договора Исполнитель
отвечает за их действия, как за свои собственные.
14.5. Взаимоотношения Сторон, не урегулированные настоящим Договором, определяются
действующими законами и иными нормативными актами Российской Федерации.
14.6. Об изменении банковских реквизитов, почтового адреса, предстоящей реорганизации
или ликвидации Сторона, которой касаются эти изменения, обязана письменно уведомить
другую Сторону в течение 10 (десяти) рабочих дней с даты соответствующего изменения.
14.7. Контактная информация Представителя Исполнителя: ФИО ______________, телефон
______________, адрес электронной почты ______________.
7
14.8. Контактная информация Представителя Заказчика: ФИО ______________, телефон
______________, адрес электронной почты ______________.
14.9. Настоящий Договор составлен и подписан в 2-х (двух) экземплярах, имеющих
одинаковую юридическую силу, по одному для каждой из Сторон.
15.
Приложения
15.1. На момент подписания Договор имеет следующие Приложения:
•
Приложение 1 Техническое задание.
•
Приложение 2 Календарный план работ и их стоимость.
•
Приложение 3 Требования к разработке СТП.
•
Приложение 4 Требования к разработке ФТР.
16.
Юридические адреса и банковские реквизиты Сторон
Исполнитель:
Заказчик:
______________
______________
Государственная корпорация «Банк
развития и внешнеэкономической
деятельности (Внешэкономбанк)»
Юридический и почтовый адрес: проспект
Академика Сахарова, д. 9, Москва, 107996,
Россия;
ИНН 7750004150, КПП 997950001
ОГРН 1077711000102, ОКПО 00005061
ОКВЭД: основной 65.12, дополнительные
65.23, 65.23.1, 65.23.2, 65.23.4, 67.12.2,
67.13.51.
счет 47422810100000059100 во
Внешэкономбанке
к/с 30101 810 5 00000 00 0060 в ОПЕРУ
Московского ГТУ Банка России (БИК
044525000)
БИК 044525060
Юридический адрес: ______________
Почтовый адрес: ______________
ИНН ______________
КПП ______________
ОГРН ______________
ОКПО ______________
ОКВЭД: ______________
Р/с ______________
в ______________
К/с ______________
БИК ______________
От Исполнителя:
От Заказчика:
______________
______________
______________
______________
____________________ ______________
____________________ ______________
8
Приложение 1
к Договору выполнения работ
№ _________________ от «_____» ____________ 201_ г.
Техническое задание
Создание Автоматизированной системы управления закупочной
деятельностью Внешэкономбанка
1. Назначение и цели создания Автоматизированной системы управления
закупочной деятельностью Внешэкономбанка
1.1. Назначение Системы
Автоматизированная система управления закупочной деятельностью Внешэкономбанка
(Система) предназначена для автоматизации процесса управления закупками
Внешэкономбанка.
Система должна обеспечить автоматизацию выполнения задач, возлагаемых на
сотрудников, участвующих в закупочной деятельности Внешэкономбанка, соответствующей
актуальным целям и современным практикам Внешэкономбанка,
Система должна обеспечить обмен информацией между корпоративными системами
Внешэкономбанка, и внешними системами, задействованными в процессе выполнения работ.
Корпоративными системами для интеграции являются:
• Система электронного документооборота (далее – СЭД), сопровождающая
процесс управления деятельностью Внешэкономбанка;
• Система голосования «Система ведения коллегиальных органов» (далее – СВКО),
сопровождающая процесс выявления победителей торгов.
К внешним системам относятся:
• Система Общероссийского официального сайта (далее – ООС) закупок,
обеспечивающая размещение извещений о проведении закупок, ведение единых
государственных реестров – реестра недобросовестных поставщиков, реестра
жалоб, реестра контрактов;
• Система электронной торговой площадки (далее – ЭТП), обеспечивающая
организацию электронных аукционов и других видов торгов в сети Интернет,
предоставление услуг полного цикла по проведению и сопровождению
электронных торгов.
Объектом автоматизации является функциональная деятельность подразделений
Внешэкономбанка, направленная на сбор, контроль и анализ информации о процедуре и
результатах размещения заказов на поставку товаров, выполнение работ, оказание услуг для
нужд Внешэкономбанка.
1.2 Цели создания Системы
Целью работ по созданию Системы является автоматизация рабочих процессов
исполнения функций по подготовке, проведению и учету закупок на поставку товаров,
выполнение работ, оказание услуг для нужд Внешэкономбанка, планирования и размещения
заказов, заключения и исполнения контрактов, мониторинга и контроля вышеуказанных
функций.
9
Создание Системы должно быть направлено на:
− повышение качества управленческих решений;
− повышение эффективности процессов и результатов закупочной деятельности;
− формирование
универсального
инструмента
управления
закупочными
процедурами на всех этапах;
− формирование единой закупочной политики среди структурных подразделений
Внешэкономбанка.
При выполнении работы должны быть решены следующие задачи:
− Анализ отраслевой принадлежности и определение концепции организационно –
закупочной деятельности;
− Автоматизация процесса планирования закупок товаров, работ, услуг (разработка
Плана закупок);
− Автоматизация процесса приема и обработки заявок на размещение заказа;
− Автоматизация функций управления процессом размещения заказа;
− Автоматизация функций контроля над размещением заказа;
− Автоматизация процесса формирования отчетных и иных (повестки дня комиссий,
протоколы, документация конкурсов и др. не являющиеся отчетами) документов;
− Автоматизация процесса ведения регламентированных федеральным законом
информационных реестров;
− Формирование отчетных форм;
− Хранение документации участников закупочных процедур, а также
промежуточной и итоговой отчетной документации, предоставляемой по
результатам исполнения договоров;
− Снижение количества ошибок при выполнении процессов планирования,
размещения, исполнения государственного заказа;
− Проведение последующего аудита поставки товаров, выполнения работ, оказания
услуг и формирование рейтинга поставщиков;
− Экономия рабочего времени и связанных экономических затрат при
осуществлении процедур размещения заказа, подготовке сводных отчетных
документов.
При создании Системы необходимо руководствоваться следующими нормативными
документами и проектами документов:
− Федеральный закон Российской Федерации от 18 июля 2011 г. № 223-ФЗ «О
закупках товаров, работ, услуг отдельными видами юридических лиц» (в
действующей редакции) (далее – 223-ФЗ);
− Федеральный закон Российской Федерации от 17 мая 2007 года № 82-ФЗ «О банке
развития» (в действующей редакции) (далее – 82-ФЗ);
− Порядок разработки, приобретения, внедрения и сопровождения прикладного
программного обеспечения во Внешэкономбанке, утвержденный приказом
Внешэкономбанка от 07.12.2004 № 480;
− Проект Положения о закупках Внешэкономбанка, разрабатываемый в рамках
создания Системы и описанный в подпункте 2.1.1 данного Технического задания;
− Проект Регламента осуществления закупочной деятельности Внешэкономбанка,
разрабатываемый в рамках создания Системы и описанный в п. 2.1.2 данного
Технического задания;
− Иные внутренние нормативные документы, разрабатываемые в рамках создания
Системы и описанные в пункте 2 данного Технического задания.
Этапы, состав и содержание работ по созданию Системы приведены в Приложении 2 к
Договору.
10
2 Анализ действующей внутренней нормативной базы и бизнес-процесса
закупки, подготовка предложений по их совершенствованию
Исполнитель проводит анализ:
− действующих во Внешэкономбанке внутренних нормативных документов,
регламентирующих закупочную деятельность;
− положений о структурных подразделениях и должностных инструкций
работников-участников бизнес-процесса закупки;
− бизнес-процесса закупки;
− основных направлений закупочной деятельности Внешэкономбанка.
По результатам анализа Исполнитель подготавливает отчет с указанием выявленных
проблемных моментов (несоответствия законодательству, дублирование/отсутствие
функционала и т.д.) в организации закупок, который должен содержать предложения по
устранению указанных проблем/оптимизации бизнес-процесса, а также информацию (в
форме сравнения) об опыте решения аналогичных вопросов и организации процесса закупок
другими крупными государственными компаниями, и формирует требования к Системе.
2.1 Разработка проектов внутренних нормативных документов
На основании результатов анализа, проведенного в ходе реализации п.1,
руководствуясь требованиями действующего законодательства, собственным опытом и
опытом других государственных компаний, Исполнитель разрабатывает проекты внутренних
нормативных документов, регламентирующих закупочную деятельность Внешэкономбанка.
2.1.1 Положение о закупках
Положение о закупках является основным внутренним нормативным документом,
регламентирующим закупочную деятельность во Внешэкономбанке.
Положение должно полностью соответствовать требованиям действующего
законодательства и содержать, в том числе, следующие разделы:
− цели закупочной деятельности;
− принципы организации закупочной деятельности;
− принципы и общие требования к планированию закупок;
− способы закупок (не менее 5 конкурентных способов закупки), формы процедур
закупки и условия их применения (условия применения выбранного способа
должны предусматривать, в том числе, возможность проведения закупки в
электронной форме (где применимо));
− общие требования, предъявляемые к участникам закупочных процедур и
документам, входящим в состав заявки на участие;
− общие требования к порядку организации и проведения закупочных процедур (в
том числе в электронной форме);
− общие требования к порядку заключения договоров;
− общие требования к отчетности;
− общие требования к порядку организации и проведения закупочных процедур в
особых закупочных ситуациях (в том числе предварительный квалификационный
отбор, закупка продукции, содержащей сведения ограниченного распространения,
мелкие закупки, заключение рамочных договоров).
2.1.2 Регламент осуществления закупочной деятельности
Регламент осуществления закупочной деятельности должен быть разработан в
соответствии с Положением о закупках и определять компетенцию и порядок
11
взаимодействия подразделений, должностных лиц и коллегиальных органов
Внешэкономбанка, являющихся участниками бизнес-процесса закупки.
Регламент должен соответствовать Положению о закупках и содержать, в том числе,
следующие разделы:
− участники процесса закупки (инициатор закупки, организатор закупки,
согласующие подразделения, комиссия по закупкам, контролирующий орган – с
указанием прав, обязанностей, функционала и ответственности данных участников
в рамках бизнес-процесса закупки);
− порядок планирования закупок;
− порядок проведения закупочных процедур (в соответствии со способами,
определенными в Положении о закупках - в том числе порядок подготовки и
согласования документов, определения НМЦ, проведения закупки и
заключения/внесения изменений в договор);
− порядок подготовки и формы отчетности по закупкам.
2.1.3 Положение о Комиссии по закупкам
Положение о Комиссии по закупкам должно соответствовать Положению о закупках и
Регламенту осуществления закупочной деятельности, и содержать, в том числе, следующие
разделы:
− цели деятельности Комиссии;
− принципы деятельности Комиссии;
− состав Комиссии;
− функции Комиссии;
− регламент работы Комиссии;
− полномочия, обязанности и ответственность участников Комиссии (Председателя
Комиссии, Секретаря Комиссии, членов Комиссии).
2.1.4 Методика расчета начальной (максимальной) цены договора
Методика расчета НМЦ договора должна соответствовать Положению о закупках и
Регламенту осуществления закупочной деятельности и устанавливать типовые подходы к
определению НМЦ при размещении заказов, в том числе, на:
− выполнение работ;
− поставку товаров;
− оказание услуг.
Методика должна также определять возможные источники получения информации,
необходимой для расчета НМЦ, порядок применения такой информации при расчете НМЦ
(включая примеры расчета), а также форматы представления результатов расчета.
2.1.5 Методика оценки заявок на участие в процедурах закупки
Методика оценки заявок на участие должна соответствовать Положению о закупках и
Регламенту осуществления закупочной деятельности и определять типовые критерии
оценки, применяемые подразделениями Внешэкономбанка при разработке закупочной
документации, а также подходы к рассмотрению и оценке заявок на участие по указанным
критериям, в том числе:
− на стадии отбора – для каждого из требований, предъявляемых в соответствии с
Положением о закупках к участникам закупочных процедур и документам,
входящим в состав заявки на участие, должен быть определен конечный перечень
оснований для отказа в допуске к участию в процедуре закупки при невыполнении
данного требования;
12
− на стадии оценки – для каждого из случаев закупки (поставка товаров/выполнение
работ/оказание
услуг)
должен
быть
определен
типовой
перечень
критериев/подкритериев оценки, а также порядок оценки заявок на участие по
данному критерию.
2.1.6 Типовые формы Комплекта документов о проведении закупки
Для каждого из способов закупки, определенных в Положении о закупках, должна быть
разработана типовая форма Комплекта документов о проведении закупки (заявка на
проведение закупки, извещение о проведении закупки, документация процедуры закупки и
т.д.).
2.1.7 Типовые формы договоров
В соответствии с требованиями к порядку заключения договоров, установленными в
Положении о закупках, Регламенте осуществления закупочной деятельности и иных
внутренних нормативных документов Внешэкономбанка, для каждого из основных
направлений закупочной деятельности Внешэкономбанка (не менее 10), определенных в
ходе анализа, проведенного в ходе реализации п.1, должна быть разработана типовая форма
договора.
2.1.8 Должностные инструкции работников подразделения, выполняющего
функции организатора закупки
Для каждой должности работников подразделения, выполняющего функции
организатора закупки, с учетом функционала, определенного Регламентом осуществления
закупочной деятельности, должна быть разработана типовая должностная инструкция.
13
3
Требования к Системе
3.1
Требования к нормативным документам «Спецификация
пользователя» и «Функционально-технические решения»
требований
В соответствии с Порядком разработки, приобретения, внедрения и сопровождения
прикладного программного обеспечения во Внешэкономбанке, утвержденным приказом
Внешэкономбанка от 07.12.2004 № 480, должны быть разработаны документы
«Спецификация требований пользователя» и «Функционально-технические решения» в
соответствии с Приложениями 3 и 4 к Договору.
Этапы, на стадии которых разрабатываются вышеуказанные документы, приведены в
Приложении 2 к Договору.
3.2
Требования к Системе в целом
Система должна обеспечить автоматизацию выполнения задач, возлагаемых на
сотрудников, участвующих в закупочной деятельности Внешэкономбанка, в части
формирования, обмен информацией между корпоративными системами Внешэкономбанка и
внешними системами, задействованными в процессе закупочной деятельности с учетом с
учетом соблюдения законодательства РФ и нормативных документов Внешэкономбанка.
Организационное, техническое, программное, информационное и лингвистическое
обеспечение должно быть реализовано на единых системных концепциях, определенных для
Системы в целом.
В Системе должна обеспечиваться возможность модификации с учетом изменений
нормативной базы, а также требований, предъявляемых Внешэкономбанком в процессе её
эксплуатации.
В Системе должен быть предусмотрен механизм расширения функциональных
модулей. Система должна быть создана таким образом, чтобы была обеспечена возможность
интеграции в свою среду новых подсистем и расширения функций уже имеющихся
подсистем за счет модульного принципа их построения, а также использования принятых в
мире стандартов на правила передачи (протоколы, интерфейсы) и хранения информации.
Система должна быть разработана с учетом требований нормативных документов,
разрабатываемых в рамках создания Системы, перечень которых указан в п. 5.
Система должна иметь модульную архитектуру, позволяющую осуществлять штатное
администрирование и настройку Системы через интерфейс Системы без привлечения
разработчиков.
Система должна быть разработана на основе открытого программного кода, свободного
от прав третьих лиц.
В Системе должен быть реализован функционал по изменению и сохранению истории
параметров Системы, в том числе:
− маршруты следования заявок;
− формы документов по закупкам;
− состава комиссий после опубликования информации о закупке;
− отчетные документы.
Система должна выполнять свои функции при следующих условиях:
− количество подразделений Внешэкономбанка – не менее 200;
− количество зарегистрированных пользователей – не менее 1000;
− количество одновременных сетевых соединений, которые обрабатываются
инфраструктурой Системы – не менее 150;
− объем хранимых пользовательских документов – 20 Терабайт.
14
Система должна предусматривать возможность хранения данных в течение 10 лет после
вывода её из промышленной эксплуатации.
В Системе должен быть предусмотрен механизм оповещения пользователей (группы
пользователей) о ключевых событиях, касающихся работы Системы. Условия
функционирования будут уточнены на этапе проектирования Системы.
3.3
Требования к функциональным возможностям Системы
В состав Системы должны входить следующие функциональные блоки:
− блок управления проведением закупочных процедур;
− блок управления заявками на проведение закупочных процедур;
− блок управления работой Комиссии по закупкам;
− блок формирования и контроля исполнения закупок;
− блок формирования и экспертизы закупочной документации;
− блок управления и сопровождения закупочных процедур;
− блок сопровождения и мониторинга исполнения договоров;
− блок сводной аналитической отчетности;
− блок администрирования;
− блок управления доступом.
3.3.1
Требования к функциям блока управления проведением закупочных процедур
Блок управления проведением закупочных процедур должен выполнять следующие
функции:
− формирование комплектов документов для вынесения на рассмотрение Комиссии
по закупкам вопросов о проведении закупочных процедур;
− согласование комплектов документов с заинтересованными подразделениями
Внешэкономбанка;
− корректировка комплектов документов.
3.3.2
Требования к функциям блока управления заявками на проведение закупочных
процедур
Блок управления заявками на проведение закупочных процедур должен выполнять
следующие функции:
− формирование заявок на проведение закупочных процедур;
− согласование заявок с заинтересованными подразделениями Внешэкономбанка;
− корректировка заявок.
3.3.3
Требования к функциям блока управления работой Комиссии по закупкам
Блок управления работой Комиссии по закупкам должен выполнять следующие
функции:
− формирование повестки дня и проектов решений Комиссии по закупкам
Внешэкономбанка;
− функциональное обеспечение проведения заседаний Комиссии по закупкам
(определение кворума, проведение голосования и т.д.);
− формирование документов Комиссии по закупкам (протоколов, выписок и т.д.);
− размещение информации о закупках и документов Комиссии по закупкам на ООС
и ЭТП.
3.3.4
Требования к функциям блока формирования и контроля исполнения закупок
Блок формирования и контроля исполнения закупок должен выполнять следующие
функции:
15
− формирование запросов на осуществление закупок;
− формирование планов-графиков проведения закупок (на основании отобранных
запросов) на очередной финансовый год по формам, согласованным с
Внешэкономбанком;
− выгрузка информации в приложения Microsoft Office (Microsoft Word, Microsoft
Excel и др.);
− мониторинг, контроль установленных сроков исполнения отдельных задач,
оповещение пользователей при превышении сроков исполнения.
Должна быть систематизирована следующая информация:
− уникальный номер заявки;
− описание заявки и обоснование предмета заявки;
− журнал изменений версий заявок с правками и комментариями с возможностью
просмотра каждой версии и всей истории заявки;
− расчет начальной стоимости заявки;
− сопроводительные документы к заявке (в форматах *.doc, *.xls, *.pdf, *.tif, *.ipg и
др.).
3.3.5
Требования к функциям блока формирования и экспертизы закупочной
документации
Блок формирования и экспертизы закупочной документации должен выполнять
следующие функции:
− автоматизированное
формирование
проекта
закупочной
документации
(техническое задание, технические требования, закупочная документация);
− хранение данных о версионности разрабатываемых документов с возможностью
просмотра полной истории работы над документами;
− использование шаблонов при работе с документацией;
− разбиение по функциональным полям утвержденной версии закупочной
документации;
− возможность назначения необходимого и достаточного числа экспертов
(пользователей Системы) для проведения экспертизы закупочной документации;
− возможность
проведения
уполномоченными
экспертами
экспертизы
подготовленной закупочной документации;
− возможность добавления замечаний, как ко всему представленному документу, так
и к отдельным разделам;
− возможность вносить экспертом правки в подготовленной закупочной
документации с учетом версионности вносимых изменений;
− возможность коллективного обсуждения при проведении экспертизы:
− возможность выгрузки документов (заключения по итогам экспертизы и т.д.) в
приложения Microsoft Office (Microsoft Word, Microsoft Excel и др.).
Должен поддерживаться ряд функциональных статусов закупочной документации:
− новая;
− формируется;
− на экспертизе;
− на доработке;
− одобрена.
3.3.6
Требования к функциям блока управления и сопровождения закупочных
процедур
Блок управления и сопровождения закупочных процедур должен выполнять следующие
функции:
16
− хранение информационной карты о проводимом конкурсе, содержащей, в том
числе, реестровый номер закупки, наименование предмета закупки, информация
об объемах закупки, объемы планового финансирования закупки, заказчик
закупки, дата размещения закупки, плановая дата завершения закупки, плановая
дата заключения договора по итогам закупки и др.;
− отображение списка закупочных процедур в соответствии с их статусом
(объявлен, отмена, подведены итоги, заключен договор);
− генерация, хранение и экспорт из Системы протоколов вскрытия, оценки и
сопоставления заявок, поданных на участие в закупочных процедурах;
− возможность изменения сроков и отмены проводимых закупочных процедур;
− возможность учета информации о поданной заявке на участие в закупочных
процедурах;
− возможность генерации и экспорта в приложения Microsoft Office протокола
вскрытия поданных заявок, протокола рассмотрения поданных заявок, протокола
оценки и сопоставления поданных заявок;
− возможность генерации в Системе проекта договора с учетом данных заявкипобедителя.
3.3.7
Требования к функциям блока сопровождения и мониторинга исполнения
договоров
Блок сопровождения и мониторинга исполнения договоров должен выполнять
следующие функции:
− учет и регистрацию заключенных договоров;
− учет и контроль выполнения основных параметров и этапов договоров;
− учет требований к товарам, работам (услугам), сформированных на этапе
подготовки закупочной документации;
− учет сроков завершения как отдельных этапов, так и каждого вида работ (услуг),
либо сроков поставки товаров, предусмотренных в рамках договоров;
− учет стоимостных параметров товаров, работ (услуг) и оснований завершения
отдельных этапов (договоров);
− возможность учета отчетов по результатам выполненных работ, оказанных услуг;
− экспертизу результатов исполняемых договоров, используя две различные роли
экспертов (эксперт, старший эксперт);
− предоставление возможности эксперту проверять каждое из активных полей этапа
исполнения договора и формирование комментария к документу;
− возможность генерации итогового экспертного заключения;
− предоставление возможности старшему эксперту менять решение эксперта;
− необходимость цветовой дифференциации этапов, прошедших экспертизу, не
прошедших и ожидающих заключения эксперта, этапов, по которым отчет
исполнителя был предоставлен вовремя и с нарушением сроков.
3.3.8
Требования к функциям блока сводной аналитической отчетности
Блок сводной аналитической отчетности должен содержать набор страниц
со
статичными статистическими отчетными формами, представленными текстовыми и
графическими элементами.
Блок должен обеспечивать генерацию и экспорт произвольно создаваемых отчетов в
приложения Microsoft Office (Microsoft Word, Microsoft Excel и др.).
Требования к отчетам должны, в том числе, соответствовать следующим условиям:
− должна быть реализована возможность выгрузки статистических данных из всех
блоков Системы;
17
− должна быть реализована возможность выгрузки данных в соответствии со
статусами (этапами работы в Системы);
− должна быть реализована возможность выгрузки данных в разрезе структурных
подразделений Внешэкономбанка.
3.3.9
Требования к функциям блока администрирования
Блок администрирования должен выполнять следующие функции:
− управление Системой посредством специализированного интерфейса;
− настройка параметров функционирования Системы и справочной информации;
− разделение прав доступа пользователей к документам, формируемым в ходе
процедур по закупочной деятельности;
− возможность ограничения доступа пользователей к определенным блокам
Системы, объектам, отдельным страницам, формам, полям форм, отдельным
записям, данным и программной логике.
3.3.10 Требования к функциям блока управления доступом
Блок управления доступом должен выполнять следующие функции:
− регистрация пользователей Системы, внесение сведений о пользователях,
редактирование, удаление, блокирование информации о них;
− добавление, редактирование, изменение настроек прав доступа ролей;
− разграничение доступа пользователей Системы к объектам защиты:
• персональные данные, хранимые и обрабатываемые в Системе;
• информация, необходимая для реализации функциональности: данные о
закупочных процедурах, планах закупок, заявках на размещение заказов,
контрактах с выигравшими поставщиками и другие данные;
− разграничение доступа пользователей и администраторов Системы к
выполняемым действиям.
3.4
Требования к информационному обеспечению
Входящие в состав Системы подсистемы и блоки в процессе функционирования
должны вести обмен информацией на основе открытых форматов обмена данными,
используя для этого входящие в их состав модули информационного взаимодействия.
Все программное обеспечение Системы, а также инсталляционный комплект
поставляется на электронном носителе (CD/DVD).
Система должна быть разработана с использованием общего программного
обеспечения с открытым исходным кодом.
Разработанное программное обеспечение в рамках настоящего технического задания
должно поставляться с открытым исходным кодом.
3.5
Требования к составу, структуре и способам организации данных в Системе
При интеграции с ООС для размещения информации о размещении заказа должны
использоваться справочники ООС для размещения информации о размещении заказа, в
соответствии с опубликованным на сайте http://zakupki.gov.ru регламентом.
В состав информационного обеспечения Системы должны входить:
− нормативно-справочная информация;
− классификаторы;
− справочники, словари и реестры;
− база данных;
− унифицированные формы документов, отчетов и протоколов.
18
В Системе должна содержаться нормативно-справочная информация (документы в
формате PDF или аналог), регламентирующие процесс осуществления закупок.
Создаваемая Система должна содержать:
− планы закупок;
− информацию о реализации планов закупок;
− информацию о закупках, об исполнении контрактов;
− реестр контрактов, заключенных заказчиками;
− библиотеку типовых контрактов, типовых условий контрактов;
− реестр жалоб, плановых и внеплановых проверок, их результатов и выданных
предписаний;
− результаты мониторинга закупок, аудита в сфере закупок, а также контроля в
сфере закупок;
− отчеты, предусмотренные Федеральным законом, а также иные отчеты,
уточняемые с Заказчиком на этапе проектирования Системы.
При описании закупок Система должна использовать Общероссийский классификатор
видов экономической деятельности, продукции и услуг (ОКДП).
Система должна обеспечивать возможность загрузки, структурированного хранения и
доступа пользователей к нормативно-справочной информации. Необходимо обеспечить
хранение истории изменений нормативно-справочной информации. Система должна
обеспечивать выгрузку нормативно-справочной информации в приложения Microsoft Office
(Microsoft Word, Microsoft Excel и др.).
В состав Системы должны входить специализированные утилиты резервного
копирования и восстановления данных.
3.6
Требования к интерфейсу Системы
Взаимодействие пользователей с ПО Системы должно осуществляться посредством
визуального графического интерфейса. Интерфейс Системы должен быть понятным и
удобным и должен обеспечивать быстрое отображение экранных форм. Навигационные
элементы, средства ввода/вывода и редактирования информации должны быть выполнены в
удобной для пользователя форме.
Интерфейс должен соответствовать современным эргономическим требованиям и
обеспечивать удобный доступ к основным функциям и операциям Системы. Интерфейс
должен быть рассчитан на использование манипулятора типа «мышь» или сенсорных
экранов, а также клавиатуры.
Все надписи экранных форм, диалоговых окон, а также информационные сообщения,
выдаваемые пользователю, должны быть на русском языке.
Все документы, формируемые в Системе, должны предоставляться пользователю на
русском языке.
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных
неверными действиями пользователей, неверным форматом или недопустимыми значениями
входных данных. В указанных случаях Система должна выдавать пользователю
соответствующие сообщения, после чего возвращаться в рабочее состояние,
предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
Экранные формы должны проектироваться с учетом требований унификации:
− экранные формы пользовательского интерфейса должны быть выполнены в
едином графическом дизайне;
− для обеспечения сходных операций должны использоваться сходные графические
значки, кнопки и другие управляющие навигационные элементы;
19
− термины, используемые для обозначения типовых операций, а также
последовательность действий должны быть унифицированы;
− внешнее поведение сходных элементов интерфейса должны реализовываться
одинаково для однотипных элементов.
Терминология программного обеспечения Системы должна соответствовать 223-ФЗ.
3.7
Требования к методическому и нормативному обеспечению
Должны быть разработаны методики и инструкции выполнения операций в Системе, в
том числе:
− руководство пользователя в разрезе функциональных обязанностей сотрудников
структурных подразделений Внешэкономбанка;
− руководство администратора;
− инструкция по установке и настройке Системы;
− программа-методика испытаний.
Должны быть разработаны необходимые регламенты и нормативные документы по
выполнению операций в Системе, в том числе внутренние документы Внешэкономбанка для
работы с Системой с целью осуществления ВЭБ закупочной деятельности в соответствии с
223-ФЗ:
− Положение о закупках Внешэкономбанка;
− Регламент осуществления закупочной деятельности Внешэкономбанка;
− Спецификация требований пользователя (Приложение 3 к Договору);
− Функционально-технические решения (Приложение 4 к Договору);
− Проекты приказов, направленные и обеспечивающие нормативную и правовую
формализацию процесса закупочной деятельности Внешэкономбанка.
Должен быть разработан и подписан Акт о вводе Системы в эксплуатацию.
Документы Спецификация требований пользователя (Приложение 3 к Договору),
Функционально-технические решения (Приложение 4 к Договору) разрабатываются в
соответствии со стандартами Внешэкономбанка.
Документация на Систему передается на бумажных и машинных носителях (CD/DVD).
Текстовые документы, передаваемые на машинных носителях, должны быть представлены в
форматах MS Office (Ms Word, Ms Excel и др.). Вся документация должна быть представлена
на русском языке.
3.8
3.8.1
Требования к взаимодействию с другими системами
Требования к взаимодействию с корпоративными системами
Взаимодействие с корпоративными системами СЭД, СВКО должно осуществляться в
соответствии с принятыми форматами и регламентом обмена данными с Системой,
разрабатываемых и утверждаемых на этапе проектирования Системы, с учетом нормативных
документов Внешэкономбанка и Политики безопасности Внешэкономбанка.
Требования к характеристикам взаимосвязей создаваемой Системы с корпоративными
системами, требования к их совместимости, в том числе указания о способах обмена
информацией (автоматически или пересылкой документов) должны быть разработаны и
уточнены на этапе проектирования Системы.
Разработка Системы не должна требовать никаких существенных изменений в
настройках СЭД, СВКО.
20
3.8.2
Требования к взаимодействию с внешними системами
Взаимодействие с внешними системами должно осуществляться в соответствии с
нормативными
документами
Внешэкономбанка
и
Политики
безопасности
Внешэкономбанка.
3.8.2.1 Требования к взаимодействию с ООС
Взаимодействие с ООС по размещению информации о размещении заказа
(http://zakupki.gov.ru) должна осуществляться в соответствии с «Альбомом форматов XMLдокументов передаваемых в электронной форме по телекоммуникационным каналам связи в
рамках интеграции Общероссийского официального сайта со смежными системами»
(http://zakupki.gov.ru/wps/wcm/connect/9bf9020046d13b6489508be6f5c46611/%D0%90%D0%B
B%D1%8C%D0%B1%D0%BE%D0%BC+%D0%A2%D0%A4%D0%A4.doc?MOD=AJPERES).
Система должна позволять размещать на ООС следующие документы:
− годовой План закупок товаров, работ, услуг и изменения к нему;
− извещения о проведении процедуры и изменения к ней;
− данные о поданных на участие в закупках заявках;
− документация к процедуре и изменения к ней;
− протоколы, оформляемые в ходе рассмотрения и оценки заявок, протоколы
комиссии Внешэкономбанка, протоколы вскрытия, оценки и сопоставления
заявок;
− разъяснения к документации;
− проекты договоров;
− иные документы, оформляемые в ходе проведения процедуры.
Система должна формировать отчет о размещении на ООС перечисленных документов
с возможностью выгрузки в приложения Microsoft Office (Microsoft Word, Microsoft Excel и
др.).
Регламент обмена данными с Системой, требования к совместимости, в том числе
указания о способах обмена информацией должны быть уточнены на этапе проектирования
Системы.
3.8.2.2 Требования к взаимодействию с ЭТП
В качестве формата передачи данных для интеграции с ЭТП должен использоваться
формат XML. Регламент обмена данными с Системой, требования к совместимости, в том
числе указания о способах обмена информацией должны быть уточнены на этапе
проектирования Системы.
Система должна позволять размещать на ЭТП следующие документы:
− извещение о проведении процедуры и изменения к ней;
− документация к процедуре и изменения к ней;
− протоколы, оформляемые в ходе рассмотрения и оценки заявок, протоколы
комиссии Внешэкономбанка, протоколы вскрытия, оценки и сопоставления
заявок;
− данные о победителях закупок;
− проекты договоров;
− иные документы, оформляемые в ходе проведения процедуры.
Система должна формировать отчет о размещении на ЭТП перечисленных документов.
Система
должна
поддерживать
следующие
процедуры,
проводимые
Внешэкономбанком, на ЭТП:
− аукцион;
− запрос котировок;
21
− конкурс.
3.9
Требования к техническому обеспечению Системы
Конкретный состав и конфигурация технического оборудования уточняются при
проектировании Системы в Функционально-технических решениях.
Для создания Системы используются технические средства Внешэкономбанка.
3.10 Требования к серверному оборудованию
Рекомендуется использование одного сервера базы данных, одного или двух серверов
приложений.
Минимальные характеристики одного сервера для Системы:
− Процессор 2 х 2 GHz;
− Оперативная память 4Гб;
− Жесткий диск 500 GB;
− Устройства чтения DVD-CD;
− Сетевая карта 100 Mbit.
− операционную систему семейства Unix или Windows Server 2008 standard.
Серверное программное обеспечение Системы должно включать в себя:
− СУБД PostgreSQL;
− сервер Apache, используемый как web-сервер;
− языковые средства PHP;
− сервисное программное обеспечение общего применения.
3.11 Требования к автоматизированным рабочим местам
Система должна эксплуатироваться на операционных системах Microsoft Windows XP,
Microsoft Windows Vista, Microsoft Windows 7
Минимальные технические характеристики автоматизированных рабочих мест для
работы с Системой:
− Процессор: 300 MHz или выше;
− Оперативная память: 1024 Мб RAM или выше;
− TFT монитор (1280х1024) или выше;
− Свободное место на HDD 40 Гб или больше;
− Устройства взаимодействия с пользователем: клавиатура и мышь.
− Операционная система Windows XP SP3 или выше, Microsoft Windows Vista,
Microsoft Windows 7;
− Web-браузер Internet Explorer (ver 7 и выше).
3.12 Требования по диагностированию
Диагностирование Системы должно обеспечивать выявление неработоспособности
технических средств, базового и прикладного программного обеспечения.
Все подсистемы, входящие в состав Системы, должны иметь средства и процедуры
диагностирования.
3.13 Требования к информационной безопасности и защите информации от
несанкционированного доступа
В
соответствии
с
руководящим
документом
Гостехкомиссии
России
«Автоматизированные системы. Защита от несанкционированного доступа к информации.
Классификация автоматизированных систем и требования по защите информации» Система
относится к группе многопользовательских автоматизированных систем, в которых
22
одновременно
обрабатывается
и
хранится
информация
разных
уровней
конфиденциальности. Требуемый класс защиты информации в Системе – 1Г.
Система должна обеспечить:
− исключение несанкционированного доступа к обрабатываемой в Системе
информации и данным, информация должна предоставляться пользователям в
соответствии с их уровнем доступа;
− исключение
реализации
несанкционированных
или
непреднамеренных
воздействий, вызывающих хищение, разрушение, уничтожение, искажение
информации или сбои в работе технических средств;
− предотвращение утери, искажения информации при возникновении аварийных
ситуаций.
Защита информации от несанкционированного доступа должна обеспечиваться
средствами подсистемы информационной безопасности.
Разработка компонентов информационного и программного обеспечения Системы
должна осуществляться с учетом требований по защите информации от
несанкционированного доступа:
− ГОСТ Р 50922-96 «Защита информации. Термины и определения»;
− ГОСТ Р 50739-95 «Защита от несанкционированного доступа к информации»;
− Руководящий документ. Концепция защиты средств вычислительной техники от
несанкционированного доступа к информации- М.,1992.
− Гостехкомиссия России. Руководящий документ. Автоматизированные системы.
Защита от несанкционированного доступа к информации. Классификация
автоматизированных систем и требования по защите информации.-М.,1992
− Гостехкомиссия России. Руководящий документ. Средства вычислительной
техники. Защита от несанкционированного доступа к информации. Показатели
защищенности от несанкционированного доступа к информации. -М.,1992.
− Гостехкомиссия РФ. Руководящий документ. Защита от несанкционированного
доступа к информации. Термины и определения. М.: Воениздат, 1992.
3.14 Требования к обеспечению безопасности работ/услуг
Должны быть обеспечены следующие требования к обеспечению безопасности
работ/услуг:
− исполнитель обязан не передавать третьим лицам информацию, используемую для
выполнения работ/услуг, и сведения о характере оказываемых услуг.
− исполнитель обязан оказывать услуги с соблюдением действующих правил и норм
техники безопасности, пожарной безопасности, а также иных утвержденных и
зарегистрированных в установленном порядке актов уполномоченных органов
государственной власти в сфере охраны труда.
− в процессе оказания услуг обработка и хранение персональных данных и
конфиденциальной информации должны производиться в соответствии с
действующим законодательством.
3.15 Требования к тренингам пользователей Системы
При внедрении Системы необходимо проведение тренингов для пользователей
подразделений Внешэкономбанка (с учетом функциональных обязанностей) и
администраторов Системы.
Система должна оснащаться обучающими роликами. Обучающие ролики должны быть
интуитивно понятными. В роликах должны иллюстрироваться пошаговые действия для всех
процедур закупочной деятельности. Обучающие ролики должны иметь возможность
выполняться на любом рабочем месте пользователя.
23
3.16 Требования к сроку и объему гарантии качества выполненных работ
Гарантия на Систему – не менее 6 месяцев с даты подписания Акта сдачи-приемки
выполненных работ.
3.17 Техническое сопровождение Системы
Со стороны Исполнителя должна быть предусмотрена возможность обеспечения
послегарантийного технического сопровождения программного обеспечения.
В рамках технического сопровождения программного обеспечения Исполнитель
должен обеспечить заданные в Функционально-технических решениях уровни доступности,
мощности, непрерывности, безопасности и аудита, а также обеспечить консультационную
помощь Заказчику.
Техническое сопровождение Системы осуществляется на условиях отдельно
заключаемых Сторонами Договоров.
24
4
Требования к составу и содержанию работ по созданию Системы
Работы по созданию Системы выполняются в два этапа. Состав и отчетные материалы
представлены в Таблице 1.
Таблица 1. Состав и содержание работ
№
Название этапа и содержание работ
этап
а
Анализ действующей внутренней нормативной
1
базы и бизнес-процесса закупки, подготовка
предложений
по
их
совершенствованию,
разработка и согласование проектов внутренних
нормативных документов Внешэкономбанка
2
Формирование требований к Системе:
– организация работ по проекту;
– аудит сложившейся практики организационно –
закупочной деятельности ВЭБ;
– определение стандартов закупок;
– описание моделей закупок при применении
стандартов с учетом типичных и специфичных
закупок ВЭБ;
– разработка нормативно-правовых актов по
работе с Системой на основании 223-ФЗ;
– формирование требований к функциональным и
технологическим подсистемам;
– формирование и утверждение уточненного
технического задания;
оформление отчета о выполненной работе
Разработка технорабочего проекта и ППО.
Разработка технорабочего проекта:
– разработка концептуальной архитектуры
Системы, определение стратегий и требований к
конвертации данных, определение стратегии,
требований и сценариев тестирования,
определение стратегии внедрения;
– разработка проектных решений по созданию
Системы и ее подсистем;
– разработка, оформление, согласование и
утверждение документации в объёме,
необходимом для описания полной
совокупности принятых проектных решений и
достаточном для дальнейшего выполнения
работ по созданию Системы;
– установка и настройка программных средств
разработки;
Разработка ППО:
– разработка специализированных программных
модулей;
– разработка программных средств переноса
существующих баз данных в базы данных
Системы;
– разработка, согласование и утверждение
рабочей документации.
Разрабатываемые документы
(предоставляемые
Внкшэкономбанку)
– Проект Положения о закупках;
– Проект Регламента осуществления
закупочной деятельности;
– Проект Положения о Комиссии по
закупкам;
– Проект Методики расчета
начальной (максимальной) цены
договора;
– Проект Методики оценки заявок на
участие в процедурах закупки;
– Проекты Типовых форм
Комплекта документов о
проведении закупки;
– Проекты Типовых форм
договоров;
– Проекты Должностных
инструкций работников
подразделения, выполняющего
функции организатора закупки;
– Формирование требований к
Системе
– Спецификация требований
пользователя;
– Функционально-технические
решения;
– Описание программного
обеспечения;
– Пояснительная записка
технорабочего проекта;
– Инсталляционный комплект на
электронном носителе (CD/DVD);
– Инструкция по установке и
настройке
25
3
4
Проведение ОПЭ Системы:
– подготовка персонала Внешэкономбанка,
обеспечивающего эксплуатацию Системы;
– пусконаладочные работы:
o установка и настройка функциональных
подсистем;
o перенос существующих баз данных в базы
данных Системы;
o комплексная наладка всех средств и
подсистем Системы;
– проведение приемо-сдаточных испытаний;
– проведение опытной эксплуатации, доработка
по результатам опытной эксплуатации;
– обеспечение технической поддержки
пользователей, осуществляющих ОПЭ Системы.
Ввод Системы в промышленную эксплуатацию:
– тренинг всех пользователей Системы;
– проведение приёмочных испытаний.
– Программа-методика испытаний
Системы;
– Руководство пользователя в
разрезе функциональных
обязанностей сотрудников;
– Руководство администратора;
– Обучающие видеоролики;
– Протоколы по результатам
испытаний;
– Обновленный инсталляционный
комплект комплексно –
информационной Системы на
электронном носителе (CD/DVD)
– Сертификаты пользователей;
– Протоколы по результатам
испытаний.
Все документы, указанные в Таблице 1, предоставляются Заказчику в печатном
экземпляре в формате приложений Microsoft Office (Microsoft Word, Microsoft Excel и др.) и
на электронном носителе (CD/DVD).
Контроль и приемка работ по созданию Системы должна осуществляться в
соответствии с договорными документами, заключенными между Внешэкономбанком и
исполнителем.
26
5
Нормативные документы
Перечень нормативных документов, определяющих требования к Системе.
5.1
Нормативно-правовые акты
− Федеральный закон Российской Федерации от 18 июля 2011 г. № 223-ФЗ «О
закупках товаров, работ, услуг отдельными видами юридических лиц».
− Федеральный закон Российской Федерации от 17 мая 2007 года № 82-ФЗ «О банке
развития» .
− Федеральный закон Российской Федерации от 26 июля 2006 года № 135-ФЗ
«О защите конкуренции».
− Постановление Правительства РФ 29 декабря 2010 года № 1191 «Об утверждении
Положения о ведении реестра государственных и муниципальных контрактов, а
также гражданско-правовых договоров бюджетных учреждений на поставки
товаров, выполнение работ, оказание услуг».
− Бюджетный Кодекс Российской Федерации.
− Положение о закупках товаров, работ, услуг для нужд государственной
корпорации
«Банк
развития
и
внешнеэкономической
деятельности
(Внешэкономбанк)» от 09 февраля 2012 года № 62.
5.2
Нормативно-технические документы
− ГОСТ Р ИСО/МЭК 9126. Информационная технология. Оценка программной
продукции. Характеристики качества и руководства по их применению.
− ГОСТ 2.105-95. Единая система конструкторской документации. Общие
требования к текстовым документам.
− ГОСТ 19.503-79. Единая система программной документации. Руководство
системного программиста. Требования к содержанию и оформлению
− ГОСТ 28195-89. Оценка качества программных средств. Общие положения.
− ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании
автоматизированных систем.
− ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на
автоматизированные системы. Автоматизированные системы. Стадии создания.
− ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на
автоматизированные
системы.
Техническое
задание
на
создание
автоматизированной системы.
− ГОСТ 34.603-92. Виды испытаний автоматизированных систем.
− РД 50-34.698-90. Автоматизированные системы требования к содержанию
документов.
− ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на
автоматизированные системы. Автоматизированные системы. Термины и
определения.
− ГОСТ 19.101-77-82. Единая система программной документации. Виды программ
и программных документов.
− РД 50-680-88 Методические указания. Автоматизированные системы. Основные
положения.
− РД 50-682-89 Методические указания. Информационная технология. Комплекс
стандартов и руководящих документов на автоматизированные системы. Общие
положения.
27
− РД Автоматизированные системы. Защита от несанкционированного доступа к
информации. Классификация автоматизированных систем и требования по защите
информации.
− ГОСТ Р 50922-96 Защита информации. Термины и определения.
− ГОСТ Р 50739-95 Защита от несанкционированного доступа к информации.
− РД Концепция защиты средств вычислительной техники от несанкционированного
доступа к информации.
− РД Средства вычислительной техники. Защита от несанкционированного доступа
к информации. Показатели защищенности от несанкционированного доступа к
информации.
− РД Защита от несанкционированного доступа к информации. Термины и
определения.
− ПОТ Р М-016-2001 РД 153-34.0-03.150-00 Межотраслевые правила по охране
труда (правила безопасности) при эксплуатации электроустановок.
− СанПиН 2.2.4.1294-03. Гигиенические требования к аэроионному составу воздуха
производственных и общественных помещений.
− СанПиН 2.2.2/2.4.1340-03. Гигиенические требования к персональным электронновычислительным машинам и организации работы.
От Исполнителя:
От Заказчика:
______________
______________
______________
______________
____________________ ______________
____________________ ______________
28
Приложение 2
к Договору выполнения работ
№ _________________ от «_____» ____________ 201_ г.
Календарный план Работ и их стоимость
№
этапа
1
2
Наименование Работ
Анализ действующей внутренней
нормативной базы и бизнес-процесса
закупки, подготовка предложений по
их совершенствованию, разработка и
согласование проектов внутренних
нормативных
документов
Внешэкономбанка.
Формирование требований к Системе:
– организация работ по проекту;
– аудит сложившейся практики
организационно – закупочной
деятельности ВЭБ;
– определение стандартов закупок;
– описание моделей закупок при
применении стандартов с учетом
типичных и специфичных закупок ВЭБ;
– разработка нормативно-правовых
актов по работе с Системой на
основании 223-ФЗ;
– формирование требований к
функциональным и технологическим
подсистемам;
– формирование и утверждение
уточненного технического задания;
оформление отчета о выполненной
работе
Разработка технорабочего проекта и
ППО.
Разработка технорабочего проекта:
– разработка концептуальной
архитектуры Системы, определение
стратегий и требований к
конвертации данных, определение
стратегии, требований и сценариев
тестирования, определение стратегии
внедрения;
– разработка проектных решений по
созданию Системы и ее подсистем;
– разработка, оформление,
согласование и утверждение
документации в объёме,
необходимом для описания полной
совокупности принятых проектных
решений и достаточном для
дальнейшего выполнения работ по
созданию Системы;
– установка и настройка программных
средств разработки.
Стоимость
Работ,
с НДС
в руб.
Срок
окончания
этапа
____*
____**
Разрабатываемая
документация
– Проект Положения о
закупках;
– Проект Регламента
осуществления закупочной
деятельности;
– Проект Положения о
Комиссии по закупкам;
– Проект Методики расчета
начальной (максимальной)
цены договора;
– Проект Методики оценки
заявок на участие в
процедурах закупки;
– Проекты Типовых форм
Комплекта документов о
проведении закупки;
– Проекты Типовых форм
договоров;
– Проекты Должностных
инструкций работников
подразделения,
выполняющего функции
организатора закупки;
– Формирование требований к
Системе;
– Протокол выполнения Работ
по этапу 1
– Спецификация требований
пользователя;
– Функционально-технические
решения;
– Описание программного
обеспечения;
– Пояснительная записка
технорабочего проекта;
– Инсталляционный комплект
на электронном носителе
(CD/DVD);
– Инструкция по установке и
настройке;
– Протокол выполнения Работ
по этапу 2
29
3
4
Разработка ППО:
– разработка специализированных
программных модулей;
– разработка программных средств
переноса существующих баз данных
в базы данных Системы;
разработка, согласование и утверждение
рабочей документации.
Проведение ОПЭ Системы:
– подготовка персонала
Внешэкономбанка, обеспечивающего
эксплуатацию Системы;
– пусконаладочные работы:
o установка и настройка
функциональных подсистем;
o перенос существующих баз
данных в базы данных Системы;
o комплексная наладка всех
средств и подсистем Системы;
– проведение приемо-сдаточных
испытаний;
– проведение опытной эксплуатации,
доработка по результатам опытной
эксплуатации;
обеспечение технической поддержки
пользователей, осуществляющих ОПЭ
Системы.
Ввод Системы в промышленную
эксплуатацию:
– тренинг всех пользователей
Системы;
– проведение приёмочных испытаний.
Итого за Работы:
В том числе НДС (18%):
____**
– Программа-методика
испытаний Системы;
– Руководство пользователя в
разрезе функциональных
обязанностей сотрудников;
– Руководство администратора;
– Обучающие видеоролики;
– Протоколы по результатам
испытаний;
– Обновленный
инсталляционный комплект
комплексно –
информационной Системы на
электронном носителе
(CD/DVD);
– Протокол выполнения Работ
по этапу 3
____**
– Сертификаты пользователей;
– Протоколы по результатам
испытаний;
– Акт сдачи приемки Работ
* - с даты подписания Договора обеими Сторонами;
** - с даты окончания предыдущего этапа Работ.
Общая стоимость выполнения Работ составляет ______________ (______________)
рублей __ копеек, в том числе НДС (18%) – ______________ (______________) рублей __
копеек.
От Исполнителя:
От Заказчика:
______________
______________
______________
______________
____________________ ______________
____________________ ______________
30
Приложение 3
к Договору выполнения работ
№ _________________ от «_____» ____________ 201_ г.
Требования к разработке СТП
СОДЕРЖАНИЕ
СОДЕРЖАНИЕ .................................................................................................................................... 30
1. Введение............................................................................................................................................ 31
2. Цель документа ................................................................................................................................ 31
3.Соглашения по терминологии ......................................................................................................... 31
4. Структура СТП ................................................................................................................................. 33
Титульный лист и лист согласований ................................................................................................ 33
Раздел 1. Общие положения................................................................................................................ 34
1.1.
Наименование разработки................................................................................................... 34
1.2.
Основание для разработки .................................................................................................. 34
1.3.
Цели и задачи разработки.................................................................................................... 34
1.4.
Соглашения по терминологии ............................................................................................ 34
1.5.
Список используемых сокращений .................................................................................... 34
1.6.
Перечень нормативных документов................................................................................... 34
Раздел 2. Постановка задачи ............................................................................................................... 34
2.1.
Краткое описание банковского продукта или операции.................................................. 34
2.2.
Описание информационных объектов. .............................................................................. 34
2.3.
Модель данных на логическом уровне .............................................................................. 35
2.4.
Подразделения, участвующие в процессе выполнения операции................................... 35
2.5.
Пользователи (рабочие места) и их основные функции .................................................. 35
2.6.
Технологическая схема (ТС) операций.............................................................................. 36
2.7.
Детализация технологической схемы операций ............................................................... 37
2.8.
Требования к экранным формам......................................................................................... 38
2.9.
Описание выходной информации....................................................................................... 38
2.10.
«Требования по обеспечению доступности»..................................................................... 38
2.11.
«Требования по обеспечению мощности»......................................................................... 39
2.12.
«Требования по обеспечению непрерывности» ................................................................ 40
2.13.
Требования по обеспечению безопасности и аудиту ....................................................... 40
Раздел 3. «Предварительная оценка затрат на создание или изменение ИС»................................ 41
Раздел 4. Процедура функционального тестирования ..................................................................... 41
4.1.
Определение графика функционального тестирования ИС............................................. 41
4.2.
Определение параметров ИС. ............................................................................................. 41
4.3.
Определение источников данных....................................................................................... 41
4.4.
Проверка логики работы ИС. .............................................................................................. 41
Приложение 1. ...................................................................................................................................... 42
Лист согласований ............................................................................................................................... 43
31
1. Введение
Документ Стандарт на “Спецификации требований пользователя” (СТП) создается
для формализованного описания технологии совершения банковских операций с целью
обобщения
и
систематизации
требований,
предъявляемых
к
разрабатываемой
автоматизированной системе или ее части со стороны Заказчика (подразделения банка), а
также информация о требованиях доступности, непрерывности, мощности и безопасности
ИС.
Стандарт применяется при создании спецификаций требований пользователя в рамках
проектов автоматизации технологических процессов банка.
2. Цель документа
Основная цель данного документа определить и принять к исполнению такие
стандартные
соглашения,
соблюдение
которых
позволило
бы
готовить
документ
“Спецификации требований пользователя”, в котором:
1. В формализованном виде содержится вся необходимая информация о требованиях к
разрабатываемой системе или ее части, описанная языком, понятным как банковскому
специалисту, формулирующему задачу, так и проектировщику автоматизированной
системы.
2. Информация
является
исходной
для
стадии
проектирования
и
разработки
автоматизированной системы и представлена в необходимом для этого объеме.
3.Соглашения по терминологии
Банковский продукт – результат деятельности банка по предоставлению услуг
клиентам и банкам-контрагентам, выполнению агентских функций и обеспечению
деятельности самого банка. Банковский продукт всегда сопровождается либо юридическим
документом (договор, контракт, поручение, регламент), либо инструкцией, техническим
порядком или законом в области банковской деятельности.
Описание банковского продукта содержит необходимые характеристики услуги,
разрешенные операции, различные ограничения, накладываемые на операции в рамках
продукта, а также последовательность, условия и сроки выполнения различных операций,
требования по разграничению доступа к обрабатываемой/хранимой информации и
обеспечению ее безопасности.
32
Банковские продукты могут группироваться в Виды Банковских продуктов, которые
определяют множество продуктов, имеющих одинаковое целевое назначение и ряд схожих
характеристик и операций (Аккредитивы, Депозиты, Кредиты).
Банковская операция – завершенная последовательность действий, связанных с
созданием и реализацией банковского продукта. Операция характеризуется Регламентом
выполнения - полным набором условий, действий, документов и технологии их выполнения.
Действие – элементарная часть операции, которая всегда выполняется в одном
подразделении Банка конкретным исполнителем (на одном рабочем месте) и порождает
документ(ы) или их изменения. С точки зрения документооборота, в результате действия
возможно: формирование нового документа, дополнения к существующему документу,
коррекция
документа,
визирование,
подписание
и
т.п.
Действия
выделяются
по
функциональному признаку как приводящие к логически завершенному результату путем
выполнения
какой-либо
функции
(«ввод
документа»,
«контроль»,
«авторизация»,
«формирование проводки, сообщения»). Действия могут объединяться в этапы выполнения
операции, которые определяют функционально-законченные части операции.
Информационный объект – формализованное представление устойчивой группы
взаимосвязанных
данных,
над
которыми
совершаются
действия
(операции)
в
автоматизированной системе или ее части при реализации банковского продукта в рамках
решения рассматриваемой задачи.
События – значимые для выполнения банковских операций результаты внешних
процессов.
Условия выполнения определяют набор правил, регламентирующих возможность
выполнения операций, действий или направления передачи документа.
Пользователь – сотрудник Банка, выполняющий банковскую операцию или ее часть.
Используемые сокращения
ППО – прикладное программное обеспечение;
ДРИС ДОББ – Департамент разработки информационных систем Дирекции по обеспечению
банковской безопасности;
ИС – информационно-технологическая система. Информационно-технологическая система
представляет собой ППО, работающее на технологической платформе. Основными
характеристиками ИС являются функциональность, доступность, мощность, безопасность и
непрерывность;
СУН – стандартный уровень непрерывности;
СТП – спецификация требований пользователя;
ТС – технологическая схема.
33
4. Структура СТП
Спецификация требований пользователя, как документ, должен содержать следующие
части:
Титульный лист и лист согласований.
Содержательная часть.
Приложения.
Титульный лист и лист согласований
Формат титульного листа и листа согласований приведен в Приложении 1.
На титульном листе указывается название документа, номер его версии.
На листе согласования перед представлением документа на согласование и утверждение
должны быть заполнены следующие графы:
Название документа.
Имя файла, в котором хранится электронная копия документа.
Номер версии документа.
Исходному документу присваивается номер 1.0, где первая цифра до точки
означает номер версии, вторая - номер ее модификации. При внесении
незначительных изменений в документ наращивается на единицу номер
модификации
версии
документа
(например,
1.1).
При
внесении
существенных изменений в документ (например, при значительном
изменении технологии выполнения операции) увеличивается на единицу
номер самой версии документа (например, 2.0). В случае изменения номера
версии документа, предыдущая версия утрачивает силу.
Дата завершения разработки документа.
Подразделение-исполнитель документа
Ответственный разработчик
Исполнитель.
Указать должность, фамилию и инициалы лица, разработавшего документ.
Утверждено.
Согласовано.
Указать фамилии и инициалы начальников подразделений банка, с
которыми
происходит согласование
документа
и его утверждение.
Персональный состав лиц включаемых в данные разделы зависит от статуса
задачи.
История изменений документа.
34
Раздел 1. Общие положения
1.1.
Наименование разработки
Указывается полное наименование разработки.
1.2.
Основание для разработки
Указываются заявки на разработку ИС и документы, на основании которых была
составлена заявка на разработку (решение Руководства, нормативные документы и т.п.).
1.3.
Цели и задачи разработки
Формулируются цели, которые должны быть достигнуты в результате разработки с
указанием предполагаемого эффекта и определяются задачи, которые необходимо решить
для достижения поставленных целей.
1.4.
Соглашения по терминологии
Приводится список и разъяснения специфических банковских и информационных
терминов, используемых в СТП.
1.5.
Список используемых сокращений
Приводится список и расшифровка всех сокращений, используемых в СТП.
1.6.
Перечень нормативных документов
Приводится перечень нормативных документов с номерами и датами утверждения
(как внешних, так и внутренних), регламентирующих
выполнение операций в рамках
банковских продуктов.
Раздел 2. Постановка задачи
2.1.
Краткое описание банковского продукта или операции
Приводится краткое описание продукта или операции.
2.2.
Описание информационных объектов.
Приводится описание реквизитов информационных объектов в виде.
“Полное название” (“Сокращенное название”)
Назначение: ..........................
Описание реквизитов:
35
Полное
наименование
Информационны
й объект*
Тип*
Размер*
Способ
ввода и
Диапазон
Значений
Комментарий*
Внешнее
представление
(формат)
* “Информационный объект” - имя информационного объекта, к которому относится
данный
реквизит.
Для
реквизитов
вычисляемого
типа
необходимо
указать
соответствующие формулы (алгоритм).
* “Тип” - указывается один из типов представления значений реквизита: число (целое,
вещественное), строка, дата, массив и т.д.
* “Размер” - количество знаков для символьных и значащих цифр для целых данных
(без учета знака), для вещественных данных записывается число в следующем виде
М,n, где М- число значащих цифр, включая число знаков после десятичного
разделителя и с учетом знака, n - число цифр дробной части.
* “Способ ввода” – задается способ ввода необходимых значений- вручную, выбор
пользователем из справочника, автоматическое проставление из справочника или
автоматическое вычисление по уже введенным данным.
* “Комментарий” - необязательная характеристика реквизита, в которой указывается
дополнительная
информация;
если
необходимо
особо
отметить
внешнее
представление (формат реквизита при выводе на экран, принтер или во внешнее
сообщение), внешние источники информации, вопросы сопряжения с внешним ППО.
2.3.
Модель данных на логическом уровне
Для наглядности представления связей между информационными объектами может
быть приведена модель данных на логическом уровне. Пример возможного вида диаграммы
приведен в Приложении 2.
2.4.
Подразделения, участвующие в процессе выполнения операции
Приводится перечень подразделений, участвующих в выполнении операции, их зон
ответственности, в том числе указываются подразделения, использующие информацию или
результаты операции на просмотр.
2.5.
Пользователи (рабочие места) и их основные функции
Приводится перечень пользователей (ролей и подразделений), участвующих в
выполнении операции и описание их функций в рамках данной задачи.
1. Операционист («Клерк») Подразделение 1
•
Операция 1
36
•
Операция 2
3. «Контроллер» Подразделение 2
•
Операция 3
•
Операция 4
4. «Офицер» Подразделение 1
•
Операция 5
5. «Офицер» Подразделение 2
•
Операция 6
6. «Менеджер» Подразделение 1
•
Операция 7
•
Операция 8
7. «Менеджер» Подразделение 2
•
Операция 9
В данном пункте также приводится перечень операций по обслуживанию
пользователей ИС, выполняемых сотрудниками ДЭИС на регулярной основе или по
запросам пользователей (например, подключение/отключение пользователей, изменение
прав пользователей)
2.6.
Технологическая схема (ТС) операций.
ТС должна отражать:
•
этапы - действия, выполняемые пользователем и/или информационной системой при
обработке документов и/или информационных объектов;
•
последовательность выполнения этапов/действий;
•
условия переходов от одного этапа/действия к другому этапу/действию;
•
взаимодействие с внешними объектами, событиями (описание интерфейсов);
•
выходные
результаты
операции/этапов/действий
в
терминах
созданных
или
модифицированных документов и других информационных объектов.
При этом указываются документы, с которыми или на основании которых
выполняются указанные действия, перечень возможных состояний документов и хранилища,
в котором данные документы располагаются.
При необходимости может быть использовано несколько диаграмм различных уровней
детализации, отражающих этапы декомпозиции операции. ТС строится для каждой операции
и обязательно включает все этапы/действия первого уровня декомпозиции, на которые
разлагается операция.
37
Соглашения по используемым в диаграммах символам.
Приводятся условные обозначения всех используемых в диаграммах графических
символов и их расшифровка.
2.7.
Детализация технологической схемы операций
Автоматизируемые процессы, отмеченные на технологической схеме, должны быть
более детально описаны следующим образом:
Наименование этапа/действия.
Событие, инициирующее этап/действие.
Входные информационные объекты.
Приводится перечень входных информационных объектов, обрабатываемых в
операции.
Алгоритм.
Описывается
последовательность
действий,
выполняемых
пользователями
или
информационной системой для достижения результата операции, включая действия по
обеспечению защиты, целостности и достоверности информации (формирование/проверка
электронно-цифровой подписи (ЭЦП), закрытие (шифрование) данных и пр.).
Ограничения допустимости выполнения операции, например, по типам клиентов, для
которых допустимо выполнение операции, по видам используемых валют (например, только
рубли) и т.п. Критерии отбора (классификации информационных объектов), например, типы
клиентов, вид валюты, должны быть строго определены или указана ссылка на
соответствующий документ.
Бухгалтерские шаблоны операции.
Приводится перечень счетов (1-го и 2-го порядка, масок счета), используемых для
учета результатов выполнения операции в следующем виде:
Счет
Наименование счета
Примечание *
Заполнение поля “Примечание” является необязательным. Заполняется в случае, если
нет полной ясности из наименования счета или требуются специальные пояснения.
Приводится перечень всех бухгалтерских проводок (их макетов), порожденных в
данной операции.
Счет по
дебету
Счет по
кредиту
Содержание
проводки
(наименовани
е суммы)
Основание Операция/действие
38
Основание - документ, на основании которого осуществляется проводка.
В счете по Дебету и Кредиту необходимо указывать лицевые счета. Если указан счет 2го порядка или маска счета, необходимо описать правила определения или формирования
лицевых счетов.
2.8.
Требования к экранным формам
Приводится перечень экранных форм. Для каждой экранной формы приводится:
- ссылка на список этапов/действий, подлежащих реализации в экранной форме,
- в случае необходимости, список полей и правила их заполнения/обработки в
соответствии с алгоритмом этапа/действия с учетом требуемых ограничений по
доступу к информации,
- перечень вызываемых дочерних форм с указанием события, вызывающего такую
форму.
2.9.
Описание выходной информации
2.9.1. Выходные формы
Приводится перечень выходных форм. Для каждой выходной формы приводится:
- список элементов формы,
- алгоритм заполнения элементов формы,
- требования к макету выходной формы.
2.9.2. Выходные данные
Приводится перечень данных, которые должны быть переданы в электронном виде.
Для них определяется:
2.10.
-
структура и формат данных,
-
порядок формирования электронного файла,
-
порядок передачи данных и применяемые средства защиты.
Требования по обеспечению доступности
В данном разделе приводятся:
-
перечень критических бизнес функций;
-
определение недоступности для услуги в целом и для каждой критической бизнес
функции;
-
требования по параметрам доступности критических бизнес функций с
обоснованием их значений с учетом негативных последствий от недоступности;
-
время предоставления бизнес функции;
39
-
критические периоды в течение времени предоставления бизнес функции (при
необходимости);
-
время
запланированного
простоя
для
технического
обслуживания
(технологические перерывы);
-
время восстановления бизнес функции в случае потери доступности;
-
количество возможных случаев потери доступности за год с указанием негативных
последствий в зависимости от частоты случаев потери доступности;
-
суммарное время недоступности бизнес функции за год с указанием негативных
последствий в зависимости от продолжительности недоступности бизнес
функции;
-
уровень доступности бизнес функции за год, определяющийся как:
суммарное время предоставления – суммарное время
недоступности
суммарное время предоставления
-
х 100%
возможность использования альтернативных процедур для выполнения бизнес
функции.
Требования по обеспечению доступности приводятся для вновь создаваемой ИС, а так
же в случае если для действующей ИС пользователем выставляются новые требования. В
случае модернизации действующей ИС, при которой требования по обеспечению
доступности остаются неизменными, приводится фраза: «требования по обеспечению
доступности остаются неизменными и соответствуют документу №…».
2.11.
Требования по обеспечению мощности
В данном разделе приводятся:
-
обязательные требования по параметрам мощности ИС:
-
количество пользователей ИС (берется из соответствующей заявки на разработку);
-
предполагаемая скорость прироста пользователей (по умолчанию – 0% в год);
-
ограничение на продолжительность выполнения наиболее критических операций
(в случае отсутствия критических с точки зрения продолжительности операций
следует указать «требований к продолжительности выполнения операций не
выдвинуто»);
-
дополнительные требования по параметрам мощности, с учетом ее специфики,
например:
•
требования
к
объемам
и
срокам
хранения
предполагаемых темпов прироста информации;
информации
с
учетом
40
•
требования к количеству операций (выполняемых одновременно или за
период) с учетом прогнозируемых периодов интенсивного использования
функционала ИС. Требования могут быть выдвинуты по наиболее критичным
операциям, указаны в целом по ИС или в пересчете на одного пользователя.
Примеры:
количество
проводок
за
рабочий
день,
количество
подготавливаемых выходных форм (отчетов), количество обрабатываемых
заявок на модификацию НСИ);
•
требования по времени выполнения стандартных запросов на обслуживание
ИС (например, срок подключения нового клиента к услуге Банк-клиент).
-
обоснование значений параметров мощности с учетом негативных последствий от
их нарушения.
Требования по обеспечению мощности приводятся для вновь создаваемой ИС, а так же
в случае если для действующей ИС пользователем выставляются новые требования. В случае
модернизации действующей ИС, при которой требования по обеспечению мощности
остаются
неизменными,
приводится
фраза:
«требования
по
мощности
остаются
неизменными и соответствуют документу №…».
2.12.
Требования по обеспечению непрерывности
В данном разделе приводится соответствие ИС требованиям одного из СУН. Для ИС с
требованиями непрерывности, отличными от нулевого СУН приводится перечень работ по
обеспечению требований. Требования по обеспечению непрерывности приводятся для вновь
создаваемой ИС, а так же в случае если для действующей ИС пользователем выставляются
новые требования. В случае модернизации действующей ИС, при которой требования по
обеспечению непрерывности остаются неизменными, приводится фраза: «требования по
непрерывности остаются неизменными и соответствуют документу №…».
2.13.
Требования по обеспечению безопасности и аудиту
В данном разделе приводятся требования:
•
по идентификации и авторизации пользователей в прикладной задаче, т.е.
предоставление прав на вход (работу в системе) (например: парольная система
ORACLE, система с применением ТМ-идентификации, система разовых паролей
и т.п.);
•
по контролю достоверности информации, т.е. установление подлинности,
неизменности документов (например: наличие электронных подписей, наличие
системы двойного ввода (авторизации) информации, визуального сравнения с
бумажным носителем и т.п.);
41
•
требования к аудиту (например: протоколирование действий пользователя,
ведение журнала изменений и т.п.).
•
степень конфиденциальности обрабатываемой в рамках задачи и хранимой
информации и требования по разграничению прав доступа к ней со стороны как
подразделений, так и пользователей одного подразделения;
•
определение критической информации с точки зрение доступности и времени
реакции системы (времени обслуживания).
Раздел 3. Предварительная оценка затрат на создание или изменение ИС
В данном разделе приводится предварительная оценка денежных затрат при создании
или изменении ИС с помощью внешних поставщиков путем заключения соответствующего
договора или заказа на производство работ на создание или изменение ИС. Данная оценка
подготавливается сотрудниками ДОББ.
При выполнении работ собственными силами данный раздел не заполняется.
Раздел 4. Процедура функционального тестирования
4.1.
Определение графика функционального тестирования ИС.
Определяются контрольные моменты предъявления компонент
ИС
для
предварительного тестирования, а также готовой ИС для полного функционального
тестирования.
4.2.
Определение параметров ИС.
Указывается перечень и значения параметрических настроек ИС.
4.3.
Определение источников данных.
Указывается перечень наборов данных,
используемых
в
функциональном
тестировании. Указываются исходные данные и требуемые временные диапазоны
4.4.
Проверка логики работы ИС.
Описывается сценарий функционального тестирования, в котором указывается:
-
последовательность ввода данных п.4.3.
-
перечень контрольных точек (фрагмента) ИС и способы проверки алгоритмов и
выходных данных
В процессе проверки устанавливается соответствие интерфейсов макетам (описаниям)
экранных форм. Раздел по процедуре функционального тестирования может быть оформлен
в виде приложения к СТП.
42
Приложение 1
Подразделение – разработчик СТП
Автоматизированная информационная система
Внешэкономбанка
«Наименование разработки»
Спецификация требований пользователя
версия х.хх
г. Москва, YYYY г.
43
Лист согласований
Название:
Имя файла:
Версия:
Дата:
Подразделение:
Утвержда
ю
«Наименование разработки»
Должность
Начальник
подразделениязаказчика
Подпись
Ф.И.О.
Дата
Согласован
о
ОЗИ
ДОББ
СВК
Подраздел
ение заказчик
……
Исполнитель
Версия
Дата
История изменений
Причина изменений
От Исполнителя:
От Заказчика:
______________
______________
______________
______________
____________________ ______________
____________________ ______________
44
Приложение 4
к Договору выполнения работ
№ _________________ от «_____» ____________ 201_ г.
Требования к разработке ФТР
Содержание
Содержание ...................................................................................................................................... 44
1. Назначение документа ................................................................................................................ 45
2. Структура документа, требования к отдельным его элементам ............................................. 45
3. Титульный лист и лист согласований........................................................................................ 45
4. Содержательная часть ................................................................................................................. 45
4.1. Наименование ........................................................................................................................... 45
4.2 Основание для разработки........................................................................................................ 45
4.3. Соглашение по терминологии................................................................................................. 45
4.4. Список используемых сокращений ........................................................................................ 45
4.5. Функциональное наполнение .................................................................................................. 45
4.5.1. Модель данных ...................................................................................................................... 45
4.5.2. Функциональная модель ....................................................................................................... 46
4.5.3. Пользовательский интерфейс............................................................................................... 46
4.5.3.1. Общие требования .............................................................................................................. 46
4.5.3.2. Макеты экранных форм ..................................................................................................... 46
4.5.3.3. Макеты отчетов................................................................................................................... 47
4.5.3.4. Меню.................................................................................................................................... 47
4.6. Интерфейсы с внешними подсистемами................................................................................ 47
4.7. Решения по архитектуре технических и программных средств .......................................... 47
4.8. Реализация функций администрирования и сопровождения проектируемой (под)системы
........................................................................................................................................................... 48
4.9. Реализация требований по информационной безопасности и управлению доступом ...... 48
4.10. Реализация требований по обеспечению доступности ....................................................... 50
4.11. Реализация требований по обеспечению мощности ........................................................... 54
4.12. Реализация требований по обеспечению непрерывности .................................................. 54
4.13. Состав и содержание эксплуатационной документации .................................................... 54
4.14. Планирование разработки и внедрения............................................................................... 54
Приложение 1. Титульный лист..................................................................................................... 56
Приложение 2. Лист согласований ................................................................................................ 57
– 44 –
45
1. Назначение документа
Настоящий
Стандарт регламентирует
структуру и содержание
документа
“Функционально-технические решения” (ФТР), который создается ДОББ с целью
формализованного описания принятых решений по реализации требований пользователя к
задаче, зафиксированных в «Спецификации требований пользователя» (СТП).
2. Структура документа, требования к отдельным его элементам
Функционально-технические решения, как документ, должен содержать следующие
части:
Титульный лист и лист согласований.
Содержательная часть.
Приложения.
3. Титульный лист и лист согласований
Формы титульного листа и листа согласований представлены в Приложении к
документу.
4. Содержательная часть
4.1. Наименование
Должно соответствовать наименованию, указанному в соответствующей спецификации
требований пользователя.
4.2 Основание для разработки
Приводится ссылка на документ ”Спецификации требований пользователя” или
“Экспертное заключение” содержащие информацию, на основании которой проводилась
разработка данного документа.
4.3. Соглашение по терминологии
Приводится список и разъяснения специфических информационных терминов,
используемых в документе.
4.4. Список используемых сокращений
Приводится список и расшифровка всех сокращений, используемых в документе.
4.5. Функциональное наполнение
4.5.1. Модель данных
Приводится перечень создаваемых и/или модифицируемых объектов баз данных,
реализующих логическую модель информационных объектов, описанных в СТП, и фрагмент
диаграммы их взаимных связей и связей с существующими объектами.
Приводится
техническое
описание
создаваемых
и/или
модифицируемых
информационных объектов с указанием их структуры, размера, форматов, диапазонов
допустимых значений. Устанавливается соответствие физической и логической моделей
представления данных, описываются реализация механизмов поддержания логической
целостности и непротиворечивости данных.
Здесь и далее: «соответствие» предлагается устанавливать в табличной форме,
например:
Таблица (поля)
Информационный объект в
проектируемой
Комментарий
СТП
(под)системы
– 45 –
46
4.5.2. Функциональная модель
Приводится диаграмма 1 последовательности вызова функций 2 (под)системы в привязке
к описанной в СТП технологической схеме.
Приводятся миниспецификации создаваемых (модифицируемых) функций (процедур)
ƒ событие(я), инициирующее выполнение функции (процедуры)
ƒ условия выполнения функции (процедуры)
ƒ входные данные (описание переменных, используемых при вызове функции
(процедуры) и/или перечень атрибутов информационных объектов физической
модели)
ƒ блок-схема и/или описания алгоритмов расчета и агрегирования данных,
приведенных в СТП
ƒ выходные данные (описание переменных, возвращаемые функцией
(процедурой) и/или перечень атрибутов информационных объектов
физической модели, значения которых изменяются в ходе выполнения
функции (процедуры))
ƒ событие(я), генерируемое функцией (процедуры), уведомляющее иные
функции (процедуры) о своем успешном/неуспешном завершении или этапах
прохождения, а также нарушениях установленных правил разграничения
доступа.
4.5.3. Пользовательский интерфейс
4.5.3.1. Общие требования
Описываются решения по реализации пользовательского интерфейса:
ƒ режим отображения информации (текстовый, эмулятор терминала,
графический; многооконность);
ƒ вид представления информации (текст, таблицы, графики, диаграммы и т.д.);
ƒ средства активизации функциональных процедур (организация меню и
использование функциональных клавиш);
ƒ организация представления справочной информации;
ƒ использование специальных технических средств для ввода/вывода
информации пользователем (сканер, плоттер, носители информации, средства
аутентификации и т.д.);
ƒ требуемое разрешение монитора.
При наличии утвержденного Стандарта на пользовательский интерфейс делается
ссылка на этот документ. При необходимости описываются специфические особенности и
предполагаемые отличия от Стандарта с обоснованием необходимости введения этих
отличий.
Приводится описание структуры диалога, включающее в последовательность вызовов
экранных форм, меню и отчетов.
4.5.3.2. Макеты экранных форм
Приводится перечень и описание макетов экранных форм (ЭФ), включающее список
экранных блоков с описанием полей (тип, длина, наличие справочника, обязательность,
диапазон значений и процедуры проверки корректности) и перечнем функций, вызываемых
по нажатию функциональных клавиш.. Для каждой экранной формы указываются ее
назначение, параметры запуска и возвращаемые значения. Окончательный вид ЭФ
приводится в «Руководстве пользователя».
1
2
формат диаграммы и средства ведения определяются ДИТ.
здесь: функции, реализующие соответствующий этап/действие технологической схемы СТП
47
Устанавливается соответствие описаний ЭФ СТП и программной реализации с
указанием особенностей отбора и отображения набора экземпляров информационных
объектов и доступных действий над ними в различных режимах работы экранной формы.
4.5.3.3. Макеты отчетов 3 .
Приводится перечень отчетов.
Для каждого отчета приводятся параметры запуска, а также точки и способ запуска
отчета в ЭФ.
4.5.3.4. Меню
Приводится перечень пунктов меню (под)системы.
Для каждого пункта меню указываются назначаемые роли, определяющие полномочия
по запуску.
Описываются точки входа в (под)систему из действующего меню АИС ВЭБ или
информационных подсистем.
4.6. Интерфейсы с внешними подсистемами
Приводится перечень ПО (информационных систем), с которым предполагается
взаимодействие проектируемой (под)системы, способы обмена данными. Приводится
описание проектируемых алгоритмов импорта/экспорта и используемых функций
разработчика (API)с указанием применяемых механизмов и средств контроля целостности и
достоверности данных.
4.7. Решения по архитектуре технических и программных средств
Приводятся решения по программно-аппаратной платформе, на базе которых
реализуется поставленная задача:
ƒ общая структура (состав и взаимодействие) основных аппаратных
компонентов системы (серверы, сетевое оборудование, АРМ), с указанием
существующих компонентов инфраструктуры, новых компонентов, а также
существующих компонентов, требующих модернизации
ƒ детальный состав аппаратного и программного обеспечения основных
компонентов системы:
o специфические средства ввода и представления информации;
o операционная система;
o СУБД;
o конфигурация и настройки;
o механизмы и средства защиты;
ƒ детальное описание взаимодействия компонентов:
o протоколы передачи данных;
o потоки данных;
o правила взаимодействия;
ƒ услуги внешних поставщиков, необходимые для обеспечения работы и
обслуживания ИС;
ƒ системы обеспечения функционирования ИС (электропитание, охлаждение,
площадь);
ƒ инструментальные средства разработки.
3
выходные формы в СТП
48
Решения по технической архитектуре приводятся для вновь создаваемой ИС, а так же в
случае если для действующей ИС пользователем выставляются новые требования по
доступности, мощности и изменяется техническая архитектура. В случае модернизации
действующей ИС, при которой требования по обеспечению доступности и техническая
архитектура остаются неизменными, приводится фраза: «требования по обеспечению
доступности, мощности, непрерывности, безопасности и техническая архитектура остаются
неизменными и соответствуют документу №…».
4.8. Реализация функций администрирования и сопровождения проектируемой
(под)системы
В этом разделе приводятся описания спроектированных процедур выполнения штатных
операций, необходимых для обслуживания ИС, их трудоемкости и необходимых ресурсы, в
части:
ƒ обслуживания пользователей ИС, выполняемые на регулярной основе или по
запросу пользователей;
ƒ обслуживания ППО и технологической платформы в целях обеспечения их
работоспособности;
ƒ сопровождения договоров с внешними поставщиками, необходимых для
обслуживания ИС;
ƒ мониторинга, контроля функционирования, предоставления информации о
состоянии и характеристиках ИС;
Приводится перечень договоров с внешними поставщиками, необходимых для
обеспечения работы и обслуживания ИС, которые должны быть подготовлены и согласованы
в ходе разработки ИС.
Приводятся описания средств администрирования и поддержания работоспособного
состояния проектируемой (под)системы:
ƒ Перечень
управляющих
параметров
(под)системы,
подлежащих
периодическому изменению во время эксплуатации, описание их воздействия
на работу системы, допустимые значения. Технические решения по
реализации на прикладном уровне средств установки управляющих
параметров, описание АРМ администратора проектируемой (под)системы (в
случае отличия от действующих решений ).
ƒ Технические решения по реализации средств администрирования
пользователей. Описание АРМ администратора пользователей проектируемой
(под)системы (в случае отличия от действующих решений).
ƒ Технические решения по реализации средств создания рабочих мест
пользователей. Указывается, требуется ли разработка специальных средств по
установке и обновлению клиентского программного обеспечения для
разрабатываемой (под)системы или используются стандартные или ранее
разработанные средства с указанием их наименования.
4.9. Реализация требований по информационной безопасности и управлению
доступом
В разделе описывается реализация требований по информационной безопасности и
управлению доступом в соответствии с требованиями СТП.
49
Приводится описание реализации системы авторизации пользователей в прикладной
задаче (системе). Описываются средства, с помощью которых проводится авторизация
(стандартные средства операционной системы, стандартные средства базы данных, какаялибо система аутентификации, и т.п.) Указывается место проведения авторизации в
прикладной задаче. Указываются данные пользователя, влияющие на правила разграничения
доступа, которые становятся достоверно известны после проведения авторизации (ФИО,
наименование (под)системы/АРМа, Референс, др.). Если авторизация осуществляется
прикладным процессом, то приводится описание процесса как части проектируемой
подсистемы методами и средствами, определенными настоящим документом;
Приводится описание реализации системы разграничения доступа. Описываются
средства реализации (firewall, стандартные средства операционной системы, стандартные
средства базы данных, и т.п.). При описании реализации функций указываются все факты
взаимодействия с системой разграничения доступа. Если разграничение доступа
осуществляется прикладным процессом, то приводится описание процесса как части
проектируемой подсистемы методами и средствами, определенными настоящим
документом;
Формулируются настройки системы разграничения доступа пользователей к
документам (информационным объектам) и операциям (функциям). Настройки приводятся
для каждой роли отдельно.
Приводится описание реализации и настройки используемых средств системы защиты
от НСД - программно-аппаратных средств защиты от НСД, криптографических систем
защиты информации, других специальных средств и организационных мероприятий или
ссылки на действующие решения;
Приводится описание реализации и настройки системы контроля целостности. Исходя
из СТП, определяются объекты4, подвергаемые контролю, и указываются средства, с
помощью которых проводится контроль;
В случае создания системы аудита действий пользователей на уровне прикладного ПО,
приводится описание ее реализации и настроек. Описываются средства аудита (средства
операционной системы сервера, стандартные средства базы данных, внешняя подсистема, и
т.п.). Указываются события, подвергаемые аудиту, структура записи в журнале аудита, место
хранения и режим доступа к журналу аудита.
4
исполняемые модули, конфигурационные файлы, объекты СУБД - процедуры, описания таблиц,
представления, триггеры
50
4.10. Реализация требований по обеспечению доступности
4.10.1 Обеспечение требований по регламенту предоставления доступа
В случае наличия СТП приводится ссылка на соответствующий раздел и пункт СТП
или дополнения к СТП, в соответствии с которым разрабатывается ФТР. Вывод констатация факта соблюдения регламента, изложенного в СТП и дополнениях к СТП.
В случае отсутствия СТП приводится развернутый регламент предоставления доступа
на основании разработанного в ФТР решения. В этом случае ФТР должен содержать
согласующую подпись заказчика на листе согласования.
4.10.2 Обеспечение требований по уровням поддержки
В случае наличия СТП приводится ссылка на соответствующий раздел и пункт СТП
или дополнения к СТП, в соответствии с которым разрабатывается ФТР. Вывод констатация факта соблюдения требований по уровням поддержки, изложенных в СТП и
дополнениях к СТП.
В случае отсутствия СТП приводится развернутое описание уровней поддержки на
основании разработанного в ФТР решения. В этом случае ФТР должен содержать
согласующую подпись заказчика на листе согласования.
4.10.3 Обеспечение требований по восстановлению при глобальных отказах
4.10.3.1 Перечень требований по восстановлению при глобальных отказах
В случае наличия СТП приводится ссылка на соответствующий раздел и пункт СТП
или дополнения к СТП, в соответствии с которым разрабатывается ФТР.
4.10.3.2 Перечень критических компонент
Заполняется в виде таблицы:
№
1
2
Наименование компоненты системы
Программный/аппаратный
В таблицу заносятся компоненты системы, отказ которых приводит к глобальному
отказу. Наименование компоненты должно дословно совпадать с ее наименование в разделе,
описывающем архитектуру системы.
4.10.3.3 Резервирование критических компонент
4.10.3.3.1. Программные компоненты и данные
Заполняется в виде таблицы:
№
1
Наименова Периодичность
ние
компонент
ы системы
Метод
Оценка Оценка
объема времени
данных копирова
в ГБ
ния на
МЛ в
мин.
ежедневно,
полная
конкретный
день копия,
недели, конкретный инкрементал
день
месяца,
с ьная копия
периодичностью Х
часов,
по
отдельным заявкам
и т.п.
2
– 50 –
Оценка
времени
восстанов
ления с
МЛ в мин.
Необходи Необходим
мость
ость
создания
копирован
«быстрой» ия БД без
копии на
остановки*
дисках*
*
+/+/-
51
* Создание «быстрой» копии на дисках (технология Snapshot) используется в случае,
если есть жесткие ограничения на доступное для выполнения операции время и прямое
копирование на МЛ не возможно. После создания копии исходные данные доступны для
работы пользователей, а запись на МЛ производится с этой копии. Данная опция доступна
только при использовании внешних дисковых массивов корпоративного уровня.
** Копирование БД без остановки используется для создания резервных копий в
системах, работающих в режиме 24*7 (например, Процессинговый центр), и подразумевает
также необходимость создания «быстрой» копии на дисках. Для использования данной
опции разработчик ППО должен разработать скрипты для перевода БД в режим «Backup» и
обратно в рабочий режим.
Рекомендации.
Для резервирования основных БД обычно создается ежедневная полная копия с
созданием «быстрой» копии на дисках и последующей записью на МЛ.
Для резервирования файловой системы – инкрементальная копия по рабочим дням и
полная в выходной.
Для резервирования файлов ППО - полная копия по отдельным заявкам при изменении
ППО и/или полная 1 раз в месяц/квартал.
ВНИМАНИЕ! В соответствии с документами, определяющими порядок выполнения
резервного копирования («Описание системы централизованного резервного копирования
данных» №75/Е40004 от 12.01.2012, «Порядок учета, использования, хранения
и
уничтожения технологических магнитных лент» №6027/Е40004 от 09.11.2011), срок
хранения резервных копий на МЛ составляет 6 месяцев.
4.10.3.3.2. Аппаратные компоненты:
Заполняется в виде таблицы
№
Наименование
компоненты
системы
Наличие
резерва
(да/нет)
Тип резерва
Оценка времени, необходимого для подготовки
резерва к работе (без учета времени, необходимого
для восстановления данных из резервной копии)
1
2
Рекомендации.
В графу «Тип резерва» заносится информация о способе резервирования (холодный/
кластер и т.п.) и резервирующей аппаратной компоненте.
4.10.3.4 Процедуры восстановления после глобальных отказов
Заполняется в виде таблицы
№ Наименование компоненты
системы
1
2
Описание процедуры восстановления
Оценка времени
восстановления
Рекомендации.
В случае если процедура восстановления сводится к восстановлению компонент из
резерва, графа «Описание процедуры восстановления» может содержать ссылки на таблицы
раздела 2.3.3.
Время восстановления должно включать время на поиск неисправности.
4.10.3.5 Процедура локализации инцидентов
Заполняется в виде таблицы.
52
В таблицу в обязательном порядке должны быть включены описания глобальных
отказов в порядке убывания вероятности возможных причин. В случае необходимости после
описания глобальных отказов в таблицу могут включаться описания типовых инцидентов, не
приводящих к глобальным отказам.
Категория: ______________________________
____________________________________
Внешние проявления (признаки) группы
инцидентов:
ПРИЗНАК
ПРИЧИНА
Краткое
Возможные
Категоризаци
наименование
причины
признака
я (ИСПП)
инцидента
(ИСПП)
Тип
<Описание внешних проявлений инцидентов, которые может сообщить пользователь
по телефону в СПП>
НАЗНАЧЕНИЕ
ДЕЙСТВИЯ
Обязательства
Глобальны
Группа
Действия по обработке
Ответствен
по времени
й отказ
назначения
обработки,
инцидента
ный
(да/нет)
(ИСПП)
(рабочие часы)
Категория 1
1
Причина
инцидента 1
Тип 1
2
Элемент 1
На
именование 1
Категория 2
1
Причина
инцидента 2
Тип 2
2
Элемент 2
2
Внешние проявления (признаки) группы
инцидентов:
ПРИЗНАК
Краткое
наименование
признака
(ИСПП)
ПРИЧИНА
Категоризаци
я (ИСПП)
Возможные
причины
инцидента
Категория 1
Наименование
2
Тип 1
Категория 1
<Описание внешних проявлений инцидентов, которые может сообщить пользователь
по телефону в СПП>
НАЗНАЧЕНИЕ
Группа
назначения
(ИСПП)
Глобальный
отказ
(да/нет)
ДЕЙСТВИЯ
Обязательства
по времени
обработки,
(рабочие часы)
Действия по обработке
инцидента
1
Причина
инцидента 1
2
3
В случае наличия документа, регламентирующего сроки и процедуру устранения
отказа какого-либо вида, в таблице в графе «Действия» допускается ссылка на этот
документ. В противном случае процедура описывается или, в случае описания глобального
отказа, приводится ссылка на таблицу из 4.10.4.
53
4.10.3.6 Вывод о соблюдении требований по восстановлению при глобальных
отказах.
В разделе должны быть сформулированы следующие выводы:
• Все критические компоненты услуги, выход из строя которых может повлечь
глобальный отказ, выявлены (п. 4.10.2.).
• Для всех критических компонент разработаны процедуры восстановления в случае
отказа (п. 4.10.4.).
• Для всех компонент, включая критические, описаны процедуры локализации
неисправностей (4.10.5.)
• Максимальное время восстановления функциональности услуги после выхода из
строя любой одной из критических компонент не превышает сроки, указанные в
СТП или в настоящем документе (п. 4.10.1.).
54
4.11. Реализация требований по обеспечению мощности
В этом разделе приводится описание технических решений по реализации требований
по обеспечению мощности ИС, выдвинутых в СТП. Описание технических решений должно
включать:
• перечень компонентов ИС (описанных в разделе 4.7), критических с точки зрения
параметров мощности;
• параметры мощности каждого из указанных в перечне компонентов ИС;
• параметры мощности услуг внешних поставщиков, необходимых для обеспечения
работы и обслуживания ИС (пропускная способность каналов передачи данных,
скорость и объемы поставки оборудования и расходных материалов, потребляемых
в рамках использования ИС);
• параметры систем обеспечения функционирования (электропитание, охлаждение,
площадь);
• оценка трудоемкости выполнения операций по обслуживанию пользователей;
• требования к квалификации сотрудников ИТ-подразделений, выполняющих
операции по обслуживанию пользователей;
• решения по мониторингу и сбору информации о мощностных характеристиках ИС и
ее компонентов;
• обоснование соответствия требованиям мощности ИС, выдвинутым в СТП.
4.12. Реализация требований по обеспечению непрерывности
В данном разделе приводится соответствие ИС требованиям одного из СУН. Для ИС с
требованиями непрерывности, отличными от нулевого СУН приводится перечень работ по
обеспечению требований.
4.13. Состав и содержание эксплуатационной документации
Раздел должен содержать перечень эксплуатационной документации, разрабатываемой
на этапе создания ППО, включая Руководства Пользователя и Администратора.
4.14. Планирование разработки и внедрения
В данном разделе приводятся перечень и порядок работ по разработке (план
разработки) и внедрения (план внедрения) ИС с указанием подразделений исполнителей, или
же сроки подготовки плана внедрения и плана разработки и ответственных за их подготовку.
План разработки должен
содержать информацию о cроках и ответственных
исполнителях работ по разработке и тестированию:
• ППО и технологические платформ;
• договоров с внешними поставщиками, необходимых для обеспечения работы и
обслуживания ИС;
• процедур выполнения штатных операций, необходимых для обеспечения работы
обслуживания ИС;
• процедур решения стандартных инцидентов (устранения глобальных отказов) ИС;
• регламентов функционирования ИС;
• процедур внесения изменений в промышленную среду и возврата к исходному
состоянию.
План внедрения должен
содержать информацию о cроках и ответственных
исполнителях следующих мероприятий:
• разработка и выполнение процедуры внесения изменений в промышленную среду и
процедуры возврата к исходному состоянию;
• создание комиссии по проведению независимого тестирования и программыметодики испытаний;
– 54 –
55
создание и реализация программы обучения пользователей и сотрудников
функциональных ИТ-подразделений, участвующих в использовании и эксплуатации
ИС;
• заключение договоров с внешними поставщиками, необходимых необходимые для
обеспечения работы и обслуживания ИС;
• изменение каталога штатных операций;
• пополнение базы стандартных решений инцидентов;
• подготовка акта о запуске ИС в промышленную эксплуатацию;
• утверждение регламента функционирования ИС при необходимости.
При определении сроков и ответственных исполнителей перечисленных выше
мероприятий необходимо учитывать следующие требования:
• Процедура внесения изменений в промышленную среду должна содержать
информацию о возможной недоступности ИС в ходе ее выполнения и меры по
снижению негативного влияния недоступности ИС на деятельность Банка и сроки
выполнения работ. Процедура возврата к исходному состоянию должна содержать
критерии ее инициации. Ответственным за подготовку указанных процедур
является ответственный исполнитель. Ответственным за исполнение указанных
процедур при внесении изменений в промышленную среду является администратор
внедрения из числа сотрудников ДЭИС.
• Ответственным за создание комиссии по проведению независимого тестирования и
программы-методики испытаний является исполнитель из числа сотрудников
ДЭИС. Программа-методика испытания должна определять сроки и ответственных
за выполнение работ, объемы, методы и среду тестирования.
• Ответственным за подготовку программы обучения является ответственный
исполнитель. Программа обучения должна определять сроки и ответственных за
выполнение работ, объем обучения.
• Ответственным за заключение договоров с внешними поставщиками является
ответственный исполнитель.
• Ответственным за внесение изменений в каталог штатных операций и пополнение
базы данных стандартных решений инцидентов является администратор ИТ-услуги;
• Ответственным за подготовку акта о запуске ИС в промышленную эксплуатацию
является сотрудник ДЭИС, отвечающий за организацию внедрения. Акт готовится
по факту завершения внедрения и подтверждает соответствие ИС требованиям
заявки.
• Проект приказа об утверждении регламента функционирования ИС должен быть
направлен на согласование в течение месяца с момента утверждения акта о запуске
ИС в промышленную эксплуатацию.
•
56
Приложение 1. Титульный лист
Функционально-технические решения
Подразделение – разработчик ФТР
«Наименование разработки»
г. Москва, 201_ г.
57
Приложение 2. Лист согласований
Название:
Имя файла:
Версия:
Дата:
Подразделение:
«Наименование разработки»
Должность
Ф.И.О.
Подпись
Дата
Утверждаю
Согласовано
Исполнитель
История изменений
Версия
Дата
Причина изменений
От Исполнителя:
От Заказчика:
______________
______________
______________
______________
____________________ ______________
____________________ ______________
Документ
Категория
Типовые договоры
Просмотров
95
Размер файла
1 064 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа