Тендерная документация по закупке оборудования, программного обеспечения и услуг информационных технологий (тендер №3)

Вид материалаДокументы

Содержание


Лот №15 Услуги по разработке почтового on-line сервиса
Назначение и цели создания Системы
Развитие казахстанского сегмента Интернета. Внедрение конкурентоспособного на внутреннем и внешнем рынках интернет продукта.
Структура комплекса средств автоматизации
Требования к способам и средствам информационного обмена с Системой
Требования к способам и средствам связи для информационного обмена между компонентами Системы
Требования к численности и квалификации персонала и режиму его работы
Требования к приспособляемости (к изменению условий эксплуатации), масштабируемости Системы
Влияние изменения количества услуг и приложений
Влияние изменения требований к системе безопасности
Требования к надежности
Требования к надежности технических средств и программного обеспечения
Требования к обеспечению информационной безопасности
Общие требования
Компонент контроля защищённости.
Разделение доступа
Управление доступом пользователей к Системе
Состав и содержание работ по созданию Портала Общие требования к проведению работ Порядок выполнения работ по созданию Системы
Подобный материал:
1   ...   12   13   14   15   16   17   18   19   20

Лот №15 Услуги по разработке почтового on-line сервиса


Участник тендера должен представить предложение на оказание услуг по разработке системы почтового on-line сервиса.


Сроки оказания услуг – до 31 декабря 2010 г. Начало оказание услуг с момента получения Уведомления о признинии тендерной заявки выигравшей .


Участник тендера должен предоставить не менее 3-х вариантов разработанных технических решений, 3-х вариантов дизайн-концепта системы почтового on-line сервиса, а так же опытную инсталляцию сервиса.


Участник тендера должен подтвердить объем оказанных услуг за 2009 г., в объеме не менее 40 млн. тенге (договора, акты выполненных работ, оригинал, либо нотариально заверенная копия).


Участник тендера должен подтвердить опыт создания промышленных web систем для крупных национальных компаний, с численностью центрального аппарата не менее 300 человек и сетью филиалов в 16 городах Республики Казахстан (оригинал, либо нотариально заверенная копия подтверждающих писем от Заказчиков, актов выполненных работ).


Назначение и цели создания Системы


Назначение Системы

Основное назначение системы – почтовый on-line сервис.

Цели и задачи создания Системы

К целям создания относятся

Развитие в доменной зоне .KZ почтового on-line сервиса.

Основными задачами, обеспечивающими достижение цели, являются:
  • Развитие казахстанского сегмента Интернета. Внедрение конкурентоспособного на внутреннем и внешнем рынках интернет продукта.
  • Увеличение доли внутреннего трафика, посредством возврата пользователей с зарубежных аналогов
  • Продвижение посредством портала, услуг АО «Казахтелеком»


Требования к Системе

Требования к Системе в целом

Общими требованиями являются:

  • Сервис должен содержать необходимый объем информации и механизм своевременной актуализация содержания.
  • Данный сервис должен иметь возможность быстрой интеграции с любым порталом АО «Казахтелеком».
  • Структура представления информационных ресурсов и пользовательские интерфейсы по доступу к ресурсам и сервисам должны быть интуитивно понятны широкому кругу пользователей сети Интернет.
  • Предоставляемые услуги и сервисы должны иметь очевидную ценность для пользователей сервиса.
  • Инфраструктура сервиса должна обеспечивать совместную работу групп ее сопровождения.
  • Инфраструктура сервиса должна в максимальной степени интегрировать существующий у Заказчика программно-аппаратный комплекс, кроме тех особых случаев, когда это не представляется возможным из-за архитектурных особенностей создаваемого сервиса.


Основными принципами создания сервиса должны быть:
  • использование широко известного и зарекомендовавшего себя программного и аппаратного обеспечения;
  • использование общепризнанных и широко используемых стандартов структурирования информации и описания сервисов XML и WSDL;
  • высокая степень масштабирования программных и аппаратных средств;
  • использование эффективных методов защиты от несанкционированного доступа к информационным ресурсам.


Требования к структуре и функционированию Системы

Система должна быть реализована в составе следующих функциональных комплексов задач (подсистем):
  • Подсистема: почтовый on-line сервис.

Структура комплекса средств автоматизации

Участник тендера должен предоставить предложение по организации почтового on-line сервиса с описанием функций программного и аппаратного обеспечения.


Количественный состав серверов, входящих в КСА, зависит от количества пользователей портала и интенсивности их обращений к приложениям и документам.

Окончательный состав серверов и АРМ должен быть определен на стадии «Технический проект» и уточнен по результатам опытной эксплуатации Системы.


