Техническое задание для поставщиков. Приложение №2 к Закупочной документации



страница5/14
Дата24.04.2016
Размер0.9 Mb.
1   2   3   4   5   6   7   8   9   ...   14

Клиентская часть


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

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

  3. Система должна предоставлять web-интерфейс, полностью дублирующий возможности «толстого» клиента и обеспечивающий доступ ко всем функциям (как минимум, пользовательским) и модулям, входящих в состав Системы. Функции администрирования могут быть реализованы с использованием «толстого» клиента; предпочтение, однако, при прочих равных, будет отдано решению с полнофункциональным «тонким» клиентом.

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

  5. Язык интерфейса системы – русский.

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

  7. Клиентская часть должна обладать возможностью работы через web-proxy.

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

  9. Программное обеспечение для клиентских рабочих мест пользователей:



    Вид ПО

    Программный продукт

    Версия

    1

    ОС

    Microsoft Windows

    XP/Vista/Seven/2003 Server/2008 Server

    2

    ОС

    Linux

    Red Hat 4.x и выше

    3

    Web-браузер

    Microsoft Internet Explorer

    6.0 и выше

    4

    Web-браузер

    Mozilla FireFox

    2.0 и выше
  • Управление экранными формами и представлениями


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

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

    3. Система должна предоставлять гибкие возможности настройки представлений: фильтры, подсветки, связанные с типом представления атрибуты (например, набор полей) и пр.

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

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

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

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


    1. Решение должно предоставлять гибкие возможности по созданию новых объектов, новых полей объектов и установке связей между объектами Системы (инцидентом, запросом на изменение, заданием и др.).

    2. Всем новым экземплярам объектов Системы должен присваиваться уникальный ID.

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

    4. Новые поля объектов должны включаться в полнотекстовый индекс для последующего использования при полнотекстовом поиске.

    5. Должно быть обеспечено отсутствие ограничений при задании обязательных полей и условий обязательности.

    6. Должно быть обеспечено отсутствие ограничений при установке условий доступности полей.

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

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

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

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

    11. Должна быть реализована возможность связывания вложенных файлов и текста в единую смысловую канву (например, посредством использования полей html формата).

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

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

    14. Решение должно предоставлять максимально гибкие возможности по управлению жизненным циклом объектов Системы, связанным с изменением значения поля «Статус». Система должна предоставить инструмент для определения:

    • правил перехода между статусами,

    • условий контроля при входе и выходе со статуса,

    • необходимых действий при переходе между статусами,

    • прав на выполнение перехода между статусами.

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

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

    • управления связями между объектами, в т.ч. установления двунаправленных связей, связей «один к одному», «один ко многим», «многие ко многим».

    • хранения в существующем объекте ссылок на другие объекты,

    • возможности фильтрации объектов, на которые выполняется ссылка,

    • построения иерархий объектов,

    • контроля поддержания целостности связей.

        1. Решение должно предоставлять гибкие возможности по изменению и расширению модели данных Системы: созданию любых новых типов объектов, определения их полей, связей, прав и других настроек. Предложение должно содержать описание механизма реализации этих возможностей и ограничений, связанных с его применением.

        2. Решение должно предоставлять возможность групповой обработки объектов (одновременное изменение атрибутов объектов, например, закрытие нескольких инцидентов) как вручную, так и автоматически по преднастроенной логике.

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

        4. Полный перечень подлежащих настройке объектов и их атрибутов, в т.ч. связей между ними, должен быть сформирован и согласован с Заказчиком при проектировании Системы.
  • 1   2   3   4   5   6   7   8   9   ...   14


    База данных защищена авторским правом ©bezogr.ru 2016
    обратиться к администрации

        Главная страница