2. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
2.1. Этапы жизненного цикла проекта автоматизации и выбор стратегии его внедрения
Современный жизненный цикл ИТ представляет собой поэтапный процесс, охватывающий различные состояния системы, начиная с того момента, когда система необходима, и до ее полного отключения.
Поскольку разработка ИС компании, как правило, специфична для конкретной компании, специфика целевой деятельности компании влияет на ее структуру. Однако организационная структура компаний с разными сферами деятельности схожа, поэтому каждая компания имеет несколько отделов, которые занимаются тем или иным бизнесом в этой компании, вне зависимости от того, что она продает или производит. Такая ситуация справедлива для всех организаций независимо от вида деятельности [39].
Корпоративные информационные системы разрабатываются в форме проектов, но многие функции на этапе управления проектами и разработки проект являются общими и не зависят от характера проекта или объема темы. Поэтому следует рассматривать общую проблему управления проектами.
Проект – это конкретное, обдуманное, рассчитанное во времени изменение в независимой системе с четко определенной начальной целью, достижение которой определяет эффективность проекта. Проект также требует риска, времени, финансирования, ресурсов, результатов и организационной структуры проекта.
Каждый проект проходит через определенные состояния, которые необходимо завершить, независимо от размера и сложности проделанной в нем работы. Проект начался по плану, без документов, сейчас он завершен. Совокупность стадий развития проекта, от генерации идеи до ее завершения, делится на этапы (этапы, этапы).
Вместе с тем существуют определенные различия в определении необходимого количества этапов и их содержания, так как эти характеристики зависят не только от конкретных условий реализации проекта, но и от опыта участников проекта. Однако основное содержание и логика процесса разработки информационной системы в большинстве случаев являются общими.
Рассмотрим текущие этапы развития информационных систем.
1) Концептуализация. Этот этап определяет не только характер проекта, но и его концепцию. Это включает в себя:
- разработка идеи проекта и постановка целей;
- организация команды проекта;
- изучение требований заказчиков и других участников проекта и определите их мотивы;
- сбор первичных данных и анализ текущего состояния бизнес-операций.
- определение ключевых функциональных требований и ограничения в отношении физических, финансовых и человеческих ресурсов;
- сравнительная оценка доступных вариантов;
- подготовка, рассмотрение и утверждение проектных предложений.
2) разработать должностную инструкцию. На этом этапе разрабатываются технические спецификации (ТЗ) и заключаются контракты с заказчиками.
Передача средств коммуникации и мониторинг хода работы участников проекта.
3) дизайн. Этот шаг включает в себя определение подсистем и их взаимосвязей, завершение проекта и выбор наиболее эффективного способа использования доступных ресурсов. Этот этап включает в себя следующее:
- выполнение основных задач проекта;
- развитие традиционных специальных знаний;
- концептуальный дизайн;
- подготовка технических инструкций и спецификаций;
- разработка модели, рассмотрение и утверждение.
При этом определяются выходные и входные потоки, их виды, средства защиты информации, программно-вычислительные комплексы. На этом этапе разрабатываются схема данных, связь с программными модулями, список операций, диаграмма системных ресурсов и диаграмма программных модулей.
4) производство. На этом этапе осуществляется управление проектными работами, подсистемы разрабатываются, объединяются в единое целое и тестируются. Суть этого шага в следующем:
- выполнение работ по разработке программного обеспечения;
- подготовка к внедрению разработанной системы;
- управление основами программы.
5) Запустить разработанную систему. Это включает в себя тестирование системы, запуск ее в реальных условиях, обсуждение результатов проекта и возможность заключения нового контракта. Суть этого шага в следующем.
- провести комплексное тестирование разработанной системы.
- обучить персонал работе с системой;
- составление соответствующей документации, сдача разработанной системы пользователям, первоначальная пуско-наладка, а затем внедрение в производственную эксплуатацию.
- сопровождение программы, поддержка и сервис.
- оценить результаты проекта и подготовьте итоговый документ.
- разрешать различные споры, возникающие в ходе проектной деятельности и выполнения всех проектных задач.
- хранить и обобщать эмпирические данные для реализации будущих проектов, анализировать опыт, полученный в рамках проекта, и определять другие направления развития [4].
Второй и третий этапы часто называют этапом системной инженерии, а последние два этапа называют этапом реализации проекта.
Ранние этапы проекта должны иметь решающее влияние на достигнутые результаты, так как принимаются решения, которые определят качество будущего. Однако, как правило, 30 % результатов проекта приходится на этап концепции и моделирования, 20 % — на этап разработки и проектирования, а остальные 30 % — на этап эксплуатации объекта.
Концепция жизненного цикла является одной из фундаментальных концепций проектирования систем. Жизненный цикл — это непрерывный процесс, который начинается с решений по разработке и продолжается в процессе развертывания.
В настоящее время существует международный стандарт ISO/IEC 12207 (ISO — Международная организация по стандартизации), определяющий время жизни ИС (далее p-цикл). …
ISO/IEC 12207 используется для определения объема жизненного цикла, включая процессы, действия и задачи, выполняемые во время разработки. Стандартная структура курса основана на трех практических группах:
ИС, разработка, эксплуатация и сопровождение ИС) приобретение и внедрение.
Это поможет с ключевыми действиями, такими как документация, качество, состав, аудит, проверка и визуализация.
Организационные процессы, такие как управление проектами, анализ жизненного цикла инфраструктуры проекта и обучение совершенствованию.
Важнейшим процессом жизненного цикла является разработка и эксплуатация информационных систем. Кроме того, каждый процесс обычно отличается от конкретных проблем, решений и результатов предыдущих «реализованных» шагов.
Разработка информационной системы включает в себя все действия по созданию программного обеспечения и его компонентов в соответствии с требованиями. Обработка информации включает следующие этапы:
— подготовка проектной документации.
— разработанный программный продукт (далее ПП)
Модель жизненного цикла ИС представляет собой структуру, описывающую набор действий, процессов и задач, которые должны быть выполнены в течение жизненного цикла ИС, а также отношения между этими задачами, процессами и процедурами.
Стандарт ISO/IEC 12207 не рассматривает вопросы и процедуры, методы реализации и детали, относящиеся к процессу жизненного цикла ИС, и, поскольку стандарт является общим, он предоставляет только описание структуры процесса. Модель жизненного цикла, но для всех технологий и методов разработки программного обеспечения. Модель жизненного цикла зависит от характеристик ИС и условий ее разработки и функционирования. Поэтому не имеет смысла предоставлять конкретную модель жизненного цикла и методологию для общего развития ИТ без привязки к конкретным темам. На сегодняшний день наиболее распространены две модели жизненного цикла:
- модель водопада;
- итерационная модель;
- спираль.
Последовательное проектирование — это классический способ разработки разнообразных систем, независимо от области их применения. Эта модель широко использовалась при разработке информационных систем в семидесятых и восьмидесятых годах. Метод каскадного проектирования хорошо описан в отечественной и зарубежной литературе в различных областях, включая стандарты, методологические исследования и учебники. Каскадная организация труда официально рекомендована и широко применяется в различных отраслях промышленности.
Водопадная модель представляет собой последовательную организацию задач. При этом главной особенностью этой модели является разделение этапов разработки всего программного продукта. Обратите внимание, что переход от одного шага к другому не выполняется после выполнения всех задач на предыдущем шаге. При этом каждый этап завершается выпуском пакета документов, достаточного для дальнейшей разработки сторонними командами разработчиков.
На сегодняшний день существует несколько стабильных фаз разработки программного обеспечения, которые в значительной степени не зависят от темы.
- анализ требований заказчика.
- проектирование системы (разработка алгоритма, прототип, реализация структуры базы данных);
- разработка системы;
- тестирование разработанной продукции;
- поставка готовой продукции.
Первым шагом водопадной модели является изучение решаемой проблемы и четкое определение всех требований пользователя. Результатом этого шага является курс действий, согласованный всеми сторонами (далее ТП).
На втором этапе разрабатывается проектное решение, отвечающее всем требованиям, указанным в техническом задании.
Третий этап – реализация проекта.
На четвертом этапе разработанное программное обеспечение проверяется на соответствие требованиям, указанным в ТЗ. При этом задание выявляет ряд скрытых недостатков, которые выявляются только в реальных условиях работы ИСИС.
Заключительный этап – сдача финального проекта. Его главная задача – убедить клиента полностью выполнить все требования.
Каскадная модель хорошо зарекомендовала себя и широко используется во многих видах развития технологий, поэтому имеет положительные стороны.
Рассмотрим основные преимущества использования данной формы:
- на каждом этапе каскадной модели создается полный комплект проектной документации, отвечающий критериям непротиворечивости и полноты. Заключительный этап предполагает разработку пользовательской документации. Он включает поддержку всех типов IP, указанных стандартом. Методология, данные, организация, аппаратное и программное обеспечение.
- этапы работ, выполняемые в логической последовательности, позволяют планировать не только время выполнения, но и связанные с ним затраты.
В то же время эти недостатки делают данную модель полностью непригодной для использования, либо увеличивают стоимость и сроки разработки проекта. На сегодняшний день многие программные проекты потерпели неудачу из-за использования неподходящих процессов разработки.
Рассмотрим недостатки использования регрессионных моделей при разработке ИС.
- результаты разработки системы сильно запаздывают. Этот недостаток в основном связан с тем, что в результате использования последовательного метода обработки результаты согласовываются с клиентом только после завершения очередного этапа работ.
- как правило, ошибки и дефекты обнаруживаются не на текущем этапе работы, а на следующем этапе работы, что сразу приводит к необходимости возврата на предыдущий этап. Непрерывный пошаговый процесс над проектом часто является результатом ошибок, допущенных на первом этапе, которые обнаруживаются только при работе над следующим этапом проекта. Поэтому при обнаружении ошибки проект возвращается к предыдущему шагу, ошибка устраняется, и проект переходит к следующему шагу. Как правило, они усложняют взаимодействие между командами разработчиков, выполняющими отдельные этапы работы, и являются основной причиной путаницы в рабочих графиках.
- сложность параллельных проектных работ. Сложность параллельной работы заключается в необходимости постоянной координации между разными частями проекта. Чем больше отдельные части проекта связаны друг с другом, тем более синхронизированы эти части и тем более связанной становится команда разработчиков. Поэтому преимущества балансировки работы просто исчезают.
- мы перегружены информацией на каждом этапе. Эта проблема связана с сильной взаимозависимостью между различными группами разработчиков, и когда необходимо внести изменение в какую-либо часть проекта, необходимо уведомить всех разработчиков, которые его используют или могут использовать. Это потому, что они заняты своей работой. Синхронизация внутренних документов сама по себе становится огромной проблемой, когда система содержит множество взаимосвязанных подсистем.
- кроме того, результаты проектных работ могут быть объективно определены и оценены только после завершения стадий тестирования системы, то есть стадий анализа, проектирования и разработки, но реализация этих стадий требует больших денежных затрат. да время Как упоминалось ранее, задержка в оценке проекта создает значительные трудности в обнаружении ошибок на этапах анализа и проектирования, поэтому проект должен вернуться к предыдущему этапу, и весь процесс разработки должен быть повторен.
Рассмотрим итеративную модель жизненного цикла. Эта модель идеальна, потому что только очень простые задачи проходят через все этапы, не повторяясь и не возвращаясь к более раннему этапу инженерного процесса. При разработке больших и нетрадиционных систем необходимо увеличение ресурсов на протяжении всего жизненного цикла за счет ошибок и ошибок на предыдущих этапах, изменения внешних требований условий работы системы. С этой моделью разработки вы всегда можете вернуться и исправить свои ошибки.
Классический итеративный дизайн исключает возможность возврата к предыдущему шагу. Однако эта позиция представляет собой интересный по своей сути аспект разработки программного обеспечения, который не опирается на объектно-ориентированный дизайн. Это желание предсказать все ситуации, в которых будет применяться система, а это в большинстве случаев сделать невозможно.
Все традиционные методы программирования ориентированы только на минимизацию прибыли. Однако имейте в виду, что когда вы возвращаетесь назад, вам всегда приходится переделывать то, что, по вашему мнению, уже сделано.
Применяя эту модель к объектно-ориентированной технологии, мы можем отказаться от целостности стадий и фаз. Вместо этого рекомендуется распределить увеличение функциональности и интерфейсных операций на итераторы. Он был стар, когда он пришел домой
Каждая итерация представляет собой полный цикл разработки, ведущий к внешней или внутренней версии программного продукта, который от итерации к итерации совершенствуется до полной системы.
Поэтому каждый виток спирали соответствует разработке версии или части программного продукта, определяются цели и спецификации проекта, определяется качество и планируется работа спирали на следующий виток. . . С каждой итерацией жизненного цикла детали этого проекта становятся все глубже и глубже, что приводит к выбору варианта и, в конечном итоге, к его реализации.
Спиральный дизайн позволяет перейти к следующему этапу проекта, не дожидаясь завершения работы, выполненной на текущем этапе, а любую работу, не выполненную на следующем этапе, всегда можно выполнить. Основная цель каждой итерации — создать приложение, которое сможет обслуживать пользователей как можно быстрее. Это значительно упрощает процесс внесения дополнений и уточнений в ваш проект.
Спиральный подход к разработке программного обеспечения не только устраняет многие недостатки водопадной модели, но и предоставляет множество дополнительных возможностей, делающих процесс разработки более гибким.
Кроме того, давайте рассмотрим преимущества использования этого метода в разработке программного обеспечения.
Итеративная (или пошаговая) разработка значительно упрощает внесение изменений в проект по мере изменения требований пользователя.
Применение спиральной модели приводит к постепенной интеграции самостоятельных элементов государственной организации в единое целое. Другими словами, поэтапный подход к системной интеграции на самом деле представляет собой непрерывный процесс. Системная интеграция начинается с небольшого количества элементов, поэтому при внедрении возникает меньше проблем.
Снижение рисков. Это относится ко всем моделям разработки программного обеспечения, но самая высокоскоростная спиральная модель снижает уровень риска. Это напрямую связано с тем, что интеграция всех этих методов уже произошла на первом этапе.
Спиральная конструкция обеспечивает более надежную и стабильную систему. Потому что по мере развития информационной системы на каждом этапе выявляются и исправляются слабые места и ошибки. В то же время вы можете установить важные параметры производительности. Это делается перед запуском системы только при использовании серийной модели.
Инкрементный метод поддерживает повторное использование компонентов (вы можете использовать метод компонентов программирования). Это все потому, что гораздо проще определить общие элементы проекта, когда они хотя бы частично разработаны, чем пытаться определить их на ранней стадии проекта.
Итерационные методы помогают улучшить процесс разработки. В конце каждого шага анализ позволяет организации-разработчику оценить необходимые изменения и улучшить следующий шаг.
При этом основной задачей использования катушек является определение момента перехода на следующую. Чтобы решить эту проблему, нам нужно определить временные рамки для каждого этапа жизненного цикла. В противном случае процесс разработки программного обеспечения превратится в бесконечное совершенствование уже проделанной работы. Следовательно, даже если все запланированные задачи не выполнены, итерация должна продолжаться, как и планировалось.
В развитии ООО «Электронный документооборот» компания «ЦТР» использует спиральный жизненный цикл. Это помогает сократить время разработки программного обеспечения, выявляя риски на ранней стадии.
К настоящему времени «ЦТР» ООО «Электронный документооборот» разработал несколько стратегий внедрения ИС.
а) Стратегия «параллельного применения» означает одновременное использование старых и новых технологий для решения проблем. Сравнение результатов. Если результаты будут стабильными во времени, они перейдут к новым технологиям.
б) стратегия «прыжка». Скачки — Новая технология реализуется только после внедрения и принятия новой технологии, в то время как старая технология работает до некоторой степени.
в) Стратегия «Пилотный проект». Пилотные проекты. Тактика полетов используется для ограниченного числа операций, и охват часто невелик.
г) стратегия удушья. Кастомизация — это автоматизация небольшой части производственного процесса, обычно выбираемая по критериям, эффективность которых приводит к более качественному выполнению процесса только при наличии определенных препятствий.
Рассмотрим преимущества и недостатки стратегии внедрения, разработанной ИС «Электронный документооборот» ООО «ЦТР» (таблица 14).
Таблица 14 – Сравнение стратегий внедрения ИС «Электронный документооборот» ООО «ЦТР»
Поэтому целесообразно выбирать стратегию автоматизации «параллельного использования» при ограниченном бюджете разрабатываемой информационной системы и на ранних стадиях внедрения.
Для решения этой проблемы был выбран стандарт LC IS ISO/IEC 12207, который распространяется на все типы программ.
2.2 Характеристика нормативно-справочной, входной и оперативной информации
Основными входными документами разрабатываемой ИС «Электронный документооборот» ООО «ЦТР» является договор на закуп товаров и услуг, информация по поставке, информация по реализации, информация по заказам в отделах ремонта, обучения и разработки программных решений.
При этом частота возникновения документов в группе компаний
ООО «ЦТР» составляет до 10 документов в один день.
В таблице 15 приведен реквизитный состав входных документов в зависимости от его типа.
Таблица 15 – Реквизитный состав входных документов
При этом количество записей составляет несколько записей для одного документа.
В сводной таблице 16 приведены основные характеристики справочников, необходимые для работы ИС «Электронный документооборот» ООО «ЦТР».
Таблица 16 – Основные характеристики справочников
| Название справочника | Ответственный за ведение справочника | Объем в строках | Средняя частота актуализации в год | Средний объем актуализации, % в год |
| Пользователи | Администратор | 50 | 1 | 2 |
| Отдел | Администратор | 50 | 0 | 0 |
| Компании и филиалы | Администратор | 10 | 0 | 0 |
| Администратор | 10 | 0 | 0 | |
| Товары | Сотрудник АХЧ | 1000 | 100 | 10 |
| Категории товаров | Сотрудник АХЧ | 20 | 2 | 10 |
| Продолжение таблицы 14Поставщики | Сотрудник АХЧ | 100 | 20 | 20 |
| Статус | Администратор | 2 | 0 | 0 |
2.3. Характеристика результатной информации
К результативной информации относятся отчеты, которые необходимы директорам дочерних компаний и филиалов ООО «ЦТР», а также генеральному директору.
Также результативной информацией в рамках системы является чек и состояние склада.
В сводной таблице 17 приведены основные характеристики результативной информации. Все отчеты, отображающие процесс обработки информации, имеют возможность неоднократного распечатывания.
Таблица 17 – Основные характеристики результативных фалов
| Название результативного файла | Частота формирования | Таблицы, на основе которых формируются | Способ доставки до ИС |
| Чек | 11000 раз в год | Заказ | ИНТЕРНЕТ |
| Отчеты | 2000 раз в год | Договора на закуп Выплаты персоналу Заказ Заказ на услуги | ИНТЕРНЕТ |
| Состояние склада | 240 | Поставки Товары | ИНТЕРНЕТ |
2.4 Разработка ER- модели базы данных
Модель ER представляет собой формальную структуру, не описывающую графические средства самопредставления. Диаграммы организационных отношений были предложены в качестве стандартного графического представления моделей ER.
На рисунке 9 представлена ER-модель ИС «Электронный документооборот» ООО «ЦТР».
Рисунок 9 – ER-модель ИС «Электронный документооборот» ООО «ЦТР»
Опишем структуру разработанной базы данных (таблица 18-34).
Таблица 18 – Структура таблицы «Услуги»
Таблица 19 – Структура таблицы «Статус»
Таблица 20 – Структура таблицы «Программное обеспечение»
Таблица 21 – Структура таблицы «Поставщики»
Таблица 22 – Структура таблицы «Месяц»
Таблица 23 – Структура таблицы «Договор закупки»
Таблица 24 – Структура таблицы «Поставки»
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее |
| Код поставки | idpki | число | 8 | ключевое поле |
| Код договора | iddogz | число | 8 | |
| Дата поставки | datapost | дата | ||
| Код ТМЦ | idtmc | число | 8 | |
| Количество | kolvo | число | 8 | |
| Цена | cena | число | 8 | |
| Код пользователя | idu | число | 8 |
Таблица 25 – Структура таблицы «Категория»
Таблица 26 – Структура таблицы «ТМЦ»
Таблица 27 – Структура таблицы «Заказ услуги»
Таблица 28 – Структура таблицы «Пользователи» +6
Таблица 29 – Структура таблицы «Роль»
Таблица 30 – Структура таблицы «Компании/филиала»
Таблица 31 – Структура таблицы «Выплаты»
Таблица 32 – Структура таблицы «Отдел»
Таблица 33 – Структура таблицы «Заказ»
Таблица 34– Структура таблицы «Заказ-ТМЦ»
2.5. Дерево функций и сценарий диалога
Рассмотрим иерархию функций обработки данных, разработанную информационной системой. Иерархия операций обработки данных в электронном документообороте
Рабочее дерево компании «ЦТР» содержит следующие основные функции:
— ведение каталога (добавление, редактирование, удаление, просмотр информации);
— управление информацией.
Действующая форма документа (рисунок 10).
Обратите внимание, что базовые данные документа хранятся в таблицах базы данных, созданных в СУБД MYSQL. Отображение и печать данных, в которых информация о результатах хранится в таблице.
Работа пользователя осуществляется в интерактивном режиме ООО «ЦТР» с «Электронный документооборот». Он основан на взаимодействии человека и компьютера для решения проблем путем отправки и получения сообщений через периферийные устройства. Вычислительные технологии интерактивного режима на компьютерах подразумевают организацию прямого взаимодействия в режиме реального времени между пользователем и устройством. При этом компьютер информирует человека о состоянии решаемой задачи и активно влияет на ее решение. Кроме того, интерактивный режим позволяет получать обратную связь. Это функциональная задача (программа) и цикл взаимодействия сообщений между задачами и пользователями.
Сценарий диалога взаимодействия пользователя и ИС «Электронный документооборот» ООО «ЦТР» отображен на рисунке 11.
Рисунок 11 – Меню ИС «Электронный документооборот» ООО «ЦТР»
2.6. Структурная схема пакета (дерево вызова процедур и программ)
На рис. 12 показана блок-схема пакетов электронного документооборота ООО «ЦТР».
Пакет «ЦТР» ООО «Электронный документооборот» включает в себя несколько функциональных модулей, основными из которых являются:
Подтвердить пароль для подключения к базе данных.
Размещение информации в системе, включая такие элементы, как сортировка и приоритизация информации.
Сделать звонок, по которому можно узнать необходимые данные.
Отвечать на запросы пользователей, переключая систему отображения информации из одного режима в другой.
Эталонный блок для постоянного хранения данных и управления ими.
Рисунок 12 – Схема пакета ИС «Электронный документооборот» ООО «ЦТР»
Рассмотрим программные модули, разработанные в рамках реализации ИС «Электронный документооборот» ООО «ЦТР» (таблица 35).
Таблица 35 – Программные модули
| № п/п | Наименование модуля | Функции модуля |
| 1 | Ответы на запросы пользователя | Выдача результатов согласно запросам пользователя. |
| 2 | Проверка пароля | Осуществляется доступ пользователя. |
| 3 | Распределение информации | Происходит распределение информации по таблицам. |
| 4 | ПМ справочники | Программный модуль запускается при необходимости введения новых, таких как компании/филиалы, сотрудники, отделы, категории товаров, товары, поставщики. В рамках модуля возможны режимы добавления данных, редактирования данных и удаление данных. |
| 5 | ПМ Договора на закуп и поставки | Программный модуль запускается для работы с договорами на закуп и поставки. В рамках данного модуля предусмотрены ввод и корректировка договоров на закуп, добавление поставок к договору, осуществление фильтрации данных по месяцам. |
| 6 | ПМ Реализация | Программный модуль запускается для работы с реализацией. В рамках данного модуля предусмотрены ввод и корректировка продаж, добавление ТМЦ к продаже, вычисление итоговой суммы и печать чека |
| Продолжение таблицы 337 | ПМ Услуги | Программный модуль запускается для работы с заказами на предоставление услуги. В рамках данного модуля предусмотрены ввод и корректировка заказов на обучение, на ремонт компьютерной техники, на разработку программных решений, на аудиторскую проверку. |
Выводы по 2 главе
Работа пользователя с «Электронным документооборотом» ООО «ЦТР» осуществляется в интерактивном режиме. Он основан на взаимодействии человека и компьютера для решения проблем путем отправки и получения сообщений через периферийные устройства. Технология вычислений в интерактивном режиме на компьютерах представляет собой организацию прямого взаимодействия в режиме реального времени между пользователем и устройством. При этом компьютер информирует человека о состоянии решаемой задачи и активно влияет на ее решение. Кроме того, интерактивный режим отзывчив. Это функциональная задача (программа) и цикл взаимодействия сообщений между задачами и пользователями.
В пакет «ЦТР» входит множество функциональных модулей ООО «Электронный Документооборот».