Требования к способам и средствам информационного обмена с Системой

Система должна использовать коммуникационную среду Интернет для информационного обмена с внешними пользователями, информационными источниками и автоматизированными информационными системами.

Средством организации информационного обмена со стороны пользователя должно являться программное обеспечение, обеспечивающее просмотр HTML-страниц, созданных в соответствии с рекомендациями консорциума W3C и соответствующих спецификации HTML 4.01.

Указанное программное обеспечение должно поддерживать передачу данных по протоколу HTTP версии 1.1.

В Системе должны быть реализованы средства конвертирования данных из форматов обменных файлов в унифицированные форматы представления данных пользователю.

В качестве стандарта идентификации и описания данных для интеграции приложений возможно использование языка XML.

Состав информации, получаемой от внешних автоматизированных систем и внешних информационных источников, должен быть определен после разработки протоколов двустороннего информационного обмена с организациями — владельцами систем и источников.


Требования к способам и средствам связи для информационного обмена между компонентами Системы


Для обеспечения информационного обмена, компоненты Системы должны работать в составе единой вычислительной сети, построенной по технологии Интернет/интранет.

В качестве основного средства связи между компонентами Системы должна быть использована локальная вычислительная сеть, построенная по технологии Ethernet (конкретная реализация технологии должна быть определена на стадии проектирования).

Должна быть предусмотрена возможность работы функционально законченных компонентов Системы в разных удаленных локальных вычислительных сетях, и коммуникации через сеть интернет.

В качестве базового протокола сетевого и межсетевого взаимодействия должен использоваться TCP/IP.

Для сетей на базе Ethernet должна быть предусмотрена возможность резервирования.


Требования к численности и квалификации персонала и режиму его работы

Для поддержки функционирования Системы, Исполнителем должна быть создана Служба эксплуатации, персонал которой должен обладать знаниями в области информационных и сетевых платформ, на которых будет реализована Система, опытом редакционного наполнения содержимого Системы, а также опытом администрирования баз данных.

В состав персонала, необходимого для обеспечения эксплуатации комплекса средств автоматизации (КСА) Системы, должны входить:
  • администраторы Системы – выделенный персонал, в обязанности которого входит выполнение специальных технологических функций;
  • эксплуатационный персонал - специалисты, обеспечивающие функционирование технических и программных средств, обслуживание и обеспечение рабочих мест пользователей.

Требования к составу, должностным обязанностям, режиму и технологиям работы Службы эксплуатации должны быть определены на стадии «Рабочая документация».


Требования к приспособляемости (к изменению условий эксплуатации), масштабируемости Системы


Требования к приспособляемости Системы заключаются в обеспечении возможности ее работоспособности в следующих случаях:
  • при изменении количества пользователей сервиса;
  • при изменении количества услуг и приложений;
  • при изменении требований к системе безопасности.


Влияние изменения количества пользователей сервиса


Изменение количества пользователей сервиса оказывает основное влияние на нагрузочную способность аппаратного и программного обеспечения Системы. Увеличение нагрузочной способности может выполняться как за счет увеличения мощности аппаратного комплекса, так и за счет увеличения их количества. При этом необходимо соблюдать следующие требования:
  • система должна адаптироваться к увеличению нагрузочной способности без необходимости изменения архитектуры или установки дополнительного программного обеспечения;
  • добавление новых серверов не должно приводить к полной остановке функционирования Системы.


Влияние изменения количества услуг и приложений


Изменение количества услуг и приложений оказывает основное влияние на нагрузочную способность серверов баз данных, а также фронтальных серверов Системы. Увеличение нагрузочной способности может выполняться как за счет увеличения мощности серверов, так и за счет увеличения их количества путем объединения в кластеры. Увеличение нагрузочной способности фронтальных серверов может выполняться как за счет увеличения мощности, так и за счет увеличения их количества. При этом необходимо соблюдать следующие требования:
  • Система должна адаптироваться к увеличению нагрузочной способности без необходимости изменения архитектуры или установки дополнительного программного обеспечения;
  • добавление новых серверов не должно приводить к полной остановке функционирования Системы.


Влияние изменения требований к системе безопасности


Изменение требований к системе безопасности может оказывать влияние на все составные части Системы. Система должна адаптироваться в соответствии с изменяющимися требованиями с соблюдением следующих условий:
  • в процессе адаптации защищенность не должна становиться хуже существующей на момент начала адаптации;
  • процесс адаптации не должен прерывать доступ пользователей к сервису;
  • процесс адаптации не должен прерывать процесс подготовки и публикации документов;
  • процесс адаптации не должен затрагивать тех пользователей, на которых не распространяются новые требования.


