Оглавление

Оглавление

1. Термины, используемые в техническом задании. 3

2. Общие положения. 3

2.1. Название системы.. 3

2.2. Наименование предприятий разработчика и заказчика системы и их реквизиты.. 3

2.3. Порядок внесения изменений в техническое задание. 3

3. Порядок оформления и предъявления заказчику результатов работ. 4

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

4.1. Цели создания системы.. 4

4.2. Задачи, решаемые при помощи системы.. 4

4.3. Целевая аудитория системы.. 4

5. Требования к системе и программному обеспечению.. 4

5.1. Требования к программному обеспечению системы.. 4

5.2. Требования к численности и квалификации персонала, обслуживающего систему. 4

5.3. Требования к системе администрирования. 4

6. Языковые версии системы.. 5

7. Группы пользователей. 5

8. Дизайн системы.. 5

9. Структура системы.. 5

10. Описание блока №1. 6

11. Описание элементов блока №1. 7

11.1. Управление. 7

11.2. Конструктор БД.. 8

11.3. Пользователи, роли, отношения. 9

11.4. Конструктор логики. 10

11.5. Ввод-Вывод. 11

12. Функциональное описание блока №1. 13

12.1. Процесс построения CRM-системы.. 13

12.2. Основные функциональные возможности. 14

13. Описание протокола ввода – вывода. 15

14. Контент и наполнение системы.. 16

15. Дополнительная информация. 16

16. Порядок контроля и приемки работ. 16

17. Реквизиты и подписи сторон. 16

1.  Термины, используемые в техническом задании

Браузер — программа-клиент (Internet Explorer, FireFox, Opera, Safari, Chrome и т. п.), предоставляющая пользователю возможности навигации по сайтам, просмотру сайтов и скачивания файлов.

Веб-страница — HTML-документ сайта, отображаемый браузером пользователя и имеющий уникальный URL-адрес.

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

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

2.  Общие положения

2.1.  Название системы

Блок №1 (связующие ядро) для конструктора CRM-систем.

2.2.  Наименование предприятий разработчика и заказчика системы и их реквизиты

2.3.  Порядок внесения изменений в техническое задание

Частота обновления  — отсутствует;

Плановый пересмотр — отсутствует;

Неплановый пересмотр — при согласовании ТЗ с Разработчиком.

3.  Порядок оформления и предъявления заказчику результатов работ

Готовый блок передается заказчику в виде виртуальной машины (VMWare) и исходных кодов.

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

4.1.  Цели создания системы

Основная цель создания системы заключается в ускорении разработки CRM-систем под нужды клиентов заказчика.

4.2.  Задачи, решаемые при помощи системы

Задачи связанные с ведением СРМ-деятельности заказчика.

4.3.  Целевая аудитория системы

Сотрудники компании заказчика.

5.  Требования к системе и программному обеспечению

5.1.  Требования к программному обеспечению системы

Для функционирования системы необходимо установленное программное обеспечение VMWare server 2.0. http://www. /ru/products/datacenter-virtualization/server/overview. html

5.2.  Требования к численности и квалификации персонала, обслуживающего систему

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

5.3.  Требования к системе администрирования

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

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

5.3.2.  Редактирование информации

Создание и редактирование информации в системе разрешается только пользователям с соответствующими правами доступа.

5.3.3.  Управление пользователями и правами доступа

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

6.  Языковые версии системы

Язык и локализация блока должна быть полностью на русском языке. Кодировка, используемая в блоке и базах данных, должна быть (UTF-8).

7.  Группы пользователей

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

8.  Дизайн системы

Требования не предъявляются.

9.  Структура системы

Система (CRM-конструктор) представляет из себя функционально законченную среду для создания СRM-систем под цели заказчика. Система состоит из ряда блоков (Рисунок 1). В данном техническом задании рассматривается только Блок №1 (Связующие ядро).

Рисунок 1 - общая структура CRM-конструктора.

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

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

·  Блок подключаемых модулей – Блок представляет из себя хранилище существующих подключаемых модулей (личные кабинеты, система баннеров и т. д. ) и организует связи необходимых модулей с остальными элементами системы.

·  Блок отчетности – Блок предназначен для формирования требуемой отчетности. Он содержит конструктор отчетов с программируемыми функциями.

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

·  Блок интеграции с подрядчиками – Блок предназначении для организации взаимодействия с внешними подрядчиками предоставляющими различные сервисы (email рассылки, смс рассылки и т. д.)

·  Блок интеграции с внешними системами и сайтами – Основная задача данного блока осуществлять взаимодействие со встраиваемым программным кодом в сторонние порталы, системы, сайты (Форма обратной связи на сайте клиента и т. д.)

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

10.  Описание блока №1

Основная назначение блока заключается в первоначальной настройке рабочего пространства, организации ролей и логики взаимодействия, формирование хранилищ по данные. Фактически блок производит подготовку и настройку алгоритмов работы создаваемой под проект CRM-системы. Структурная схема блока представлена на (Рисунок 2).

Рисунок 2 - структурная схема блока №1 (связующие ядро).

Блок состоит из следующего набора элементов:

·  Управление (настроечный интерфейс);

·  Конструктор БД (внутренние проектные базы данных);

·  Пользователи, роли, отношения (типы пользователей со индивидуальными правами и обязанностями в создаваемой системе);

·  Конструктор логики (алгоритмы работы создаваемой системы);

·  Ввод-Вывод (шина обмена данными).

11.  Описание элементов блока №1

11.1.  Управление

Данный элемент блока №1 предназначен для управления созданными CRM-системами, фактически все создание и настройка производится именно из этого элемента. Он содержит весь административный интерфейс.

Модульная схема элемента управления представлена на (Рисунок 3).

Рисунок 3 - модульная схема элемента управления.

Элемент управления состоит рада модулей:

·  Модуль авторизации – предназначен для управления доступами к конструктору организации полномочий административного персонала.

·  Модуль проектов – представляет из себя список всех проектов созданных в CRM-конструкторе. Позволяет создавать новые проекты, связывать их с клиентами. Основная задача модуля связать созданную CRM-систему с CRM-конструктором.

·  Модуль плагинов – предназначен для настройки необходимых плагинов (рабочих модулей ) создаваемой системы. Модуль организует изолированные настройке под каждый проект.

·  Модуль ролей – отвечает за формирование всех типов ролей которые будут использоваться в создаваемой CRM-системе. По сути список типов участников.

·  Модуль данных – основное назначение это управление элементом «конструктор БД». Позволяет настраивать структуру базы данных создаваемой системы. Или менять существующую.

·  Модуль скриптов логики – основное назначение это управление элементом «конструктор Логики». Позволяет производить связывание объектов в создаваемой CRM-системе между собой, прописывание условий и прав доступа ролям. А также организацию процесса работы в создаваемой CRM-системе.

11.2.  Конструктор БД

Модуль представляет из себя механизмы работы с различными СУБД. Он позволяет создавать структуру и формировать связи между сущностями. Основное назначение - создание готово базы данных под создаваемую CRM-систему, создание объектно реляционных проекций (ORM) сущностей создаваемой CRM-системы и организация управления данными через объекты.

Модульная схема элемента конструктор БД представлена на (Рисунок 4)

Рисунок 4 - модульная схема элемента "конструктор БД".

Элемент «конструктор БД» состоит:

·  Модуль СУБД – предназначен для конфигурирования серверов СУБД. Организации доступа к ним, формирование логики создания баз данных. Так же позволяет организовать резервирование автоматические копии, и при необходимости репликации между серверами.

·  Модуль проектных БД – основная задача связана с управлением проектными базами данных на сервере СУБД. Модуль организует унифицированный интерфейс работы с запросами на основе скриптового языка SQL.

·  Модуль миграций – содержит наборы миграций описывающих структуру таблиц базы данных. Позволяет производить изменение структуры сущностей системы.

·  Модуль скриптов – наборы скриптов связывающих реляционные данные из модуля БД с объектами. Основное функциональное назначение конфигурирования сохранения и загрузки объектов в базу данных (объект может быть составным и содержатся в нескольких таблицах базы данных).

·  Модуль объектов - предназначен для управления созданной базой данных через объекты. Фактически представляет из себя программный интерфейс по работе с БД. Все остальные проектные элементы и модули системы работают с данным модулем.

11.3.  Пользователи, роли, отношения

Элемент пользователей, ролей, отношений предназначен для организации всех существующих типов пользователей в создаваемой CRM-системе. С разделением их на группы, установкой степеней доступа к данным. Как и в элементе «конструктор БД», в данном элементе основная задача – создание объектов пользователей системы.

Модульная схема элемента пользователей, ролей, отношений представлена на (Рисунок 5).

Рисунок 5 - модульная схема элемента пользователей, ролей, отношений.

Элемент пользователей, ролей, отношений содержит:

·  Модуль типов пользователей – предназначен для организации типов пользователей которые будут участвовать в CRM-системе. Так же модуль предоставляет возможность организовать группы (к примеру: покупатели, клиент, сотрудники компании, сотрудники подрядчика и т. д.).

·  Модуль структуры пользователей – предназначен для формирования структуры каждого типа пользователей, фактически формирует те наборы полей и связок которыми должен обладать тип пользователя.

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

·  Модуль отношений между типами – основная задача данного модуля организация взаимоотношений между типами пользователей (к примеру: покупатели и клиент связаны с сотрудниками компании а они в свою очередь связаны с сотрудниками подрядчика и т. д. т. е. сотрудники подрядчика не взаимодействуют с покупателями и клиентами напрямую).

·  Модуль объектов – аналогично модулю объектов в элементе «конструктор БД». Все остальные проектные элементы и модули системы работают с данным модулем.

11.4.  Конструктор логики

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

Модульная схема элемента «конструктор логики» представлена на (Рисунок 6).

Рисунок 6 - модульная схема элемента "конструктор логики".

Элемент «конструктор логики» содержит:

·  Модуль процессов – предназначен для формирования процессов которые могут проходить в создаваемой CRM-системе (к примеру: процесс звонок покупателю, процесс регистрация покупателя, процесс формирования отчета клиентом и т. д.)

