34
быть утеряно безвозвратно большое количество информации. Так как нет
возможности делать резервные копии этих данных.
После изучения процессов планирования в организации, можно сде-
лать определённый вывод о том, что используемый сервис не позволяет пол-
ноценно реализовать календарное планирование, по причинам:
- процессы создания задач для сотрудников или бригад медлительны,
так как выполняются одним человеком,
- отсутствует возможность полноценно оценить объём выполняемых
работ,
- отсутствие возможности быстро связать материальные затраты с вы-
полняемыми работами,
- отсутствие взаимосвязи между выполняемыми задачами,
- слабый контроль над ходом выполнения задач.
Так как сервис «GoogleКалендарь», создавался как сервис органайзер,
то в нем нет и не будет множества функций, необходимых для планирования
работ у организаций. В то время, когда создавалась организация, средств,
предоставляемых бесплатными сервисами, было достаточно, но в данное
время ясно, что функциональность этого сервиса не удовлетворяет требова-
ниям, необходимым для полноценной работы.
Таким образом, анализ существующей практики календарного плани-
рования на предприятии позволил сделать вывод, что функций применяе-
мого сервиса «Google Календарь» недостаточно для полноценной работы в
качестве системы календарного планирования. В связи с этим необходимо
перейти на другую систему, которая позволит реализовать отсутствующий
функционал, а также позволит части сотрудникам самостоятельно создавать
задачи и проекты и назначать лиц, контролирующих их выполнение.
35
ГЛАВА 3. РАЗРАБОТКА ПРИЛОЖЕНИЯ ДЛЯ
КАЛЕНДАРНОГО ПЛАНИРОВАНИЯ В СТРОИТЕЛЬСТВЕ
3.1 Выбор среды разработки
После рассмотрения вариантов систем календарного планирования
было принято решение разработать программное обеспечение, а не поку-
пать или арендовать. Аргументами за это решение были:
- высокая стоимость подобных программ (бесплатные не позволяют
организовать необходимые требования);
- избыточность подобных систем (множество функций не будут ис-
пользоваться, а ресурсы сервера будут занимать).
В результате рассмотрения этой задачи были сформулированы требо-
вания, для будущей программы и дано поручение разработать техническое
задание. Задачи, которые будет выполнять данная система:
- хранить информацию об пользователях системы,
- ограничивать права на работу в системе для пользователей,
- создавать задачи и назначать ответственных за их выполнение,
- объединять задачи в проекты,
- хранить документы необходимые для задач и проектов,
- иметь возможность контроля за выполнением.
После этого были рассмотрены варианты реализации программного
обеспечения и среды разработки. На рассмотрении было вынесены следую-
щие варианты:
- среда разработки QT Creator и фреймворк QT, и язык программиро-
вания C++,
- среда разработки Lazarusи язык программирования Object Pascal,
- среда разработки Net Beans IDE и язык программирования PHP (для
веб разработки),
36
- среда разработки Embar cadero RAD Studio, языки программирова-
ния C++ и Object Pascal,
Были рассмотрены плюсы и минусы каждого варианта (таблица 10).
Таблица 10 – Варианты реализации программного обеспечения
и среды разработки
Вариант
Преимущества
Недостатки
QT и QT Creator
- кроссплатформенный разра-
ботка;
- визуальная среда разработки
графического интерфейса;
- наличие качественной доку-
ментации
- для некоммерческой версии
среды большой размер дистри-
бутива;
- высокая стоимость лицензии
на коммерческую версию.
Lazarus
- кроссплатформенная разра-
ботка;
- визуальная среда разработки
графического интерфейса;
- бесплатная среда разработки.
- малое количество документа-
ции;
- малое количество компонен-
тов.
NetBeans
- кроссплатформенная разра-
ботка;
- для работы нужен только
браузер;
- наличие качественной доку-
ментации.
- более медленная работа в
сравнении с приложениями;
- необходимость нанимать сто-
роннего разработчика.
Embarcadero RAD
Studio
- кроссплатформенная разра-
ботка;
- наличие качественной доку-
ментации;
- визуальная среда разработки
графического интерфейса;
- большое количество компо-
нентов;
- наличие бесплатной версии.
высокая стоимость коммерче-
ской версии продукта, что не
столь существенно, поскольку
существует бесплатная версия.
В качестве среды разработки системы календарного планирования
была выбрана среда разработки Embar cadero Delphi XE 10.2 (рисунок 5), а
в качестве языка программирования Object Pascal.
37
Рисунок 5 - Внешний вид среды разработки Delphi XE 10.2
Этот выбор обусловлен тем, что в этой среде существует множество
инструментов, позволяющих упростить и ускорить процесс разработки по-
добного программного обеспечения, такие как компоненты графического
интерфейса или компоненты доступа к базам данных, использование бес-
платной версии. А также компоненты, позволяющие создавать клиент-сер-
верные или веб приложения.
Так же в среде разработки присутствует возможность создавать при-
ложения для операционных систем Android, iOS, Linux 64x, Windows 32x,
Windows 64x. Причём для всех систем кроме Linux 64x, может использо-
ваться один фреймворк Fire Monkey (FMX), что облегчает и ускоряет разра-
ботку ПО, в связи с тем, что может быть использован один код для всех опе-
рационных систем.
Следующим шагом был выбор системы хранения данных. Для того,
чтобы можно было обеспечить возможность одновременной работы с дан-
ными всех сотрудников, необходима система, позволяющая параллельную
38
работу множества пользователей. Исходя из этого в качестве системы хра-
нения данных была выбрана СУБД. При этом к СУБД были предъявлены
следующие условия:
- малое потребление ресурсов,
- простота обслуживания,
- малые затраты на приобретение,
- многопользовательский доступ.
Исходя из требований к СУБД было принято решение не применять
файловые базы данных, поскольку у них нет хорошей поддержки много-
пользовательского режима доступа.
На рассмотрение были предложены СУБД, представленные в таблице
11, каждая из которых имеет как свои преимущества, так свои недостатки.
Таблица 11 – Преимущества и недостатки СУБД
СУБД
Преимущества
Недостатки
Firebird
- многопользовательский доступ;
- развитые инструменты разра-
ботки и поддержки;
- минимальные требования к ре-
сурсам;
- высокая скорость доступа к дан-
ным;
- отсутствие ограничений на ис-
пользование ресурсов СУБД;
- наличие качественной докумен-
тации;
- бесплатная СУБД, для любых це-
лей.
Postgre SQL
- многопользовательский доступ;
- развитые инструменты разра-
ботки и поддержки;
- высокая скорость доступа к дан-
ным;
- нет ограничения на использова-
ние ресурсов СУБД;
- качественная документация;
- бесплатная СУБД, для любых це-
лей.
требовательность к ресурсам.
39
Продолжение таблицы 11
СУБД
Преимущества
Недостатки
IBM DB2
Express-C
- многопользовательский доступ;
- развитые инструменты разра-
ботки и поддержки;
- высокая скорость доступа к дан-
ным;
- качественная документация;
- бесплатная СУБД, для любых це-
лей.
- ограничения на использование
ресурсов СУБД.
MySQL
- многопользовательский доступ;
- развитые инструменты разра-
ботки и поддержки;
- минимальные требования к ре-
сурсам;
- высокая скорость доступа к дан-
ным;
- нет ограничения на использова-
ние ресурсов СУБД;
- качественная документация.
- бесплатная версия обязывает ис-
пользовать лицензию GPL.
Выбор для разработки остановился на СУБД Firebird, которая полно-
стью соответствует предъявленным требованиям.
В качестве среды разработки базы данных, была выбрана IBExpert
(рисунок 6), которая бесплатна для использования на территории СНГ.
Рисунок 6 - Внешний вид среды разработки IB Expert.
40
Так как в качестве системы хранения данных, была выбрана СУБД
Firebird, то для работы с ней могут быть использованы множество компо-
нент, которые созданы для Delphi. Но выбор пал на компоненты Fib Plus
распространяемые бесплатно, по причине наилучшей скорости взаимодей-
ствия с выбранной СУБД, хоть и в ущерб универсальности.
Для отображения информации для пользователей, были использованы
как бесплатные компоненты, так и коммерческие, была выбрана библиотека
компонентов Eh Lib Standard стоимость годовой подписки которой состав-
ляет 14000 рублей. А также библиотека JEDI Visual Component Library, рас-
пространяемая бесплатно. Таким образом, расходы на все инструменты раз-
работки составит только стоимость библиотеки Eh Lib Standard.
Но такое решение подходит не для всех организаций, а только для тех,
которые имеют возможность привлечения сторонних или своих специали-
стов для разработки. При этом полученный продукт можно оперативно из-
менять и дорабатывать, что зачастую невозможно в случае использования
сторонних разработок.
3.2. Разработка базы данных
Первым шагом при разработке системы календарного планирования
будет разработка базы данных для хранения данных. Это важный этап при
разработке любое ПО, которая хранит и обрабатывает данные. Именно на
этом этапе закладываются система хранения и обработки.
Если не верно спроектировать базу данных, то программы, которые
будут использовать эти данные, не смогут работать корректно.
Среда разработки была выбрана ранее и поэтому не будем описывать
её.
Для работы нашего ПО, используется СУБД Firebird 3 и среда разра-
ботки IB Expert. База данных разрабатывается в несколько этапов, описание
которых представлено в таблице 12.
41
Таблица 12 – Этапы разработки базы данных
Номер этапа
Содержание работ
1 этап
- определение данных, которые будут храниться и обра-
батываться;
- разработка принципиальной схемы данных;
- описание типов данных необходимых для данных;
- разработка связей между таблицами.
2 этап
- создание доменов для полей таблиц;
- создание генераторов для создания уникальной нумера-
ции таблиц;
- создание таблиц данных;
- создание индексов для быстрой выборки из базы дан-
ных;
- создание триггеров для обработки вводимых данных;
- создание хранимых процедур.
3 этап
корректировка структуры во время разработки после вы-
яснения дополнительных требований.
Для данной базы данных первый этап был разработан заранее, по-
этому разработка базы была начата со второго этапа.
Домены создаются для лучшего контроля над типами данных, в слу-
чае необходимости изменить тип или размер хранимых данных, их можно
будет изменить путем изменения домена, при этом все данные, которые при-
вязаны к домену, изменятся во всех таблицах базы данных.
В базе данных будут использованы несколько типов данных:
- INT1 типа INTEGER;
- BI типа BIGINT;
- DT типа TIMESTAMP;
- STR20 типа VARCHAR хранение строк длинной до 20 символов;
- STR50 типа VARCHAR хранение строк длинной до 50 символов;
- STR300 типа VARCHAR хранение строк длинной до 300 символов;
- STR500 типа VARCHAR хранение строк длинной до 500 символов;
- BL типа BLOB для текстовых данных;
- BL1 типа BLOB для хранения произвольных данных.
42
Распределение данных по таблицам базы данных представлена в таб-
лице 12.
Таблица 12 - Общая характеристика таблиц базы данных
Название таблицы
Поля
Таблица пользовате-
лей (USERS) - хранит
данные пользовате-
лей, которые будут ис-
пользовать данное ПО
- уникальный ключ пользователя*;
- фамилия*;
- имя*;
- отчество;
- логин*;
- пароль*;
- доступ к системе* (не используется в данный момент, будет
реализовано в дальнейшем);
- примечание;
- статус пользователя* (активный или архивный).
Таблица задач
(WORKS):
хранит информацию о
задачах для пользова-
телей.
- уникальный ключ задачи*;
- создатель задачи*;
- исполнитель задачи;
- дата и время начала выполнения задачи;
- дата и время окончания выполнения задачи;
- наименование задачи*;
- примечание;
- сотрудник, контролирующий выполнение задачи;
- дата и время создания задачи*;
- дата и время последнего изменения*;
- сотрудник последний изменивший задачу*;
- состояние задачи от исполнителя (1 в работе, 2 завершено);
- состояние задачи от контролёра (1 в работе, 2 согласовано
выполнение).
Таблица проектов
(PROJECTS): хранит
информацию о проек-
тах.
- уникальный ключ проекта*;
- создатель проекта*;
- дата и время начала выполнения проекта;
- дата и время окончания выполнения проекта;
- наименование проекта*;
- примечание;
- сотрудник, контролирующий выполнение проекта;
- дата и время создания задачи*;
- дата и время последнего изменения*;
- сотрудник последний изменивший проект*;
- состояние проекта.
Связка проектов и за-
дач (WORKS_LIST):
хранения прикреплён-
ных к проекту файлов.
- уникальный ключ*;
- номер задачи*;
- номер проекта к которому относится задача*.
43
Продолжение таблицы 12
Название таблицы
Поля
Хранимые файлы про-
ектов (FILES):
- уникальный ключ*;
- номер проекта, которому принадлежит файл*;
- файл записанный в базу данных*;
- имя файла*.
После создания полей, начинается создание индексов и связей, созда-
ются первичные, внешние или уникальные ключи, индексы для полей. Все
числовые поля будут использовать индексы, так как это либо уникальные
значения, по которым идентифицируются данные, либо связка по этим по-
лям, в этом случае поиск информации по ключам осуществляется намного
быстрее.
В некоторых случаях использование генераторов или автоинкремент-
ных полей для поддержки уникальности полей невозможно. В этом случае
можно использовать уникальные ключи UNIQUE, тогда СУБД сама прокон-
тролирует, чтобы не было повторов.
Далее создаются генераторы для всех уникальных полей. Для упроще-
ния работы и автоматического использования генераторов создаются триг-
геры, которые автоматически генерируют уникальные поля. В среде разра-
ботки баз данных IB Expert для создания генераторов и триггеров доста-
точно поставить галочки для нужного поля (рисунок 7).
Рисунок 7 - Автоматическое создание генератора для поля