Требования к надежности

Перечень аварийных ситуаций

Ниже приводится перечень возможных аварийных ситуаций с указанием требований к средствам восстановления работоспособности Системы.

  1. Сбой программного обеспечения КСА (отдельного АРМ или сервера).

После сбоя серверной операционной системы или СУБД в процессе выполнения пользовательских задач должно быть обеспечено восстановление данных в базе данных до состояния на момент окончания последней нормально завершенной перед сбоем транзакции.

Время восстановления работоспособности при сбоях и отказах не должно превышать 6-ти часов. В это время не входит разворачивание и настройка специального программного обеспечения на сервере(ах). В указанное время не входит решение проблем с техническим обеспечением и инсталляция операционной системы. Описание процедур восстановления Системы должно содержаться в Регламенте восстановления Системы.

  1. Выход из строя части технических средств КСА.

Выход из строя одного из АРМ или нарушение канала связи локальной сети между АРМ и сервером не должны приводить к прекращению функционирования КСА, при этом должна обеспечиваться возможность выполнения функций, связанных с вышедшим из строя АРМ на другом АРМ.
  1. Сбои или выход из строя активного накопителя на жестком магнитном диске.

КСА должен обеспечивать возможность «горячей» замены сбойного или вышедшего из строя активного накопителя на жестком магнитном диске без остановки функционирования КСА и потерь информации.

В КСА должна быть обеспечена возможность восстановления данных с внешнего накопителя после восстановления активного накопителя.

  1. Импульсные помехи, сбои или прекращение электропитания.

Импульсные помехи, сбои или прекращение электропитания не должны приводить к выходу из строя технических средств КСА и/или нарушению целостности данных.

Прекращение электропитания на время до 15 минут не должно приводить к прекращению функционирования КСА.


Требования к надежности технических средств и программного обеспечения


Надежность КСА в части технического обеспечения должна обеспечиваться:
  • использованием технических средств повышенной отказоустойчивости и их структурным резервированием;
  • наличием на объектах автоматизации запасных изделий и приборов (ЗИП);
  • защитой технических средств по электропитанию путем использования источников бесперебойного питания;
  • дублированием носителей информационных массивов.


Требования по эргономике и технической эстетике


Дизайн Системы должен удовлетворять следующим требованиям по эргономике и технической эстетике:
  • быть достаточно «легким» по объему графических элементов и обеспечивать как можно большую скорость загрузки страниц сервиса;
  • обеспечивать легкую идентификацию раздела сервиса, в котором находится пользователь;
  • обеспечивать минимум усилий и временных затрат пользователя для навигации по страницам сервиса;
  • обладать развитой системой поиска информации, посредством контекстного поиска;
  • корректно отображаться при всех возможных разрешениях и количестве одновременно отображаемых цветов монитора;
  • сохранять идентичность отображения на большинстве современных ОС и web-браузерах;
  • обладать системой подсказок в местах, где у пользователя потенциально могут возникнуть затруднения;
  • обеспечивать приемлемый результат при распечатке страниц пользователей сервиса на принтере;
  • корректно отображать информацию на компьютерах без предустановленных флэш-модулей, с отключенной поддержкой скриптов и пр.;
  • предусматривать возможность поддержки мультиязычного контента.


Требования к обеспечению информационной безопасности


Участник тендера должен предоставить предложение и описание по обеспечению информационной безопасности пользователей сервиса.

Общие требования


Общие требования к Системе включают:
  • применяемые в Системе средства и технологии защиты, объединяемые в Систему защиты информации (СЗИ) должны обеспечивать открытость архитектуры и обладать свойствами модульности, масштабируемости и возможности адаптации к различным организационным и техническим условиям;
  • СЗИ должна удовлетворять требованиям проводимой Заказчиком технической политики и строиться на основе ограниченного числа типов и версий приобретаемого программного обеспечения, а также типов и конфигураций аппаратно-программных средств защиты;
  • СЗИ должна обеспечивать необходимую и достаточную защиту ресурсов Системы от характерных угроз безопасности, определенных с учетом объективных факторов и анализа возможных моделей нарушителей;
  • СЗИ должна предполагать независимость функционирования каждой из входящих в ее состав структурных подсистем защиты. Нарушение функционирования любой подсистемы защиты не должно приводить к нарушению функционирования других подсистем защиты;
  • средства защиты, входящие в состав СЗИ, должны иметь развитые средства регистрации критических системных событий в электронных журналах и средства оперативного оповещения об этих событиях администраторов безопасности;
  • для эффективной эксплуатации и сопровождения СЗИ должен быть предусмотрен комплекс организационно-технических мер и разработаны необходимые организационно-распорядительные документы.