·  Модуль данных – необходим для работы с объектами данных создаваемой CRM-системы. Позволяет установить поведение объектов, правила создания, удаления, изменения, различные количественные показатели и т. д.

·  Модуль пользователей – по сути тоже самое что и модуль данных только по работе с пользователями. Также позволяет создать поведение объектов, условия создания и т. д.

·  Модуль связей – основной модуль Блока №1 (связующего ядра). Фактически на основе процессов, пользователей, данных формирует взаимосвязи между ними. Позволяет задавать степень доступа к данным пользователей в рамках проходящего процесса. Организует последовательности доступов и условий доступов к данным. Представляет из себя визуальный конструктор связей обектов.

·  Модуль миграций – модуль предназначен для работы с таблицами бд хранящими данные о процессах. Фактически хранение настроек создаваемой CRM-системы.

11.5.  Ввод-Вывод

Основная задача данного элемента организация обмена данными с другими блоками системы. Элемент предоставляет унифицированный протокол обмена данными на основе формата JSON, XML. Фактически через этот элемент происходит все взаимодействие между данными и пользователями.

Модульная схема элемента «ввод - вывод» представлена на (Рисунок 7).

Рисунок 7 - модульная схема элемента "ввод - вывод".

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

·  Модуль обмена данными – набор блоков обеспечивающих надлежащее выполнение процессов обмена данными между различными внутренними и внешними элементами управления системой. И состоит из следующих блоков:

o  Параметры синхронизации сущностей – конфигурационное хранилище, которое описывает правила обмена и отношения между сущностями

o  Блок выборки данных – осуществляет подбор данных, которые требуется отправить, на основании запроса и параметров синхронизации сущностей.

o  Блок сохранения данных – осуществляет сохранение разобранных данных, в соответствии с параметрами синхронизации сущностей.

o  Блок подготовки данных к отправке – осуществляет формирование выходных пакетов данных, на основании данных от блока выборки данных и передачу соответствующему интерфейсу для отправки.

o  Блок структурирования полученных данных – отвечает за формирование задания для блока сохранения данных на основании чтения входного формата данных, полученного от интерфейсов.

o  БД обмена данными – осуществляет хранение истории синхронизаций, доступов и сессией обмена данными.

o  Блоки уведомлений - отвечают за уведомление внутренних и внешних потребителей о состоянии и завершении процесса обмена данными.

o  Внутренний интерфейс обмена данными – интерфейсы к модулю ввода-вывода для внутреннего обмена данными между блоками и модулями системы.

o  Внешний интерфейс обмена данными – содержит правила и форматы обмена данными для внешних потребителей и поставщиков данных.

12.  Функциональное описание блока №1

12.1.  Процесс построения CRM-системы

Блок №1 (связующие ядро) является отправной точкой по созданию CRM-системы. поэтому процесс создания начинается именно с него. Схема процесса создания CRM-системы представлена на (Рисунок 8).

Рисунок 8 - схема процесса создания CRM-системы.

Результатом данных действий является весь перечень настроек и конфигурации для запуска автоматического разворачивания CRM-системы. Система автоматически создаст rails-приложение со всей логикой занесенной в настройки. Фактически после создание CRM-системы, она становится доступна как отдельно стоящие приложение.

12.2.  Основные функциональные возможности

Основными функциональными возможностями Блока №1, по сути, является создание конфигурации и изолированной БД под конфигурацию. Далее на основе rails’овских механизмов происходит создание полноценного приложения которое автономно через Блок №1 взаимодействует с остальными блоками системы. Функциональные возможности разрабатываемой CRM-системы ограничиваются только возможностями языков и средств разработки (Ruby on rails, sql и т. д.).

13.  Описание протокола ввода – вывода

Все блоки системы обмениваются данными через элемент блок №1 связующего ядра. Общий принцип обмена представлен на (Рисунок 9).

Рисунок 9 - схема принципа обмена данными между блоками.

Базовый протокол обмена данными в системе представлят собой пакет данных, который состоит из двух или трех частей:

·  Заголовок - содержит информацию о структуре пакета и передаваемых в нем данных, в том числе (аутентификационные данные, версионность, временные параметры, контрольные суммы передаваемых данных, сессионную инфомрацию, информацию о получателе). Необязательная часть пакета, так как для внутреннего обмена данными может и не передаваться в целях минимизации избыточности.

·  Тело сообщения – содержит передаваемые данные, в одном из поддерживаемых форматов (JSON, XML, BASE64). В случае отсутствия заголовка, содержит так же информацию об отправителе и получателе, так как для внутренних систем применяется упрощенная авторизация, а потери данных минимизированы.

·  Приложения – содержит дополнительные файлы, которые могут передаваться, как в составе пакета, так и отдельно.

14.  Контент и наполнение системы

Контент и первоначальное наполнение системы осуществляется силами заказчика.

15.  Дополнительная информация

Любые изменения и дополнения данного технического задания возможны при согласовании заказчика и исполнителя.

16.  Порядок контроля и приемки работ

Порядок определяется планом разработки проекта представляемого заказчику исполнителем перед началом работ.