Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО «ЛС-Технологии»

ИНН 7807258360 ОГРН 1227800102375

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

12 - 2023

Корпоративная система управления проектным предприятием


Сергей Загурский, руководитель направления TDMS, АО «СиСофт Девелопмент»

Предлагаем совершить экскурс в историю идеи, воплощенной в жизнь командой единомышленников 20 лет назад. От электронного архива проектной организации TDMS прошла путь развития до корпоративной системы управления инженерными данными. Разработчики платформы TDMS в АО «СиСофт Девелопмент» уверены в том, что система была и остается интересной заказчикам, благодаря тому что является открытой для разработки приложений.

Вместо предисловия

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

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

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

Что от нас хотел заказчик…

Несмотря на то что еще во времена СССР существовала довольно серьезная унификация всего и вся, работали отраслевые институты, писались стандарты, разрабатывались единые методики, тем не менее, в начале 2000-х, как, впрочем, и сегодня, мы имеем большую вариативность подходов, отвечающих за организацию технического документооборота в области проектирования промышленных и гражданских объектов. Два предприятия, которые занимаются разработкой проектной документации для одних и тех же объектов строительства, могут иметь существенно различающуюся структуру проекта, требования к оформлению и выпуску проектной продукции (ПП), а о процессах управления проектным производством и говорить нечего — их вариативность уже заложена, например, в размерах организаций, накопленном опыте, уровне интеграции информационных систем и т.п.

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

  1. Сделать максимально простую систему, в которую можно впихнуть практически любые неструктурированные данные2.
  2. Сделать систему, основанную на стандартах и некотором «наиболее логичном подходе», мейнстриме, постаравшись запихнуть в нее максимально возможное количество вариантов работы компаний по выпуску ПП.
  3. Сделать сразу несколько систем, более-менее заточенных на конкретных заказчиков и типы проектов.
  4. Сделать систему, которая позволяет разрабатывать другие системы, обладая достаточной гибкостью, чтобы удовлетворить любым текущим и будущим потребностям заказчика.

Не буду описывать плюсы и минусы первых трех подходов. Платформа TDMS — не про это. Добавив немного пафоса, скажем, что с ее помощью можно реализовать любой из перечисленных подходов. Начав с варианта 1, перейти ко 2-му, а затем начать плодить из варианта 2 варианты 3 на любой вкус и цвет.

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

…и что получилось в итоге

Давайте перенесемся на 20 лет назад, посмотрим на технологии того времени и поймем, почему платформа TDMS именно такая, а не какая-либо другая.

С точки зрения технологического стека, она представляет собой среду быстрой разработки, объектную программируемую надстройку над реляционной базой данных. Если вы никогда не видели данную систему, но видели Microsoft Access, то вам будет несложно понять, что это за «зверь». Замените таблицы на типы объектов, вместо полей у нас атрибуты, добавьте встроенную версионность, умение работать с иерархическими структурами данных, готовое управление правами доступа (через роли и статусы) — и вы получите TDMS.

Встроенный язык программирования — Visual Basic. Но не используемый в Word, Excel и Access Visual Basic for Applications (VBA), а именно Visual Basic Script (VBS). Почему мы не взяли VBA? Это вопрос исключительно коммерческий. Ежегодная стоимость лицензии VBA была достаточно высокой, успешность нового проекта при его запуске всегда лучше оценивать критически. Мы просто не рискнули использовать VBA, тем более что существенных преимуществ он не дает — ему далеко до возможностей компилируемых языков, подключение внешних библиотек ограничено технологией, системных библиотек с открытым кодом немного. С последним у VBS, кстати, значительно лучше — язык часто используется системными администраторами, интерпретатор встроен в ОС Windows. Для него есть множество примеров по программированию взаимодействия как с приложениями, встроенными в Windows, так и с различными прикладными системами.