Требования к структуре и функциям подсистем СЗИ


Для обеспечения требований к безопасности структура СЗИ должна включать:
  • подсистему защиты информации от НСД;
  • подсистему активного аудита;
  • средства антивирусной защиты и защиты от СПАМа.



  1. Подсистема защиты информации от НСД должна включать следующие функциональные элементы:
  • средства управления доступом и идентификации;
  • средства контроля, управления и идентификации при удаленном доступе
  • средства экранирования.



  1. Подсистема активного аудита должна включать следующие компоненты:
  • компонент обнаружения вторжений;
  • компонент контроля защищённости.



  1. Средства антивирусной защиты должна включать компоненты, обеспечивающие:
  • антивирусную защиту рабочих станций (АРМов);
  • антивирусную защиту серверов, включая серверы приложений Системы


Подсистема защиты информации от НСД

Подсистема защиты информации от НСД должна предусматривать:
  • защиту ресурсов Системы от НСД со стороны внешних телекоммуникационных сетей – сети Интернет;
  • регистрацию системных событий и попыток НСД к защищаемым ресурсам штатными и дополнительными средствами.


Подсистема защиты информации от НСД должна интегрировать:
  • штатные средства защиты от НСД сетевых операционных систем;
  • штатные средства защиты от НСД систем управления базами данных;
  • штатные средства защиты от НСД используемых приложений;
  • штатные аппаратно-программные комплексы защиты от НСД АРМов авторизуемых пользователей (администраторов, редакторов);
  • средства защиты от НСД серверов;
  • средства защиты от НСД межсетевых экранов, маршрутизаторов и другого коммуникационного оборудования.

Средства контроля, управления и идентификации при доступе к Системе должны обеспечивать процедуры идентификации пользователей, контроля подключения и управления их доступом к Системе.


Подсистема активного аудита

Подсистема активного аудита должна включать:
  • компонент обнаружения вторжений;
  • компонент контроля защищённости.
  1. Компонент обнаружения вторжений.

Компонент обнаружения вторжений должен обеспечивать выявление в реальном масштабе времени информационных атак, проводимых злоумышленниками или нарушителями, на защищаемые ресурсы Системы


Компонент обнаружения вторжений должен выполнять следующие функции:
  • выявление информационных атак;
  • автоматическое блокирование информационных атак до их фактической реализации;
  • формирование рекомендаций по устранению обнаруженной информационной атаки;
  • мониторинг трафика, циркулирующего в Системе на сетевом, транспортном и прикладном уровнях модели взаимодействия открытых систем;
  • оповещение администратора безопасности об обнаруженных событиях, нарушающих политику безопасности Системы.


Модуль генерации отчётов должен обеспечивать создание отчётов по результатам работы компонента обнаружения вторжений на основе содержимого информационного фонда, включающих в себя:
  • сведения об обнаруженной атаке;
  • информацию об объекте атаки;
  • информацию об источнике атаке;
  • тип метода реагирования, применённого по отношению к обнаруженной атаке;
  • полное или частичное содержимое пакетов данных, на основе которых был сделан вывод о факте реализации атаки;



  1. Компонент контроля защищённости.

Компонент контроля защищенности должен обеспечивать проведение анализа защищённости ресурсов Системы посредством моделирования информационных атак и анализа уязвимостей защищаемых ресурсов. Помимо функций анализа защищённости компонент должен позволять проводить инвентаризацию состава ресурсов тестируемой Системы


Разделение доступа


Система должна обеспечивать защиту от несанкционированного доступа и изменения содержимого портала стандартными средствами используемого web-сервера и операционной системы.

Аутентификация для работы с разделами Системы должна производиться по персональным именам пользователя и паролю. Каждому пользователю может быть предоставлено право на совершение определенных действий с теми или иными типами документов и функциональными блоками подсистемы:
  • просмотр элементов;
  • добавление элементов;
  • редактирование элементов;
  • удаление элементов;
  • визирование элементов;
  • редактирование прав доступа к разделу.

По умолчанию все действия во всех модулях для вновь создаваемых пользователей запрещены. Каждое из вышеуказанных действий может быть по отдельности разрешено или запрещено для определенного пользователя для каждого из разделов (функциональных блоков) подсистемы.

В Системе должна существовать возможность входа под главной административной учетной записью, которая предоставляет право на совершение любых предусмотренных функционалом действий в любых разделах подсистемы.


Управление доступом пользователей к Системе


