Подсистема хранения и поиска документов

Общие положения
Полное наименование системы и ее условное
обозначение
Полное наименование системы: Официальный портал Администрации г. Новокузнецка
Краткое наименование: портал Admnkz
Источники и порядок финансирования
Источником финансирования является бюджет Новокузнецкого городского округа.
Порядок финансирования определяется условиями контракта.
Порядок оформления и предъявления заказчику
результатов по созданию системы
Система передается в виде функционирующих компонентов и приложений на базе
средств вычислительной техники Заказчика и Исполнителя в сроки, установленные
контрактом. Приемка системы осуществляется комиссией в составе уполномоченных
представителей Заказчика и Исполнителя.
Порядок предъявления системы, ее испытаний и окончательной приемки определен в п.6
настоящего ТЗ. Совместно с предъявлением системы производится сдача разработанного
Исполнителем комплекта документации согласно п.8 настоящего ТЗ.
Перечень нормативно-технических документов,
методических материалов, использованных при
разработке ТЗ
При разработке автоматизированной системы и создании проектно-эксплуатационной
документации Исполнитель должен руководствоваться требованиями следующих
нормативных документов:
ГОСТ 19.201-78. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И
ОФОРМЛЕНИЮ;
ГОСТ
34.601-90.
Комплекс
стандартов
Автоматизированные системы. Стадии создания;
на
автоматизированные
системы.
ГОСТ
34.201-89.
Информационная
технология.
Комплекс
стандартов
на
автоматизированные системы. Виды, комплексность и обозначение документов при
создании автоматизированных систем;
РД 50-34.698-90. Методические указания. Информационная технология. Комплекс
стандартов на автоматизированные системы. Автоматизированные системы. Требования к
содержанию документов.
Определения, обозначения и сокращения
1. Портал — web-приложение, позволяющее объединять другие web-приложения
(отвечающие стандарту JSR-286) в рамках одного сайта.
2. CMS — система управления содержанием
3. Артефакт — объект, созданный любым компонентом системы. Например, пользователь,
документ, папка, журнал, категория, организация.
4. Проект — мероприятие, имеющее начало и завершение.
5. СМИ — средства массовой информации.
6. ОРД — организационно- распорядительный документооборот.
7. НСИ — нормативно-справочная информация.
8. GUI — графический интерфейс пользователя.
9. СПО — свободное программное обеспечение.
Назначение и цели создания системы
Назначение системы
Портал Admnkz предназначен для комплексного информационно-аналитического
обеспечения процессов Администрации г. Новокузнецка, в части исполнения следующих
процессов:
1. Создание, согласование и публикация различных документов, и для всеобщего, и для
корпоративного ознакомления
2. Поддерживать актуальную информацию о структуре и составе всех подразделений
Администрации с публикацией актуальных контактных данных для всеобщего и для
корпоративного ознакомления.
3. Обеспечивать оперативную обратную связь с жителями города по актуальным вопросам
и проблемам.
4. Интегрировать в систему любое количество веб-приложений, обеспечивающих работу
конкретных подразделений в зависимости от задач каждого подразделения.
5. Взаимодействовать с АИС других муниципальных и федеральных организаций,
используя стандартные протоколы взаимодействия.
Цели создания системы
Основными целями создания портала Admnkz являются:
Замещение существующей информационной системы, которая не предоставляет
возможность комплексного информационно-аналитического обеспечения процессов,
перечисленных выше;
Повышение эффективности исполнения процессов, перечисленных выше, путем
сокращения непроизводительных и дублирующих операций, операций, выполняемых
«вручную», оптимизации информационного взаимодействие участников процессов.
Повышение качества принятия управленческих решений за счет оперативности
представления, полноты, достоверности и удобства форматов отображения информации;
Повышение информационной открытости и прозрачности деятельности Администрации
города и её подразделений, повышение удобства и комфорта (снижение финансовых и
временных затрат) физических и юридических лиц при получении информации о
деятельности Администрации, и её услугах.
Характеристика объекта автоматизации
Объектом автоматизации являются следующие
эффективности выполнения указанных процессов:
процессы,
а
также
контроль
1. Организационно — распорядительный документооборот с последующей публикацией
документа на общедоступной и/или корпоративной части сайта, а также отслеживание
публикации в бумажных средствах массовой информации.
2. Поддержка и публикация актуальной информации об оргструктуре и контактных
данных Администрации и её подразделений.
3. Приём и прохождение всех видов обращений граждан, включая электронные,
бумажные и устные.
4. Организация online-обсуждения проектов нормативных документов с целью учёта
мнений жителей города.
Данные процессы осуществляются следующими специалистами:
сотрудниками всех подразделений Администрации;
сотрудниками отдела кадров;
сотрудниками отдела делопроизводства;
сотрудниками отдела писем и обращений;
Перечень подсистем их назначение и
основные характеристики
В портал Admnkz должны входить следующие подсистемы:


















подсистема хранения и поиска документов;
подсистема проектов;
подсистема управления нормативно-справочной информацией;
подсистема хранения и проверки сертификатов ЭЦП;
движок бизнес-процессов;
подсистема приложений документооборота;
подсистема прохождения обращений;
подсистема формирования оргструктуры и контактных данных;
подсистема контроля и исполнения поручений;
подсистема публикации в СМИ;
подсистема совместной работы;
подсистема «корпоративный мессенджер»
клиентское рабочее место;
подсистема интеграции;
подсистема организации и проведения обсуждений в электронной форме;
подсистема формирования отчетности;
подсистема приёма граждан;
подсистема публикации медиа-данных;
Система должна состоять из следующих компонентов:
1. Microsoft Active Directory для идентификации корпоративных пользователей с
помощью протокола LDAP.
2. Сервер приложений JEE, предпочтительно JBoss 7.1 или выше.
3. Портал класса Enterprise с поддержкой портлетов JSR-168 и JSR-286, предпочтительно
Liferay версии 6.1 или выше. Версия должна быть самой новой на момент окончания
работ по разработке системы.
4. Платформа для документооборота Alfresco версии 4.0 или выше. Версия должна быть
самой новой на момент окончания работ по разработке системы.
5. JDBC-совместимая СУБД класса Enterprise
Требования к способам и средствам связи
для информационного обмена между
компонентами системы
Входящие в состав портала Admnkz подсистемы в процессе функционирования должны
обмениваться информацией на основе открытых форматов обмена данными, используя
для этого:







движок бизнес-процессов,
стандартный сервис сообщений (JMS),
web-сервисы;
WebDAV;
JSON;
вызовы EJB;
Persistence units в стандарте JPA 2.0
Требования к интеграции компонентов
Портал должен поддерживать разнообразные источники аутентификации пользователей:
1. Корпоративные пользователи, принадлежащие к Администрации г. Новокузнецка,
проходят аутентификацию через Microsoft Active Directory.
2. Корпоративные пользователи, принадлежащие к другим муниципальным или
федеральным организациям, проходят аутентификацию:


или через встроенную систему хранения пользователей портала,
или через корпоративные системы аутентификации своей организации по
протоколам LDAP или NTLM.
3. Некорпоративные пользователи проходят аутентификацию через встроенную систему
хранения пользователей портала.
При аутентификации пользователей все компоненты должны:



или пользоваться системой аутентификации портала,
или использовать собственную систему аутентификации. В этом случае компонент
должен автоматически синхронизировать свою базу пользователей с базой
пользователей портала, и регистрировать свой источник аутентификации в общей
системе аутентификации портала.
поддерживать стандарт JAAS
Все компоненты и подсистемы обязательно должны быть оформлены в виде портлетов,
сконфигурированных для встраивания в конкретный портал. Портлеты должны
поддерживать взаимодействие через Public render parameters и/или events.
Все компоненты и подсистемы должны поддерживать поиск в стандарте OpenSearch и
интегрироваться в поисковую систему портала тоже с помощью OpenSearch.
Все артефакты, созданные в подсистемах, должны регистрироваться в системе
публикации портала. Каждый артефакт может быть связан с одним или несколькими
проектами.
При разграничении прав доступа все компоненты должны:


или использовать систему разграничения прав доступа, встроенную в портал,
или синхронизировать собственную систему разграничения прав доступа с
общепортальной системой. В этом случае синхронизация должна быть
двухсторонней. Права доступа, назначенные конкретному артефакту через портал,
должны автоматически копироваться в собственную систему компонента. И
наоборот, если права доступа назначены в собственной системе компонента, они
должны автоматически копироваться в систему прав доступа портала.
Если компонент поддерживает назначение категорий и меток для артефактов, то при этом
должны использоваться:

или категории и метки портала

или собственная система категорий и меток компонента. В этом случае
собственный перечень категорий и меток должен автоматически привязываться к
портальному перечню категорий и меток.
Требования к отображению информации
При отображении информации внешний вид должен гибко настраиваться одним из
следующих способов:



используя обработчики шаблонов Freemarker, Velocity или XSLT.
используя настройки, сохранённые во внешних файлах в формате XML;
используя графический интерфейс пользователя.
Предпочтительным способом является использование обработчиков шаблонов.
Портлеты должны поддерживать фильтры при отображении информации. Фильтры могут
задаваться:



в параметрах конфигурации портлета
в параметрах URL
в PRP (public render parameter)
Требования к форматам данных
ЭЦП хранится в виде отсоединённой подписи в формате CMS (RFC 3852 «Cryptographic
Message Syntax) или RFC 5126 "CMS Advanced Electronic Signatures (CadES)".
Графические изображения хранятся в формате JPEG с максимальными размерами 720x576
px.
Медиа-данные принимаются и хранятся в формате H.264 (видео) + AAC (аудио) в
контейнере FLV. Максимальный размер 480x384 px. На стороне клиента следует
отображать медиа-данные в виде:
1. HTML5 video с кодеками: H.264 + AAC с контейнером FLV. Это предпочтительный
вариант, поскольку можно не делать перекодировку на серверной стороне.
2. Если указанные кодеки не поддерживаются, отображать как HTML5 video с кодеком
Theora
+
Vorbis
и
контейнером
OGG
3. Если не поддерживается HTML5 video, отображать через Flash player с кодеками: H.264
+
AAC
с
контейнером
FLV.
4. Если не поддерживается HTML5 video и кодеки H.264 + AAC, отображать через Flash
player с кодеками: Theora + Vorbis с контейнером OGG.
Требования к режимам
функционирования системы
Для портала Admnkz определены следующие режимы функционирования:


Нормальный режим функционирования;
Аварийный режим функционирования.
Основным режимом функционирования портала является нормальный режим. В
нормальном режиме функционирования системы:



серверное программное обеспечение и технические средства северов обеспечивают
возможность круглосуточного функционирования, с перерывами на обслуживание
не более 2 часов;
исправно работает оборудование, составляющее комплекс технических средств;
исправно функционирует системное, базовое и прикладное программное
обеспечение системы.
Для обеспечения нормального режима функционирования системы необходимо
выполнять требования и выдерживать условия эксплуатации программного обеспечения и
комплекса технических средств системы, указанные в соответствующих технических
документах (техническая документация, инструкции по эксплуатации и т.д.).
Аварийный режим функционирования системы характеризуется отказом одного или
нескольких компонент программного и (или) технического обеспечения. В случае
перехода системы в предаварийный режим необходимо:





завершить работу всех приложений, с сохранением данных;
выключить рабочие станции операторов;
выключить все периферийные устройства;
выполнить резервное копирование БД.
после этого необходимо выполнить комплекс мероприятий по устранению
причины перехода системы в аварийный режим.
Требования по диагностированию
системы
Портал Admnkz (или сервер приложений) должен предоставлять инструменты
диагностирования основных процессов системы, трассировки и мониторинга процесса
выполнения программы.
Компоненты должны предоставлять удобный интерфейс для возможности просмотра
диагностических событий, мониторинга процесса выполнения программ.
При возникновении аварийных ситуаций, либо ошибок в программном обеспечении,
диагностические инструменты должны позволять сохранять полный набор информации,
необходимой разработчику для идентификации проблемы (логи, текущее состояние
памяти, файловой системы).
Перспективы развития модернизации
системы
Портал Admnkz должен реализовывать возможность дальнейшей модернизации как
программного обеспечения, так комплекса технических средств. Портал должен
подключать в себя веб-приложения, соответствующие стандартам JSR-286.
Также необходимо предусмотреть возможность увеличения производительности системы
путем её масштабирования и кластеризации.
Показатели назначения
Портал Admnkz должен обеспечивать возможность исторического хранения данных с
глубиной не менее 3 лет.
Система должна обеспечивать возможность одновременной работы не менее 100
пользователей для просмотра и поиска информации на сайте, и не менее 30-ти
пользователей для других подсистем при следующих характеристиках времени отклика
системы:


для операций навигации по экранным формам системы – не более 3 сек;
для операций добавления и редактирования документов – не более 1 сек.
Контрольный документ: в формате MS Word, размер — 5Мб, открываем по
локальной сети.
Время формирования аналитических отчетов определяется их сложностью и может
занимать продолжительное время.
Система должна предусматривать возможность масштабирования по производительности
и объему обрабатываемой информации без модификации ее программного обеспечения
путем модернизации используемого комплекса технических средств. Возможности
масштабирования должны обеспечиваться средствами используемого базового
программного обеспечения (сервером баз данных и сервером приложений).
Требования к надежности
Система должна сохранять работоспособность и обеспечивать восстановление своих
функций при возникновении следующих внештатных ситуаций:



при сбоях в системе электроснабжения аппаратной части, приводящих к
перезагрузке ОС, восстановление программы должно происходить после
перезапуска ОС и запуска сервера баз данных и сервера приложений;
при ошибках в работе аппаратных средств (кроме носителей данных и программ)
восстановление функции системы возлагается на ОС;
при ошибках, связанных с программным обеспечением (ОС и драйверы устройств),
восстановление работоспособности возлагается на ОС.
Требования к эргономике и технической
эстетике
Взаимодействие пользователей с прикладным программным обеспечением, входящим в
состав системы должно осуществляться посредством визуального графического
интерфейса (GUI) через web-browser. Интерфейс системы должен быть понятным и
удобным, не должен быть перегружен графическими элементами и должен обеспечивать
быстрое отображение экранных форм. Навигационные элементы должны быть выполнены
в удобной для пользователя форме. Средства редактирования информации должны
удовлетворять принятым соглашениям в части использования функциональных клавиш,
режимов работы, поиска, использования оконной системы. Ввод-вывод данных системы,
прием управляющих команд и отображение результатов их исполнения должны
выполняться в интерактивном режиме. Интерфейс должен соответствовать современным
эргономическим требованиям и обеспечивать удобный доступ к основным функциям и
операциям
системы.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора
типа «мышь», то есть управление системой должно осуществляться с помощью набора
экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен
используется главным образом при заполнении и/или редактировании текстовых и
числовых
полей
экранных
форм.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме
системных
сообщений)
должны
быть
на
русском
языке.
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных
неверными действиями пользователей, неверным форматом или недопустимыми
значениями входных данных. В указанных случаях система должна выдавать
пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние,
предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
Экранные формы должны проектироваться с учетом требований унификации:




