Сервер Firebird имеет следующие достоинства:

• Минимальные системные требования и в то же время высокая производительность и надежность сервера.

• Отсутствие платы за распространение.

• Несложный процесс установки и поддержки сервера. Удобство в использовании и отсутствие специальной подготовки механизма администрирования баз данных.

• Возможность подключения пользовательских функций (UDF) в виде dll библиотек, разработанных на любом языке программирования с использованием различных сред разработки (например, Delphi, C++ Builder, C++).

Firebird может работать на множестве платформ, в числе которых GNU/Linux, Microsoft Windows и разнообразные Unix платформы.
К компьютерной комплектации для работы сервера предъявляются минимальные требования. Этим требованиям удовлетворяет любой современный, и даже устаревший компьютер [3].

Работа сервера контролируется посредством приложения Firebird Guardian. Данным приложением осуществляется первоначальный запуск сервера, а также его перезапуск в случаях, когда по какой-либо причине сервер стал неработоспособен. На восстановление работоспособности сервера затрачиваются доли секунды, поэтому большинству пользователей сбой в работе даже не будет заметен.

Для разработки Firebird БД используется программа IBExpert. IBExpert – GUI-оболочка, назначение которой заключается в разработке и администрировании БД InterBase и Firebird, а также выбор, добавление и изменение данных, хранящихся в БД.

IBExpert имеет в своем составе множество облегчающих работу компонентов: визуальный редактор объектов БД, редактор SQL запросов и исполнитель скриптов, отладчик хранимых процедур и триггеров, построитель области, инструмент для импорта данных из различных источников, собственный скриптовый язык, а также дизайнер БД и т.д.

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

На рисунке 1.6 показан интерфейс программы IBExpert.

Рисунок 1.6 – Интерфейс программы IBExpert

1. ИСРП

Для разработки интерфейса АРМа проектировщика была использована ИСРП (интегрированная среда разработки программы) Delphi 7.0.

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

Delphi имеет возможность получения доступа к различным типам БД. При использовании BDE (Borland Database Engine – механизм доступа к БД), форм и отчетов можно получить доступ к локальным БД и сетевым БД.

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

Delphi обладает широким набором возможностей. Благодаря этим возможностям, устраняется необходимость производить программирование компонентов Windows общего назначения, а именно, меток и пиктограмм. Также в среде имеются заранее определенные визуальные и невизуальные объекты, в число которых входят кнопки, меню, объекты с данными и диалоговые панели. Использования этих объектов достаточно, например, для обеспечения ввода данных, прибегая только к нескольким нажатиям кнопок мыши, не переходя к программированию.

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

Рисунок 1.7 – Оконная форма Delphi, с размещенными на ней компонентами

Визуальное программирование предоставляет возможность размещать объекты на экране монитора до того, как будет происходить выполнение самой программы. Средства визуальной разработки дают возможность производить работу с объектами, держа их перед глазами и получая результаты практически сразу. Способность видеть объекты такими, какими они будут представлены в ходе исполнения программы, устраняет необходимость проведения множества операций, производимых вручную, что отличает работу в среде, не имеющей визуальных средств программирования. После того, как объект помещен в форму среды, все его свойства тут же отображаются в виде кода, соответствующего объекту как единице, которая исполняется в процессе работы программы. Таким образом, программирование в Delphi заключается в расположении на форме компонентов, необходимых для конкретных задач, и написанию для каждого из них обработчиков событий, если это необходимо [4].

Также следует отметить, что среда Delphi использует язык программирования Delphi (ранее известный как Object Pascal), который имеет право считаться господствующим языком, используемым для разработки программных продуктов.

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

1. Техническая часть

   1. Разработка автоматизированных рабочих мест

      1. Сроки проектирования

Процесс создания проекта сочетает в себе как сбор исходных данных, так и составление смет на ПИР (проектно-исследовательскую работу).

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