Для управления доступом пользователей к ресурсам администратор Системы должен иметь возможность выполнять следующие действия:
  • просматривать список пользователей Системы;
  • добавлять и удалять учетные записи пользователей;
  • блокировать учетную запись пользователя без удаления ее из базы данных;
  • назначать роли пользователям;
  • просматривать журнал действий авторизованных пользователей.


Требования к функциям Системы

Почта


Услуга бесплатной электронной почты с ограниченным хостингом до 100 МБ (необходимо предусмотреть механизм возможности расширения).
  • Адресная книга – позволяет пользователю добавлять, удалять и править контактную информацию адресатов.
  • Отправка сообщений – позволяет пользователю создавать и отправлять (перенаправлять или отвечать на) письма.
  • Черновик (периодическое сохранение сообщения) – позволяет пользователю путем нажатия соответствующей кнопки или с периодом в определенное время, заданное в настройках сохранять новое сообщение с возможностью последующего редактирования.
  • Выплывающий список контактов при отправке сообщения – предоставляет пользователю список контактов удовлетворяющим введенным символам в строке адресата-получателя, что облегчает и ускоряет процесс отправки сообщений.
  • Оформление писем – дает возможность оформлять письма в виде HTML.
  • Прием сообщений – дает возможность пользователю, получать сообщения.
  • Сортировка сообщений – позволяет пользователю сортировать сообщения по: дате, теме, отправителю и другим критериям.
  • Поиск сообщений – позволяет пользователю осуществлять поиск по различным параметрам сообщения (тема, отправитель, тело сообщения и т.д.).
  • Уведомления о поступлении сообщений (на страничках других сервисов) – дает возможность пользователю получать уведомления в окне браузера в момент получения нового сообщения.
  • Drag & Drop – дает возможность пользователю «перебрасывать» сообщения с одной папки в другую путем захвата определенного сообщения (зажав левую кнопку мышки на сообщением) и выброса ее в нужную папку (отпустив левую кнопку мыши над требуемой папкой).
  • Вложение файлов – позволяет пользователю отправлять и получать сообщения с прикрепленными к ним файлами не превышающими определенный размер в МБ (задается администратором).
  • Спам-фильтр – фильтрует трафик, отправляя в папку СПАМ, или блокируя подозрительные сообщения.
  • Пометки (прочитанное, избранное) – Позволяет пользователю помечать или убирать пометку с сообщений в папке как прочитанное или избранное. Избранные сообщения помечаются особым знаком (например, звездочкой), тем самым обозначаю ее важность.
  • Архивирование – позволяет отправлять старые сообщения в папку архив
  • Функция раскрывающихся папок – позволяет создавать неограниченное количество подпапок.
  • Предложить email друзьям – отсылает специально оформленное сообщения-приглашения на почтовый адрес, введенный пользователем.
  • Использованный объем – дает возможность пользователю видеть количество свободного места оставшегося на почтовом ящике.
  • Личный календарь – позволяет пользователю планировать, вести заметки, добавлять встречи и другую информацию используя удобный интерфейс
  • Нить, тред (позднее) – автоматически группирует сообщения с одинаковой парой получатель-отправитель и темой в «цепь».
  • Личные настройки – дает возможность пользователю редактировать отображение, интерфейс и правила поведения почтового ящика.

Состав и содержание работ по созданию Портала

Общие требования к проведению работ

Порядок выполнения работ по созданию Системы

Участник тендера должен предоставить календарный план график создания проектного решения, включающий в себя план работ, с подробной детализацией, декомпозицией задач, параллелизацией работ и трудозатратами.

Примечание * - опытный участок для Системы предназначен для проведения апробации разработанных решений по Системе на площадке Заказчика и отработки функционирования Системы. Его создание является необходимым условием для проведения в дальнейшем испытаний, оговоренных в данном документе. Конфигурация опытного участка в общем случае представляет собой от одного до двух рабочих (клиентских) мест на территории Заказчика и выделенное место на сервере для установки серверной части Системы. Также в состав опытного участка входит часть программно-технического комплекса Системы, установленного на территории Исполнителя в виде трёх рабочих мест и одного сервера с программной конфигурацией, идентичной конфигурации сервера портала Заказчика, предназначенного для апробирования и сопровождения проектных решений полнофункциональной версии проекта. Эксплуатация опытного участка осуществляется совместно силами Исполнителя (1-2 специалиста) и Заказчика (1-3 специалиста, прошедшими предварительную подготовку у Исполнителя и имеющих базовые навыки работы с Системой. Опытный участок прекращает свое существование в момент приемки Заказчиком Системы в промышленную эксплуатацию. После этого рабочие места опытного участка становятся штатными рабочими местами Системы.