все экранные формы пользовательского интерфейса должны быть выполнены в
едином графическом дизайне, с одинаковым расположением основных элементов
управления и навигации;
для обозначения сходных операций должны использоваться сходные графические
значки, кнопки и другие управляющие (навигационные) элементы. Термины,
используемые для обозначения типовых операций (добавление информационной
сущности, редактирование поля данных), а также последовательности действий
пользователя при их выполнении, должны быть унифицированы;
внешнее поведение сходных элементов интерфейса (реакция на наведение
указателя «мыши», переключение фокуса, нажатие кнопки) должны
реализовываться одинаково для однотипных элементов.
Все интегрируемые в систему веб-приложения должны использовать технологию
skins, которая позволяет отображать все приложения в едином стиле с порталом.
Система должна соответствовать требованиям эргономики и профессиональной медицины
при условии комплектования высококачественным оборудованием (ПЭВМ, монитор и
прочее оборудование), имеющим необходимые сертификаты соответствия и безопасности
Росстандарта.
Требования к защите информации от
несанкционированного доступа
Портал Admnkz должен обеспечивать защиту от несанкционированного доступа (НСД) на
уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по
классификации действующего руководящего документа Гостехкомиссии России
«Автоматизированные системы. Защита от несанкционированного доступа к информации.
Классификация автоматизированных систем» 1992 г.
Компоненты подсистемы защиты от НСД должны обеспечивать:



идентификацию пользователя;
проверку полномочий пользователя при работе с системой;
разграничение доступа пользователей на уровне задач и информационных
массивов.
Протоколы аудита системы и приложений должны
несанкционированного доступа как локально, так и в архиве.
быть
защищены
от
Уровень защищённости от несанкционированного доступа средств вычислительной
техники, обрабатывающих конфиденциальную информацию, должен соответствовать
требованиям к классу защищённости 6 согласно требованиям действующего
руководящего документа Гостехкомиссии России «Средства вычислительной техники.
Защита от несанкционированного доступа к информации. Показатели защищенности от
несанкционированного доступа к информации».
Защищённая часть системы должна использовать "слепые" пароли (при наборе пароля его
символы не показываются на экране либо заменяются одним типом символов; количество
символов не соответствует длине пароля).
Защищённая часть системы должна автоматически блокировать сессии пользователей и
приложений по заранее заданным временам отсутствия активности со стороны
пользователей и приложений.
Защищённая часть системы должна предотвратить работу с некатегоризированной
информацией под сеансом пользователя, авторизованного на доступ к конфиденциальной
информации.
Защищённая часть системы должна передавать данные по защищённому протоколу https и
SSL.
Требования по сохранности информации
при авариях
Программное обеспечение Портала Admnkz должно восстанавливать свое
функционирование при корректном перезапуске аппаратных средств. Должна быть
предусмотрена возможность организации автоматического и (или) ручного резервного
копирования данных системы средствами системного и базового программного
обеспечения (ОС, СУБД), входящего в состав программно-технического комплекса
Заказчика.
Приведенные выше требования не распространяются на компоненты системы,
разработанные третьими сторонами и действительны только при соблюдении правил
эксплуатации этих компонентов, включая своевременную установку обновлений,
рекомендованных производителями покупного программного обеспечения.
Требования к патентной частоте
Установка системы в целом, как и установка отдельных частей системы не должна
предъявлять дополнительных требований к покупке лицензий на программное
обеспечение сторонних производителей, кроме программного обеспечения, указанного в
разделе 4.3.4
Требования по стандартизации и
унификации
Взаимодействие пользователей с прикладным программным обеспечением, входящим в
состав системы должно осуществляться посредством визуального графического
интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен
быть перегружен графическими элементами и должен обеспечивать быстрое отображение
экранных форм. Навигационные элементы должны быть выполнены в удобной для
пользователя форме. Средства редактирования информации должны удовлетворять
принятым соглашениям в части использования функциональных клавиш, режимов
работы, поиска, использования оконной системы. Ввод-вывод данных системы, прием
управляющих команд и отображение результатов их исполнения должны выполняться в
интерактивном
режиме.
Интерфейс
должен
соответствовать
современным
эргономическим требованиям и обеспечивать удобный доступ к основным функциям и
операциям системы.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора
типа «мышь», то есть управление системой должно осуществляется с помощью набора
экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен
используется главным образом при заполнении и/или редактировании текстовых и
числовых полей экранных форм.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме
системных сообщений) должны быть на русском языке.
Экранные формы должны проектироваться с учетом требований унификации:



все экранные формы пользовательского интерфейса должны быть выполнены в
едином графическом дизайне, с одинаковым расположением основных элементов
управления и навигации;
для обозначения сходных операций должны использоваться сходные графические
значки, кнопки и другие управляющие (навигационные) элементы. Термины,
используемые для обозначения типовых операций (добавление информационной
сущности, редактирование поля данных), а также последовательности действий
пользователя при их выполнении, должны быть унифицированы;
внешнее поведение сходных элементов интерфейса (реакция на наведение
указателя «мыши», переключение фокуса, нажатие кнопки) должны
реализовываться одинаково для однотипных элементов.
Требования к функциям (задачам),
выполняемым системой
Каждая подсистема должна предоставлять один или несколько настраиваемых портлетов с
обзорной информацией по текущему состоянию дел с возможностью перехода по ссылкам
на более детальную информацию. Эти портлеты будут помещены на «приборную доску»
пользователя для быстрого обзора текущих задач и текущего состояния дел.
Подсистема хранения и поиска
документов
Отображение иерархии
Каждый артефакт в системе может быть включён в номерклатуру дел. Документы,
проекты, поручения и обращения всегда включаются в номенлатуру дел. Остальные виды
артефактов - в зависимости от настроек администратора в системе.
Номенклатура дел - это иерархия папок. Один и тот же артефакт может быть включён в
несколько папок. Для каждой папки администратор устанавливает настройки. При этом
никакого GUI не надо, условия просто записываются в виде выражений или в виде бизнесправил:









условия для автоматического включения артефакта в папку.
условия для ручного включения артефакта в папку.
может ли пользователь явным образом добавлять артефакт в папку. Цепочка обработчиков
событий до и после добавления.
может ли пользователь явным образом удалять артефакт из папки. Цепочка обработчиков
событий до и после удаления.
может ли пользователь явным образом добавлять внешний файл в папку. Какие типы
файлов допускаются? Цепочка обработчиков событий до и после добавления.
может ли пользователь явным образом удалить отдельный файл из папки. Цепочка
обработчиков событий до и после удаления.
может ли пользователь явно создать подпапку. Цепочка обработчиков событий до и после
создания.
может ли пользователь явно удалить подпапку. Цепочка обработчиков событий до и после
удаления.
один или несколько обработчиков для формирования виртуальных вычисляемых
подпапок, файлов и артефактов. Например, мы можем отображать файл "Справочник
телефонов.pdf" в папке "/Кадры/Управление транспорта". Файл виртуальный, формируется
"на лету" из соответствующей адресной книги. Для виртуальной вычисляемой подпапки
мы можем задавать такие же обработчики, как и для "реальной".
Исполнитель разрабатывает и предоставляет следующие стандартные обработчики
событий:
1. Подсчёт хэш-суммы одиночного файла. Поиск документа, содержащего хотя бы один
файл с данной хэш-суммой в любом из представлений.
2. Автоматическое создание документа из одиночного файла. При этом в документе
создаётся одно представление в зависимости от типа файла, и оно помечается как
оригинал. Название документа создаётся из имени файла, отсекая расширение.
3. Добавление в папку ссылки на заданный артефакт.
4. Создание ссылки на артефакт из *.url - файла.
5. Создание проекта из папки, добавленной пользователем.
6. Добавление в проект ссылки на заданный артефакт.
7. Совпадает ли название папки или файла с зарезервированными названиями.
Автоматически меняем название или прерываем обработку.
При редактировании и последующем сохранении артефакта происходит вычисление
условий - в какие папки номенклатуры дел он включается. Удаление артефакта из
системы происходит по принципу подсчёта ссылок. Когда артефакт удаляют из какой-то
папки в номенклатуре дел, то при этом удаляется только ссылка на него. Сам артефакт
удаляется, когда удалена последняя ссылка не него.
Отображение артефакта
Артефакт может отображаться в SMB/CIFS зависимости от своего типа или в виде
отдельного файла, или в виде папки. Если артефакт отображается в виде папки, то в этом
случае внутри папки должны отображаться:


файл *.url. Это файл типа "application/internet-shortcut". Он содержит URL артефакта, тип
артефакта и уникальный ID артефакта. Название файла совпадает с названием артефакта.
Этот файл можно открыть любым браузером
другие файлы и папки в зависимости от вида атрефакта.
Например, как отображается документ "распоряжение № 356-12 О предоставлении
земельного участка":
Папка с названием "распоряжение № 356-12 О предоставлении земельного участка"





файл "распоряжение № 356-12 О предоставлении земельного участка.url" - виртуальный,
только для чтения, формируется на лету.
папка "редактируемые файлы" - это представление документа в виде редактируемых
файлов. Отображаем, если это представление есть. Внутри папки отображаем файлы,
входящие в данное представление. Файлы можно редактировать, удалять. Можно
добавлять в эту папку файлы разрешённых типов
папка "сканированные изображения" - это представление документа в виде скан.
изображений. Отображаем, если это представление есть.
ещё папки в зависимости от количества представлений.
любые другие виртуальные вычисляемые файлы и папки. Исполнитель предоставляет API
для формирования вычисляемых файлов и папок. Используя это API разработчик,
например, может создать вычисляемый файл "распоряжение № 356-12 О предоставлении
земельного участка.zip", который формируется на лету и содержит всё содержимое
документа в виде одного архива.
Формат файла *.url
[InternetShortcut]
URL=http://www.admnkz.ru/do/my/document/12345
ArtefactTypeID=<тип
артефакта:
документ,
ArtefactID=12345
проект,
обращение,
и
тд>
Поля URL, ArtefactTypeID и ArtefactID являются обязательными. Если они не указаны,
файл не считается ярлыком артефакта и игнорируется. Подробное описание формата
файла: http://www.fmtz.com/formats/url-file-format/article
Функции:
1. Хранить документы в электронном виде в любых форматах
2. Добавлять, редактировать и удалять документы
3. Поддержка транзакций
4. При редактировании обеспечить хранение всех версий документа.
Версия документа относится к документу в целом, а не к отдельному файлу.
Сценарий работы с версиями:
1. Создаётся документ с текущей версией 1.0
2. Пользователи редактируют атрибуты документа и входящие в него файлы. Все
изменения записываются в текущую версию.
3. Документ помечается как окончательный или вручную пользователем через GUI, или
автоматически в результате бизнес-процесса (например, подписания). Текущая версия
становится недоступной для редактирования.
4. Если пользователь снова редактирует этот документ, то создаётся следующая версия
(1.1) и все изменения записываются в неё.
Для каждого документа пользователь может посмотреть список версий, и перейти по
списку на выбранную версию.
5. Поддержка индексирования по реквизитам документов и по содержанию.
6. Поиск как по реквизитам документов, так и по содержанию.
7. Поддержка постоянного URL документа, не зависящего от его состояния,
местоположения и настроек системы. Это должен быть URL портала Liferay,
настраиваемый через friendly-url.
8. Хранение и проверка ЭЦП на документах.
9. Поддержка нескольких «представлений» для одного и того же документа. Одно из
представлений помечается как оригинал. Например, у документа могут одновременно
быть четыре представления: в виде документа DOC (оригинал), в виде нескольких
отсканированных страниц, в виде HTML для наилучшего отображения на сайте, в виде
произвольного XML (который содержит некоторые извлечённые из текста данные,
например, контакты упоминающихся лиц). Или оригиналом может быть сканированное
представление, а DOC получился путём автоматического распознавания.
10. Возможность подключения внешней системы распознавания текстов.
11. Импорт-экспорт документа и его реквизитов. Массовый импорт-экспорт. Программно
и через GUI.
12. Система разграничения прав доступа к документу;
13. Хранить документы с привязкой к проектам. При отображении документов на
виртуальном диске проект отображается в виде папки, а связанные документы в виде
файлов в папке. Если один и тот же документ связан с несколькими проектами, документ
отображается в нескольких папках. При копировании документа в папку проекта
происходит автоматическая привязка документа к проекту. При удалении документа из
папки проекта документ не удаляется, а отсоединяется от проекта.
14. Предоставляет доступ к документам через виртуальный диск по протоколам WebDAV
и SMB/CIFS.
15. Хранит медиа-данные большого объёма (видео, аудио) и предоставляет доступ к ним
по протоколам WebDAV, SMB/CIFS, а также выдачу сохранённых роликов в виде
потокового видео по запросу через медиа-сервер. Если запрашиваемый клиентом формат
медиаданных отличается от формата, в котором хранятся эти данные, выполнять
конвертацию «на лету».
16. Хранит графические изображения и предоставляет доступ к ним по протоколам
WebDAV, SMB/CIFS, а также выдачу сохранённых изображений в заданном формате и
размерах, выполняя преобразование «на лету». При добавлении новых изображений
преобразовывать их в заданный формат и размеры для хранения. Формат и размеры
изображений для хранения задаются администратором.
17. Администратор может задать в настройках набор зарезервированных шаблонов
названий. Если пользователь пытается дать артефакту зарезервированное название,
система выдаёт предупреждение и не позволяет сохранить артефакт с зарезервированным
именем. Шаблон является regex - выражением.
Импорт-экспорт
Импорт и экпорт одиночного документа и его реквизитов
Импорт и экпорт файлов документа выполняется через GUI путём копирования файлов в
соответствующее представление документа в WebDAV. Импорт-экпорт документа со всеми
реквизитами выполняется:

через GUI со страницы, отображающей документ. В списке действий должны быть
пункты: сохранить в XML, загрузить из XML.

программно - разработчики должны предоставить API для сохранения и загрузки
одиночного документа из файла XML.
Массовый импорт и экпорт документов и их реквизитов
Массовый импорт документов из файлов выполняется через GUI копированием файлов в
определённую папку WebDAV. Администратор может создавать любое количество папок
импорта в любом месте иерархии. Каждый файл, скопированный в такую папку,
превращается в документ в формате, описанном в разделе "Реквизиты документа". При
этом:


создаётся одно представление в зависимости от типа файла, по правилам, описанным в
разделе "Создание документа".
тип документа, организация, подразделение и другие атрибуты по умолчанию
настраиваются администратором для данной папки
Массовый импорт-экпорт документов и их реквизитов выполняется:


