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

Главная / Блог / Статьи / Информационные / Проект сервиса создания юридических документов

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

Наша компания завершила проектирование сервиса создания документов и юридической поддержки для нашего партнера. Основное назначение сервиса - автоматизация процессов создания и согласования документов между двумя и более участниками. При этом сервис максимально упрощает процесс создания, заполнения, согласования, подписания и хранения (облачный сервис) документов за счет большого количества шаблонов документов, использования опросников, ЭЦП, web и мобильных приложений.

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

Все работы мы выполнили в соответствии с типовой методикой выполнения проектов, применяемой в нашей компании. Наш опыт может быть интересен другим компаниям и разработкам и поэтому мы постарались описать основные процессы, которые мы применяем для проектирования систем, на примере данного проекта.


Разработка технического задания - это процесс разработки архитектуры системы (продукта)

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

Особенно это важно в заказных проектах, когда заказчик должен определить состав и содержание работ для исполнителя, но не до конца имеет представление о деталях. При этом часто возникает ситуация, что на момент разработки ТЗ ни заказчик, ни клиент до конца не понимают что хотелось бы получить в результате.

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

Для примера, существуют методики MoDAF, ToGAF, DoDAF. В целом, они схожи в том, что предлагают рекомендации по структурированию представлений, моделей и порядку их разработки с целью всестороннего описания проектируемой системы. Все эти методики в основе имеют модель Захмана, которая описывает “кто-что-когда” должен выполнить и какой необходимо получить результат.

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




Что?
(Набор объектов)

Сущности, важные для компании, и связи между ними.

Как?
(Процессы)

Как работают процессы в компании.

Где?
(Сети распространения)

Где компания ведет бизнес. Где производит, куда поставляет и т.д.

Кто?
(Распределение ответственности)

Люди, их роли и их обязанности. Орг. структура компании.

Когда?
(Временные интервалы)

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

Почему?
(Мотивирующие факты)

Цели компании и её владельцев, стратегия компании и т.д.

1. Идентификация (контекстуальный).

Топ-менеджеры компании намечают границы изменения.  Они смотрят на него с высоты птичьего полета. В рамках интервью они рассказывают свою идею. Архитекторы готовят высокоуровневое описание рамок изменения. Например, описываются ключевые группы сущностей, которые участвуют в изменении, необходимы для него, на которые повлияет изменение.

Роль: планировщик.






Список сущностей важных для бизнеса.



Список бизнес процессов.


Список мест размещения бизнеса.


Список организаций важных для бизнеса.


Перечень событий важных для бизнеса.


Перечень бизнес целей и стратегий.


2. Определение (концептуальный).

На этом этапе формируем описание того, как изменится бизнес компании для реализации этого изменения. Когда и как поменяется орг. структура, обязанности сотрудников, бизнес-процессы и т.д.


Роль: владелец.

Концептуальная модель данных (методика)



Функциональная модель бизнес процессов (методика)



Информационные потоки (методика)



Модель потоков работ (методика)



Генеральный график

(диаграмма Ганта)



Прецеденты использования


3. Представление (логический).

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


Роль: архитектор.

Логическая модель данных (методика)



Системная архитектура приложения (методика)



Архитектура распределенной системы.


Человеко-машинный интерфейс.


График выполнения работ.

Модель бизнес правил.



4. Спецификация (физический).  Формируется подробное описание того, что и как нужно изменить в компонентах систем. Изменение кода инф. систем, спецификации на новое оборудование и куда оно будет установлено и т.д.


Роль: подрядчик.

Физическая модель данных (методика).



Описание функций и процедур приложения.

Технологическая архитектура.


Образцы презентации.



Операционный график.

Определение правил.

5. Конфигурация (из контекста).

На этом этапе выполняются работы по реализации изменения. Все, что нужно было выполнить, реализуем в нужной последовательности правильными людьми.


Роль: разработчик.

Определение данных.

Программа.

Сетевая архитектура.

Архитектура безопасности.

Контроль времени.

Разработка правил.

6. Готовая система (пользовательский). Проверяем, как работа  повлияла на компанию.

Роль: пользователь.

База данных.

Приложение.

Сеть.

Организация.

Расписание.

Стратегия.



Архитектурные представления

Все работы можно объединить в четыре основных представления:

  • Общее описание
  • Функциональное представление
  • Системное представление
  • Технологическое представление

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

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