Применение VBS потребовало от нас создания для него специальной среды, аналогичной применяемой в VBA. В дополнение к более чем 500 методам и свойствам классов прикладного интерфейса программирования (API), мы дополнили VBS своими переменными окружения: ThisApplication, ThisObject, ThisScript, CurrentUser и т.п. Для работы с программным кодом на VBS в состав входит приложение для разработчика и администратора TDMS Developer. Кроме редактора и отладчика программного кода, в это приложение встроены средства управления конфигурацией и администрирования системы.

У нас никогда не стоял вопрос, использовать ли СУБД в составе платформы TDMS или нет. Объемы данных крупной проектной организации исчисляются десятками гигабайт, файловые массивы — терабайтами. Выбирая СУБД, мы остановили выбор на системах Oracle и Microsoft. Этот выбор был стопроцентным попаданием в рынок, новых систем нам не потребовалось довольно долго.

Только годы спустя в список СУБД, поддерживаемых системой, мы добавили еще одну: Postgres. Отметим, что мы это сделали еще до того, как импортозамещение стало обязательным к исполнению для многих российских компаний, и Postgres появилась даже там, где раньше о ее применении не было и речи. Просто на определенном этапе развития решений на основе TDMS нам потребовалась бесплатная база данных без ограничений по объему, какие имелись и имеются у бесплатных версий СУБД от Oracle и Microsoft.

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

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

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

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

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

Такие приложения, в зависимости от сложности и значимости, могут иметь разные определения, но по сути являются сервисами. Сервисами TDMS являются, например, файловый сервер, веб-сервер, сервис синхронизации с AD, приложение TDM365, модуль управления субподрядом и др. Программирование сервера в основном идет на C# в среде Visual Studio, но сервер также позволяет запускать код на VBS, что значительно облегчает перенос части разработанного функционала систем на сервер приложений.

Такая приятная гибкость образовалась...

Гибкость платформы вызвала развитие множества решений с использованием TDMS. Даже сегодня, спустя уже почти два десятилетия, многие из этих первобытных систем все еще используются заказчиками. В большинстве случаев такие «консервы» мы обнаруживаем там, где больше ничего не требуется в рамках задач, возложенных на систему. Какими бы простыми ни казались эти системы нам сегодня, они выполняли и выполняют ровно то, что от них хотели заказчики.

Постепенно из большого разнообразия решений на TDMS, появившихся в то время, — архивы конструкторских и проектно-конструкторских организаций, системы для БТИ, системы управления имуществом и ряд других — начало выкристаллизовываться то направление, с которым и станет ассоциироваться современная TDMS.

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

Как мы прокачались до 88-го уровня

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

Средства просмотра

Первым дополнительным продуктом к платформе стал встроенный вьювер TDMS Viewer. Это простой инструмент, умеющий просматривать все основные графические форматы, PDF и *.dwg. Он имеет одну важную отличительную особенность — способность смотреть файлы из потока, то есть открывать документы без прямого доступа к файлам. Данная возможность оказалась весьма востребованной на предприятиях с повышенными требованиями к обеспечению информационной безопасности.

Средства просмотра встроены в веб-версию TDMS

Средства просмотра встроены в веб-версию TDMS

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

Средства хранения файлов

По мере роста файловых данных стало очевидно, что хранить файлы только в больших бинарных объектах СУБД — неверно. Вместе с выходом третьей версии у нас появился свой файловый сервер. Разумеется, две другие возможности по хранению файлов в базе данных и на URL сохранились как для совместимости, так и для большей гибкости. Так, например, шаблоны документов разных видов, файлы сертификатов пользователей и другие типы файлов, которые в какой-то степени являются частью конфигурации, по-прежнему хранятся в СУБД; а, например, файлы с ограниченным доступом, с грифом «Коммерческая тайна» или «Для служебного пользования» могут храниться в специально устроенном хранилище на URL.

Программные интерфейсы

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

Автоматизация выпуска

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

Управление проектами

Система с самого начала активно развивалась и двигалась от электронного архива в сторону управления проектным производством. Нашим заказчикам потребовалось календарно-сетевое и ресурсное планирование, и как часть системы появился собственный модуль оперативного планирования и управления ресурсами, иногда для простоты называемый «Диаграмма Ганта».