через GUI. При отображении списка документов в папке, или списка документов,
полученных в результате поиска, должно быть доступно действие: сохранить в XML. Для
экспорта документов на веб-странице должно быть доступно действие: загрузить из XML.
программно - разработчики должны предоставить API для массового сохранения и
загрузки документов со всеми реквизитами из файла XML. API - на усмотрение
разработчика, при этом предпочтительно ( но не обязательно) использовать API Liferay
Portlet
data
handlers
(http://www.liferay.com/community/wiki//wiki/Main/Portlet+DataHandlers).
Формат XML для хранения документа
XML должен содержать все развизиты документа, включая файлы. Формат XML - на
усмотрение разработчика, при этом предпочтительно (но не обязательно) использовать
формат импорта-экспорта данных портала Liferay (http://www.liferay.com/community/wiki//wiki/Main/Portlet+DataHandlers).
Поиск
Поиск документа по реквизитам
Документ можно найти по любому из реквизитов, включая содержание документа
(полнотекстовый поиск).
Если реквизит содержит справочник (например, вид документа), то при выборе из
справочника пустой строки должны находиться все документы, если других реквизитов
поиска не задано.
Особенности поиска по регистрационному номеру
Так как в большинстве документов (распоряжения, постановления) в регистрационном
номере записано число, поиск по номеру для данных документов должен быть точным.
Предлагается вынести настройку поиска по регистрационным номерам для отдельных
видов документов. То есть для каждого вида документа настраиваем шаблон поиска, и
при случае всегда его можем поменять.
Делаем 4 настройки для поиска:
- поиск по любому вхождению символов % {number} %
- поиск с начала {number} %
- поиск по окончанию % {number}
- точный поиск {number}
Обзорная информация по текущему состоянию дел
По документообороту
Для исполнителя
Мои задачи
Всего – количество всех задач, включая завершенные
В работе – всего (количество задач в работе)
Из них
• Новых – количество новых задач, с которыми сотрудник еще не ознакомился
• Подходит срок исполнения – количество задач, до срока исполнения которых осталась
неделя или меньше
• Просроченных – количество задач, срок исполнения по которым истек на текущий
момент
• Активных – количество задач в работе за исключением новых
Завершенных – всего
Из них
• Исполнено в срок
• Исполнено с нарушением срока
Мои документы
Всего – количество всех документов
Новых – количество документов, с которыми сотрудник еще не ознакомился
На согласовании – количество документов на согласовании
На согласовании просроченных – количество документов, срок согласования по которым
истек на текущий момент
Согласованных – количество документов, согласованных на данный момент времени
Зарегистрированных – количество документов, у которых есть регистрационный номер и
дата
Опубликованных – количество документов, зарегистрированных и показываемых на сайте
для публики
Мои проекты
Всего – количество всех проектов
Активных – количество активных на данный момент проектов
Требует внимания – количество проектов, в которых есть задача к исполнению
Завершенных – количество завершенных проектов
Проекты моего подразделения
Всего – количество всех проектов
Активных – количество активных на данный момент проектов
Требует внимания – количество проектов, в которых есть задача к исполнению
Завершенных – количество завершенных проектов
Для контролера распорядительных документов (вид документов - распоряжения,
постановления)
Всего – количество задач
Назначенных – количество задач, по которым назначены исполнители
Есть ответ от исполнителя – количество задач, по которым исполнитель ответил, но нет
окончательного ответа
Просроченных – количество задач, срок исполнения по которым истек на текущий момент
Завершенные – количество задач, на которые есть окончательный ответ
Для контролера канцелярии (вид документов - письма)
Всего – количество задач
Назначенных – количество задач, по которым назначены исполнители
Есть ответ от исполнителя – количество задач, по которым исполнитель ответил, но нет
окончательного ответа
Просроченных – количество задач, срок исполнения по которым истек на текущий момент
Завершенные – количество задач, на которые есть окончательный ответ
Для работника канцелярии (вид документов - письма)
Всего - количество документов
Незарегистрированных - количество вновь пришедших документов, у которых нет
регистрационного номера
Зарегистрированных – всего
Из них:
• За последний день
• За последнюю неделю
• За последний месяц
Для работника регистрационного отдела распорядительных документов (вид
документов - распоряжения, постановления)
Всего - количество документов
Незарегистрированных - количество согласованных документов, у которых нет
регистрационного номера
Зарегистрированных – всего
Из них:
• За последний день
• За последнюю неделю
• За последний месяц
По виртуальной приемной
Для исполнителя
Всего – количество всех обращений, включая завершенные
В работе – всего (количество обращений в работе)
Из них
• Новых – количество новых обращений, с которыми сотрудник еще не ознакомился
• Подходит срок исполнения – количество обращений, до срока исполнения которых
осталась неделя или меньше
• Просроченных – количество обращений, срок исполнения по которым истек на текущий
момент
• Активных – количество обращений в работе за исключением новых
Завершенных – всего
Из них
• Исполнено в срок
• Исполнено с нарушением срока
Для администратора
Всего – количество обращений
Новых – количество поступивших обращений
Назначенных – количество обращений, по которым назначены исполнители
Есть ответ от исполнителя – количество обращений, по которым исполнитель ответил, но
нет окончательного ответа на обращение в целом
Просроченных – количество обращений, срок исполнения по которым истек на текущий
момент
Завершенные – количество обращений, на которые есть окончательный ответ
Подсистема проектов
Проект — это сущность, объединяющая множество артефактов на уровне портала. Проект
может содержать внутри себя документы, контакты, новости, форумы или отдельные
сообщения с форумов, ссылки, обращения, сообщения электронной почты и вообще
любые артефакты. Все артефакты, относящиеся к какому-то делу, удобно группировать в
проект. Каждый артефакт может принадлежать к одному или нескольким проектам.
Проект может быть:


создан пользователем в явном виде
создан системой автоматически
Проект имеет следующие состояния:


не начат,
в работе,


отложен,
завершён.
У каждого пользователя и у каждого подразделения всегда существует "проект по
умолчанию". Он создаётся автоматически, его нельзя удалить. В этот проект
присоединяются артефакты, которые созданы пользователем или ситемой без явного
указания проекта.
Проект может быть создан пользователем в явном виде через GUI или автоматически при
создании артефакта (например, документа в системе документооборота). В этом случае
пользователю предлагается выбор: начать новый проект, присоединить артефакт к одному
или нескольким существующим проектам или оставить артефакт неприсоединённым. В
последнем случае артефакт всё равно присоединяется к "проекту по умолчанию". Вновь
созданному проекту по умолчанию присваивается статус «в работе».
Артефакт, созданный в папке проекта, автоматически присоединяется к проекту.
Сторонний артефакт можно присоединить к проекту путём копирования его в папку
проекта или через GUI в приложении, где создан артефакт.
У каждого проекта есть пользователи-участники. В участники проекта автоматически
добавляются авторы артефактов проекта. Также можно добавить участников вручную.
Проект
предоставляет
участникам
общее
рабочее
пространство.
С каждым проектом связана «комната» в чате. При создании проекта комната создаётся
автоматически, и в неё автоматически без дополнительных запросов присоединяются все
участники.
Проект может содержать ссылки на связанные проекты с указанием вида связи:
родительский или дочерний.
На виртуальном диске проект отображается в виде папки, содержащей артефакты.
Связанные проекты отображаются в виде подпапок.
Если проект создан системой автоматически и не содержит ни одного артефакта, то он
автоматически удаляется.
Подсистема хранения и проверки
сертификатов ЭЦП
Подсистема уже существует у Заказчика и должна использоваться для формирования
серверных подписей и проверки ЭЦП, сформированных на клиентских местах.
Взаимодействие с подсистемой должно производиться по вызовам EJB. Документация
будет предоставлена Исполнителю.
Движок бизнес-процессов
Функции:
1. Обеспечивать прохождение бизнес-процесса в форматах BPMN, BPEL или JPDL.
2. Позволять ввод определений процессов как через GUI администратора, так и
программно.
3. Отображать текущее состояние процесса.
4. Хранить завершённые процессы.
5. По каждому процессу поддерживать журнал прохождения.
6. Должен иметь простой редактор для конечного пользователя, предназначенный для
настройки конкретного экземпляра процесса. Вот, например, типичный процесс
согласования:
В каком-то подразделении создаётся документ или пакет документов, требующий согласования. Сотрудник
либо выбирает готовую схему согласования, либо задаёт её сам. Схема согласования практически всегда
представляет собой перечень лиц для согласования, с указанием, какое это согласование - независимое
параллельное или последовательное. Схема также может быть комбинацией этих двух видов. Например:
[параллельно согласовать: Птичкин + Собакин + Кошкин] далее последовательно: Крокодилова ->
Кенгуренко -> Орлов. При последовательном согласовании в случае несогласия какого-либо лица
возвращаемся на предыдущий этап.
Сотруднику нужен простой редактор, чтобы быстро задать схему согласования или
отредактировать существующую. Для других процессов так же. Конструктор UI
предназначен не для создания процесса с нуля, а для простой и быстрой настройки
существующего процесса.
Подсистема приложений
документооборота
Документооборот должен соответствовать следующим
стандартам:
1. ГОСТ Р 6.30-2003. Кроме того, документ должен содержать QR-код. В этом коде
записан постоянный URL документа.
2. ГОСТ Р ИСО 15489-1-2007
3. Приказу Министерства связи и массовых коммуникаций Российской Федерации
(Минкомсвязь России) от 2 сентября 2011 г. N 221 г. Москва "Об утверждении
Требований к информационным системам электронного документооборота федеральных
органов исполнительной власти, учитывающих в том числе необходимость обработки
посредством данных систем служебной информации ограниченного распространения"
4. Распоряжение коллегии Администрации Кемеровской области от 27.12.2007 № 1440-р
«Об утверждении Инструкции по делопроизводству в исполнительных органах
государственной власти Кемеровской области»
5. Распоряжение Администрации г. Новокузнецка от 30.01.2009 № 207 «Об утверждении
инструкции по делопроизводству в Администрации г. Новокузнецка»
Функции:
1. Отслеживать полный цикл прохождения документа, включая его согласование (если это
требуется)
2. Администратор, технолог или конечный пользователь может задавать для каждого
документа или класса документов свои маршруты прохождения.
3.История прохождения документа
Хранить полную историю прохождения документа. Сохранять события только верхнего уровня:



создание,
изменение,
прохождение бизнес-процессов. Например:
01.02.13 14:25 - отправлен на ознакомление Сидорову, Иванову (посмтореть полный
список)...
01.02.13
14:32
Сидоров
ознакомился
01.02.13
15:08
Иванов
ознакомился
01.02.13 15:21 - ознакомление завершено



сохранение окончательной версии
создание новой версии
удаление документа
История прохождения документа отображается на вкладке на странице документа.
Администратор должен иметь возможность просматривать журнал полностью, по всем
документам.
4. Регистрация входящих и исходящих документов и присвоение номера и даты.
Система должна поддерживать неограниченное количество журналов регистрации.
Каждая организация, подразделение, команда или отдельное должностное лицо может
иметь один или несколько журналов регистрации. Один журнал обязательно является
журналом по умолчанию. Каждый журнал должен поддерживать автоматическую
нумерацию с настройкой шаблона входящего или исходящего номера. Для
автоматической генерации номера может использоваться:





текущий счётчик данного журнала
текущий день, месяц, год
тип документа
ID организации
ID подразделения
Пользователь может исправить вручную автоматически присвоенный номер и дату. В
этом случае введённый номер проверяется на уникальность и соответствие шаблону.
Для каждого журнала указываем, когда нумерация начинается с начала:




каждый год,
каждый месяц,
каждый день
никогда
Пользователь может просматривать любой журнал и выводить его на печать.
У пользователя должна быть возможность установить несколько зарезервированных
номеров. Эта функция нужна, когда требуется зарегистрировать документ задним числом.
5. Регистрация и импорт в систему сообщений электронной почты. В дальнейшем
зарегистрированное сообщение электронной почты проходит все процессы так же, как и
любой входящий документ. Автоматическая регистрация исходящих сообщений
электронной почты.
6. Публикация документа на сайте в общедоступной или корпоративной части в
зависимости от прав доступа.
7. Формировать ЭЦП документа. В зависимости от настроек это может быть или обычная,
или усовершенствованная ЭЦП. Документ для подписания формируется на серверной
стороне, далее подписывается на клиентской, используя JavaScript, CAPICOM и
крипропровайдер, установленный на клиентской стороне.
Регистрация и импорт в систему сообщений
электронной почты
Действующие лица:


Администратор
Секретарь (роль организации)
Входящие сообщения
Входящие и исходящие сообщения эл.почты отображаются через портлет. Входящих
адресов эл.почты может быть неограниченное количество. Один портлет может
отображать входящие сообщения с нескольких указанных адресов. Адреса указывает
администратор в настройках портлета. Администратор может одновременно установить
следующие настройки:



Отображать сообщения на явно указанные адреса. Указываем перечень email-адресов.
Отображать сообщения на личный адрес эл.почты текущего пользователя. Используется
адрес пользователя, указанный в профиле пользователя портала, раздел "Мой профиль">"Детали"
Отображать сообщения на адрес подразделения, где текущий пользователь является
секретарём. Адрес вычисляется так:
1. определяем все подразделения, для которых данный пользователь выполняет роль
секретаря;
2. из каждого подразделения берём адрес эл. почты из раздела "Дополнительные emailадреса". Берём адрес, помеченный как "основной".


Отображать входящие сообщения
Отображать исходящие сообщения
Портлет содержит список сообщений. Секретарь просматривает сообщения и для каждого
нажимает кнопку "принять", "принять и зарегистрировать" или "удалить". Если нажата
кнопка "удалить", сообщение полностью удаляется. Если нажата кнопка "принять" или
"принять и зарегистрировать", то сообщение преобразуется
документооборота. Тип документа - "сообщение эл.почты";
в
документ
для
При этом создаются :



одно представление в виде редактируемых файлов, и в него включается текст сообщения
вложения включаются представления в зависимости от типа файла по тому же алгоритму,
который описан в разделе "Создание документа"
дополнительные атрибуты исходного сообщения копируются в атрибуты созданного
документа. Используются атрибуты: заголовок, отправитель, адрес получателя, время
отправки и время получения.
Шаблон имени созданного документа: тема + номер (если есть).
Расположение документа вычисляется согласно правилам номенклатуры дел.
Если выбрано действие "принять и зарегистрировать", то сообщение регистрируется в
журнале входящих для того подразделения, которому оно прислано. Если сообщение
прислано на личный адрес пользователя, то оно регистрируется в его личном журнале
входящих.
Далее зарегистрированное сообщение электронной почты проходит все процессы так же,
как и любой входящий документ.
Исходящие сообщения.
Пользователь может создать исходящее сообщение из окна редактирования документа. Из
списка действий выбираем "отправить по эл.почте". Пользователь заполняет адрес
получателя. Текущий документ присоединяется автоматически. Нажимаем кнопку
"отправить и зарегистрировать".
Исходящее сообщение регистрируется в журнале исходящих для того подразделения, от
имени которого оно отправлено. Если оно отправлено от имени пользователя, то оно
регистрируется в журнале исходящих данного пользователя.
Сценарий прохождения документа - распоряжения
1. Параллельное согласование с разными подразделениями. Могут участвовать
подразделения своей организации и сторонние организации. Например, список
согласования:



отдел цен
управление торговли
МУ Дирекция единого заказчика (это сторонняя организация)
Согласование, как правило, параллельное. Эту схему и следует считать схемой по
умолчанию для данного этапа. Хотя пользователь должен иметь возможность при запуске
документа на согласование задать другие настройки, например добавить ещё этапы.
2. Последовательное согласование: Правовое управление - Руководитель аппарата - Глава
города
3. Подписанный документ идёт в общий отдел. Там его регистрируют в журнале
исходящих, то есть дают номер и ставят дату подписания. В результате получается,
например, "распоряжение администрации № 2201 от 12.09.2012".
4. Общий отдел сканирует подписанный документ, каждую страницу в отдельный файл
(TIFF,JPG,PNG). Имена файлам даём по правилу: <номер документа>-<номер
страницы>.jpg . Например "2201-0.jpg", "2201-1.jpg", "2201-2.jpg". Страница с номером "0"
- это лист с подписями. Остальные страницы нумеруются по порядку.
5. Система собирает страницы, относящиеся к одному документу, и создаёт из них
представление документа в виде сканированных изображений.
6. Если документ требуется опубликовать на сайте, делаем его доступным для просмотра
для публики. По умолчанию эта галочка ("опубликовать на сайте") установлена, но общий
отдел может её убрать. Некоторые распоряжения не публикуются на сайте, например,
кадровые.
7. Если документ требуется опубликовать в бумажных средствах массовой информации,
общий отдел запускает этот процесс.
Сценарий опубликования документа в бумажных СМИ
Администратор системы создаёт перечень бумажных СМИ. Чаще всего перечень будет
состоять из одной организации, но возможно и добавление новых.
1. Отдел делопроизводства выбирает из перечня одно или несколько СМИ и запускает
документ на опубликование.
2. Сотрудник СМИ заходит на портал под своим именем и паролем и в своём списке для
публикации видит полученный документ.
3. Когда документ опубликован, сотрудник СМИ заполняет для этого документа номер и
дату выпуска, где он опубликован. После этого документ уходит в список уже
опубликованных. Список опубликованных сгруппирован по выпускам.
Сценарий прохождения внутреннего документа
Внутренний документ, это, например, служебная записка. Внутренний документ, как
правило, не публикуется на сайте для публики и не публикуется в бумажных СМИ.
1. Последовательное подписание по произвольному списку. Например: начальник своего
отдела - руководитель аппарата - первый зам.главы по экономике. Первым в списке
подписания по умолчанию стоит начальник своего отдела.
Создание документа
Новый документ может быть создан:


явным образом с нуля
явным образом путём закачки существующих файлов

неявным образом путём закачки существующих файлов
Неявным образом путём закачки существующих файлов
Это служебная функция, её вызывают автоматически другие подсистемы. На входе - один или
несколько файлов. Система автоматически создаёт документ:



заголовок - создаётся из названия первого файла, отсекая расширение
содержание - файлы автоматически раскидываются по представлениям
организация, подразделение, проект, права доступа и связанные документы - назначаются
автоматически в зависимости от контекста вызова.
Явным образом
Шаг 1.
Вкладка "Начало"
При создании открывается форма, где мы указываем обязательные поля:



Заголовок
Тип документа
Подразделение (по умолчанию - подразделение, где работает сотрудник)
Вкладка "Содержание"
Если мы создаём документ из существующих файлов, то дополнительно во вкладке
"Содержание" выбираем один или несколько файлов. При нажатии на кнопку "Добавить
файлы..." появляется окно с возможностью выбрать несколько файлов. Для примера
смотрите Liferay, "Панель управления" -> "Document and media" -> "Добавить" -> "Multiple
documents"
Вкладка "Дополнительно"


галочка "сразу зарегистрировать во входящих". По умолчанию не отмечена.
поле "в ответ на...", где мы можем выбрать существующий документ. По умолчанию
пустое.
Нажимаем "Далее>>".
Шаг 2.
Если для выбранного типа документа требуется заполнить ещё какие-то реквизиты, то на
следующем шаге отображаем форму с этими реквизитами. Например, мы выбрали тип
документа "Заявление на отпуск". У него есть дополнительные реквизиты "дата начала" и
"дата окончания". Отображаем и заполняем их на этом шаге.
Нажимаем "Готово".
Шаг 3.
3.1 Если документ создаётся с нуля, то мы автоматически генерируем для него
представление в виде редактируемых файлов и помечаем это представление как оригинал.
Генерируем на основе шаблона для данного типа документа, организации и
подразделения. Например, для одного и того же типа документа "Служебная записка", но
для разных подразделений будут использоваться разные бланки. Если у подразделения
нет своего бланка, используем бланк организации для этого типа. Если у организации нет
своего бланка, используем бланк по умолчанию для данного типа документа.
3.2 Если документ создаётся закачкой существующих файлов, то мы автоматически
разбиваем указанные файлы по представлениям. Администратор системы для каждого
представления указывает маски имён файлов по умолчанию (например .doc, *.xlsx,
my.xml). Позже при редактировании документа пользователь может перебросить файл(ы)
из одного представления в другое.
Если по результатам автоматического раскидывания файлов у нас получилось несколько
представлений, то оригиналом назначаем представление в виде редактируемых файлов.
Если его нет, то представление в виде изображений. Если и его нет, то представление как
HTML. Если его тоже нет, тогда любое.
Реквизиты документа
Любой документ имеет следующие постоянные реквизиты:
1. Заголовок
2. Содержание. Этот реквизит состоит из нескольких блоков, которые являются
представлением одного и того же документа в разных видах. В документе может быть
одновременно 1 или более таких блоков. Один из блоков помечен как оригинал.
Остальные блоки - производные от оригинала. Например, оригиналом может быть
представление в виде изображений, а представление в виде редактируемых файлов
получено автоматически через распознавание.
2.1 Представление в виде редактируемого файла или нескольких файлов. Например,
распоряжение в виде документа DOC, приложение № 1 в виде XLS, приложение № 2 в
виде PPT. Все три файла относятся к одному представлению.
2.2 Представление в виде сканированных картинок. Может содержать любое количество
графических файлов.
2.3 Представление в виде одного или нескольких HTML и CSS. Иногда удобно
сгенерировать его заранее и хранить в базе.2.4 Представление в произвольном виде,
например некоторые XML-файлы, содержащие извлечённые из текста данные.
Администратор может задавать допустимые типы файлов для каждого представления.
Нужно будет два варианта настроек для каждого представления:
1. настройки при создании документа Это список масок файлов, причем для разных
представлений эти списки не должны пересекаться, чтобы при импорте не записать
один и тот же файл в разные представления. Например *.png может быть только в
представлении "в виде скан.картинок". Эта настройка может выглядеть так: *.doc
*.docx *.xls *.xlsx
2.настройки для дальнейшего редактирования
Это список mime-типов, допустимых в данном представлении. Для разных
представлений допустимые типы могут пересекаться. Например "image/gif" может
быть и в настройках для "Представления в виде редактируемого файла" (потому
что у документа вполне может быть приложение в виде картинки), и в
"Представление в виде сканированных картинок"
3. Подразделение или организация, которой принадлежит документ.
4. Вид документа.
5. Категории, метки. Если поручение создано в рамках проекта, то оно "наследует"
категории и метки проекта и плюс какие-то свои.
Отображение документа
Окно документа состоит из нескольких вкладок: "Главная", и другие вкладки.
При работе с документом основное и самое часто используемое содержимое должно
отображаться на главной вкладке. При работе с документом главное содержимое - это сам
документ. Поэтому отображаем его сразу в самом крупном блоке, а не в уголке в виде
прикреплённого документа. См. файл Документ1. Кнопка "Действия..." - выпадающее
меню. Кнопка "Редактировать" открывает файл для редактирования. Если тип документа
поддерживает редактирование прямо в окне, конечно, дать пользователю такую
возможность.
Если у документа помимо обязательных есть ещё какие-то поля, то самые важные из них
отображаем на главной вкладке ниже поля "заголовок", а менее важные выносим на
вкладку "Подробнее". Например, мы создаём документ "Заявление на отпуск", у которого
есть дополнительные поля "дата начала" и "дата окончания". Эти поля отображаем на
главной вкладке.
Работа с задачами
Если документ в процессе прохождения пришёл к человеку, то возможные действия и
связанные с этим поля отображаем справа на вкладке "Главная" (См. файл Документ 2)
Блок справа удобно сделать в виде split-панели, у которой можно поменять ширину,
свернуть/развернуть (см. Документ 3, справа).
Если активных задач несколько по одному документу, отображаем их все в боковушке.
Пользователь может каждую задачу свернуть/развернуть. Если задача одна, то сразу
рисуем её развёрнутую.
Работа с файлами и представлениями
В файле "Документ 3" изображено представление, состоящеее из нескольких файлов.
Отображение
Для каждого представления слева отображаем перечень всех входящих в него файлов.
При нажатии на заголовок в окне просмотра перемещаемся в начало выбранного файла.
Для каждого файла справа от заголовка отображается кнопка с самым используемым
действием (редактировать) и выпадающее меню с остальными действиями:






передвинуть вверх
передвинуть вниз
переименовать
переместить в другое представление ( выбор представления - в подменю)
скачать
удалить
Редактирование
Кнопка "редактировать" напротив файла открывает выбранный файл для редактирования
в соответствующем приложении на локальной машине пользователя (*.docx - в MS Word,
*.xlsx - в MS Excel).
Кнопка "редактировать все" открывает все файлы из текущего представления для
редактирования в соответствующих приложениях на локальной машине пользователя.
При сохранении файла в приложении пользователя (например, мы нажали кнопку
"Сохранить в MS Word") он автоматически сохраняется в базе без дополнительных
действий.
Добавление
Кнопки "добавить" и "добавить из файла" добавляют файл в текущее представление.
Кнопка "добавить..." содержит выпадающее меню с выбором типа файла (из разрешённых
для данного представления). Добавляется файл на основе шаблона для данного типа
документа+подразделения+типа файла, если такой шаблон задан, или на основе шаблона
по умолчанию, если не задан. Поля в файле заполняются соответствующими значениями
из реквизитов документа, так же, как при создании документа.
Кнопка "добавить из файла" вызывает окно выбора существующего файла (тоже из
разрешённых для данного представления).
Права доступа
Пользователь может установить права доступа на вкладке "права". Часть прав
присваивается автоматически при создании документа, например, если документ создан в
проекте, то доступен для редактирования всем участникам проекта. Права могут быть
назначены:


в кратком виде
в полном виде
Режим "в кратком виде"
Пользователь видит одно поле "Кому доступен документ" со списком для выбора. Можно
выбрать один вариант:
1. всем. Имеется в виду: публике - право на просмотр, участникам редактирование/удаление
2. участникам проекта. Имеется в виду: публике - недоступно, участникам проекта редактирование/удаление
3. подразделению. Имеется в виду: публике - недоступно, участникам проекта редактирование/удаление, своему подразделению - редактирование/удаление
4. организации. Имеется в виду: публике - недоступно, участникам проекта редактирование/удаление, своему подразделению - редактирование/удаление,
своей организации - просмотр
Пользователь может также нажать кнопку "ещё..." и переключиться в полный вид.
У администратора должна быть возможность добавить свой вариант краткого выбора и
соответствующий ему набор прав. Для администратора не обязательно GUI, можно просто
хранить эту настройку в каком-то xml-конфиге.
Режим "в полном виде"
Пользователь видит таблицу:
| роль
| смотреть | редактировать | удалить | обсудить |
+-------------------------------------+-----------+---------------+--------| публика
|
|
|
| X
|
| участники проекта
| X
| X
| X
| X
|
| своё подразделение
|
| X
|
| X
|
| ещё подразделение
|
| X
|
| X
|
| своя организация
| X
|
|
| X
|
| ещё организация (выбрать)| X
|
|
|
|
| перечень ролей
|
|
|
|
|
Подписание документа
Каждый реквизит документа должен иметь настройку - подписываемый или нет. Эта
настройка устанавливается администратором системы. В подписываемые реквизиты по
умолчанию входях обязательные реквизиты документа. Из реквизита "Содержание"
подписывается только представление, помеченное как оригинал.
Порядок формирования подписи
1. На серверной стороне формируем xml-файл, в который включаем:
1.1 ID документа
1.2 Время подписания в виде штампа времени с указанием часового пояса.
1.3 для каждого подписываемого реквизита указываем:



ID реквизита
Название реквизита
Значение реквизита. Если значение является двоичными данными, кодируем их в
Base64. Если длина значения превышает некоторый предел, установленный
администратором системы, то формируем дайджест значения и кодируем его в
Base64. Если значение реквизита состоит из нескольких секций, например,
содержит несколько файлов: перечисляем каждый файл, и для каждого указываем
значение или дайджест значения.
2. Получившийся xml-файл кодируем в Base64, передаём на клиентскую сторону и
подписываем подписью CMS.
3. Проверяем подпись на серверной стороне
4. Сохраняем подпись как один из реквизитов документа
Редактор БП
Редактор БП используется в двух вариантах:
1. технолог БП использует его в развёрнутом виде для создания шаблонов БП
2. конечный пользователь использует его в кратком виде для заполнения полей БП
Технолог создаёт шаблон БП.
Шаблон состоит из нескольких этапов. Для каждого этапа указываем:
1. Тип этапа.
Тип этапа может быть стандартный или встроенный.
Для стандартного типа.
Это может быть, например: рассылка, ознакомление, согласование, подписание. Типы
отличаются набором настроек. Для каждого типа есть стандартный набор настроек:



перечень участников
способ выполнения - последовательно или параллельно
человекопонятный заголовок для этапа
Дальше могут добавляться специфические настройки для каждого типа. Например, для
"ознакомления" добавляем настройку:

требовать подтверждения - если она установлена, для конечного пользователя
отображается внизу кнопка "Ознакомлен". И пока он её не нажал, задача считается
невыполненной.
Для "подписания", например, будет дополнительная настройка

подписывать с помощью ЭЦП: обязательно, предлагать, не предлагать
Для встроенного типа.
На данный момент существует один встроенный тип этапа: вызов другого БП. Для него
указываем:



какой БП вызываем
ждём ли завершения
куда переходим в случае успешного и в случае неуспешного завершения
Разработчик должен иметь возможность добавить в систему свой тип этапа.
2. Перечень участников.
Перечень участников в шаблоне процесса может включать в себя любое количество
пунктов. Каждый пункт представляет собой:
1.
2.
3.
4.
набор условий для должностного лица + настройку "по умолчанию выбран"
или набор условий для подразделения + настройку "по умолчанию выбран"
или конкретное должностное лицо + настройку "по умолчанию выбран"
или конкретное подразделение + настройку "по умолчанию выбран"
Чаще всего будет использоваться, конечно пункты с набором условий, а не с конкретными
лицами или подразделениями.
Набор условий может быть, например таким:




"участники текущего проекта"
"сотрудники моего подразделения"
"начальник моего подразделения"
"начальники по иерархии начиная от [моего подразделения | указанного
подразделения] и до [ верха иерархии | указанного подразделения ]"
У разработчика должна быть возможность добавить новый набор условий и указать для
него человекопонятное имя.
3. Способ выполнения - последовательно или параллельно.
4. Действия при успешном окончании этапа: завершить весь процесс или перейти на
другой этап. По умолчанию - переходим на следующий этап, но можем выбрать и какойто другой этап.
5. Действия при неуспешном окончании этапа: завершить весь процесс или перейти на
другой этап (указываем этап)
6. Кто кроме инициатора процесса может менять настройки этапов. Например, инициатор
указал в каждом этапе список согласования и запустил процесс. Процесс пришёл к
очередному участнику. Может ли этот участник изменить лист согласования? Это и
указываем.
7. Обязательный этап или нет.
8. Запретить изменения в документе: не запрещать, запретить на время выполнения этапа,
запретить навсегда в случае успешного прохождения этапа.
9. Регистрировать во входящих.
10. Регистрировать в исходящих.
Для пунктов 9-10 будет 3 варианта значений: "не регистрировать", "регистрировать
всегда", "по решению пользователя"
"не регистрировать" - когда пользователь получил документ, кнопка "зарегистрировать во
входящих" для него недоступна, даже если он сам захочет зарегистрировать документ в
журнале входящих для своего отдела
"регистрировать всегда" - наоборот, документ всегда автоматически регистрируется в
журнале входящих для отдела, не спрашивая пользователя и пользователь уже не может
его выкинуть из журнала
"по решению пользователя" - документ автоматически не регистрируется, но для
пользователя доступна кнопка "зарегистрировать во входящих"
Значение по умолчанию: "по решению пользователя"
Если документ отправлен конкретному должностному лицу, то регистрируем его в
журнале подразделения, где работает это должностное лицо.
Для каждого из реквизитов, перечисленных в пп 1-6, указываем способ отображения для
конечного пользователя: "не отображать", "отображать в основных параметрах",
"отображать в доп.параметрах"
Для каждого БП мы можем указать другой БП, который должен запуститься:


при успешном окончании процесса
при неуспешном окончании процесса
Предусловия
Для каждого БП мы можем указать набор предусловий, то есть, при каких условиях этот
БП будет отображаться в списке "Действия..." для документа и выполняться. Технолог
может задать два встроенных предусловия:
1. По типу документа (можно выбрать несколько типов)
2. Доступен документ для редактирования или нет
У разработчика должна быть возможность добавить любые другие предусловия по своему
усмотрению.
Конечный пользователь
Конечный пользователь видит для своего документа перечень возможных действий,
например, "ознакомить", "согласовать", "подписать", и тд. Выбирает действие и видит на
экране окно для первого этапа (см. файл Окно1). В список согласования уже добавлены
люди или подразделения согласно условиям, указанным в шаблоне, и уже отмечены или
не отмечены по умолчанию. Кроме списка согласования отображаются реквизиты,
отмеченные как "отображать в основных параметрах". Для необязательных этапов
отображается галочка. Пользователь может установить её, и в этом случае этап будет
выполняться.
Пользователь может или сразу нажать "Готово" или нажать "Ещё параметры..." и в этом
случае он увидит расширенное окно процесса (файл Окно 2), где отображаются все
параметры (основные и дополнительные) и все этапы. Заполнив форму, пользователь
нажимает "Готово" и запускает процесс.
Бизнес-процесс "распорядительный документ"
1. Тип документа – распоряжение, постановление
2. Может создать – любое подразделение администрации
3. Начинает процесс подразделение, ФИО начальника которого будет стоять в документе
в графе «Внесено»
4. После завершения редактирования документ направляется на ознакомление юристам
(обязательно), финансистам (если есть материальное обеспечение), и всем
заинтересованным лицам, которые будут в дальнейшем подписывать документ. Если
заинтересованные лица есть, то сначала они должны ознакомиться, отредактировать
документ по своему усмотрению, а к юристам документ попадает в последнюю очередь.
5. После внесения пожеланий всех заинтересованных сторон, документ отправляется на
согласование лицам, описанным в п. выше, руководителю аппарата и Главе города.
Согласование последовательное – сначала подразделения, затем юристы, руководитель
аппарата и Глава. Вместо руководителя аппарата в некоторых случаях может подписывать
зам., курирующий данное направление.
6. После подписания документ регистрируется, публикуется (при необходимости) и
окончательная версия с подписями рассылается заинтересованным подразделениям,
юристам и в отдел делопроизводства.
7. Если в документе есть поручения (как правило для людей, подписавших документ),
контролер расписывает поручения и ставит сроки исполнения
8. Документ считается исполненным, когда все поручения по нему выполнены. Если
поручений не было, то после рассылки.
Бизнес-процесс "письмо"
1. Тип документа – письмо
2. Может создать – любое подразделение администрации
3. Чаще всего письма пишут от имени Главы или профильного заместителя Главы, в
некоторых случаях от своего имени, соответственно, процесс начинает подразделение,
которое структурно подчиняется данному заместителю, и необходимо иметь возможность
выбрать, кто инициатор письма (начальник отдела, зам. Главы, Глава). От этого зависит,
какой шаблон будет использоваться для письма.
4. На письмо в некоторых случаях может требоваться согласование. Обязательно
согласование при написании письма подразделением от имени профильного зама или
Главы. При необходимости согласования выбираем заинтересованных лиц. Если в их
числе есть Глава, он согласует последним. Остальные могут согласовывать параллельно.
5. Если письмо пишут от имени профильного зама, или Главы, то начальник
подразделения ставится исполнителем.
6. Письмо рассылается всем заинтересованным лицам по списку рассылки.
7. Если необходимо исполнение поручений, указанных в письме, контролер расписывает
поручения и ставит сроки исполнения
8. Письмо считается исполненным, когда все поручения по нему выполнены. Если
поручений не было, то после рассылки.
Бизнес-процесс "письмо - ответ на входящее"
1. Тип входящего документа – письмо, телеграмма
2. Тип исходящего документа – письмо
3. Может создать – любое подразделение администрации, которому дано поручение
4. Иногда отвечают от имени Главы или профильного заместителя Главы, в некоторых
случаях от своего имени, соответственно процесс начинает подразделение, которое
структурно подчиняется данному заместителю, и необходимо иметь возможность
выбрать, кто инициатор письма (начальник отдела, зам. Главы, Глава). От этого зависит,
какой шаблон будет использоваться для письма. В шаблоне должны указываться дата и
номер входящего документа, на который дается ответ.
5. На письмо в некоторых случаях может требоваться согласование. Обязательно
согласование при написании письма подразделением от имени профильного зама или
Главы. При необходимости согласования выбираем заинтересованных лиц. Если в их
числе есть Глава, он согласует последним. Остальные могут согласовывать параллельно.
6. Если письмо пишут от имени профильного зама, или Главы, то начальник
подразделения ставится исполнителем.
7. Письмо рассылается всем заинтересованным лицам по списку рассылки.
8. Письмо считается исполненным, когда все поручения по нему выполнены.
Бизнес-процесс "кадровые распоряжения" (отпуск,
прием на работу, увольнение…)
1. Тип документа – кадровый приказ, распоряжение
2. Может создать – специалист отдела кадров
3. Начинает процесс специалист отдела кадров, заполняя шаблон распоряжения
4. Приказ, распоряжение согласовывается с начальником подразделения и подписывается
Главой
5. Рассылается заинтересованным лицам (начальнику подразделения, о сотруднике
которого было распоряжение)
6. Распоряжение считается выполненным после рассылки
Бизнес-процесс "ответ на обращение гражданина в
виртуальной приемной"
1. Тип документа – обращение
2. Может создать – любой гражданин
3. Начинает процесс администратор ВП, регистрируя обращение и публикуя на портале
4. Обращение идет
(необязательный этап)
на
ознакомление
руководителю
виртуальной
приемной
5. По обращению администратор, либо иногда руководитель ВП, создает поручения и
ставит сроки исполнения.
6. Обращение считается исполненным после выполнения всех поручений.
В случае письменного, устного, либо по электронной почте обращения граждан
(организаций), БП происходит аналогично созданию ответа на обращение гражданина в
виртуальной приемной, только процесс начинает администратор, занося данные и
присвоив регистрационный номер.
Подсистема прохождения обращений
Подсистема должна соответствовать требованиям закона 152-ФЗ от 27.07.2006 «О
персональных данных».
Подсистема должна хранить и обрабатывать обращения в подсистеме документооборота.
Обращение — это просто один из видов документов. Так же, как и любой документ в
системе документооборота, обращение имеет свой процесс прохождения. От внутреннего
документа обращение отличается только способом возникновения: оно создаётся в
виртуальной приёмной на портале. Далее назначение, и контроль исполнения происходит
используя подсистему поручений.
Система должна поддерживать неограниченное количество виртуальных приёмных. В
каждой приёмной ведётся свой журнал регистрации. Виртуальная приёмная может быть
создана для:




организации
подразделения
корпоративного пользователя
проекта
Для каждого из вышеперечисленных может существовать только одна приёмная. То есть
не может быть две виртуальных приёмных для одного и того же подразделения, например.
Сценарии
Роли:



Ведущий виртуальной приёмной
Заявитель
Публика
1. Обращение в виртуальную приёмную через сайт
1. Заявитель заполняет форму на сайте. Что касается идентификации заявителя - cм. пункт
"Идентификация заявителя". Заявитель нажимает "Отправить".
2. В системе документооборота создаётся документ "Обращение". Новые поступившие
обращения отображаются для Ведущего.
3. Ведущий просматривает обращения и принимает решение:
3.1 Удалить обращение - если это спам.
3.2 Принять обращение. В этом случае оно регистрируется в журнале входящих, получает
номер и дату регистрации.
4. Ведущий указывает, публиковать обращение на сайте или нет. По умолчанию публиковать.
5. Ведущий создаёт по обращению одно или несколько поручений, в зависимости от
количества вопросов, затронутых заявителем. При этом используется "подсистема
прохождения поручений".
6. Дальнейшее прохождение поручений и ответов на них идёт по сценариям из раздела
"подсистема прохождения поручений".
7. По каждому из поручений может дать ответ:


тот, кому оно поручено (стандартно по сценарию прохождения поручения)
сам ведущий
8. Все принятые ответы (включая те, что созданы Ведущим) могут быть опубликованы на
сайте. Ведущий может для каждого "окончательного" ответа установить галочку публиковать на сайте или нет. По умолчанию- публиковать. Все принятые ответы
регистрируются в журнале исходящих.
2. Письменное обращение на бумаге.
1. Обращение в бумажном виде поступает ведущему.
2. Ведущий создаёт документ "обращение", заполняет поля. Ведущий может включить в
обращение сканированный оригинал. Поле "способ получения" - "письменное". Заявитель
идентифицируется по номеру и виду документа, если они сообщаются в обращении.
3. Ведущий регистрирует обращение в журнале входящих и ставит галочку - публиковать
на сайте или нет. По умолчанию - публиковать. Дальнейшее прохождение идёт по
сценарию 1.
3. Обращение по эл.почте
Все входящие сообщения эл.почты регистрируются в "подсистеме документооборота".
После этого ведущий:
1. Просматривает сообщение.
1.1 - Спам – удаляет
1.2 - Если это обращение - нажимает кнопку "создать обращение". При этом
автоматически создаётся документ "обращение". Реквизиты автора берутся из реквизитов
письма. Автор при этом идентифицируется по адресу эл. почты.
2. Дальнейшее прохождение идёт по сценарию 1.
4. Обращение на личном приёме.
1. Ведущий создаёт документ "обращение". Сначала документ создаётся в статусе
черновика.
2. По ходу личного приёма ведущий записывает реквизиты заявителя, краткое содержание
вопроса, может присоединить документы. Автор идентифицируется по виду и номеру
документа.
3. Ведущий регистрирует обращение в журнале и может опубликовать на сайте. По
умолчанию - публиковать.
4. Дальнейшее прохождение идёт по сценарию 1.
Идентификация заявителя
При первом обращении в виртуальную приемную, человек автоматически регистрируется
в системе и ему на электронную почту высылается имя входа и пароль. В дальнейшем он
может отправлять обращения из личного кабинета, либо, в случае если человек не
логинится в систему, система его сначала пытается в базе по электронному адресу, и
только при неуспешной попытке поиска добавляет.
Идентификация заявителя может происходить:
 по адресу электронной почты и паролю,
 по СНИЛС (после подключения к ЕСИА).
Функции:
1. Отслеживать полный цикл прохождения обращения;
2. Администратор, технолог или конечный пользователь может задавать для каждого
обращения или класса обращений свои маршруты прохождения.
3. Хранить полную историю прохождения документа.
6. Автоматическая регистрация
некорпоративных пользователей.
обратившихся
граждан
на
сайте
в
качестве
7. Автор обращения через «Личный кабинет» может видеть свои обращения, ответы, и на
какой стадии рассмотрения и у кого находится его обращение.
8. Администратор или технолог может задавать контрольные сроки прохождений:
для всех обращений,
для обращений, соответствующих заданным условиям;
для каждого конкретного обращения
9. Система отслеживает контрольные сроки, и сигнализирует администратору и
исполнителям о приближении контрольных сроков.
10. Система должна регистрировать все виды обращений: через сайт, письменные,
голосовые и видео-обращения, обращения по электронной почте, личный приём. В случае
голосовых и видео-обращений сохраняется запись обращения.
11. Поиск и отображение обращений по всем реквизитам и общий поиск одной строкой.
12. Ведущий приёмной или администратор системы может установить настройку:
принимать голосовые/видео - обращения через сайт или нет. В этом случае в форме
обращения будет отображаться или не отображаться фрагмент для ввода
голосового/видео- обращения.
Публикация обращений на сайте
Обращения публикуются в общедоступной части в зависимости от прав доступа.
Администратор виртуальной приёмной может устанавливать права доступа, в том числе доступно ли данное распоряжение для просмотра для публики. Из данных о заявителе
публикуем:


ФИО
социальную группу
Взаимодействие с виртуальными приёмными
Администрации Кемеровской области, районных
администраций и муниципальных предприятий
Если обращение перенаправлено для исполнения в другую виртуальную приёмную, то
оно должно также отображаться в этой виртуальной приёмной.
Отчёты
Все отчёты генерируются, используя "подсистему отчётов". Шаблон отчёта создаётся в
администратором или технологом, используя Eclipse BIRT. Разработчики предоставляют
стандартный набор отчётов. Шаблоны находятся в прикреплённых файлах *.dot.
Реквизиты обращения
Обращение "наследует" от обычного документа (см.
документооборота), и дополнительно содержит реквизиты:
Подсистему
приложений
1. Автор обращения. Если обращение коллективное - первый из списка подписавшихся.
1.1 Социальная группа автора – справочник
2. Коллективное или нет
3. Тема – справочник
4. Дата поступления обращения
5. Дата публикации ответа
6. Статус обращения. Вычисляется автоматически по тем же правилам, что и статус
поручения.
7. Способ получения - электронное из виртуальной приёмной, письменное, эл. почта,
личный приём
8. Публиковать ход исполнения или нет. Если публиковать, то на сайте отображается
история прохождения обращения включая всё дерево поручений - кому и когда передано
для ответа, когда получены ответы.
Текущие реквизиты обращения
<column name="appealId" type="long" primary="true" /> - Первичный ключ
<column name="statusCode" type="int" /> - Код статуса (в настоящее время не
используется)
<column name="statusStr" type="String" /> - Описание статуса (используется)
<column name="header" type="String" /> - Заголовок
<column name="theme" type="String" /> - Тема
<column name="content" type="String" /> - Описание
<column name="appealerAddress" type="String" /> - Адрес обратившегося лица
<column name="appealerSocialStatus" type="String" /> - Социальный статус обратившегося
лица
<column name="appealerPhone" type="String" /> - Телефон обратившегося лица
<column name="appealerEMail" type="String" /> - Электронная почта обратившегося лица
<column name="isCollectivity" type="String" /> - Флаг коллективного обращения
<column name="documentNumber" type="String" /> - Регистрационный номер документа
<column name="appealerFirstName" type="String" /> - Имя обратившегося лица
<column name="appealerLastName" type="String" /> - Фамилия обратившегося лица
<column name="appealerMiddleName" type="String" /> - Отчество обратившегося лица
<column name="liferayPublic" type="String" /> - Флаг публичности обращения
<column name="nodeRef" type="String" /> - NodeRef объекта в Alfresco
<column name="userId" type="long" />
<column name="userName" type="String" />
<column name="groupId" type="long" />
<column name="createDate" type="Date" />
<column name="modifiedDate" type="Date" />
<column name="companyId" type="long" />
Подсистема формирования оргструктуры
и контактных данных
Функции:
1. Каждый сотрудник, зарегистрированный в системе, может редактировать свои
контактные данные. Также может указать, публиковать их на сайте или нет. Если
публиковать, то кто может их видеть: все посетители, или только сотрудники, и
сотрудники каких отделов.
2. Администратор оргструктуры может добавлять, удалять, редактировать и публиковать
контактные данные сотрудников. Администратор может устанавливать расширенные
права на контактные данные сотрудников, например, на каждый конкретный телефон,
email или IM сотрудника. Таким образом, некоторые телефоны одного и того же
сотрудника доступны для просмотра всем, некоторые - только указанным
организациям/подразделениям.
3. Администратор оргструктуры может добавлять, удалять, редактировать подразделения
организации.
4. Администраторы оргструктуры могут иметь разные полномочия:



доступ ко всем организациям и подразделениям,
доступ только к своей организации;
доступ только к своему подразделению;
5. Отображение контактной информации должно иметь гибкие настройки и фильтры:
1 фильтр по заданной организации, включая или не включая под-организации
2 фильтр: отображать подразделения
3 фильтр: отображать сотрудников
4 фильтр: по проектам, тегам и категориям
5 фильтр: по ролям (все роли Liferay)
6 фильтр: по контактной информации
7 фильтр: по дополнительным полям
Каждый фильтр читается в порядке приоритета:
1. Из текущего URL
2. Из PRP и/или event
3. Из настроек портлета
Отображение списка:
1. иерархическое или нет
2. шаблон списка: таблица, перечень, grid. Как указано в п. "Требования к отображению
информации", это следует делать через обработчик шаблонов. Администратор при
настройке отображения указывает шаблон списка, который будет использоваться.
Разработчики создают три шаблона: таблица, перечень, grid. Для примера смотрите
Liferay, отображение динамических списков данных.
3. отбражение отдельного контакта: Администратор назначает шаблон отображения. Для
примера смотрите Liferay, отображение динамических списков данных.
4. редактирование отдельного контакта: Администратор назначает шаблон
редактирования или шаблон URL'a для редактирования, если оно будет делаться в другом
портлете.
Сортировка: по любой комбинации полей.
У администратора должна быть возможность добавлять/редактировать/удалять шаблоны.
Добрый совет: используйте для отображения публикатор Liferay. Большая часть там уже
есть, остальное доделаете. Но вообще-то смотрите сами, если у вас есть лучшее решение,
используйте его.
6. Создавать много адресных книг. В адресную книгу может включаться как пользователь
сайта, так и сторонний контакт. Адресная книга имеет область видимости: глобальная,
сайт, одна или несколько организаций (включая или не включая подорганизации), одно
или несколько подразделений организации (включая или не включая дочерние
подразделения), команда, проект (включая или не включая подпроекты), один или
несколько пользователей.
7. Импорт-экспорт адресных книг в форматах CSV, LDIF, XML. Как бы я это сделала:
экспортировала бы всё только в XML, а для каждого из дополнительных форматов
создала бы XSL. Прогоняем XML через XSL и получаем на выходе нужный формат.
Таким образом можно легко добавлять новые форматы для экспорта.
8. Контакты из адресных книг автоматически должны быть доступны для корпоративного
мессенджера без дополнительных операций по добавлению, подтверждению, взаимной
авторизации и прочего.
9. Вывод на печать адресных книг и контактных данных отдельного человека.
10. При вводе адреса используются справочники КЛАДР до уровня улиц включительно.
Пользователь должен иметь возможность или выбрать пункт из справочника, или
написать его вручную. EJB для выбора из КЛАДР уже имеется у Заказчика. Документация
будет предоставлена исполнителю.
11. При вводе сертификатов ЭЦП пользователь указывает файл *.cer. В базе Liferay
сохраняем только отпечаток SHA1 и имя настроек для работы с сертификатом. Остальное
вводим/читаем и храним через EJB Криптосервис (http://admnkz.ru:8000/crypto).
Взаимодействие с другими портлетами
Этот портлет должен также уметь передавать текущую выбранную организацию/
подразделение/контакт в Public render parameter и/или event, чтобы другие портлеты (или
экземпляры этого же портлета) могли отобразить информацию по выбранной
организации/ подразделению/контакту. Для этого в портлете должна быть настройка: при
выборе: "отобразить отдельный элемент" или "оставаться на месте". Например, мы в
портлете отображаем списком/деревом/grid-ом организации, их подразделения и людей
внутри подразделений. На каждом элементе рисуется ссылка. Нажимаем на ссылку. Что
происходит:


портлет указывает ID текущего элемента в Public render parameter и/или event.
Другие портлеты на странице (или другие экземпляры этого же портлета) могут
поймать это значение и отобразить свою информацию по выбранному элементу.
в зависимости от настройки или переходим к отображению выбранного элемента,
или не делаем ничего.
Таким образом, мы можем сделать настроить отображение информации по схеме masterdetail.
Например, мы на добавляем на страницу два портлета оргструктуры. В первом в
настройках указываем: отображать только организации и подразделения + при выборе:
"оставаться на месте". Это будет master-portlet. Во втором портлете в настройках
указываем: отображать только людей. В этом случае, когда в первом портлете мы
нажимаем на какую-то организацию/подразделение, во втором портлете отображаются
сотрудники этого подразделения.
Для примера смотрите Liferay, взаимодействие портлетов "навигация по категориям" и
"публикатор".
Предложение по орагнизации оргструктуры в LDAP.
Есть три роли: сотрудник, руководитель, заместитель.
Есть иерархия "разделов" (разделом может быть отдел/департамент/подразделение или др.
единица).
В кадом "разделе" могут быть три роли. Отсюда строится понятие "непосредственный"
руководитель, понятие "вверх по иерархии руководителей/разделов".
Внутри каждой группы в лдапе д.б. всегда следующие группы-роли: руководитель,
заместитель (возможно еще сотрудник, но все пользователи в лдапе уже являются
сотрудниками?).
Есть вариант создания этих групп программно внутри подсистем, но такие права будут
нужны во многих системах и будет удобней их создать в лдапе.
Возможно необходима группа-роль "текущий отдел" для назначения прав только на этот
отдел без наследования по подотделам (уточнить).
Есть еще глобальные три группы-роли, в которые входят все роли соответствующим
образом - для назначения на руководителей всех уровней, всех заместителей, всех
сотрудников (сотрудников уточнить).
Подсистема контроля и исполнения
поручений
Поручение может быть полным или кратким:


Полное поручение - это классическое "официальное" поручение, со всеми
реквизитами и процессами прохождения.
Краткое поручение - просто строчка в списке "TODO" с галочкой "сделано-не
сделано".
Сценарии
Действующие лица:



Создатель поручения (имеет все возможности Контролёра + свои собственные)
Контролёр
Исполнитель
Создание полного поручения
1. Создатель создаёт поручение
2. Создатель выбирает контролёра (по умолчанию контролёр уже выбран - это сам
создатель), сроки и исполнителей
3. Нажимает кнопку: "сохранить" или "на исполнение"
3.1 Если нажато "сохранить", то поручение остаётся в состоянии "не начато"
3.2 Если нажато "на исполнение", то задание переходит в состояние "в работе",
отображается в списке задач исполнителей, и в списке заданий «на контроле» для
контролёра и для создателя. Поручение также регистрируется в журнале и получает номер
и дату.
Если поручение создано в рамках проекта, то оно также отображается в списке задач
проекта.
Создание краткого поручения
1. Пользователь создаёт поручение
2. Пользователь заполняет заголовок, более подробное описание, может прикрепить
документы или поручения
3. Нажимает кнопку: "сохранить"
4. Поручение сохраняется в состоянии "не начато" в списке задач пользователя, и в списке
задач проекта (если оно создано в рамках проекта). В журнале не регистрируется.
Исполнитель отвечает на поручение
1. Исполнитель видит поручение в списке своих задач.
2. В окне поручения исполнитель может просматривать всё в режиме "только чтение", и
кроме этого, для исполнителя доступна кнопка: дать ответ. Нажимаем.
3. Добавляем ответ. Указываем: окончательный или промежуточный, текст ответа +
(голосовое или видео), прикреплённые документы. Дата ответа проставляется
автоматически. Нажимаем "отправить".
4. Контролёр получает ответ, просматривает и выбирает: принять или не принять.
Контролёр также может поменять предложенный исполнителем статус ответа:
промежуточный или окончательный.
4.1 Если контролёр принял ответ, то он сохраняется с тем статусом, который дал ему
контролёр. Если это был окончательный ответ, то поручение считается выполненным.
4.2 Если контролёр не принял ответ, то в этом случае контролёр пишет свои замечания,
ответ сохраняется с замечаниями контролёра и возвращается пользователю.
Создатель редактирует поручение.
Создатель может редактировать поручение. Если поручение "не начато", то редактируется
текущая версия. Если поручение уже "в работе", то создаётся и редактируется новая
версия. Создатель может редактировать любые поля, кроме уже данных ответов
исполнителей. Далее отредактированная версия работает по тем же сценариям, что и
вновь созданное поручение.
Контролёр редактирует сроки.
Контролёр может поменять исполнителей и сроки исполнения.
Функции:
1. Каждый пользователь может создать
ответственных исполнителей, контролёра.
задачу,
назначить
сроки
исполнения,
2. Поручение может быть связано с одним или несколькими документами, обращениями,
проектами, причём хотя бы с одним проектом поручение связано всегда. Если поручение
создаётся "само по себе", то есть пользователь явно не указал проект, то поручение
помещается в проект по умолчанию, который называется "Разное".
3. Поручение может быть письменным, голосовым или видео. Голос или видео
записываются с микрофона или веб-камеры пользователя. Или можно указать готовый
аудио- или видео-файл.
4. Назначенное задание отображается в списке задач исполнителей, и в списке заданий
«на контроле» для контролёра.
5. Поручение может находиться в состояниях :






не начато - своего рода черновик ,пока не нажата кнопка "На исполнение"
в работе - находится в работе, но никто пока не дал ни одного ответа
дан промежуточный ответ - хотя бы один из исполнителей дал промежуточный
ответ
выполнено частично - хотя бы один из исполнителей дал окончательный ответ
выполнено полностью - все исполнители дали окончательный ответ
отменено - отменено создателем.
6. Поручение может содержать дочерние поручения, глубина создания дочерних
поручений не ограничена.
7. Документы, созданные в рамках исполнения задания, могут быть помечены как
«промежуточный ответ» или «окончательный ответ»
8. Система должна оповещать исполнителей и контролёра о приближении сроков
исполнения. (настраивается администратором системы, для исполнителя и контролера
разные настройки оповещения)
9. Система должна оповещать исполнителей и контролёра о просрочке исполнения ,а так
же выделять просроченное поручение цветом.(время и цвет выделения просроченных
поручений настраивается администратором системы, для исполнителя и контролера
разные настройки оповещения)
10. Подсистема также отображает статистическую информацию о прохождении
документов и обращений. (сводные отчеты - по исполнителям, по датам начала
поручений. У кого сколько поручений и в каком они состоянии)
11. Подсистема сохраняет всю историю прохождения поручения: создание,
назначение/переназначение исполнителей, назначение/перенос сроков, получение ответов,
принятие или непринятие ответов, завершение.
12. Если поручение краткое, и находится в состоянии "не начато", то пользователь может
нажать кнопку "Сделать поручением" и превратить краткое поручение в полное
"официальное" и далее работать с ним по сценариям для полного поручения. Полное
поручение нельзя вернуть в краткую форму.
Отчёты
Все отчёты генерируются, используя "подсистему отчётов". Шаблон отчёта создаётся в
администратором или технологом, используя Eclipse BIRT. Разработчики предоставляют
стандартный набор отчётов. Шаблоны находятся в прикреплённых файлах *.dot.
Реквизиты поручения
Полное поручение
1. Автор - пользователь, создавший поручение
2. Контролёр - тот, кто будет контролировать исполнение. Контролёр есть всегда. По
умолчанию это автор поручения.
3. Краткий заголовок
4. Более подробное описание. Это может быть текст + (голос или видео)
5. Ссылки на документы или поручения, в связи с которыми создано данное поручение.
Это необязательный реквизит, поручение вполне может быть создано само по себе, а не
для исполнения каких-то документов.
6. Дата начала
7. Срок исполнения. Срок исполнения может быть один общий для всего поручения, или
свой для каждого исполнителя.
8. Исполнители: один или несколько исполнителей
9. Состояние: не начато, в работе, выполнено частично, дан промежуточный ответ,
выполнено полностью.
10. Ответы. Они могут быть общими по всему поручению или отдельными по каждому
исполнителю.
Ответ может содержать:






Текст + (голос или видео)
Вид ответа: окончательный или промежуточный
Ссылки на документы или поручения, являющиеся содержанием ответа
Фактическая дата ответа (ставится автоматически).
Чей это ответ (исполнитель). Если ответ отдельный по каждому исполнителю. Для
общих ответов - не надо.
Состояние ответа: принят или не принят контролёром
По одному поручению может быть несколько ответов: неколько промежуточных и один
окончательный. То же самое, если ответы отдельные по каждому исполнителю: может
быть несколько промежуточных и один окончательный.
11. Фактические сроки исполнения. Или один на всё поручение, или отдельные сроки по
каждому исполнителю.
12. Дочерние поручения
13. Категории, метки. Если поручение создано в рамках проекта, то оно "наследует"
категории и метки проекта и плюс какие-то свои.
Краткое поручение
1. Краткий заголовок
2. Более подробное описание. Это может быть текст + (голос или видео)
3. Ссылки на документы или поручения, в связи с которыми создано данное поручение.
Это необязательный реквизит, поручение вполне может быть создано само по себе, а не
для исполнения каких-то документов.
4. Состояние: не начато, в работе, выполнено полностью.
5. Категории, метки. Если поручение создано в рамках проекта, то оно "наследует"
категории и метки проекта и плюс какие-то свои.
Подсистема организации и проведения
обсуждений в электронной форме
Функции:
1. Создавать, редактировать и удалять локальные форумы. Локальный форум может быть
привязан к какому-либо проекту, событию, пакету документов. Для каждого локального
форума назначается администратор.
2. Администратор форума может скрывать от общего доступа или удалять сообщения
участников.
3. Участником форума может быть любой зарегистрированный пользователь сайта.
4. При форуме может быть проведено одно или несколько голосований. Участники
предлагают формулировки пунктов голосования, администратор создаёт голосование и
подводит его итоги.
5. Администратор также может закрыть форум и подвести итоги обсуждения.
6. Проводить видеоконференции, используя программные решения СПО, например,
Openmeetings.
Подсистема формирования отчетности
Строится на основе генератора отчётов BIRT и является реализацией интерфейсов Liferay
Report API (com.liferay.portal.kernel.bi.reporting.*). Состоит из:


портлета или набора портлетов для администрирования
портлета для отображения отчётов
Подсистема получает данные из любой другой подсистемы через BIRT-совместимые
источники данных. То есть, каждая подсистема должна предоставить:


BIRT-совместимый источник основных данных
BIRT-совместимый источник данных для отображения справочников. Он нужен,
когда значение параметра пользователь выбирает через GUI.
Портлет для отображения отчётов
1. Выбор отчёта для отображения происходит в порядке приоритета:



из параметра текущего URL
из public render parameter и event
из настроек портлета
2. Выбор источников данных для отчёта происходит в порядке приоритета:




из параметра текущего URL
из настроек портлета
из public render parameter и event
из источников данных по умолчанию
3. Параметры для отчёта берутся в порядке приоритета:




из параметра текущего URL
из public render parameter и event
из настроек портлета
задаются через GUI
4. Сохранение сформированного отчёта в форматах офисных приложений
5. Вывод отчёта на печать
6. Предоставляет javascript-функции для формирования URL для отображения другого
отчёта:



в этом же портлете.
в другом портлете на текущей странице
в другом портлете на другой странице
Это используется, например, чтобы из сводного отчёта по ссылке показать подробный
отчёт.
7. Предоставляет javascript-функции для формирования URL:


при нажатии на этот URL создаётся public render event
при нажатии на этот URL формируются public render parameter (один или
несколько)
Это используется, чтобы отобразить master-detail отчёты. Например, мы помещаем на
страницу два портлета-отчёта: master- со списком подразделений, и detail- сводка по
исполнению поручений по данному подразделению. В master-отчёте для каждого
подразделения мы отображаем ссылку. При нажатии на ссылку: формируется public render
event, который как параметр передают ID выбранного подразделения; формируется public
render parameter на основе ID выбранного подразделения.
Для примера смотрите http://visioneo.org
8. Выбор темы оформления отчёта берётся в порядке приоритета:



из параметра текущего URL
из настроек портлета
из темы по умолчанию для всей системы.
Портлет для администрирования
1. Управление источниками данных (добавить, редактировать, удалить).
2. Управление отчётами: поместить в систему, установить настройки и параметры по
умолчанию, установить источники данных по умолчанию, убрать из системы
3. Управление темами для оформления: поместить в систему, убрать из системы,
установить тему по умолчанию.
Клиентское программное обеспечение
Вся работа на клиентском рабочем месте должна происходить через веб-браузер, и не
требовать установки дополнительного ПО. Если для работы требуются активные
элементы (апплеты, просмотр flash-роликов), то они должны устанавливаться
автоматически средствами браузера.
Кроме браузера, на клиентском рабочем месте будут установлены стандартные офисные
пакеты Microsoft Office, OpenOffice. Подсистема документооборота должна
взаимодействовать с офисным ПО прозрачным образом:
1. Пользователь открывает, редактирует и созраняет документ прозрачным образом,
так же, как при работе с локальной файловой системой. Не как с обычным
документом с какого-то интернет-сайта: скачал, сохранил локально,
отредактировал, зашёл на страницу закачки, закачал обратно. Всё должно быть
прозрачно: открыл документ по ссылке WebDAV или с присоединённой
виртуальной папки, отредактировал, нажал сохранить - документ сразу сохранился
через тот же WebDAV.
2. Прозрачно создаётся новая версия документа. Пользователь просто открыл
документ, отредактировал, сохранил, а система автоматически создала новую
версию и сохранила старую без дополнительных команд со стороны пользователя.
В MS Office по командам "Сравнить версии" и "Объединить версии" версии
документа брать из системы документооборота.
Подсистема приёма граждан
Любое должностное лицо может воспользоваться подсистемой приёма граждан.
Подсистема позволяет должностному лицу (или его секретарю):
1. Назначить расписание приёма граждан. Это означает — указать для каждого посетителя
время начала и окончания приёма, а также вид приёма — личный или видео-приём
онлайн.
2. Предварительно просматривать список граждан, записавшихся на приём. На этом этапе
должностное лицо может отказать в приёме любому посетителю с указанием причины,
или перенести приём этого посетителя на другое время.
3. По каждому посетителю прикрепить ссылки на документы, которые могут
потребоваться по его проблеме
4. Если посетитель ранее уже обращался в Администрацию, система должна отобразить
информацию о его обращениях
5. В случае видео-приёма система должна сохранять запись приёма и хранить её
определённое время, в зависимости от настроек администратора.
6. В ходе приёма или после его завершения должностное лицо может оформить каждый
личный или онлайн приём как обращение и запустить его в систему прохождения
обращений. Также должна быть возможность создать одно или несколько поручений,
связанных с этим приёмом.
Подсистема позволяет посетителю:
1. Записаться на личный приём или на приём он-лайн
2. Кратко описать свою проблему, прикрепить файлы.
3. При приближении срока приёма система напоминает об этом посетителю по
электронной почте или через систему мгновенных сообщений
4. Посетитель может отменить приём.
5. В случае переноса приёма на другое время система также оповещает посетителя об
этом.
6. В ходе видео-приёма он-лайн для посетителя доступен текстовый чат (если надо
передать какую-то короткую информацию, например, ссылку, адрес или телефон), и
пересылка файлов.
Процесс записи на приём идёт через движок бизнес-процессов.
Подсистема совместной работы
Портал должен обеспечивать возможность совместной работы, и включать в себя
следующие возможности:
Ведение адресных книг.
Адресные книги могут быть личными или корпоративными. Каждый пользователь,
проект, организация или подразделение может создавать для себя любое количество
адресных книг. Для кажого пользователя, проекта, организации или подразделения всегда
существует одна "основная" адресная книга и может быть создано любое количество
"дополнительных" адресных книг:
1. Основная адресная книга
Эта адресная книга существует всегда, её нельзя удалить. В неё входят все сотрудники
организации (если это адресная книга организации), все сотрудники подразделения (если
это адресная книга подразделения), все участники проекта (если это адресная книга
проекта) и дополнительно - сторонние контакты. Сотрудники организации/подразделения
или участники проекта всегда существуют в основной адресной книге, их нельзя оттуда
удалить. Можно только добавить сторонние контакты.
2. Дополнительная адресная книга
Это обычная адресная книга, она создаётся явным образом. Сторонние контакты и
сотрудники организации/подразделения или участники проекта добавляются в неё тоже
явным образом. В неё могут входить не все сотрудники подразделения или участники
проекта.
Таким образом, корпоративному пользователю доступны:

его личная адресная книга




адресные книги его подразделения
адресные книги вышестоящих подразделений
адресные книги организации
адресные книги по всем проектам, в которых он участвует
Один и тот же контакт может входить в несколько адресных книг. При редактировании
контакта пользователь отмечает, в какие адресные книги входит контакт, и дополнительно
- доступен ли контакт для просмотра для публики.
Права доступа
Для организации, подразделения или проекта есть роль "Администратор контактных
данных". Он может менять права доступа к отдельным контактам и адресной книге в
целом.
По умолчанию любой пользователь может редактировать адресную книгу, которая
находится в его поле действия. То есть участник проекта может редактировать адресные
книги проекта, корпоративный пользователь может редактировать адресные книги
организации или подразделения.
Календарь
Предназначен для отображения дел, а также для планирования событий, встреч. В
календарь входят:



задачи, привязанные ко времени
задачи, не привязанные ко времени (см. Подсистему поручений, "краткое
поручение")
поручения (см. Подсистему поручений, "полное поручение")
Далее называем всё перечисленное выше общим словом "задача". Каждая задача может
содержать любое количество подзадач. Каждая задача может входить в несколько
календарей. При редактировании задачи пользователь отмечает, в какие календари входит
задача, и дополнительно - доступна ли задача для просмотра для публики.
Календарь может быть личный, общий для подразделения, для проекта или для
организации. У каждой организации/ подразделения/ проекта/ пользователя всегда
существует один "основной" календарь и любое количество дополнительных:
1. Основной календарь.
Этот календарь существует всегда, его нельзя удалить. В нём по умолчанию
отображаются
все
задачи,
связанные
с
данным
пользователем/проектом/организацией/подразделением.
2. Дополнительный календарь.
Создаётся явным образом. Задачи добавляются в него тоже явным образом.
Права доступа
Для организации, подразделения или проекта есть роль "Администратор календарей". Он
может менять права доступа к отдельным задачам и к календарю в целом.
По умолчанию любой пользователь может добавлять задачи в календарь, который
находится в его поле действия. Участник проекта может добавлять/редактировать задачи в
календаре проекта. Корпоративный пользователь может добавлять задачи в календарь
своего подразделения и нижестоящих подразделений.
Дополнительные функции¶
1. Импорт — экспорт событий в форматы XML, iCalendar.
Подсистема публикации медиа-данных
Подсистема должна обеспечивать показ фотографий (в виде фотогалереи), видеороликов,
аудиозаписей и прямых трансляций.
1. Публикация фоторепортажей
1.1 Основные требования:
1.1.1 По завершению задачи в системе будет добавлен новый тип данных для структур
сетевого контента - "Inline Gallery".
1.1.2 Предполагается, что такой тип данных будет использоваться в новостях для
добавления в них галерей сопровождающих новость фотографий.
1.1.3 Администратор сможет свободно добавлять поля такого типа в структуру сетевого
контента. При этом он сможет сделать такое поле повторяемым, позволяя тем самым
загружать в галерею более одного изображения. Должна быть возможность "одним
кликом" загрузить много изображений.
1.1.4 Менеджер, добавляющий сетевой контент на сайт, сможет добавлять изображения в
соответствующее данному типу поле, не размещая их в Documents and Media.
1.1.5 Предполагается, что изображения из галерей будут автоматически размещаться в
директории в настраиваемой администратором директории.
1.1.6 Предполагаеться, что для посетителей портала галерея будет отображаться в виде
набора эскизов (набора копий изображений малого размера) с возможностью просмотра
оригинального изображения при клике на эскиз.
1.1.7 Предполагается, что добавленные в галерею изображения в обычном виде (не в виде
эскизов) можно будет вставлять в любое html поле сетевого контента с помощью
инструмента выбора изображений галереи, аналогичного уже существующему
инструменту добавления изображений из Documents and Media или по URL.
1.1.8 Новый тип данных должен быть реализован с использованием стандартных решений
LifeRay, а для иллюстрации его работы в портале должны быть созданы тестовые
элементы портала.
1.1.9 Новый тип данных "Inline Gallery" должен быть доступен при конфигурировании
полей структур сетевого контента через интерфейс администратора, аналогично другим
типам полей сетевого контента.
1.1.10 В систему должна быть добавлена тестовая структура, содержащая поле типа "Inline
Gallery" с дополнительным текстовым полем для комментария, для которого должна быть
включена возможность повторения.
1.1.11 В систему должен быть добавлен тестовый Velocity шаблон, отображающий такую
структуру в виде галереи эскизов с отображением комментария для каждого эскиза и
разворачиванием просмотра изображения в нормальном виде при клике на эскиз.
1.1.12 На панели инструментов редактирования текстового html поля должен добавиться
инструмент, позволяющий добавлять в html текст любое изображение из галерей текущего
контента.
1.1.13 При создании сетевого контента с галереей добавляемые изображения должно
размещаться автоматически без использования Documents and Media. Директорию, в
которой будут размещаться изображения галереи, будет задавать администратор портала в
параметрах настройки сервера.
1.1.14 Клиентский функционал просмотра изображений галереи на клиенте рекомендуется
реализовать с помощью YUI Library.
1.1.15 При добавлении сетевого контента с галереей изображения галереи должны быть
доступны по прямой ссылке.
1.1.16 При добавлении сетевого контента на стороне сервера должны автоматически
создаваться эскизы изображений галереи. Эскизы должны создаваться на серверной
стороне.
1.1.17 При добавлении или изменении сетевого контента у менеджера сайта должна быть
возможность загрузки изображений, просмотра загруженных изображений и удаления
загруженных изображений.
1.1.18 При сохранении сетевого контента изображения галерей должны автоматически
трансформироваться, используя сервис преобразований (п.1.2). При созаднии структуры
сетевого контента Администратор указывает, какое преобразование использовать.
Администратор системы может указать, какое преобразование использовать по
умолчанию. По умолчанию используется преобразование в принятый в системе формат:
1.1.19.1 Для самих изображений - согласно "Требованиям к форматам данных" - JPEG с
максимальными размерами 720x576 px.
1.1.20.2 Для эскизов изображений - аналогично самим изображениям - JPEG с
максимальными размерами 120x96 px.
1.1.21 При удалении сетевого контента изображения и их эскизы из его галерей должны
автоматически удаляться
1.2 Дополнительные требования
1.2.1 Предлагается добавить в систему сервис LifeRay, осуществляющий трансформации
изображений с использованием ImageMagic, так чтобы все трансформации изображений
использовали этот сервис с некоторым набором исходных параметров.
1.2.2 Предлагается добавить в систему портлет, позволяющий администратору
настраивать параметры трансформаций через веб-интерфейс.
2. Публикация видеосюжетов
2.1 Основные требования
2.1.1 Публикация сюжетов должна работать аналогично публикации фотогалерей.
2.1.2 В систему должен быть добавлен новый тип данных для структуры сетевого
контента "Video Gallery"
2.1.3 Предполагается, что такой тип данных будет использоваться в новостях для
добавления в них галерей сопровождающих новость видеосюжетов.
2.1.4 Администратор сможет свободно добавлять поля такого типа в структуру сетевого
контента. При этом он сможет сделать такое поле повторяемым, позволяя тем самым
загружать в галерею более одного видео.
2.1.5 Менеджер, добавляющий сетевой контент на сайт, сможет добавлять видео в
соответствующее данному типу поле, не размещая их в Documents and Media.
2.1.6 Предполагается, что изображения из галерей будут автоматически размещаться в
стандартной директории хранения изображений LifeRay внутри структуры сетевого
контента.
2.1.7 Предполагается, что для посетителей портала галерея будет отображаться в виде
набора плейеров для просмотра онлайн-видео, по одному на каждое видео.
2.1.8 Предполагается, что добавленные в галерею видео в виде плейера для
воспроизведения онлайн-видео можно будет вставлять в любое html поле сетевого
контента с помощью инструмента выбора видео галереи, аналогичного уже
существующему инструменту добавления изображений из Documents and Media или по
URL.
2.1.9 Новый тип данных должен быть реализован с использованием стандартных решений
LifeRay, а для иллюстрации его работы в портале должны быть созданы тестовые
элементы портала.
2.1.10 Новый тип данных "Video Gallery" должен быть доступен при конфигурировании
полей структур сетевого контента через интерфейс администратора, аналогично другим
типам полей сетевого контента.
2.1.11 В систему должна быть добавлена тестовая структура, содержащая поле типа "Inline
Gallery" с дополнительным текстовым полем для комментария, для которого должна быть
включена возможность повторения.
2.1.12 В систему должен быть добавлен тестовый Velocity шаблон, отображающий такую
структуру в виде плейеров для просмотра онлайн-видео с отображением комментария для
каждого видео.
2.1.13 На панели инструментов редактирования текстового html поля должен добавиться
инструмент, позволяющий добавлять в html текст любое видео из галерей текущего
контента в виде плейера для просмотра онлайн-видео.
2.1.14 Клиентский функционал просмотра изображений галереи на клиенте рекомендуется
реализовать с помощью YUI Library / Alloy UI.
2.1.15 При создании сетевого контента с галереей добавляемые видео должно
размещаться на сервере автоматически без использования Documents and Media.
2.1.16 При добавлении или изменении сетевого контента у менеджера сайта должна быть
возможность загрузки видео, просмотра загруженных видео и удаления загруженных
видео.
2.1.17 При сохранении сетевого контента изображения галерей должны автоматически
трансформироваться в формат, соответствующий "Требованиям к форматам данных" :
2.1.18.1 HTML5 video с кодеками: H.264 + AAC с контейнером FLV. Это
предпочтительный вариант, поскольку можно не делать перекодировку на серверной
стороне.
2.1.18.2 Если указанные кодеки не поддерживаются, отображать как HTML5 video с
кодеком Theora + Vorbis и контейнером OGG
2.1.18.3 Если не поддерживается HTML5 video, отображать через Flash player с кодеками:
H.264 + AAC с контейнером FLV.
2.1.18.4 Если не поддерживается HTML5 video и кодеки H.264 + AAC, отображать через
Flash player с кодеками: Theora + Vorbis с контейнером OGG.
2.1.20 При удалении сетевого контента видео из его галерей должны автоматически
удаляться
2.4 Отображение видео на клиенте следует реализовать согласно требованиям к форматам
данных в следующем виде:
2.2 Дополнительные требования
2.2.1 Предлагается размещать видео не на главном сервере, а на отдельном медиа-сервере.
При этом предлагается сразу после закачки на главный сервер передавать видео на
медиасервер, так чтобы трансформация видео и вопроизведение видео для онлайнпросмотра велось с медиасервера.
2.2.2 Для трансформации и воспроизведения видео для онлайн-просмотра предлагается
использовать ffmpeg/ffserver или VLC player
2.2.3 Предлагается сделать трансформации видео управляемыми, доработав портлет,
управляюший трансформациями изображений.
2.3.4 Вопроизведение видео в онлайн-режиме должно поддерживать выгрузку видео по
кусочкам, так чтобы воспроизведение начиналось без загрузки всего файла, а
пользователь мог бы перемотать видео, так что после перемотки загрузка начиналось бы с
того кусочка на который перемотали, а не с начала видео.
3. Показ прямых трансляций
3.1 Публикация сюжетов должна работать аналогично видеогалереям.
3.1.1 В систему должен быть добавлен новый тип данных для структуры сетевого
контента "Video Stream Gallery"
3.1.2 Предполагается, что такой тип данных будет использоваться в новостях для
добавления набора прямых видеотрансляций в текст новости
3.1.3 Администратор сможет управлять списком доступных источников трансляций через
веб-интерфейс администратора.
3.1.4 Администратор сможет добавлять поля такого типа в структуру сетевого контента.
При этом он сможет сделать такое поле повторяемым, позволяя тем самым загружать в
галерею более одной трансляции одновременно.
3.1.5 Менеджер, добавляющий сетевой контент на сайт, сможет добавлять трансляции из
одного из сконфигурированных администратором источников в соответствующее
данному типу поле, и далее вставлять их в текст в любом html поле.
3.2 Для управления источниками трансляций в систему следует добавить портлет, в
котором администратор смог бы
3.2.1 Добавлять новые и редактировать и удалять существующие источники трансляции
3.2.2 Создавая и редактируя источники, задавать следующие параметры их источника:
3.2.2.1 Название
3.2.2.2 Адрес потока с одним из поддерживаемых протоколов - http, rtp, rtsp или mms.
Например, «http://192.168.1.8/video?id=za23wr64ty» - это внутренний адрес потока.
3.2.2.3 Нужна ли перекодировка, и если нужна - в какой из возможных форматов. По
умолчанию перекодирование потока не производится, но такую возможность следует
предусмотреть.
3.2.2.3 Дополнительные параметры - исходные аудио и видео кодеки, размеры, и другие
параметры, которые будут определены в ходе разработки.
3.3 Новый тип данных должен быть реализован с использованием стандартных решений
LifeRay - тип данных "Video Stream Gallery" должен быть доступен при
конфигурировании полей структур сетевого контента через интерфейс администратора,
аналогично другим типам полей сетевого контента.
3.4 Для иллюстрации работы нового типа данных в портале должны быть созданы
следующие тестовые элементы портала:
3.4.1 В систему должна быть добавлена тестовая структура веб-контента, содержащая
поле типа "Video Stream Gallery" с дополнительными текстовым полем для комментария,
полями задания времени начала и окончания трансляции и чекбокса записи трансляции.
3.4.2 В систему должен быть добавлен тестовый Velocity шаблон, отображающий такую
структуру в виде блока воспроизведения трансляции.
3.4.3 На панели инструментов редактирования текстового html поля должен добавиться
инструмент, позволяющий добавлять в html текст любую трансляцию из галерей текущего
контента в виде блока воспроизведения трансляции.
3.4.4 Клиентский функционал просмотра изображений галереи на клиенте рекомендуется
реализовать с помощью YUI Library / Alloy UI.
3.5 Серверная часть должна поддерживать все режимы ожидания и воспроизведения
трансляции.
3.5.1 У менеджера должна быть возможность свободно добавлять и удалять запись
трансляции (видео) к трансляции.
3.5.2 Поля где указывается время начала и окончания трансляции являются
обязательными. Окончание трансляции должно быть позже начала трансляции.
3.5.3 Если менеджер назначил дату начала трансляции в прошлом, трансляция
добавляется как прошедшая, если в будущем, то как планируемая.
3.5.4 Трансляция должна отображаться в виде блока вопроизведения трансляции:
3.5.4.1 Прошедшая трансляция показывается в виде плейера с возможностью просмотра
записи трансляции (если в трансляцию добавлена запись) или прямоугольника с
названием трансляции и надписью "Трансляция завершена в " + время окончания
трансляции (если записи трансляции нет).
3.5.4.2 Планируемая трансляция отображается в виде прямоугольника с названием
трансляции и надписью "Время до трансляции:" с указанием времени до трансляции (если
время трансляции еще не наступило) или плейера с возможностью просмотра трансляции
(если трансляция началась но еще не завершилась). После того как трансляция
закончилась, она автоматически трансформируется в прошедшую. В момент старта
трансляции блок автоматически переключается с прямоугольника на плейер.
3.5.5 В случае если была помечена как записываемая, сервер должен автоматически
записать идущую трансляцию и добавить получившееся видео как запись трансляции
после окончания трансляции.
3.5.6 Запись трансляции должна автоматически трансформироваться в стандартный
формат видео.
3.5.7 Запись трансляции должна размещаться на сервере аналогично видео из
видеогалерей, и также должна автоматически удаляться при удалении ее контента.
3.5.8 Ретрансляцией идущих трансляций и обработкой видео должен заниматься
медиасервер. На основном сервере должна храниться только конфигурация трансляций.
Подсистема «Корпоративный мессенджер»
Должна включать:
1. текстовый, голосовой, видеочат. Если на данный момент пользователь находится в
оффлайне, сохранять текстовые, голосовые и видео-сообщения и показывать их
пользователю, когда он выйдет в онлайн.
2. конференц-связь между пользователями, используя текстовые, голосовые и видеоконференции;
3. не требовать дополнительной авторизации и не задавать дополнительных вопросов при
включении в список пользователей на клиентском рабочем месте;
4. передача файлов;
5. перехват управления рабочим столом;
6. расшаривание рабочего стола;
7. возможность записи голосовой или видеоконференции или сеанса общения в аудио- или
видеофайл с сохранением файла в системе хранения документов. Если видеоконференция
или сеанс общения проводились в рамках какого-то проекта, сохранять файл в папке
проекта.
Подсистема должна запускаться и как отдельное приложение, и в виде портлета. Портлет
должен обеспечивать взаимодействие с другими подсистемами, используя способы,
указанные в п.п 4.1.1.3 и п.п 4.1.1.4. На клиентском рабочем месте подсистема должна или
работать:
1. Или полностью через веб-браузер с автоматической установкой активных компонентов
(апплетов, flash-player и прочего) — это предпочтительный вариант
2. Или, если необходима установка клиентских программ, выбирать программы,
соответствующие требованиям:


с нулевым администрированием со стороны клиента (пример — TeamViewer
Quicksupport),
кроссплатформенные или имеющие версии и для Windows, и для Linux.
Взаимодействие с другими подсистемами.
Корпоративный мессенджер должен иметь программный интерфейс, позволяющий на
серверной стороне:
1. послать текстовое, голосовое или видео- сообщение одному или нескольким
пользователям.
2. послать файлы одному или нескольким пользователям.
3. управлять текстовой, голосовой или видео-конференцией.
Взаимодействие с подсистемой документооборота.
В зависимости от настроек пользователя, автоматически оповещать пользователя о
событиях, связанных с его документами (появление новых, редактирование другими
пользователями, прохождение согласований, удаление и прочие события).
Взаимодействие с подсистемой проектов.
Пользователь, находящийся на главной странице проекта, должнен иметь возможности:
1. нажав ссылку, начать сеанс общения с другим участником проекта;
2. нажав ссылку, отметить галочками необходимых участников и начать конференцию.
Все отмеченные участники без дополнительных приглашений и подтверждений
включаются в конфренцию. Список участников по умолчанию формируется из списка
участников проекта, однако должна быть возможность добавить в него любого другого
пользователя системы.
3. нажав ссылку, присоединиться к идущей конференции без дополнительных
приглашений и подтверждений;
Требования к математическому
обеспечению системы
Математические методы и алгоритмы, используемые для шифрования/дешифрования
данных, а также программное обеспечение, реализующее их, должны быть
сертифицированы
уполномоченными
организациями
для
использования
в
государственных органах Российской Федерации.
Требования к информационному
обеспечению системы
Состав, структура и способы организации данных в системе должны быть определены на
этапе технического проектирования.
Уровень хранения данных в системе должен быть построен на основе современных
реляционных или объектно-реляционных СУБД. Для обеспечения целостности данных
должны использоваться встроенные механизмы СУБД.
Средства СУБД, а также средства используемых операционных систем должны
обеспечивать документирование и протоколирование обрабатываемой в системе
информации.
Структура базы данных должна поддерживать кодирование хранимой и обрабатываемой
информации в соответствии с общероссийскими классификаторами (там, где они
применимы).
Доступ к данным должен быть предоставлен только авторизованным пользователям с
учетом их служебных полномочий, а также с учетом категории запрашиваемой
информации.
Структура базы данных должна быть организована рациональным способом,
исключающим единовременную полную выгрузку информации, содержащейся в базе
данных системы.
Технические средства, обеспечивающие хранение информации, должны использовать
современные технологии, позволяющие обеспечить повышенную надежность хранения
данных и оперативную замену оборудования (распределенная избыточная
запись/считывание данных; зеркалирование; независимые дисковые массивы;
кластеризация).
В состав системы должна входить специализированная подсистема резервного
копирования и восстановления данных.
При проектировании и развертывании системы необходимо рассмотреть возможность
использования накопленной информации из уже функционирующих информационных
систем. Перечень функционирующих информационных систем приведен в разделе 3
настоящего документа.
Требования к лингвистическому обеспечению системы
Все прикладное программное обеспечение системы для организации взаимодействия с
пользователем должно использовать русский язык.
Требования к программному обеспечению системы
При проектировании и разработке системы необходимо максимально эффективным
образом использовать ранее закупленное программное обеспечение, как серверное, так и
для рабочих станций. По максимуму использовать соответствующее стандартам, с
открытым исходным кодом, бесплатное ПО.
Используемое при разработке программное обеспечение и библиотеки программных
кодов должны иметь широкое распространение, быть общедоступными и использоваться
в промышленных масштабах. Базовой программной платформой должна являться
платформа Java.
Программное обеспечение должно обеспечивать работу как в кластерной, так и в
стандартной конфигурации.
Порядок контроля и приёмки системы
Виды, состав, объем и методы испытаний системы
Базовая функциональность проверяется unit-тестами. Unit-тесты должны быть написаны
исполнителем для всех функций системы, кроме GUI.
Общие требования к приемке работ по стадиям
Сдача-приёмка работ производится поэтапно, в соответствии с рабочей программой и
календарным планом.
Сдача-приемка осуществляется комиссией, в состав которой входят представители
Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной
комиссии.
Все создаваемые в рамках настоящей работы программные изделия (за исключением
покупных) передаются Заказчику, как в виде готовых модулей, так и в виде исходных
кодов, представляемых в электронной форме на стандартном машинном носителе
(например, на компакт-диске).
Статус приемочной комиссии
Статус приемочной комиссии определяется Заказчиком до проведения испытаний.
Требования к составу и содержанию работ
по подготовке объекта автоматизации к
вводу системы в действие
В ходе выполнения проекта на объекте автоматизации требуется выполнить работы по
подготовке к вводу системы в действие. При подготовке к вводу в эксплуатацию Заказчик
должен обеспечить выполнение следующих работ:






Определить подразделение и ответственных должностных лиц, ответственных за
внедрение и проведение опытной эксплуатации ;
Обеспечить присутствие пользователей на обучении работе с системой,
проводимом Исполнителем;
Обеспечить соответствие помещений и рабочих мест пользователей системы в
соответствии с требованиями, изложенными в настоящем ТЗ;
Обеспечить выполнение требований, предъявляемых к программно-техническим
средствам, на которых должно быть развернуто программное обеспечение;
Совместно с Исполнителем подготовить план развертывания системы на
технических средствах Заказчика;
Провести опытную эксплуатацию.
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу
системы в действие, включая перечень основных мероприятий и их исполнителей должны
быть уточнены на стадии подготовки рабочей документации и по результатам опытной
эксплуатации.
Требования к документированию
Для системы на различных стадиях создания должны быть выпущены следующие
документы из числа предусмотренных в ГОСТ 34.201–89 «Информационная технология.
Комплекс стандартов на автоматизированные системы»:
1. Руководство разработчика
2. Software Architecture Document по стандарту RUP (Rational unified process)
3. Руководство администратора
4. Руководство технолога
5. Руководство пользователя. Руководство пользователя должно быть представлено в двух
видах:


в виде отдельного файла
интегрировано в справочную систему портала с привязкой к конкретным
приложениям.
Требования к обучению
Исполнитель проводит обучение:
1. Для разработчиков системы. Участвуют разработчики со стороны Заказчика, которые в
дальнейшем будут сопровождать и развивать систему.
2. Для администраторов системы.
3. Для конечных пользователей, участвующих в опытной эксплуатации, включая одного
технолога;
4. Для тренера конечных пользователей;