План-проспект отчета

  1. Общее описание
    1. Цели проекта
      Раздел содержит информацию о замысле, целях, задачах проекта.

    2. Границы проекта
      Основные ограничения проекта: по целям, задачам, связям с другими системами, ограничения временные и ресурсные.

    3. Бизнес-сценарии использования
      Несколько основных бизнес-сценариев (user story), для автоматизации которых создается система. В сценариях должны быть указаны желаемое поведение системы, пользователи, достигаемые результаты, возможно, временные и другие показатели.
      Основных сценариев должно быть не более трех.  Остальные сценарии - дополняющие. На основании бизнес-сценариев создается функциональная и системная архитектура системы.

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

    5. Термины и определения
      Перечень терминов проекта. Необходим для того, чтобы все участники проекта манипулировали одними понятиями.

  2. Функциональное представление

    1. Основные сценарии использования системы
      Формализованное описание сценариев использования системы. Это представление строится на базе бизнес-сценариев и детализирует их с точки зрения функций проектируемой системы. В каждом сценарии должны быть прописаны виды действий и их взаимосвязи, пользователи (роли), внешние системы.
      Сценарии могут быть представлены в виде UML диаграмм Use Cases.

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

    3. Функции системы
      Список функций проектируемой системы. Функции должны быть детализированы до уровня, понятного системному архитектору. При этом должна быть установлена приоритетность (важность) функций. Эти функции являются основой для Технического задания.
      Сценарии могут быть представлены в виде UML диаграмм Activity или в виде матричных форм.

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

    5. Связи с внешними системами
      В разделе должно быть описано взаимодействие с внешними системами: состав, потоки данных.

    6. Стандарты, правила, регламенты, нормативные документы,  законодательные ограничения
      Нормативные и иные ограничения или требования к системе. Например, требования ФЗ по защите персональных данных. Требования, которые должны быть учтены при разработке системных компонентов.

  3. Системное представление

    1. Компоненты системы
      Формализованное описание системных компонентов и их функции: серверы, модули, сервисы, базы данных. Компоненты системы должны реализовывать ранее описанные функции системы.

    2. Логическая модель данных
      Модель данных системы, основные атрибуты объектов. На основании логической модели данных выбирается физическая реализация (SQL/NoSQL, распределение и т.п.)

    3. Интеграция с внешними системами
      Протоколы взаимодействия с внешними системами (API).

    4. Пользовательский интерфейс
      Структура и дизайн пользовательского интерфейса

    5. Размещение элементов системы
      В разделе описывается количество и размещение аппаратного обеспечения, схемы размещения программных компонентов на аппаратных ресурсах.

  4. Технологическое представление

    1. Физическая модель данных (основные элементы)
      Структуры данных в формате выбранных СУБД

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

  5. План закупок и расходов на IT

    1. Закупки программных продуктов
      Необходимые закупки программных средств, например, лицензии на СУБД или инструментарий разработки.

    2. Хостинг
      Необходимые затраты на хостинг, параметры хостинга, размещение.

    3. Затраты на использование внешних сервисов
      Необходимые затраты на внешние сервисы, используемые в разработке или при функционировании системы. Например, сервис рассылки SMS.

  6. План реализации

    1. Работы, исполнители, сроки
      В разделе должен быть описан ориентировочный план работ по разработке системы с привлечением исполнителей и сроками.

    2. Метрики
      Основные KPI, которые планируется достигать на разных этапах разработки, функционирования системы.


Артефакты - документы, модели, диаграммы

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



Для описания моделей и описания произвольных проектных материалов мы используем текстовые и графические документы. Как правило, это Word-документ, Excel-документ или презентация. Часто для произвольных описаний используются обычные графические изображения. Например, общая концепция и замысел системы может быть описана в виде изображения с поясняющим текстом. Удобным является совместное редактирование и просмотр документов, т.к. это позволяет выполнять работу нескольким сотрудникам в одно время. Например, дизайнер занимается разработкой раздела дизайна, системный архитектор - общим описанием, а Заказчик - редактированием и правками.

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

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

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

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

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

Для описания графиков и этапов выполнения проекта могут применяться различные табличные и графические представления. Мы активно используем диаграммы Гантта, которые удобны для наглядного представления последовательности работ, связей, ресурсов, исполнителей. Диаграмма Гантта позволяет предложить и согласовать порядок разработки, а также общий график выполнения со сроками. При необходимости, объемы работ удобно редактировать добавляя и удаляя работы, общий график работ при этом остается связанным и согласованным.


Для каждого артефакта есть инструмент

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

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

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