В основном исходная информация формируется в зависимости от знаний и опыта конкретного ГИПа. С целью исключения ошибок и ускорения работы по подготовке запросов ГИПу предоставляется возможность использовать архивную базу заготовок предыдущих запросов как обязательных (в соответствии с нормативной документации на проектирование: ТУ, ТЗ, отвод земель и т.д.), так и справочного характера (ранее выполненные проекты, съемки, дополнительная информация). Архивная база запросов создается с течением времени по мере выполнения проектов и пополняется конкретными нормативными документами (основаниями для запросов). База находится в общем доступе для всех ГИПов и авторов разделов, ее пополнение производится ГИПами.

В процессе формирования карточки объекта ГИП отмечает те документы, которыми, по его мнению, будет необходимо воспользоваться при выполнении данного проекта. В автоматическом режиме, у авторов разделов отображаются необходимые задания (составление запросов, писем, список согласований и т.д.). Осуществляя подтверждение своей электронной меткой, ГИП производит пропуск того или иного документа. При получении задания на выполнение запроса автором раздела устанавливается приблизительный срок выполнения (с этой датой ознакамливается ГИП и при согласии утверждает ее своей электронной меткой), готовит запрос, подписывает у руководства, отправляет адресату и ставит дату отправки. Примерная дата получения ответа устанавливается автоматически (месяц в соответствии с законодательством), а также формируется список писем для контроля за получением ответа. Список этих писем включается в задание юриста предприятия для контроля сроков получения ответов и выставления санкций.

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

1. Отметки

Рабочий день инженера начинается с отметки в АРМе инженера. Вход в систему производится по личному логину и паролю. Введенный в окне авторизации пароль сравнивается с паролем в таблице FIO в БД (пароль сравнивается с данными в БД в соответствии с именем пользователя сотрудника). При совпадении паролей открывается главное окно программы, одновременно в таблицу FIO в БД заносится время входа инженера в АРМ, т.е. подтверждается факт присутствия работника на рабочем месте.

На рисунке 2.1 показано окно авторизации.

Рисунок 2.1 – Окно авторизации

Далее, при отсутствии активного задания, инженер выбирает задание из списка ранее выданных заданий, и после нажатия кнопки «Перейти к заданию» оно становится активным. Если же осталось незаконченным задание, выполняемое перед последним выходом из программы, то работа над ним продолжается при очередном запуске АРМ. В течение работы над заданием в таблице ZADANIE фиксируется суммарное количество часов, затраченных на полное выполнение каждого и заданий. На рисунке 2.2 изображена таблица полученных инженером заданий, содержащая всю необходимую информацию для принятия решения о переходе к выполнению одного из них. Также в таблице DGANTT фиксируется время начала и окончания выполнения заданий, выполняемых инженером.

Рисунок 2.2 – Таблица полученных инженером заданий

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

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

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

1. Опыт

Повышение качества проектов напрямую зависит от квалификации и опыта проектировщиков, как рядовых инженеров, так и ГИПов. Повышение квалификации и накапливание опыта напрямую зависит от стажа работы. Но каждый из проектировщиков имеет опыт, полученный при проектировании конкретного объекта, и даже при выполнении похожих проектов в одном институте, они могут существенно отличаться друг от друга. И ГИП, и группа проектировщиков, работающая над объектом, могут и не знать, что подобные задачи и проблемы решались ранее другой группой проектировщиков, работавшей над другим объектом. В настоящее время обмен информацией происходит случайным образом, при этом многое зависит от личностных отношений между проектировщиками. В конечном итоге, от несогласованности, от отсутствия информации страдает качество проекта, сроки его выполнения, и, в результате, прибыль предприятия. Возможность решения этой проблемы предлагается в рамках АРМа проектировщика.

Рассмотрим эту проблему на примере отдела АТиС института ОАО «Дальгипротранс».

В состав отдела АТиС входит три группы СЦБ, разрабатывающих разделы ЖАТ. Каждая из групп СЦБ, работая с разными ГИПами и разными группами смежников, решает аналогичные (для разных проектов) задачи разными способами, принимая при этом разные решения, не всегда являющиеся наиболее оптимальными. Это приводит к применению для одного заказчика (ДВЖД) различных технических и технологических решений, что вызывает у заказчика, как минимум, недоумение. Таким образом, приобретение, накапливание опыта и типизация проектных решений тесно связаны между собой.

Суть предложения для организации проектирования в отделе АТиС заключается в следующем.