Управление процессами

Одной из главных претензий к TDMS, которую предъявляли нам в основном наши конкуренты, было отсутствие собственного сервера бизнес-процессов. Нет у нас его и сейчас. Почему? Во-первых, никогда не делай сегодня то, что можешь сделать завтра. Во-вторых, если уж серьезно, на рынке с самого начала появилось довольно много серверов процессов, которые методом проб и ошибок доработав стандарт BPM до реальных требований управления информационными потоками… в один прекрасный день стали доступны для интеграции. Совершенно, так сказать, безвозмездно. И мы предпочли сделать на стороне TDMS «обертку» для чтения нотации BPM и ее перевода в собственный набор сущностей, запуска процессов, визуализации их состояния и т.п.

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

Графическое изображение хода выполнения процесса в TDMS средствами интегрированного сервера бизнес-процессов

Графическое изображение хода выполнения процесса в TDMS средствами интегрированного сервера бизнес-процессов

Чего еще нет в TDMS 7.0

Большинству пользователей действующей и более ранних версий наверняка более всего существенно, «а что нового в “семерке”?». Здесь мы только кратко опишем то, что наверняка будет интересно и пользователям, и разработчикам. Итак, что нового?

  • сервер приложений. Большое количество изменений по программированию и настройке. А если новые возможности доступны разработчикам приложений для сервера, — значит новыми возможностями очень скоро воспользуются и пользователи системы, в особенности те, кто применяет веб-версии приложения;
  • сервер приложений. Одной из наиболее значимых возможностей обновленного сервера является встроенный модуль проведения аудио/видеоконференций. Современные технологии позволяют проводить различные мероприятия с возможностью онлайн-демонстрации и обмена документами в виде ссылок на них в системе;
  • файловый сервер. Поддержка нескольких хранилищ. Разделение ключевых сервисов TDMS в настройках пользователей;
  • Windows-клиент. Возможность одновременно работать с несколькими диалогами свойств. Диалоги свойств объектов можно закреплять в главном окне и открывать в немодальном диалоге со своим программным контекстом;
  • Windows-клиент. Автоматическое запоминание любых фильтров. Казалось бы, такая небольшая вещь, но как это облегчает и ускоряет работу людей! Странно, что мы не сделали этого раньше;
  • Windows-клиент. Новые возможности выборок, в частности подсветка обновления содержимого. Если у вас есть новые неотработанные задачи, это будет заметно;
  • интерфейсы. Адаптированы новейшие версии Microsoft Office, nanoCAD.

Наверное, статью имеет смысл закончить тем, что мы планируем в следующих версиях. Самое главное, что нам предстоит сделать при переходе на TDMS 8.0, — обеспечить полноценную работу под управлением Linux. Это большая и трудоемкая задача, особенно в контексте необходимости сохранить совместимость с уже разработанными системами.

Кроме того, предстоит большая работа по переносу дополнительных модулей на сервер приложений. Модуль планирования и управления ресурсами уже перенесен, очередь за модулем автоматизации выпуска ПСД и модулем построения отчетов. Некоторые операции с файлами и тем более подготовки отчетов могут занимать длительное время. Гораздо правильнее передать решение этих задач сервису. А пользователь после их завершения будет получать соответствующее уведомление. Скорее всего, эти модули будут доступны уже в TDMS 7.0. Это общепринятая практика нашей работы. Мы никогда не жадничаем, и если у нас есть возможность реализовать полезный функционал в текущей версии, то мы это делаем. 

1 Например: а) объекты гражданского строительства (малые),
б) объекты гражданского строительства (крупные и уникальные), в) площадные промышленные объекты, г) линейные (промышленные) объекты.

2 На самом деле «неструктурированными» эти данные могут быть только в контексте определенной системы. В других системах, «заточенных» на предметную область, практически для любой информации могут быть созданы структура, атрибуты, справочники, классификаторы и функции управления данными.

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557