Google Drive (ссылка)

Google Диск — это файловый хостинг, созданный и поддерживаемый компанией Google. Его функции включают хранение файлов в Интернете, общий доступ к ним и совместное редактирование. В состав Google Диска входят Google Документы, Таблицы и Презентации — набор офисных приложений для совместной работы над текстовыми документами, электронными таблицами, презентациями, чертежами, веб-формами и другими файлами. Общедоступные документы на Диске индексируются поисковыми системами.

Google Drive имеет удобную систему разграничения доступа, подключения новых участников и предоставления открытого доступа к папкам и файлам. Это позволяет создать любую проектную структуру файлового хранилища и настроить разграничение доступа к любому элементу.


Google Docs (ссылка)

Документы Google — бесплатный онлайн-офис, включающий в себя текстовый, табличный процессор и сервис для создания презентаций, а также интернет-сервис облачного хранения файлов с функциями файлообмена, разрабатываемый компанией Google. Образован в итоге слияния Writely и Google Spreadsheets. Для мобильных платформ Google Android и Apple iOS компания разрабатывает специальную редакцию приложений.

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


Draw.io (ссылка)

Draw.io pro - это бесплатное приложение на диске Google для создания диаграмм, которое позволяет рисовать:
  • Блок-схемы
  • UML
  • Диаграммы сущность-связь
  • Сетевые диаграммы
  • Модели бизнес-процессов
  • Организационные схемы
  • Электрические схемы
  • Каркасные схемы и модели
Возможности:
  • Собственный HTML 5 Client (с полной поддержкой IE 6-8)
  • Большая встроенная библиотека элементов
  • Интуитивный интерфейс по принципу перетаскивания
  • Функция поиска и добавления изображений
  • Экспорт в форматы PNG/JPG/XML/SVG/PDF
  • Поддержка сенсорными устройствами
  • Совместная работа в реальном времени
  • Вставка диаграмм в блоги и вики-сайты


Gantter (ссылка)

Gantter - приложение для Google Drive, которое позволяет создавать диаграммы Гантта, а также открывать и редактировать файлы MS Project. Приложение интегрировано с другими Google-сервисами и удобно включается в общую архитектуру Google Drive.


Balsamiq Mockups  (ссылка)

Balsamiq Mockups — это сервис для построения макетов пользовательских интерфейсов веб-сайтов, мобильных приложений и обычных программ.

Приложение имеет большое количество шаблонных элементов дизайна, вариантов их организации (мобильные телефоны, Web-браузеры). Для создания дизайн-макета достаточно в каталоге выбрать требуемый элемент интерфейса и перетащить его в нужное место. Готовых элементов имеется огромное количество и все они разбиты на тематические категории. После окончания работы над макетом его можно сохранить в форматах PNG или PDF.


Mockingbot (ссылка)

Разработчики сервиса https://mockingbot.com/ позиционируют сервис как онлайн-платформу, позволяющую пользователям создавать интерактивные макеты и прототипы мобильных приложений. Складывается впечатление, что разработчики старались сделать систему, подобную Sketch, только в виде онлайн-сервиса. И у них получилось. Этим сервисом мы пользуемся в большинстве проектов при проектировании мобильных приложений.

Ключевые возможности сервиса:

  1. типовые шаблоны для различных устройств и разрешений (телефоны, планшеты, Web);
  2. типовые элементы управления, спроектированные с учетом целевой платформы;
  3. интерактивный макет. Сервис позволяет связывать скрины между собой и "запускать" макет в браузере;
  4. выгрузка макета в PNG, HTML, в виде приложения для Android/iOS. Для демонстрации макета на мобильном устройстве достаточно сканировать QR-код на сайте и макет будет загружен на устройство;
  5. возможность создания и использования собственных шаблонов UI с собственным поведением и состояниями;
  6. гибкие механизмы по управлению UI (цвет, размеры, фон, изображения, ...) макета;
  7. личные и открытые проекты.
  8. Совместное создание и редактирование проектов, разделение ролей
  9. возможность отправить открытую ссылку на макет

В статье https://primesoftpro.ru/blog/mobilnost/material_183/ есть подборка различных бесплатных инструментов прототипирования макетов. При желании можно выбрать любой.

Формирование ТЗ

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

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

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

Как результат, в результате выполненных нами работ, Заказчик получил полный комплект проектных документов, включая технические требования, дизайн, график выполнения и смету затрат. На основании чего принимает решение о дальнейших действиях.