ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ. 7

1 Сведение об организации. 8

1.1 Общая характеристика организации и ее деятельности. 8

1.1.1 Организационно-правовая форма и категория организации. 8

1.1.2 Предмет основной деятельности и основная цель организации. 8

1.2 Организационная структура компании. 10

1.3 Технико–экономические показатели. 13

1.4 Узкие места в деятельности организации. 14

1.5 Дерево целей организации. 14

1.6 Описание механизма функциональная организация. 15

2 Декомпозиция АСУ на подсистемы и комплексы задач. 20

2.1 Цель и концепция создания АСУ.. 20

2.2 Виды подсистем и их особенности. 21

2.3 Принципы декомпозиции функциональной части АСУ на подсистемы и комплексы задач. 21

2.4 Требования к обеспечивающим подсистемам АСУ.. 23

2.4.1 Требование к математическому обеспечению.. 24

2.4.2 Требования к программному обеспечению.. 25

2.4.5 Требования к эргономическому обеспечению.. 29

2.4.6 Требования к правовому обеспечению.. 30

2.4.7 Требования к лингвистическому обеспечению.. 31

2.4.8 Требование к организационно – методическому обеспечению.. 31

2.5 Выбор и описание информационной технологии. 31

3 Проектные решения по автоматизации комплекса задач подсистемы.. 33

3.1 Обоснование выбора подсистемы для ВКР. 33

3.2 Общий подход к описанию задач подсистемы.. 34

3.2.1 Организационно-экономическая сущность задачи. 34

3.2.2 Входная информация/входные данные. 34

3.2.3 Выходная/результатная информация. 38

3.2.4 Описание ручного и машинного алгоритмов решения задач. 39

3.3 Обоснование выбора задач для автоматизации и их описание. 40

3.3.1 Формирование плана о назначение проектов ГИПам 43

3.3.2 Составление опорного план-графика выполнения проектных работ по разделам.. 53

3.3.3 Составление списка проектных работ, выполняемых собственными силами организации и отдаваемых на субподряд. 64

3.3.4 Формирование списка подрядчиков для заключения договоров на разработку разделов ПСД.. 78

3.4 Схема взаимосвязи комплекса задач подсистемы.. 85

4 Информационное обеспечение. 86

4.1 Описание предметной области. 86

4.2 Концептуальная модель предметной области. 86

4.3 Нормализация отношений и логическая модель предметной области. 88

4.4 Обоснование выбора среды реализации. 91

4.5 Преобразование логической модели в структуру таблиц БД.. 93

5 Программное обеспечение. 101

5.1 Требования к системному программному обеспечению.. 101

5.2 Общие требования для разработки прикладного ПО.. 103

5.3 Описание интерфейса разрабатываемого программного обеспечения. 105

5.4 Программная реализация выбранного комплекса задач 108

5.4.1 Подключение к базам данных. 108

5.4.2 Работа со справочниками. 110

5.4.3 Работа с входными документами. 111

5.4.4 Работа с выходными документами. 114

5.5 Средства администрирования. 118

5.5.1 Управление списком пользователей. 118

5.5.2 Распределение прав доступа. 119

5.5.3 Инструкция по развертыванию/установке предлагаемого решения. 120

ЗАКЛЮЧЕНИЕ. 123

БИБЛИОГРАФИЧЕСКИЙ СПИСОК.. 124

Приложение А.. 127

Приложение Б. 128

Приложение В.. 129

Приложение Г. 130

Приложение Д. Часть 1. 131

Приложение Д. Часть 2. 132

Приложение Е. 133

Приложение Ж... 134

Приложение З. 135

ВВЕДЕНИЕ

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

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

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

Для достижения поставленной цели решаются следующие задачи:

• Анализ существующей системы управления в организации;
• Проведение декомпозиции АСУ на подсистемы и комплексы задач;
• Разработка проектного решения по автоматизации задач подсистемы управления процессом проектирования ООО «Параметрика»;
• Разработка информационного обеспечения подсистемы управления процессом проектирования ООО «Параметрика»;
• Разработка программного обеспечение подсистемы управления процессом проектирования ООО «Параметрика»;

1 Сведение об организации

1.1 Общая характеристика организации

1.1.1 Организационно-правовая форма

Архитектурное бюро «Параметрика», далее в тесте будет упоминаться как исходная организация, имеет следующую организационно-правовую форму – ООО (общество с ограниченной ответственностью) и действует в соответствии с Федеральным законом от 08.02.1998 № 14-ФЗ «Об обществах с ограниченной ответственностью» и уставом компании [1].

Следовательно, высшим органом управления является – общее собрание учредителей, которое состоит из двух участников. Исходная организация является малой проектной (так как численность сотрудников не превышает 100 человек). Полное название Общество с Ограниченной Ответственностью «Параметрика».

Главный офис исходной организации располагается в г. Санкт-Петербург (Адмиралтейский район) – код по ОКАТО: 40262. Дата регистрации ООО – 17.05.2016 (организация находится на рынке уже более 5 лет). География работ: Санкт-Петербург и Ленинградская область.

1.1.2 Предмет основной деятельности и основная цель организации

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

Ниже будет рассмотрен технологический процесс организации по созданию проектно-сметной документации малоэтажных коттеджей.

Проектирование частного жилого дома включает [2]:

• Составление плана участка с посадкой здания (выполнение обмеров территории; исследования возможностей участка с учётом ландшафта, залегания грунтовых вод, особенностей почвы – инженерные изыскания). От этого плана зависят технология строительства, этажность здания и т.д.;
• Разработка планировочного решения (экспликация помещений – в коттедже важно продумать расположение и размер всех комнат общего назначения, а также спален, санузлов, подсобных помещений);
• Визуализация экстерьера (разработка планов внешнего вида здания, проработка дизайнерских и других конструкторских решений);
• Создание рабочего проекта;
• Создание инженерного проекта;
• Выполнение авторского, а также технического надзора.

Для выполнения данных работ в организации используется следующее ПО: AutoCAD, Autodesk 3ds Max, Autodesk Revit, SketchUP, Homestyler.

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

Помимо абстрактной основной цели, существуют и более конкретные задачи:

• В области маркетинга: войти в топ 10 архитектурных бюро (проектных организаций) города Санкт-Петербург по колличеству выполненных объектов;
• В области персонала: обеспечить условия, необходимые для развития творческого потенциала работников и повышения их удобства (переоборудование помещений, закупка нового оборудования, повышение квалификации и обучение специалистов за счёт компании);
• Расширение области своей деятельности (открытие дочерних офисов компании в других городах, для увеличения объёма выполняемых работ и увеличения конкурентоспособности на рынке);
• Сокращение издержек, путём совершенствования аппарата управления (сокращение затрат, тем самым увеличивая долю чистой прибыли в общем обороте денежных средств);
• Расширение кадрового состава организации при помощи поиска и найма высококвалифицированных специалистов в области архитектуры и проектирования инженерных систем (ГИПы, ГАПы, а также ведущие специалисты для курирования различных разделов ПСД).

• Создание нового отдела – инженерных изысканий и геодезических работ (так как в данный момент инженерные изыскания проводятся по договору субподряда; а также поиск высококвалифицированный кадров в этот отдел/либо обучение уже существующих);
• Внедрение и совершенствование BIM технологий в процесс проектирования (для повышения точности и скорости, а также снижения себестоимости самого проектирования);

1.2 Организационная структура компании

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

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

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

Помимо отделов исходной организации можно также выделить и другие сторонние организации:

• Заказчики ПСД: ООО «Топдом», ИК ВЕКТОР, ООО «СТИ»
• Финансовые организации, предоставляющие кредитование: ПАО «Сбербанк», АО «Альфа-банк», Банк ВТБ (ПАО).
• Экспертные организации, оценивающие соответствие проектно-сметной документации требованиям технических регламентов и действующим нормативно-правовым актам: ООО «Измеритель»
• Поставщики компьютерного оборудования и ПО: ООО «Электронный мир», ООО «ДЕПО Электроникс», ООО «ЗероИнфоТехнологии».
• Субподрядные организации, оказывающие определённый набор услуг: ООО «МагмаГео» (проведение инженерных изысканий), ООО «Инсистемс», ООО «Гильдия проектировщиков» (проектирование различных инженерных систем).

Организационная структура исходной организации является матричного типа и представлена в приложении Б.

Краткое описание функций, выполняемых отделами организации:

• Бухгалтерия:
• Отдел кадров:
• Отдел информационно-технического обеспечения проектов:
• Бюро главных инженеров проекта (ГИПов):
• Планово-договорной отдел:
• Проектные отделы:
• Сметный отдел:

• Формирование плана поступления и расходов денежных средств;
• Организация выплаты заработных плат;
• Составление отчета о финансовых результатах деятельности за год;

• Составление штатного расписания;
• Составление плана отпусков на год;
• Управление документами персонала;
• Формирование приказов о кадровом движении сотрудников.

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

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

• Отслеживание показателей деятельности организации за год;
• Формирование месячного и годового плана по разработке проектной документации;
• Создание предконтрактной документации

• Разработка проектно-сметной документации по объектам.
• Формирование технических заданий.

• Разработка сметной документации по объектам;
• Составление локальной сметы по каждому разделу ПCД;

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

1.3 Технико–экономические показатели и категория организации

По данным ФНС России, выручка за 2022 год составляет 11,8 млн. рублей, из которых чистая прибыль = 7,6 млн. рублей. Исходя из анализа графика выручки за прошлые года, можно сделать вывод, что компания имеет стабильное финансовое положение и успешно развивается (так как по сравнению с 2021 годом выручка увеличилась на 3,5 млн. рублей).

Всего в штате исходной организации числится 32 сотрудника (за прошедший год: штат увеличился на 8 человек). При этом среднее количество заявок в месяц составляет: 7-11 в месяц. Среднее время разработки проектно-сметной документации по объекту составляет от 14 дней до 60 (в зависимости от состава разделов для проектирования, который непосредственно обсуждается с заказчиком и фиксируется в заключённом договоре).

Основные технико-экономические показатели (далее в тексте - ТЭП) исходной организации наглядно представлены в таблице 1.1. Все суммы указаны в тысячах рублей.

Таблица 1.1. ТЭП ООО «Параметрика»

Показатель	2021	2022	Отклонение (+, -)
Абсолютное	Относительное (%)
Выручка	8 300	11 800	+3 500	+29,66
Чистая прибыль (убыток)	4 500	7 600	+3 100	+40,79
Уставный капитал	30	30	0	0
Среднесписочная численность работников, чел.	24	32	+8	+25
Количество учредителей	2	2	0	0

1.4 Описание механизма функциональная организация

В процессе функционирования исходной организации реализуются следующие функции управления [5]:

• Маркетинг;
• Контрактация;
• Планирование производства;
• Учёт и отчётность;
• Контроль;
• Анализ.

Механизм взаимосвязи процессов разделен по следующим ресурсам и услугам:

• Проектная документация малоэтажных коттеджей;
• Трудовые ресурсы;
• Финансы.

• Техническое оборудование и ПО;

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

Функциональная структура, отображающая механизм функционирования архитектурного бюро ООО «Параметрика», представлена в приложение В.

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

• Управление процессом выпуска проектной документации малоэтажных коттеджей:
• Управление процессом снабжения техническим оборудованием и ПО:
• Управление трудовыми ресурсами/кадрами:
• Управление финансами:
• Подсистема «управления процессом проектирования» - подсистема главная роль которой заключается в том, чтобы эффективно организовать выполнение проектных работ, а также обеспечить координацию между всеми участниками, которые учувствуют в проектирование (заказчик, исполнители из проектных отделов и персонал организации). При помощи составления опорных план графиков выполнения проектных работ, ГИП контролирует сроки выполнения проектных работ (данные графики являются очень важным элементом на стадии подготовки к проектированию, так как непосредственно от правильности их составления зависит прибыль, которую может получить компания; грамотное назначение исполнителей на работы позволит своевременно сдать текущие проекты и заработать престиж среди заказчиков).
• Подсистема «информационно-технического обеспечения проектирования» - отвечает за обеспечение проектировщиков, а также других сотрудников фирмы исправно функционирующим техническим оборудованием и грамотно настроенным ПО. Специально для этого составляются планы по обслуживанию и замене оборудования; а также формируются планы по проверке безопасности внутренней ЛВС организации на предмет уязвимостей. Своевременное обеспечение сотрудников оборудованием и ПО позволяет значительно сократить издержки, связанные с простоем.
• Подсистема «управления кадрами» - подсистема отвечает за учет рабочего времени сотрудников, планирование их отпусков и выдачу больничных, составление штатного расписания. Также важной задачей рассматриваемой подсистемы является составление и ведение реестра кадрового движения сотрудников организации (в эту категорию можно включить найм нового персонала, увольнение сотрудников либо же отправку сотрудников на курсы по повышению квалификации)
• Подсистема «бухгалтерского учёта» - подсистема, отвечающая за работу с финансами (выплата заработной платы сотрудникам после уплаты обязательной части в страховые фонды; составление бухгалтерского баланса по организации за год, а также составление планов доходов и расходов денежных средств).
• Подсистема «технико-экономического планирования» - следит за технико-экономическими показателями организации, формирует портфель заказов для организации на год.
• Ограничение по нагрузке выбранного ГИПа (нагрузка выбранного ГИПа не может превышать d):
• Переменные в задаче являются целыми числами (так как они обозначают количество назначенных проектов определённого класса сложности):
• Ограничение на количество доступных проектов i-го вида сложности:

Разработка проектной документации малоэтажных коттеджей (производственный процесс) состоит из следующих этапов: расчёт сметы на разработку ПД; составление будущего эскизного проекта; составление 3d модели и согласование её с заказчиком; осуществление и контроль инженерных изысканий; разработка архитектурного проекта; разработка конструкторских решений; составление инженерного проекта; разработка архитектурно-строительного проекта и передача заказчику ПСД.

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

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

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

В рамках функции учёта и отчётности: учёт выполнения заказов, учёт выполнения плана о назначение проектов исполнителям – ГИПам; учёт выполнения опорного план-графика выполнения проектных работ по разделам; учёт проектных работ, которые будут отданы на субподряд; учёт затраченных денежных средств на проект и т.д.

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

В составе функции анализа: анализ выполнения плана о назначение проектов исполнителям – ГИПам, анализ выполнения опорного план-графика выполнения проектных работ по разделам; анализ выполнения общего бюджета проекта.

Для осуществления производственных процессов необходимо обеспечить всех сотрудников в организации рабочей компьютерной техников, а также лицензированным ПО. А также: провести закупку нового компьютерного оборудования для организации работы сотрудников, тонкую настройку программного обеспечения на каждой рабочей станции; настроить серверное оборудования архитектурного бюро; организовать внутреннюю ЛВС компании и т.д.

На этапе маркетинга: анализ рынка технического оборудования и ПО; выбор поставщиков технического оборудования и ПО.

На этапе контрактации: подготовка предконтрактной документации для покупки технического оборудования и ПО; проведение переговоров с поставщиками оборудования и ПО; заключение договора на поставку технического оборудования и ПО; закрытие договоров.

На этапе планирования: составление плана по техническому обслуживанию оборудования и ПО; cоставление плана по замене компьютерного оборудования при неисправностях; cоставление плана по проверке безопасности ЛВС.

На этапе учёта: учёт выполнения плана по техническому обслуживанию оборудования и ПО; учёт выполнения плана по замене компьютерного оборудования при неисправностях; учёт выполнения плана по проверке безопасности ЛВС.

На этапе контроля: контроль выполнения плана по техническому обслуживанию оборудования и ПО; контроль выполнения плана по замене компьютерного оборудования при неисправностях

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

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

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

На этапе планирования: cоставление плана по труду и ЗП, cоставление графика отпусков; cоставление графика проведения обучения сотрудников; cоставление штатного расписания.

Далее производится: контроль выполнения плана по труду и ЗП, контроль выполнения графика отпусков, контроль выполнения графика проведения обучения сотрудников, контроль расстановки сотрудников в расписании.

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

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

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

На этапе контрактации: cоставление и заключение договоров с финансовыми организациями; закрытие договоров с финансовыми организациями.

На этапе планирования: cоставление плана поступления и расходов денежных средств; cоставление годового финансового плана; cоставление предварительного расчёта затрат; cоставление плана по прибыли.

Далее происходит: учёт финансовых операций, учёт затрат организации; учёт прибыли организации.

На этапе контроля: контроль поступления и расходования денежных средств согласно плану, контроль выполнение годового финансового плана, контроль правильности составления предварительного расчёта затрат; контроль выполнения плана по прибыли.

На стадии анализа: анализ поступления и расходования денежных средств; анализ финансовых результатов деятельности организации

1.5 Узкие места в деятельности организации

В ходе анализа структуры, функционирования и системы управления ООО «Параметрика» основной проблемой предприятия является отсутствие систематизации хранения и обработки разноплановой и разноформатной документации, а также неупорядоченность процедур мониторинга и подготовки разрабатываемой ПСД.

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

1.6 Дерево целей

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

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

Главной целью ООО «Параметрика» является получение максимальной прибыли.

2 Декомпозиция АСУ на подсистемы и комплексы задач

2.1 Цель и концепция создания АСУ

Целью создания АСУ на предприятиях является повышение эффективности его производственной деятельности путем достижения качественного решения конструкторских, технологических, планово-экономических и других производственных задач на основе получения достоверной информации и проведения многовариантных расчетов использования имеющихся ресурсов [6].

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

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

• Формирование плана о назначение проектов ГИПам;
• Составление опорного план-графика выполнения проектных работ по разделам;
• Составление списка проектных работ, выполняемых собственными силами организации и отдаваемых на подряд;
• Формирование списка подрядчиков для заключения договоров на разработку разделов ПСД

2.2 Виды подсистем АСУ и их особенности

АСУ включает в себя две основные части: функциональную и обеспечивающую. Каждая из них обладает своими уникальными характеристиками. Если сосредоточиться на функциональной части, то она представляет собой набор подсистем, которые решают различные задачи, такие как планирование, учет, анализ и другие. Обеспечивающая часть АСУ создает условия для реализации процесса автоматизации функциональной части.

2.3 Принципы декомпозиции функциональной части АСУ на подсистемы и комплексы задач

Декомпозиция - метод системного подхода к изучению больших систем, используемых при проектировании АСУ.

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

Функциональная часть АСУ представляет собой совокупность функциональных подсистем, в каждой из которых с помощью экономических, организационных, математических методов решается одна из задач (выполняется одна из функций) управления. [7]

Подсистемы могут быть выделены по функциональному и производственно-ресурсному признаку. Функциональный признак предусматривает необходимость выделения подсистем по функциям управления, таким как планирование, учет, анализ, контроль и т.д. Производственно-ресурсный признак предусматривает необходимость выделения подсистем в зависимости от производимых работ и необходимости ресурсов для их выполнения, например: финансы, оборудование, машины, кадры, МТР и т.д.

Во время проведения декомпозиции организации были выделены следующие функциональные подсистемы:

Комплексы задач, которые решаются в перечисленных подсистемах представлены в приложении Г.

2.4 Требования к обеспечивающим подсистемам АСУ

Обеспечивающая часть – это совокупность обеспечивающих подсистем АСУ, которые выделяются независимо от решаемых в АСУ задач, в соответствии с каким-либо иным системообразующим фактором. Поэтому обеспечивающие подсистемы не являются системами управления. Каждая обеспечивающая подсистема называется также обеспечением АСУ

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

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

2.4.1 Требование к математическому обеспечению

Математическое обеспечение – совокупность математических методов, моделей и алгоритмов обработки информации, используемых при решении функциональных задач и в процессе автоматизации проектировочных работ [8].

Данное обеспечение включает:

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

Ниже можно перечислить следующие требования к математическому обеспечению АСУ:

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

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

2.4.2 Требования к программному обеспечению

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

• ПО АСУ должно быть достаточным для выполнения всех функций АСУ, которые тем или иным образом реализуются с применением средств вычислительной техники;
• Преимущественно должны использоваться системы управления базами данных (СУБД), которые были зарегистрированы в установленном порядке;
• Отсутствие данных, которые не используются для реализации задач, не сказывалось на выполнении работы;
• Наличие средств диагностики технических средств;
• Контроль на достоверность входной информации;
• Реализация мер по защите от ошибок во время ввода и обработки информации;
• Совместимость и поддержка операционной системы Windows 10;

• Наличие эксплуатационной программной документации, которая должна содержать сведения, которые обеспечат необходимую работу персонала;
• Надежность и безопасность. Программное обеспечение должно обеспечивать высокую надежность и безопасность работы системы управления, чтобы исключить возможность непредвиденных сбоев и ошибок (так, к примеру на сервер, в обязательном порядке, должно быть установлено ПО для защиты от атак методом грубой силы; примером такого программного обеспечения является программа Fail2ban).
• Гибкость и масштабируемость. Программное обеспечение должно быть гибким и масштабируемым, чтобы удовлетворять различным требованиям объектов и процессов управления, а также обеспечивать возможность расширения и модификации системы.
• Интуитивно понятный интерфейс. Программное обеспечение должно иметь простой и понятный интерфейс, чтобы операторы могли быстро и легко работать с системой управления.
• Возможность совместной работы. Программное обеспечение должно обеспечивать возможность совместной работы нескольких пользователей, чтобы операторы могли обмениваться информацией и работать с системой управления в режиме реального времени.
• Совместимость с другими системами. Программное обеспечение должно быть совместимо с другими системами, используемыми в объектах и процессах управления, чтобы обеспечить интеграцию систем и обмен информацией между ними.
• План сдачи текущих проектов;
• Нормативные значения для ГИПов;
• Реестр договоров;
• Технологическая последовательность выполнения проектных работ;
• Опорный план-график выполнения проектных работ по разделам;
• Перечень загрузки исполнителей текущими проектами по неделям;
• Календарная разбивка проектов из программы работ по неделям года;
• Cписок коммерческих предложений по ПСД;
• Список проектных работ, выполняемых собственными силами организации и отдаваемых на подряд;

2.4.3 Требования к информационному обеспечению

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

На основе базы данных входной информацией служат входные документы:

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

• План о назначение проектов ГИПам;
• Опорный план-график выполнения проектных работ по разделам;
• Список проектных работ, выполняемых собственными силами организации и отдаваемых на подряд;
• Список подрядчиков для заключения договоров на разработку разделов ПСД.

Ниже перечислены основные требования к информационному обеспечению АСУ:

• Достоверность и актуальность информации. Информация, получаемая и обрабатываемая системой управления, должна быть достоверной и актуальной, чтобы операторы могли принимать правильные решения;
• Быстродействие и эффективность. Информационное обеспечение должно обеспечивать быстродействие и высокую эффективность обработки информации, чтобы операторы могли быстро реагировать на изменения в объектах и процессах управления;
• Резервное копирование. Информационное обеспечение должно обеспечивать резервное копирование данных, чтобы исключить возможность потери информации в случае сбоев в системе.
• Безопасность. Информационное обеспечение должно обеспечивать высокий уровень безопасности хранения и обработки информации, чтобы исключить возможность несанкционированного доступа к ней.
• Совместимость с различными форматами данных. Информационное обеспечение должно быть совместимо с различными форматами данных, используемыми в объектах и процессах управления, чтобы обеспечить возможность обмена информацией между системами.

2.4.4 Требования к техническому обеспечению

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

Для функционирования ИС необходимо:

Сервер должен удовлетворять следующим минимальным требованиям:

• Процессор 5 семейства от Intel (i5-12400f) или AMD (Ryzen 5 5600); обязательное количество ядер от 6 и более; потоков от 12 и выше; минимальная частота: 2,5 ГГц.
• От 16 Gb оперативной памяти с тактовой частотой минимум 3200 МГц (количество памяти напрямую зависит от максимально возможной пиковой нагрузки на сервер);
• 256 Gb – SSD диск под систему + минимум 2 жестких диска на 1 ТБ под данные, которые будут храниться на сервере. (при этом оба жёстких диска должны состоять в RAID 1, для увеличения отказоустойчивости и предотвращения потери важных данных)
• Видеокарта начиная с модели NVIDIA GeForce GT 1030 и выше.
• ИБП на 750 W (для предотвращения выключения при скачках напряжения либо же при кратковременном отключении электроэнергии)
• Клавиатура, мышь и монитор – не обязательны, так как администрирование сервера производится путём удалённого подключения к нему по протоколу SSH.
• Процессор AMD Ryzen 3 3200G и выше, либо же аналогичный процессор от Intel, к примеру Intel Core i3-10100F (также подойдут другие процессоры из младшей 3 линейки).
• От 2 Gb оперативной памяти для запуска толстого клиента (идеальный общий объём памяти для ПК - 8 GB);
• Жесткий диск 256 Гб и выше (желательно SSD);
• Монитор, клавиатура, мышь;
• Видеокарта подойдёт даже встроенная в процессор (либо же минимальный вариант - NVIDIA GeForce GT 1030)

Требования, предъявляемые к конфигурации клиентских станций:

Дополнительные требования к техническому обеспечению:

• Система мониторинга на аппаратном уровне либо на программном: Техническое обеспечение должно обеспечивать систему мониторинга и диагностики, чтобы операторы могли быстро выявлять и решать проблемы в системе. К примеру, на сервер должны быть установлены программы, которые фиксируют все важные показатели системы такие как: загрузка ЦП, оперативной памяти, количество используемого трафика и т.д. (данные программы помогают отслеживать правильное функционирование системы).
• Формирование плана о назначение проектов ГИПам;
• Составление опорного план-графика выполнения проектных работ по разделам;
• Составление списка проектных работ, выполняемых собственными силами организации и отдаваемых на подряд;
• Формирование списка подрядчиков для заключения договоров на разработку разделов ПСД.
• Сущности: представляют объекты или понятия, связанные с данными. Они имеют уникальные идентификаторы и свойства, описывающие их характеристики;
• Атрибуты: определяют свойства или характеристики сущностей. Они могут быть простыми, например, имя или возраст, или составными, состоящими из нескольких податрибутов, например, адрес, включающий улицу, город и почтовый индекс;
• Связи: отображают взаимосвязи между сущностями. Связи определяют, как одна сущность связана с другой и какие характеристики они совместно имеют;
• Ограничения целостности: устанавливают правила и ограничения, которым должны удовлетворять данные. Например, ограничение уникальности может требовать, чтобы у каждой сущности был уникальный идентификатор.
• Ассоциации: представляют отношения между сущностями и могут быть однонаправленными или двунаправленными. Ассоциации могут иметь атрибуты, описывающие характеристики связи.

2.4.5 Требования к эргономическому обеспечению

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

• комплекса документации, которая содержит требования к рабочим местам
• информационная модель
• условия деятельности персонала
• требования к уровню подготовки персонала
• система отбора и подготовка персонала

2.4.6 Требования к правовому обеспечению

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

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

На этапе функционирования включает в себя:

• определение статуса
• правовое положение и компетенция звеньев ИС и ИТ в организации
• Права, обязанности и ответственность персонала
• Порядок создания и использования в ИС
• Процедуры регистрации, сбора, хранение и обработки

2.4.7 Требования к лингвистическому обеспечению

Лингвистическое обеспечение объединяет совокупность языковых средств для формализации естественного языка, построения и сочетания информационных единиц в ходе общения пользователей̆ со средствами вычислительноӗ техники. С помощью лингвистического обеспечения осуществляется общение человека с машиной.

Язык программирования клиентской и серверной частей ПО: Python. Шрифт ввода-вывода данных – кириллица.

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

2.4.8 Требование к организационно – методическому обеспечению

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

2.5 Выбор и описание информационной технологии

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

В информационной системе ООО «Параметрика» используется следующее техническое обеспечение:

• Персональные компьютеры (ПК) и ноутбуки разных моделей;
• Локальная сеть и сеть Internet. Все подразделения организации подключены к общей локальной сети и имеют доступ к необходимой им информации. Каждый сотрудник имеет свою учетную запись, благодаря чему получает доступ к общим документам и папкам в локальной сети, а также осуществляет связь с клиентами по электронной почте.
• На рабочих местах установлены многофункциональные устройства (МФУ), которые соединяют в себе функции нескольких устройств: принтера, сканера, ксерокса и факса. Все сотрудники имеют доступ к установленным на рабочих местах МФУ по локальной сети;
• В серверной находятся модемы для телефонной связи и Internet
• На всех ПК установлена операционная система Windows 10 Pro. Все неполадки и сбои в работе системы постоянно контролирует и исправляет системный администратор компании;
• Разработка ПСД производится в следующих программах: AutoCAD, Autodesk 3ds Max, Autodesk Revit, SketchUP, Homestyler;
• Связь по электронной почте между сотрудниками осуществляется с помощью клиента для работы с почтой Microsoft Outlook;
• Для удалённой работы сотрудников организации используется VPN клиент OpenVPN. VPN сервер позволяет сотрудникам получать доступ ко всем необходимым файлам, расположенным в ЛВС организации, при помощи создания виртуального интерфейса.

3 Проектные решения по автоматизации комплекса задач подсистемы

3.1 Обоснование выбора подсистемы для ВКР

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

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

3.2 Общий подход к описанию задач подсистемы

3.2.1 Организационно-экономическая сущность задачи

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

Наименование задачи – точная формулировка задачи, где указывается краткая сущность и направленность самой задачи;

Цель решения задачи – это то, что необходимо получить на выходе в результате выполнения поставленной задачи, то есть тот документ, который мы получим;

Назначение задачи – описание того, что необходимо автоматизировать в аппарате управления, чтобы достичь конечную цель решения задачи;

Периодичность решения задачи – частота решения задачи показывает, как часто решается определённая задача, подлежащая автоматизации. Решаться задача может раз в год, месяц, неделю, каждый день, по запросу. Данные сроки зависят напрямую от частоты потребности в данной информации.

3.2.2 Входная информация/входные данные

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

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

Перечень условно – постоянной документации:

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

Формирование локального классификатора:

• Установлен перечень объектов подлежащих классификации, который представлен в таблице 3.1.
• Систематизируются объекты по классификационным признакам:
• Для кодирования будет использоваться последовательная система кодирования.
• Необходимо разработать кодовые обозначения, которые представлены в таблице в таблице 3.2.

Таблица 3.1. Перечень объектов подлежащих классификации

Схема планировочной организации земельного участка. Генеральный план

Схема планировочной организации земельного участка. Организация рельефа вертикальной планировкой

Схема планировочной организации земельного участка. Благоустройство

Архитектурные решения. I стадия (10%)

Архитектурные решения. II стадия (30%)

Архитектурные решения. III стадия (60%)

Конструктивные и объемно-планировочные решения. I стадия (30%)

Конструктивные и объемно-планировочные решения. II стадия (70%)

Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений. Система электроснабжения

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

…

Вид проектной документации и название подраздела.

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

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

Выделенные признаки:

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

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

Характерными особенностями иерархической системы являются:

• возможность использования неограниченного количества признаков
• соподчиненность признаков классификации, что выражается разбиением каждой классификационной группировки, образованной по одному признаку, на множество классификационных группировок по нижестоящему (подчиненному) признаку.
• Оптимизация ресурсов: планирование назначения проектов Главным инженерам проекта (ГИПам) позволяет эффективно распределить ресурсы организации. Путем установления приоритетов и распределения проектов между ГИПами можно достичь более равномерного использования квалификации и опыта сотрудников, а также обеспечить более эффективное использование временных и финансовых ресурсов;
• Распределение нагрузки: четкое планирование позволяет равномерно распределить нагрузку между ГИПами. Это помогает избежать перегрузки одного ГИПа и недостатка задач для других. Равномерное распределение нагрузки способствует более эффективной работе команды и предотвращает возможные задержки или проблемы из-за неравномерного распределения задач;
• Необходимость в стимулировании сотрудников при помощи премиальных годовых выплат; тем самым эффективное распределение проектов по ГИПам также позволит и самим ГИПам получить премию за каждый объект, который будет сопровождаться.
• Организация работы: составление опорного план-графика является важным инструментом для организации и управления проектными работами. Этот план-график позволяет определить последовательность и сроки выполнения различных разделов проекта, создавая структуру и систематизацию работы.
• Управление ресурсами: план-график помогает управлять ресурсами проекта, такими как время, людские ресурсы, бюджет. Путем определения временных интервалов для каждого раздела работы и связанных с ними ресурсов можно более эффективно планировать и распределять ресурсы, чтобы удовлетворить требования проекта.
• Определение зависимостей: при составлении опорного план-графика проектных работ по разделам необходимо учитывать логические зависимости между разными этапами и задачами проекта. Это позволяет установить последовательность выполнения работ и определить зависимости, чтобы предотвратить задержки и конфликты между задачами.
• Планирование и контроль сроков: Опорный план-график служит основой для планирования и контроля сроков выполнения проектных работ. Он позволяет определить ключевые моменты проекта, а также оценить продолжительность каждого раздела работы. Это помогает управлять временными рамками и предупреждать возможные задержки, чтобы проект был выполнен вовремя.

классификации;

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

Первый уровень – вид проектной документации;

Второй уровень – название подраздела;

Таблица 3.2 Кодовые обозначения

Вид проектной документации	Название подраздела
1. Схема планировочной организации земельного участка
	1. Генеральный план
	2. Организация рельефа вертикальной планировкой
	3. Благоустройство
2. Архитектурные решения
	1. I стадия (10%)
	2. II стадия (30%)
	3. III стадия (30%)
3. Конструкторские решения
	1. I стадия (30%)
	2. II стадия (70%)
4. Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений.
	1. Система электроснабжения
	2. Система водоснабжения
…	…

Таким образом, можно сформировать итоговую таблицу с присвоением каждой строке своего кода. Её вид представлен в таблице 3.3.

Таблица 3.3 Итоговая таблица

Код	Название
1 1	Схема планировочной организации земельного участка. Генеральный план
1 2	Схема планировочной организации земельного участка. Организация рельефа вертикальной планировкой
1 3	Схема планировочной организации земельного участка. Благоустройство
…	…
2 1	Архитектурные решения. I стадия (10%)
2 2	Архитектурные решения. II стадия (30%)
2 3	Архитектурные решения. III стадия (60%)
…	…
3 1	Конструктивные и объемно-планировочные решения. I стадия (30%)
3 2	Конструктивные и объемно-планировочные решения. II стадия (70%)
…	…
4 1	Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений. Система электроснабжения
4 2	Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений. Система водоснабжения

3.2.3 Выходная/результатная информация

На основе входных данных выполняется определённый комплекс задач, выполнение которого можно автоматизировать при помощи внедрения АИС, и в результате выполнения алгоритмов формируется выходная информация в виде результирующего документа [9].

В результате операций, которые выполняются в АИС, на выходе формируются такие документы, как:

• План о назначение проектов ГИПам;
• Опорный план-график выполнения проектных работ по разделам;
• Cписок проектных работ, выполняемых собственными силами организации и отдаваемых на подряд;
• Cписок подрядчиков для заключения договоров на разработку разделов ПСД.

3.2.4 Описание ручного и машинного алгоритмов решения задач

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

Одним из основных этапов в проектировании АСУ является создание логико-информационной схемы (ЛИС), так как на её основе будет происходить дальнейшая работа по автоматизации [10]. В представленной логико-информационной схеме в приложении Д (на двух листах) наглядно показан и описан процесс автоматизации функций по решению задач отдела бюро ГИПов организации ООО “Параметрика”.

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

3.3 Обоснование выбора задач для автоматизации и их описание

Выбор задачи "Формирование плана о назначение проектов ГИПам" обосновывается следующими факторами:

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

Выбор задачи "Составление опорного план-графика выполнения проектных работ по разделам" обосновывается следующими факторами:

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

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

• Управление рисками: составление списка проектных работ, разделяющего задачи между собственными силами и подрядчиками, помогает управлять рисками. Организация может принимать решения на основе своих сильных сторон, опыта и ресурсов, минимизируя потенциальные риски, связанные с несоответствием квалификации или ограниченными ресурсами (к примеру, отсутствие нужных специалистов, которые могут разрабатывать определённый раздел ПСД). Таким образом значительно снижаются риски невыполнения работы в срок и соответственно риск попадания под санкции заказчика.
• Бюджетные соображения: при формировании списка подрядчиков можно учесть финансовые ограничения и бюджетные параметры проекта. Разные компании могут предлагать разные цены и условия, и формирование списка подрядчиков позволяет выбрать те варианты, которые соответствуют финансовым возможностям организации
• Квалификация и опыт: Формирование списка подрядчиков позволяет выбрать компании или организации с соответствующей квалификацией и опытом в разработке разделов проектно-сметной документации (ПСД). Это обеспечивает высокое качество и профессиональный подход к разработке требуемых разделов.

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

Выбор задачи "Формирование списка подрядчиков для заключения договоров на разработку разделов ПСД" обосновывается следующими факторами:

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

3.3.1 Формирование плана о назначение проектов ГИПам

Место решения задачи: бюро ГИПов ООО «Параметрика»

Цель: распределить проекты из программы работ на год по главным инженерам проектов, таким образом, чтобы годовая премиальная выплата за сопровождение проектов была наибольшей для каждого из ГИПов.

Назначение: распределить проекты, на которые были заключены договора с заказчиками, ГИПам, исходя из их текущей дневной загрузки, а также статистической трудоёмкости сопровождения каждого типа проекта определённым ГИПом [11].

Критерии: так как архитектурное бюро «Параметрика» специализируется на разработке проектной документации, главным отделом, выполняющим основной контроль и координацию проектных работ, является бюро ГИПов. Всего в отделе работает определённое количество главных инженеров, которые имеют различный стаж работы, специализацию и другие характеристики. Для распределения проектов был выбран один из ГИПов.

Стоит отметить, что у ГИПа есть несколько главных параметров: k–текущая дневная нагрузка инженера (выражается коэффициентом использования рабочего времени), d – максимальная дневная нагрузка (лимит рабочего времени). Таким образом, один ГИП может работать сразу над несколькими проектами.

Всего исходной организацией было заключено договоров на a_i проектов, где i – класс сложности проекта. На данный момент существует n классов сложности проекта. У каждого i-го класса сложности проекта есть примерное время сопровождения его ГИПом, которое обозначается как t_i, а также премиальная ставка от его реализации, которая обозначается как с_i. Премия выплачивается как определённый процент от базового оклада ГИПа, следовательно обозначим его переменной m.

Необходимо назначить выбранному ГИПу определённое число проектов, так чтобы максимизировать премиальную годовую выплату от сопровождения этих проектов. При этом надо стремиться к распределению проектов по всем ГИПам (в случае невозможности – некоторые из проектов будут отданы на субподряд).

Исходные данные:

n – количество классов сложности проекта [шт.];

a_i – количество проектов i-го класса сложности, (i = ) [шт.];

k – текущая дневная нагрузка инженера;

d – максимальная дневная нагрузка ГИПа;

t_i – примерное время сопровождения проекта i-го класса сложности, (i = );

с_i – премиальная ставка от реализации проекта i-го класса сложности, (i = );

m – размер базового оклада выбранного ГИПа [руб.]

Искомые данные:

x_i – количество проектов i-го вида сложности, которые будут назначены выбранному ГИПу (переменные принимают только целые значения);

F(x) – величина премии, которая будет назначена выбранному ГИПу за сопровождение проектов (максимально возможная величина) [руб.];

Ограничения:

(3.1)

(3.2)

(3.3)

Целевая функция:

(3.4)

Источники и способы получения данных: источниками входных данных, необходимых для решения задачи будут являться следующие документы: «Реестр договоров», «Ведомость о выполнение текущих проектов», а также справочники «Классификация проектов», «Разрабатываемые проекты», «Сотрудники»

Таблица 3.4. Макет входного документа «Реестр договоров»

№ п/п	№ договора	Вид договора	Контрагент	Предмет договора	Дата начала работ	Продолжи тельность	Стоимость	Статус
1	2	3	4	5	6	7	8	9

Таблица 3.5. Макет входного документа «Ведомость о выполнение текущих проектов»

№ п/п	Шифр проекта	ФИО ведущего ГИПа	Дата начала	Дата окончания	Выполненный объем в %
1	2	3	4	5	6

Таблица 3.6. Макет справочника «Классификация проектов»

№ п/п	Класс сложности	Коэффициент использования рабочего времени	Премиальная ставка за сопровождение в %
1	2	3	4

Таблица 3.7. Макет справочника «Разрабатываемые проекты»

№ п/п	Шифр проекта	№ договора	Тип объекта	Класс сложности	S проекти рования, м2	Плановая стоимость	Фактическая стоимость
1	2	3	4	5	6	7	8

Таблица 3.8. Макет справочника «Сотрудники»

Код сотрудника	Фамилия	Имя	Отчество	Специализация	Отдел	Зарплата	Поправочный коэффициент загрузки
1	2	3	4	5	6	7	8

Выходной документ: в результате решения данной задачи формируется документ «План о назначение проектов ГИПам»

Таблица 3.9. Макет выходного документа «План о назначение проектов ГИПам»

№ п/п	ГИП	Шифр проекта
1	2	3

Форма представления выходного документа: алфавитно-цифровая.

Потребители результатной информации и способы ее отправки: результат решения используется в бюро ГИПов, согласовывается заместителем директора по проектированию, передаётся через развёрнутую ЛВС организации.

Список таблиц базы данных, в которых хранится информация из входных документов:

• current_projects_plan;
• proj_complexity;
• projects;
• employees;
• regulatory_values;
• contracts;
  
• contracts;
• tech_sequence;
• projects;
• projects_structures;
• MRR_document;
• project_works;
• proj_complexity.
• schedule_of_projects;
• employees_load;
• projects_devide;
• projects;
• projects_works;
• employees;
  
• commercial_offers;
• project_works;
• projects;
• list_of_works;
• schedule_of_projects;
• employees;
  

Соответствие граф входных документов полям таблиц базы данных:

Таблица 3.10. Входной документ «Ведомость о выполнение текущих проектов»

№ п/п	Шифр проекта	ФИО ведущего ГИПа	Дата начала	Дата окончания	Выполненный объем в %
1	2	3	4	5	6
-	projects. project_name	employees. surname	current_projects_plan. start_date	current_projects_plan. completion_date	current_projects_plan. executed_part

Таблица 3.11. Входной документ «Реестр договоров»

№ п/п	№ договора	Вид договора	Контрагент	Предмет договора	Дата начала работ	Продолжи тельность, дн.	Стоимость, руб.	Статус
1	2	3	4	5	6	7	8	9
-	contracts. contract_number	contracts. type_of_contract	contracts. contractor	projects. project_type	contracts. start_date	contracts. duration	contracts. total_cost	contracts. contract_status

Таблица 3.12. Cправочник «Классификация проектов»

Класс сложности	Коэффициент использования рабочего времени	Премиальная ставка за сопровождение в %
1	2	3
proj_complexity. complexity_id	proj_complexity. working_time_ratio	proj_complexity. premium_rate

Таблица 3.13. Справочник «Разрабатываемые проекты»

№ п/п	Шифр проекта	№ договора	Тип объекта	Класс сложности	S проекти рования, м2	Плановая стоимость	Фактическая стоимость
1	2	3	4	5	6	7	8
-	projects. project_name	contracts. contract_number	projects. object_type	proj_complexity. complexity_ID	projects. design_area	projects. planned_cost	projects. actual_cost

Таблица 3.14. Cправочник «Сотрудники»

Код	Фамилия	Имя	Отчество	Специализация	Отдел	Зарплата	Поправочный коэффициент загрузки
1	2	3	4	5	6	7	8
employees. employee_ID	employees. surname	employees. name	employees. middle_name	project_works. work_code	employees. specialty	employees. salary	employees. daily_load

Описание машинного алгоритма для решения задачи:

• При помощи запроса к таблице БД contracts определяем значение поля «сontract_ID» для каждой записи, значение поля «сontract_status» которой = «Новый». Таким образом мы находим и записываем во временную переменную все значения ключа сontract_ID для договоров, которые были недавно заключены.
• Используя значения ключа сontract_ID, которые записаны в переменную, определяем «Шифр проекта»: запросом select к таблице БД projects определяем значение поля «Project_ID», для записей значение поля «сontract_ID» которых = ключу сontract_ID из переменной. Полученные значение заносим в переменную p [j], где j = количеству проектов. При помощи запроса select к таблице БД projects находим значения полей «project_complexity» для тех строк, где «project_complexity» принадлежит диапазону из p [j]. Подсчитываем a_i – количество проектов класса сложности i.
• При помощи запросов к таблице БД «employees» определяем актуальный список ГИПов. Найденных ранее ГИПов проверяем на наличие в таблице БД «current_projects_plan», где показывается текущая нагрузка всех ГИПов. Если ГИПа нет в этой таблице БД – это означает, что его коэффициент загрузки = 0, в противном случае записываем все проекты, которые не выполнил ГИП. Определяем тип данных проектов и подсчитываем сколько в сумме занимают эти проекты от всего рабочего времени ГИПа. При помощи цикла рассчитываем для всех главных инженеров их текущую загрузку (она может быть в интервале от 0 до 1)
• Выбираем ГИПа с минимальной загрузкой, если таких несколько, то можно взять любого из них. Данному ГИПу будут назначаться проекты в первую очередь при помощи решения мат задачи.
• Для каждого класса сложности взятых проектов находим премиальный коэффициент при помощи таблицы БД «proj_complexity», а также базовый коэффициент трудоёмкости из этой же таблицы БД. Для найденного ГИПа находим поправочный коэффициент и его зарплату из таблицы «employees». При помощи решения мат. задачи находим состав проектов, который будет назначен ГИПу.
  

Контрольный пример для машинного алгоритма:

Таблица 3.15. «Реестр договоров»

№ п/п	№ договора	Вид договора	Контрагент	Предмет договора	Дата начала работ	Продолжи тельность, дн.	Стоимость, руб.	Статус
1	2	3	4	5	6	7	8	9
1	117-КМ-76	С заказчиком	ИК ВЕКТОР	Разделы ПСД	02.06.2023	30	200 000	Исполняется
2	121-ПР-28	С заказчиком	ООО СТИ	Стадия "П" + "Р"	09.06.2022	60	900 000	Новый

Таблица 3.16. «Ведомость о выполнение текущих проектов»

№ п/п	Шифр проекта	ФИО ведущего ГИПа	Дата начала	Дата окончания	Выполненный объем в %
1	2	3	4	5	6
1	АНО/210985	Сычов А.Н.	02.06.2023	01.07.2023	80

Таблица 3.17. Справочник «Разрабатываемые проекты»

№ п/п	Шифр проекта	№ договора	Тип объекта	Класс сложности	S проектиро вания, м2	Плановая стоимость	Фактическая стоимость
1	2	3	4	5	6	7	8
1	АНО/210985	117-КМ-76	Индивидуальный жилой дом	1	120	80 000	-
2	АНО/215321	121-ПР-28	Индивидуальный жилой дом	2	250	360 000	-

Таблица 3.18. Cправочник «Классификация проектов»

Класс сложности	Нормативные трудозатраты в день в %	Премиальная ставка за сопровождение в %
1	2	3
1	20	7.5
2	40	10

Таблица 3.19. Cправочник «Сотрудники»

Код	Фамилия	Имя	Отчество	Специализация	Отдел	Зарплата	Поправочный коэффициент загрузки
1	2	3	4	5	6	7	8
101	Сычов	Александр	Николаевич	-	бюро ГИПов	100 000	0.9
102	Дрягин	Герман	Олегович	-	бюро ГИПов	80 000	1

Таблица 3.20. Выходной документ «План о назначение проектов ГИПам»

№ п/п	ГИП	Шифр проекта
1	2	3
1	Дрягин Г.О.	АНО/215321

Макет выходного документа, включая структуру информационной части:

Рисунок 3.1 – План о назначение проектов ГИПам

3.3.2 Составление опорного план-графика выполнения проектных работ по разделам

Наименование: «Составление опорного план-графика выполнения проектных работ по разделам».

Место решения задачи: бюро ГИПов ООО «Параметрика».

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

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

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

Источники и способы получения данных: источниками входных данных, необходимых для решения задачи будут являться следующие документы: «Реестр договоров», «Технологическая последовательность выполнения проектных работ», а также справочники: «МРР-4.1.02-21 – Объекты капитального строительства», «Разрабатываемые проекты», «Состав проектов».

Таблица 3.23. Макет входного документа «Реестр договоров»

№ п/п	№ договора	Вид договора	Контрагент	Предмет договора	Дата начала работ	Продолжи тельность	Стоимость	Статус
1	2	3	4	5	6	7	8	9

Таблица 3.24. Макет входного документа «Технологическая последовательность выполнения проектных работ»

№ п/п	Наименование раздела	Исходящее событие	Входящее событие
1	2	3	4

Таблица 3.25. Макет справочника «Разрабатываемые проекты»

№ п/п	Шифр проекта	№ договора	Тип объекта	Класс сложности	S проекти рования, м2	Плановая стоимость	Фактическая стоимость
1	2	3	4	5	6	7	8

Таблица 3.26. Макет справочника «Состав проектов»

№ п/п	Шифр проекта	Наименование раздела
1	2	3

Таблица 3.27. Макет справочника «МРР-4.1.02-21 – Объекты капитального строительства»

№ п/п	Наименование раздела	Сокращение	Процент от плана
1	2	3	4

Выходной документ: в результате решения данной задачи формируется документ «Опорный план-график выполнения проектных работ по разделам»

Таблица 3.28. Макет выходного документа «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектиро-вания, руб.
1	2	3	4	5	6	7	8

Форма представления выходного документа: алфавитно-цифровая.

Потребители результатной информации и способы её оправки: результат решения используется внутри отдела бюро ГИПов для разработки других документов (для дальнейшего определения команды исполнителей из проектных отделов), а также непосредственно самим ГИПом для контроля сроков выполнения работ по проекту, координации между исполнителями, выбора команды для проектирования; планово-договорным отделом. Результат решения задачи передаётся через ЛВС компании.

Список таблиц базы данных, в которых хранится информация из входных документов:

Соответствие граф входных документов полям таблиц базы данных:

Таблица 3.29. Входной документ «Реестр договоров»

№ п/п	№ договора	Вид договора	Контрагент	Предмет договора	Дата начала работ	Продолжи тельность, дн.	Стоимость, руб.	Статус
1	2	3	4	5	6	7	8	9
-	contracts. contract_number	contracts. type_of_contract	contracts. contractor	projects. project_type	contracts. start_date	contracts. duration	contracts. total_cost	contracts. contract_status

Таблица 3.30. Входной документ «Технологическая последовательность выполнения проектных работ»

№ п/п	Сокращение раздела	Исходящее событие	Входящее событие
1	2	3	4
-	project_works.work_code	project_works.work_code	project_works.work_code

Таблица 3.31. Cправочник «Разрабатываемые проекты»

№ п/п	Шифр проекта	№ договора	Тип объекта	Класс сложности	S проекти рования, м2	Плановая стоимость	Фактическая стоимость
1	2	3	4	5	6	7	8
-	projects. project_name	contracts. contract_number	projects. object_type	proj_complexity. complexity_ID	projects. design_area	projects. planned_cost	projects. actual_cost

Таблица 3.32. Cправочник «Состав проектов»

№ п/п	Шифр проекта	Наименование раздела
1	2	3
-	projects.project_name	project_works.work_code

Таблица 3.33. Cправочник «МРР-4.1.02-21 – Объекты капитального строительства»

№ п/п	Наименование раздела	Сокращение	Процент от плана
1	2	3	4
-	project_works.work_code	mrr_document.mrr_shortening	mrr_document.value

Описание машинного алгоритма для решения задачи:

• При помощи запроса select к таблице БД «contracts», определяются все значения первичного ключа contract_ID для договоров, которым присущи следующие значения атрибутов: Вид договора (поле «type_of_contract») = «C заказчиком», Статус (поле «contract_status») = «Новый». Данные значения заносятся во временную переменную – c [n], для дальнейшего использования в программе. Для каждого из значений данной переменной будет пройден цикл действий, описанный ниже (таким образом на каждый договор будет составлен свой опорный план-график);
• Используя значение первичного ключа contract_ID, из таблицы БД «projects» выбирается только та запись проекта, для которой выполняется условие: значение поля «contract_ID» = полученному ранее ключу contract_ID (далее c [1]). Значение первичного ключа (project_ID) найденного проекта заносится во временную переменную p;
• Из таблицы «projects_structures», определяются все коды разрабатываемых разделов (ключи project_work_ID), для которых справедливы следующие условия: значение поля шифра проекта «project_ID» = p. Ключи project_work_ID для данного проекта помещаем в переменную – w [n], где n – количество ключей. В выходном документе будет создано n строчек, где: в поле «schedule_ID» записывается результат функции sequence.nextval(); поле «project_work_ID» = w [n] (найденные коды разрабатываемых разделов); поле «project_ID» = p (код разрабатываемого проекта); в поле «employee_ID» - записывается значение NULL (исполнители не назначаются в данном алгоритме).
• Далее определяем «Длительность проектирования, дн.» (поле «duration») и «Стоимость проектирования, руб.» (поле «work_cost») для каждого найденного нами ранее раздела (поле «project_work_ID»): из выходного документа берутся ключи project_work_ID (переменная - w [n]) и project_ID (переменная – p). Запросом select получаем значение поля «project_type» из таблицы «projects», где поле «project_ID» = p (исходя из этого значения будет подбираться алгоритм дальнейшего решения). Данное значение поместим в переменную t.
• Если t равно «Стадия “П” + “Р”», то искомые значения рассчитываются следующим образом: для каждого w [n] находим значение «value» из таблицы MRR_document записываем в переменную v [n]; находим значение поля «planned_cost» из таблицы projects, где: поле «project_ID» = p, и записываем в переменную p_cost. Поле «work_cost» выходного документа для каждого w [n] = round ((v [n] * p_cost /100),0), где n = количеству разделов. Поле «work_duration» выходного документа для каждого w [n] = round ((v [n] * «duration»/100),0), где «duration» — это время работ для конкретного договора (оно находится запросом к таблице contracts по ключу с [1])
• Если t равно «Разделы ПСД», то алгоритм меняется: для каждого w [n] запросом находим значение поля «value» из таблицы MRR_document (записываем в переменную v [n]) и складываем эти значения между собой и результат записываем в переменную v_total. Из таблицы projects находим значение поля «planned_cost» для p (разрабатываемого проекта) и записываем в переменную p_cost. Поле «work_cost» выходного документа для каждого w [n] = round ((p_cost/v_total * v[n]),0), где n = количеству разделов. Поле «work_duration» выходного документа вычисляется по похожему алгоритму. w [n] = round ((«duration»/v_total * v[n]),0), где «duration» — это время работ для конкретного договора (оно находится запросом к таблице contracts по ключу с [1]).
• Для расчёта полей «start_date» и «expiration_date» выходной таблицы надо использовать таблицу tech_sequence, в том случае если t = «Стадия “П” + “Р”». Алгоритм: из таблицы tech_sequence запросом select определяется значение поля «project_work_ID» записи, для которой справедливо следующее: поле «previous_part» = «0» и записывается в переменную. В выходном документе при помощи запроса находим первую работу и в поле «start_date» заносим дату начала работ из договора (таблица contracts). Поле «expiration_date» = «start_date» + «work_duration» - 1. Далее при помощи таблицы tech_sequence находим project_work_ID, которые начинаются после выполнения 1 работы. В выходном документе для данных работ проставляем значение поля «start_date» = «expiration_date» + 1 (дате окончания предыдущей работы +1). С помощью такого алгоритма проставляются все значения полей «start_date» и «expiration_date» выходной таблицы.
  

Контрольный пример для машинного алгоритма:

Таблица 3.34. «Реестр договоров»

№ п/п	№ договора	Вид договора	Контрагент	Предмет договора	Дата начала работ	Продолжи тельность, дн.	Стоимость, руб.	Статус
1	2	3	4	5	6	7	8	9
1	117-КМ-76	С заказчиком	ИК ВЕКТОР	Разделы ПСД	02.01.2023	15	200 000	Исполняется
2	121-ПР-28	С заказчиком	ООО СТИ	Стадия "П" + "Р"	09.01.2023	60	900 000	Новый

Таблица 3.35. «Технологическая последовательность выполнения проектных работ»

№ п/п	Наименование раздела	Исходящее событие	Входящее событие
1	2	3	4
1	1.1	1.2	0
2	1.2	1.3	1.1

Таблица 3.36. Справочник «Разрабатываемые проекты»

№ п/п	Шифр проекта	№ договора	Тип объекта	Класс сложности	S проектиро вания, м2	Плановая стоимость	Фактическая стоимость
1	2	3	4	5	6	7	8
1	АНО/210985	117-КМ-76	Индивидуальный жилой дом	1	120	80 000	-
2	АНО/215321	121-ПР-28	Индивидуальный жилой дом	2	250	360 000	-

Таблица 3.37. Справочник «Состав проектов»

№ п/п	Шифр проекта	Наименование раздела
1	2	3
1	АНО/210985	4.1
2	АНО/210985	4.2
3	АНО/215321	1.1
4	АНО/215321	1.2

Таблица 3.38. Cправочник «МРР-4.1.02-21 – Объекты капитального строительства»

№ п/п	Наименование раздела	Сокращение	Процент от плана
1	2	3	4
1	1.1	ГП	3,1
2	1.2	ОР	4,5

Таблица 3.39. «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектирования, руб.
1	2	3	4	5	6	7	8
1	АНО/215321	1.1		09.01.2023	10.01.2023	2	11 160
2	АНО/215321	1.2		11.01.2023	13.01.2023	3	16 200

Макет выходного документа, включая структуру информационной части:

Рисунок 3.2 – Опорный план-график выполнения проектных работ по разделам по проекту

3.3.3 Составление списка проектных работ, выполняемых собственными силами организации и отдаваемых на субподряд

Место решения задачи: бюро ГИПов ООО «Параметрика»

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

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

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

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

Таблица 3.40. Макет входного документа «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектиро-вания, руб.
1	2	3	4	5	6	7	8

Таблица 3.41. Макет входного документа «Перечень загрузки исполнителей текущими проектами по неделям»

№ п/п	Исполнитель	Номер недели	Трудовой ресурс, чел.ч.
1	2	3	4

Таблица 3.42. Макет входного документа «Календарная разбивка проектов из программы работ по неделям года»

№ п/п	Номер недели	Дата начала	Дата окончания	Шифр проекта
1	2	3	4	5

Таблица 3.43. Макет справочника «Сотрудники»

Код сотрудника	Фамилия	Имя	Отчество	Специализация	Отдел	Зарплата	Поправочный коэффициент загрузки
1	2	3	4	5	6	7	8

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

Таблица 3.44. Макет выходного документа «Перечень разделов проекта выполняемых собственными силами организации»

№ п/п	Шифр проекта	Наименование раздела	Длительность	Стоимость
1	2	3	4	5

Таблица 3.45. Макет выходного документа «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектиро-вания, руб.
1	2	3	4	5	6	7	8

Таблица 3.46. Макет выходного документа «Перечень загрузки исполнителей текущими проектами по неделям»

№ п/п	Исполнитель	Номер недели	Трудовой ресурс, чел.ч.
1	2	3	4

Таблица 3.47. Макет выходного документа «Перечень разделов проекта

отдаваемых на субподряд»

№ п/п	Шифр проекта	Наименование раздела	Длительность	Стоимость
1	2	3	4	5

Форма представления выходного документа: алфавитно-цифровая.

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

Описание ручного алгоритма решения задачи:

Для решения задачи необходимо выполнить следующие действия:

• Для каждого раздела проекта (графа “Наименование раздела”) из документа «Опорный план-график выполнения проектных работ по разделам» необходимо определить исполнителей, которые могут выполнять данный раздел: для этого берём значение графы “Наименование раздела” для первой строки из опорного план графика выполнения проектных работ по разделам и в справочнике «Сотрудники» находим только те строки, значение графы “Специализация” которых = наименованию раздела проекта, найденному ранее. Таким образом определяются, какие исполнители могут выбрать данный вид проектных работ.
• Для найденных исполнителей определяем их табельный код (графа “Код” справочника сотрудников);
• Далее необходимо определить в какие недели года выполняется выбранный раздел: для этого берём значения из граф “Дата начала” и Дата окончания” из опорного план-графика выполнения проектных работ по разделам: сравнивая данные значения с аналогичными графами из документа “Календарная разбивка проектов из программы работ по неделям года”. Соответственно получаем номер недели начала выполнения проектной работы и номер недели окончания выполнения проектной работы (данные значения берём из графы “Номер недели”).
• При помощи документа “Перечень загрузки исполнителей текущими проектами по неделям” определяем загрузку исполнителя в часах в промежуток времени, в который выполняется проектная работа: берём код исполнителя и номера недели начала и окончания работы, найденные ранее; находим в перечне загрузки исполнителей подходящие строки и производим суммирование значений из графы “Трудовой ресурс, чел.ч.”
• Сравниваем полученную сумму на предыдущем шаге с значением графы “Длительность проектирования, дн” для рассматриваемого раздела из опорного план-графика. Стоит отметить, что перед сравнением значение из графы “Длительность проектирования, дн” для рассматриваемого раздела надо умножить на 8, так как предполагается, что рабочий день в организации составляет 8 часов.
• В случае если значение из графы “Длительность проектирования, дн” * на 8 меньше значения трудового ресурса для исполнителя, полученного ранее, то формируется документ “Перечень разделов проекта, выполняемых собственными силами организации по проекту” и добавляется в него строка, где в графы “Шифр проекта”, “Наименование раздела”, “Длительность” и “Стоимость” заносятся значения из аналогичных граф опорного план-графика проектирования. Таким образом распределяются все проектные работы проекта, которые отображены в опорном план-графике выполнения проектных работ по разделам.
• Также стоит учитывать, что у нас будут меняться документ “Опорный план-график выполнения проектных работ по разделам” (будет добавлен табельный код исполнителя в графу “Исполнитель”) и будут корректироваться значения графы “Трудовой ресурс, чел.ч.” в документе «Перечень загрузки исполнителей текущими проектами по неделям». Данные изменения вносятся 1 раз просто распределения работ каждого проекта.
• В конечном итоге получаются 2 документа, либо же 1. Всё зависит будут ли какие-либо работы по проекту отданы на субподряд.

Список таблиц базы данных, в которых хранится информация из входных документов:

Соответствие граф входных документов полям таблиц базы данных:

Таблица 3.48. Входной документ «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектирования, руб.
1	2	3	4	5	6	7	8
-	projects. project_name	projects_works. work_code	employees. surname	schedule_of_projects. start_date	schedule_of_projects. expiration_date	schedule_of_projects. work_duration	schedule_of_projects.work_cost

Таблица 3.49. Входной документ «Перечень загрузки исполнителей текущими проектами по неделям»

№ п/п	Исполнитель	Номер недели	Трудовой ресурс, чел.ч.
1	2	3	4
-	employees.surname	projects_devide.week_ID	employees_load.workforce

Таблица 3.50. Входной документ «Календарная разбивка проектов из программы работ по неделям года»

№ п/п	Номер недели	Дата начала	Дата окончания	Шифр проекта
1	2	3	4	5
-	projects_devide. week_ID	projects_devide. period_start	projects_devide. period_end	projects. project_name

Таблица 3.51. Cправочник «Сотрудники»

Код	Фамилия	Имя	Отчество	Специализация	Отдел	Зарплата	Поправочный коэффициент загрузки
1	2	3	4	5	6	7	8
employees. employee_ID	employees. surname	employees. name	employees. middle_name	project_works. work_code	employees. specialty	employees. salary	employees. daily_load

Описание машинного алгоритма для решения задачи:

• При помощи запроса select к таблице БД schedule_of_projects получаем значения полей: «project_ID», «project_work_ID», «start_date» и «expiration_date», для строчек значения поля «employee_ID» которых = «NULL». Значение ключа «project_ID» заносим в переменную p; все значения ключей «project_work_ID» соответствующие p, заносятся в переменную w [n], значения полей «start_date» и «expiration_date» соответствующие «project_work_ID» заносятся в переменные s [n] и e [n], где n = количество выполняемых работ по определённому p (ключу шифра проекта).
• Далее для каждого ключа раздела проекта w [n], необходимо найти код исполнителя (employee_ID) из таблицы employees. Совершается выборка строчек из таблицы БД employees, для которых значение поля «project_work_ID» = w [n]. Стоит отметить, что для одного w [n] может быть несколько исполнителей. Таким образом из полученных строк для каждого w [n], определяем значения полей «employee_ID». Эти значения заносим в переменную.
• Следующим шагом при помощи запроса к таблице БД project_devide определяем номер недели, на которой начался w [n], а также номер недели, на которой w [n] закончился: для этого используем переменные s [n] и e [n] соответственно. Алгоритм: делаем запрос к таблице project_devide и находим значение поля «project_work_ID», для которого s [n] находится между значениями полей «period_start» и «period_end», а также значение поля «project _ID» = p. Данное значение это номер недели начала раздела w [n]. Таким же образом находим номер недели окончания раздела w [n]. Все полученные значения заносятся в переменные w_s [n] и w_e [n]. Гдe w_s [n] номер недели начала для w [n], а w_e [n] – номер недели его окончания.
• Формируем записи выходной таблицы list_of_works: поле «list_ID» = sequence.nextval(); «project_ID» = p; «project_work_ID» = w [n]; значения поля «recruited» будет найдено в следующем шаге.
• Определяем значение поля «recruited» для каждой записи выходной таблицы list_of_works. Для каждого w [n] выполняется следующий алгоритм: при помощи запроса к таблице employees_load находим все записи, для которых значение поля «week_ID» принадлежит интервалу значений от w_s [n] до w_e [n]; производится выборка строк по «employee_ID»; для каждого «employee_ID» производится суммирование значений полей «workforce»; если полученное значение >= значению поля «work_duration»*8 таблицы schedule_of_projects, где «project_ID» = p и «project_work_ID» = w [n], то данный «employee_ID» записывается в таблицу schedule_of_projects, а в выходной документ в поле «recruited» - “Выполняется отделом”. После занесения значения в таблицу выходного документа производится корректировка таблицы employees_load: для назначенного исполнителя (employee_ID) уменьшается значение поля «workforce» для строчек, которые удовлетворяют условию – значение «week_ID» лежит в интервале от w_s [n] до w_e [n].
• В случае если не у одного из исполнителей w [n] сумма не удовлетворяет условию, то в выходной документ в поле «recruited» записывается значение «Отдан на субподряд». И модификация таблицы employees_load не производится.
• Происходит формирование выходных документов: выходные документы будут представлены не в виде таблиц БД, а при помощи представлений. Формируем перечень разделов проекта, выполняемых собственными силами организации: из таблицы БД list_of_works делаем выборку только тех строк, в которых поле «recruited» = “Выполняется отделом” и объединяем эту таблицу с таблицей БД schedule_of_projects. Таким же способом делаем представление для другого выходного документа.

Контрольный пример для машинного алгоритма:

Таблица 3.52. «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектирования, руб.
1	2	3	4	5	6	7	8
1	АНО/215321	1.1		09.01.2023	10.01.2023	2	11 160
2	АНО/215321	1.2		11.01.2023	13.01.2023	3	16 200

Таблица 3.53. «Перечень загрузки исполнителей текущими проектами по неделям»

№ п/п	Исполнитель	Номер недели	Трудовой ресурс, чел.ч.
1	2	3	4
1	Дрягин Г.О.	1	24
2	Дрягин Г.О.	2	16
6	Васильев Е.А.	1	40
7	Васильев Е.А.	2	8

Таблица 3.54. «Календарная разбивка проектов из программы работ по неделям года»

№ п/п	Номер недели	Дата начала	Дата окончания	Шифр проекта
1	2	3	4	5
1	1	02.01.2023	06.01.2023	АНО/210985
2	1	02.01.2023	06.01.2023	АНО/215321
3	2	09.01.2023	13.01.2023	АНО/210985
4	2	09.01.2023	13.01.2023	АНО/215321
5	3	16.01.2023	20.01.2023	АНО/210985
6	3	16.01.2023	20.01.2023	АНО/215321
7	4	23.01.2023	27.01.2023	АНО/215321

Таблица 3.55. Cправочник «Сотрудники»

Код	Фамилия	Имя	Отчество	Специализация	Отдел	Зарплата	Поправочный коэффициент загрузки
1	2	3	4	5	6	7	8
101	Дрягин	Герман	Олегович	1.1	Архитектурно-строительный	70 000	-
102	Васильев	Евгений	Антонович	1.2	Архитектурно-строительный	90 000	-

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

№ п/п	Шифр проекта	Наименование раздела	Длительность	Стоимость
1	2	3	4	5
1	АНО/215321	1.1	2	11 600

Таблица 3.57 Выходной документ «Перечень разделов проекта, отдаваемых на субподряд»

№ п/п	Шифр проекта	Наименование раздела	Длительность	Стоимость
1	2	3	4	5
2	АНО/215321	1.2	3	16 200

Таблица 3.58 Выходной документ «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектирования, руб.
1	2	3	4	5	6	7	8
1	АНО/215321	1.1	101	09.01.2023	10.01.2023	2	11 160
2	АНО/215321	1.2		11.01.2023	13.01.2023	3	16 200

Таблица 3.59. Выходной документ «Перечень загрузки исполнителей текущими проектами по неделям»

№ п/п	Исполнитель	Номер недели	Трудовой ресурс, чел.ч.
1	2	3	4
1	Дрягин Г.О.	1	24
2	Дрягин Г.О.	2	0
6	Васильев Е.А.	1	40
7	Васильев Е.А.	2	8

Макет выходного документа, включая структуру информационной части:

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

Макет выходного документа, включая структуру информационной части:

Рисунок 3.4 – Перечень разделов проекта, выполняемых собственными силами организации по проекту

3.3.4 Формирование списка подрядчиков для заключения договоров на разработку разделов ПСД

Место решения задачи: бюро ГИПов ООО «Параметрика»

Цель: найти наиболее выгодные предложения от сторонних проектных организаций на разработку разделов ПСД.

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

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

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

Таблица 3.60. Макет входного документа «список коммерческих предложений по ПСД»

№ п/п	Разработчик	Раздел	Длительность проектирования, дн.	Стоимость проектирования, руб.
1	2	3	4	5

Таблица 3.61. Макет входного документа «Перечень разделов проекта, отдаваемых на субподряд»

№ п/п	Шифр проекта	Наименование раздела	Длительность	Стоимость
1	2	3	4	5

Таблица 3.62. Макет входного документа «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектиро-вания, руб.
1	2	3	4	5	6	7	8

Выходной документ: в результате решения данной задачи формируется документ «список подрядчиков для заключения договоров на разработку разделов ПСД»

Таблица 3.63. Макет выходного документа «Cписок подрядчиков для заключения договоров на разработку разделов ПСД»

№ п/п	Разработчик	Раздел	Дата заключения	Стоимость
1	2	3	4	5

Форма представления выходного документа: алфавитно-цифровая.

Потребители результатной информации и способы ее отправки: результат решения используется планово-договорным отделом для заключения договора подряда с другими организациями и заместителем директора по проектированию. Результат решения передаётся через ЛВС компании.

Список таблиц базы данных, в которых хранится информация из входных документов:

Соответствие граф входных документов полям таблиц базы данных:

Таблица 3.64. Входной документ «Список коммерческих предложений по ПСД»

№ п/п	Разработчик	Раздел	Длительность проектирования, дн.	Стоимость проектирования, руб.
1	2	3	4	5
-	commercial_offers. company	project_works. work_code	commercial_offers. time_of_work	commercial_offers. cost_of_work

Таблица 3.65. Входной документ «Перечень разделов проекта отдаваемых на субподряд»

№ п/п	Шифр проекта	Наименование раздела	Длительность	Стоимость
1	2	3	4	5
2	projects. project_name	project_works. work_code	schedule_of_projects. work_duration 3	schedule_of_projects. work_cost

Таблица 3.66. Макет входного документа «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектирования, руб.
1	2	3	4	5	6	7	8
-	projects. project_name	projects_works. work_code	employees. surname	schedule_of_projects. start_date	schedule_of_projects. expiration_date	schedule_of_projects. work_duration	schedule_of_projects.work_cost

Описание машинного алгоритма для решения задачи:

• При помощи запроса к ранее созданному представлению таблицы БД list_of_works, определяются значения следующих полей: «project_ID» (ключ шифра проекта) и «project_work_ID» (ключ наименования раздела). Заносим данные значения во временные переменные p (ключ шифра проекта) и w [n] (ключ наименования раздела), где n = количеству разделов, отдаваемых на субподряд для данного проекта p. Значения «start_date» записываем в переменную s_d [n] (дата начала раздела по плану); значения «work_duration» записываем в переменную w_d [n] (нормативная продолжительность разработки раздела); значения «work_cost» записываем в переменную w_c [n] (нормативная стоимость разработки раздела). Данные значения определены для каждого w [n], где n = колличеству разделов, отдаваемых на субподряд из проекта p.
• При помощи запроса select к таблице БД commercial_offers, находим записи, которые удовлетворяют нашим условиям: значение поля «project_work_ID» = w [n]; «time_of_work» <= w_d [n]. Из полученных предложений выбираем только то, которое выгодны нам с финансовой точки зрения: т.е. записи значение поля «cost_of_work», которых является наименьшим и соблюдается условие «cost_of_work» <= w_c [n]. В случае если мы не нашли таких строчек, то просто выбираем строку с наименьшим значением «cost_of_work». Из полученной строки записываем значение полей «company» в переменную company [n]; число из поля «cost_of_work» заносим в с_w [n]. Данный алгоритм повторяется для всех w [n].
• Формируем итоговую uтаблицу БД subcontracting_list: значение поля «list_ID» = sequence.nextval(); поле «project_work_ID» = w [n]; поле «company» = company [n]; поле «contract_cost» = с_w [n]; поле «contract_start_date» = s_d [n]. Строки заносятся для каждого значения w [n].
  

Контрольный пример для машинного алгоритма:

Таблица 3.67. «Список коммерческих предложений по ПСД»

№ п/п	Разработчик	Раздел	Длительность проектирования, дней	Стоимость проектирования, руб
1	2	3	4	5
1	ФинПромСтрой	1.1	2	10 000
2	Астерос	1.1	1	15 000
3	МосЖилСтрой	1.2	2	13 000
4	Фаргус	1.2	1	16 000

Таблица 3.68. «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Исполнитель	Дата начала	Дата окончания	Длительность проектирования, дн.	Стоимость проектирования, руб.
1	2	3	4	5	6	7	8
1	АНО/215321	1.1	101	09.01.2023	10.01.2023	2	11 160
2	АНО/215321	1.2		11.01.2023	13.01.2023	3	16 200

Таблица 3.69. «Опорный план-график выполнения проектных работ по разделам»

№ п/п	Шифр проекта	Наименование раздела	Принят в работу
1	2	3	4
1	АНО/215321	1.1	Да
2	АНО/215321	1.2	Нет

Таблица 3.70. «Список подрядчиков для заключения договоров на разработку разделов ПСД»

№ п/п	Разработчик	Раздел	Дата заключения	Стоимость
1	2	3	4	5
1	МосЖилСтрой	1.2	11.01.2023	13 000

Макет выходного документа, включая структуру информационной части: Рисунок 3.5 – Перечень разделов проекта, отдаваемых на субподряд, по проекту

3.4 Схема взаимосвязи комплекса задач подсистемы

Схема взаимосвязи задач, решаемых в отделе бюро ГИПов, отображает суть технологии. На схеме взаимосвязи задач можно видеть, как входные документы, справочники и классификатор заносятся в БД, используются данные при решении задач, а также возможность вывода результатов в виде выходного документа: вывод на экран или же в виде бумажного документа.

На схеме можно видеть горизонтальные строки. Первая строка – массив информации, то есть справочники (как локальные, так и общероссийские/общегосударственные). Все остальные строки – отделы компании ООО “Параметрика”. Схема взаимосвязи задач представлена в приложении Е.

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

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

4 Информационное обеспечение

4.1 Описание предметной области

Предметной областью является комплекс задач подсистемы управления процессом проектирования, а именно следующие 4 задачи:

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

SQL является декларативным языком структурированных запросов, предоставляющим набор команд и операторов, которые позволяют создавать, изменять и управлять базами данных. На ряду с этим, он также позволяет определить структуру таблиц, добавлять, изменять и удалять данные, а также выполнять сложные запросы для извлечения информации из базы данных [12].

4.2 Концептуальная модель предметной области

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

При разработке концептуальной модели предметной области используются следующие элементы:

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

По результатам анализа предметной области были выявлены следующие сущности:

• proj_complexity – справочник «Классификация проектов»;
• Employees – справочник «Сотрудники»
• Projects_devide – календарная разбивка проектов из программы работ по неделям года
• Employees_load – перечень загрузки исполнителей текущими проектами по неделям;
• projects_appointment – План о назначение проектов ГИПам;
• current_projects_plan - Ведомость о выполнение текущих проектов;
• Projects – справочник «Разрабатываемые проекты»
• List_of_works – список подрядчиков для заключения договоров на разработку разделов ПСД;
• Projects_structures – cправочник «Состав проектов»
• Project_works – вид проектной работы
• Subcontracting_list – список подрядчиков для заключения договоров на разработку разделов ПСД
• MRR_document – cправочник «МРР-4.1.02-21 – Объекты капитального строительства»;
• Tech_sequence – технологическая последовательность выполнения проектных работ;
• Contracts – реестр договоров
• Schedule_of_projects – опорный план-график выполнения проектных работ по разделам
• Commercial_offers - список коммерческих предложений по ПСД
  • Избыточность данных: Одной из целей нормализации является устранение повторяющихся данных и избыточных атрибутов в отношениях. Это помогает снизить объем хранимых данных, повысить эффективность использования хранилища и предотвратить противоречия и несогласованность информации.
  • Оптимизация структуры данных: Нормализация помогает организовать данные в логически связанные отношения, что облегчает понимание и манипуляцию с данными. Хорошо структурированная база данных обеспечивает удобство разработки, поддержки и модификации системы.
  • Предотвращение аномалий данных: Нормализация способствует устранению аномалий данных, таких как проблемы при вставке, обновлении и удалении данных. Это помогает поддерживать целостность данных и гарантирует последовательность и непротиворечивость изменений.
  • Повышение производительности: хорошо нормализованная база данных обеспечивает более высокую производительность при выполнении запросов и операций. Это достигается за счет сокращения объема данных, обрабатываемых системой, и более эффективного выполнения запросов.

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

4.3 Нормализация отношений и логическая модель предметной области

Нормализация отношений в базе данных (БД) — это процесс организации данных с целью устранения избыточности и обеспечения эффективного хранения, обновления и извлечения информации. Этот процесс осуществляется в соответствии с нормальными формами, которые определяют требования к структуре данных [14].

Цели, которые преследуются при построении наиболее эффективной структуры данных:

Существуют 7 нормальных форм. Каждая нормальная форма (за исключением первой) подразумевает, что к данным уже была применена предыдущая нормальная форма. Например, прежде чем применить третью нормальную форму к данным должна быть применена вторая нормальная форма. И строго говоря, база данных считается нормализованной, если к ней применяется третья нормальная форма и выше.

Первая нормальная форма (1NF) предполагает, что сохраняемые данные на пересечении строк и столбцов должны представлять скалярное значение, а таблицы не должны содержать повторяющихся строк.

Вторая нормальная форма (2NF) предполагает, что каждый столбец, не являющийся ключом, должен зависеть от первичного ключа.

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

Нормальная форма Бойса-Кодда (BCNF) является немного более строгой версией третьей нормальной формы.

Четвертая нормальная форма (4NF) применяется для устранения многозначных зависимостей (multivalued dependencies) - таких зависимостей, где столбец с первичным ключом имеет связь один-ко-многим со столбцом, который не является ключом. Эта нормальная форма устраняет некорректные отношения многие-ко-многим.

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

Шестая нормальная форма (domain key normal form / 6NF). Каждое ограничение в связях между таблицами должно зависеть только от ограничений ключа и ограничений домена, где домен представляет набор допустимых значений для столбца. Эта форма предотвращает добавление недопустимых данных путем установки ограничения на уровне отношений между таблицами, но не на уровне таблиц или столбцов. Данная форма, как правило, не применима на уровне СУБД, в том числе и в SQL Server.

База данных считается нормализованной, если она находится как минимум в третьей нормальной форме (3NF).

Результатом логического проектирования базы данных является разработка логической модели. Логическая модель БД представляется в виде диаграммы, такой как диаграмма сущностей-связей (ER-диаграмма), которая наглядно отображает сущности, их атрибуты, отношения и ключи. В результате логического проектирования была создана ER-диаграмма, которая изображена в приложение З.

4.4 Обоснование выбора среды реализации

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

В качестве СУБД была выбрана MySQL и среда разработки - MySQL Workbench.

Преимущества MySQL [15]:

• Кроссплатформенность: MySQL предоставляет кроссплатформенную базу данных: она работает на Linux, FreeBSD и конечно на Windows. Этот критерий нужно учитывать при выборе СУБД для проектов, нацеленных на несколько платформ, в частности веб-приложений;
• Высокая доступность: MySQL является бесплатным решением, которое идеально подходит для разработки средних проектов;
• Открытый исходный код: всегда можно добавить новый необходимый функционал в код, тем самым подстроив БД под себя; аудит безопасности сообществом (нахождение бэкдоров и багов).
• Безопасность: В MySQL есть встроенные инструменты безопасности, которые поддерживают управление пользователями и их привилегиями. При недостатке стандартных инструментов пользователь всегда может установить дополнительные плагины.
• Высокая производительность.

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

Преимуществами MySQL Workbench являются:

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

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

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

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

Кроме того, MySQL Workbench обеспечивает инструменты для импорта и экспорта данных в различных форматах, таких как CSV и SQL-скрипты. Это позволяет разработчикам легко обмениваться данными с другими разработчиками или перемещаться между разными базами данных.

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

Совокупность всех этих функций делает MySQL Workbench незаменимым инструментом для разработчиков и администраторов баз данных MySQL, обеспечивая им удобство, эффективность и надежность при работе с данными.

4.5 Преобразование логической модели в структуру таблиц БД

Физическое проектирование преобразует логическую схему базы данных в конкретный набор команд DDL (Data Definition Language) для создания схемы базы данных в определенной системе управления базами данных (СУБД). Само физическое проектирование может выполняться вручную, но в настоящее время предпочтительно использовать автоматические инструменты для физического проектирования, которые генерируют DDL-скрипт для определенной версии СУБД на основе логической схемы базы данных. Результатом физического проектирования является конкретный DDL-скрипт на языке SQL, содержащий необходимые команды для создания базы данных в MySQL.

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;

SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;

SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

-- -----------------------------------------------------

-- Schema mydb

-- -----------------------------------------------------

CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8;

USE `mydb` ;

--------------------------------------------------

-- Table `mydb`.`MRR_document`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`MRR_document` (

`mrr_ID` INT NOT NULL,

`project_work_ID` INT NOT NULL,

`mrr_shortening` VARCHAR(32) NULL,

`value` INT NULL DEFAULT CURRENT_TIMESTAMP,

PRIMARY KEY (`mrr_ID`),

INDEX `project_part_idx` (`project_work_ID` ASC) VISIBLE,

CONSTRAINT `work_code`

FOREIGN KEY (`project_work_ID`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`current_projects_plan`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`current_projects_plan` (

`ID` INT NOT NULL,

`project_ID` INT NOT NULL,

`employee_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`start_date` DATE NULL,

`complete_date` DATE NULL,

`executed_part` INT NULL,

PRIMARY KEY (`ID`),

INDEX `employee_surname_idx` (`employee_ID` ASC) VISIBLE,

INDEX `project_name_idx` (`project_ID` ASC) VISIBLE,

CONSTRAINT `employee_surname`

FOREIGN KEY (`employee_ID`)

REFERENCES `mydb`.`employees` (`employee_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `project_name`

FOREIGN KEY (`project_ID`)

REFERENCES `mydb`.`projects` (`project_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`employees`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`employees` (

`employee_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`surname` VARCHAR(32) NULL,

`name` VARCHAR(32) NULL,

`middle_name` VARCHAR(32) NULL,

`division` VARCHAR(64) NULL,

`project_work_ID` INT NULL,

`salary` INT NULL,

`daily_load` INT NULL,

PRIMARY KEY (`employee_ID`),

INDEX `work_code_idx` (`project_work_ID` ASC) VISIBLE,

CONSTRAINT `work_code`

FOREIGN KEY (`project_work_ID`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`employees_load`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`employees_load` (

`load_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`employee_ID` INT NULL,

`week_ID` INT NULL,

`workforce` INT NULL,

PRIMARY KEY (`load_ID`),

INDEX `employee_ID_idx` (`employee_ID` ASC) VISIBLE,

INDEX `week_ID_idx` (`week_ID` ASC) VISIBLE,

CONSTRAINT `employee_ID`

FOREIGN KEY (`employee_ID`)

REFERENCES `mydb`.`employees` (`employee_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `week_ID`

FOREIGN KEY (`week_ID`)

REFERENCES `mydb`.`projects_devide` (`week_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`list_of_works`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`list_of_works` (

`List_ID` INT NULL DEFAULT CURRENT_TIMESTAMP,

`project_ID` INT NULL,

`project_work_ID` INT NULL,

`recruited` VARCHAR(16) NULL,

INDEX `project_name_idx` (`project_ID` ASC) VISIBLE,

INDEX `work_code_idx` (`project_work_ID` ASC) VISIBLE,

CONSTRAINT `project_name`

FOREIGN KEY (`project_ID`)

REFERENCES `mydb`.`projects` (`project_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `work_code`

FOREIGN KEY (`project_work_ID`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`proj_complexity`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`proj_complexity` (

`complexity_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`working_time_ratio` INT NULL,

`premium_rate` INT NULL,

PRIMARY KEY (`complexity_ID`),

UNIQUE INDEX `complexity_ID_UNIQUE` (`complexity_ID` ASC) VISIBLE);

-- -----------------------------------------------------

-- Table `mydb`.`project_works`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`project_works` (

`project_work_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`work_code` VARCHAR(16) NOT NULL,

`work_name` TEXT(128) NOT NULL,

PRIMARY KEY (`project_work_ID`));

-- -----------------------------------------------------

-- Table `mydb`.`projects`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`projects` (

`project_ID` INT NOT NULL,

`project_name` VARCHAR(32) NULL,

`contract_ID` INT NOT NULL,

`object_type` VARCHAR(32) NULL,

`project_complexity` INT NULL,

`design_area` INT NULL,

`planned_cost` INT NULL,

`actual_cost` INT NULL,

PRIMARY KEY (`project_ID`),

UNIQUE INDEX `project_name_UNIQUE` (`project_name` ASC) VISIBLE,

INDEX `contract_name_idx` (`contract_ID` ASC) VISIBLE,

INDEX `project_complexity_idx` (`project_complexity` ASC) VISIBLE,

CONSTRAINT `contract_number`

FOREIGN KEY (`contract_ID`)

REFERENCES `mydb`.`сontracts` (`contract_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `project_complexity`

FOREIGN KEY (`project_complexity`)

REFERENCES `mydb`.`proj_complexity` (`complexity_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`projects_appointment`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`projects_appointment` (

`list_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`employee_ID` INT NULL,

`project_ID` INT NULL,

PRIMARY KEY (`list_ID`),

INDEX `employee_idx` (`employee_ID` ASC) VISIBLE,

INDEX `project_idx` (`project_ID` ASC) VISIBLE,

CONSTRAINT `employee`

FOREIGN KEY (`employee_ID`)

REFERENCES `mydb`.`employees` (`employee_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `project`

FOREIGN KEY (`project_ID`)

REFERENCES `mydb`.`projects` (`project_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`projects_devide`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`projects_devide` (

`week_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`period_start` DATE NULL,

`period_end` DATE NULL,

`project_ID` INT NULL,

INDEX `project_ID_idx` (`project_ID` ASC) VISIBLE,

PRIMARY KEY (`week_ID`),

CONSTRAINT `project_ID`

FOREIGN KEY (`project_ID`)

REFERENCES `mydb`.`projects` (`project_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`projects_structures`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`projects_structures` (

`structure_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`project_ID` INT NOT NULL,

`project_work_ID` INT NOT NULL,

PRIMARY KEY (`structure_ID`),

INDEX `project_name_idx` (`project_ID` ASC) VISIBLE,

INDEX `project_part_idx` (`project_work_ID` ASC) VISIBLE,

CONSTRAINT `project_name`

FOREIGN KEY (`project_ID`)

REFERENCES `mydb`.`projects` (`project_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `work_code`

FOREIGN KEY (`project_work_ID`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`schedule_of_projects`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`schedule_of_projects` (

`shedule_ID` INT NOT NULL,

`project_ID` INT NULL,

`project_work_ID` INT NULL,

`employee_ID` INT NULL,

`start_date` DATE NULL,

`expiration_date` DATE NULL,

`work_duration` INT NULL,

`work_cost` INT NULL,

PRIMARY KEY (`shedule_ID`),

INDEX `project_name_idx` (`project_ID` ASC) VISIBLE,

INDEX `work_code_idx` (`project_work_ID` ASC) VISIBLE,

INDEX `worker_ID_idx` (`employee_ID` ASC) VISIBLE,

CONSTRAINT `project_name`

FOREIGN KEY (`project_ID`)

REFERENCES `mydb`.`projects` (`project_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `work_code`

FOREIGN KEY (`project_work_ID`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `worker_ID`

FOREIGN KEY (`employee_ID`)

REFERENCES `mydb`.`employees` (`employee_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`subcontracting_list`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`subcontracting_list` (

`list_ID` INT NOT NULL,

`company` VARCHAR(64) NULL,

`project_work_ID` INT NULL,

`contract_start_date` DATE NULL DEFAULT CURRENT_TIMESTAMP,

`contract_cost` INT NULL,

PRIMARY KEY (`list_ID`),

INDEX `work_code_idx` (`project_work_ID` ASC) VISIBLE,

CONSTRAINT `work_code`

FOREIGN KEY (`project_work_ID`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`tech_sequence`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`tech_sequence` (

`tech_sequence_ID` INT NOT NULL,

`project_work_ID` INT NOT NULL,

`next_part` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`previous_part` INT NOT NULL,

PRIMARY KEY (`tech_sequence_ID`),

INDEX `project_part_idx` (`project_work_ID` ASC) VISIBLE,

INDEX `next_part_idx` (`next_part` ASC) VISIBLE,

INDEX `previous_part_idx` (`previous_part` ASC) VISIBLE,

CONSTRAINT `project_part`

FOREIGN KEY (`project_work_ID`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `next_part`

FOREIGN KEY (`next_part`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `previous_part`

FOREIGN KEY (`previous_part`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`сommercial_offers`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`сommercial_offers` (

`offer_ID` INT NOT NULL DEFAULT CURRENT_TIMESTAMP,

`company` VARCHAR(64) NULL,

`project_work_ID` INT NULL,

`time_of_work` INT NULL,

`cost_of_work` INT NULL,

PRIMARY KEY (`offer_ID`),

INDEX `work_code_idx` (`project_work_ID` ASC) VISIBLE,

CONSTRAINT `work_code`

FOREIGN KEY (`project_work_ID`)

REFERENCES `mydb`.`project_works` (`project_work_ID`)

ON DELETE NO ACTION

ON UPDATE NO ACTION);

-- -----------------------------------------------------

-- Table `mydb`.`сontracts`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`сontracts` (

`contract_ID` INT NOT NULL,

`contract_number` VARCHAR(32) NOT NULL,

`type_of_contract` VARCHAR(32) NULL,

`contractor` VARCHAR(64) NULL,

`contract_subject` INT NULL DEFAULT CURRENT_TIMESTAMP,

`start_date` DATE NULL,

`duration` INT NULL,

`total_cost` INT NULL,

`contract_status` VARCHAR(16) NULL,

UNIQUE INDEX `contract_id_UNIQUE` (`contract_number` ASC) INVISIBLE,

PRIMARY KEY (`contract_ID`));

SET SQL_MODE=@OLD_SQL_MODE;

SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;

SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

5 Программное обеспечение

5.1 Требования к системному программному обеспечению

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

Далее будут приведены общие требования к системному ПО для большинства сайтов:

• Веб-сервер: основой для развёртывания сайта является веб-сервер, который будет обрабатывать запросы от пользователей и собирать html странницы на основе запросов. Наиболее часто используемыми веб-серверами являются Apache, Nginx и Microsoft IIS. Важно отметить, что для оптимального выбора веб-сервера стоит опираться на следующие критерии: потребление оперативной памяти сервером при работе с динамическим и статическим контентом; скорость загрузки страниц; список поддерживаемых ОС; инструменты для обеспечения безопасности; открытость исходного кода (для обеспечения прозрачности работы, а также для того, чтобы удостоверится, что в ПО нет бэкдоров либо же других уязвимостей). В качестве веб-сервера был выбран Nginx, так как он превосходит Apache в 2-3 раза по скорости загрузки статического контента, потребляет намного меньше оперативной памяти, поддерживает больше клиентских подключений, а также имеет более компактный исходный код. В теории можно использовать Nginx вместе с Apache для получения преимуществ обоих серверов [16].
• Операционная система: развернуть сайт можно на различных операционных системах, выбор которых в первую очередь зависит от имеющихся мощностей серверного оборудования, удобства использования самой ОС и поддержки необходимого ПО. Чаще всего для развёртывания сайта используются ОС семейства Linux такие как: Ubuntu, CentOS, Debian, Fedora. Это можно обосновать тем, что чаще всего веб-сайт разворачивается на арендованном хостинге, ресурсы которого ограничены (следовательно, выгоднее использовать Linux подобные ОС, для оптимизации использования системных ресурсов и быстроты отклика). В качестве операционной системы была выбрана Ubuntu, так как имеется поддержка Nginx, а также она является более интуитивно понятной в сравнение с остальными системами Linux [17].
• База данных: так как динамические сайты хранят информацию о пользователях, контенте и другие важные данные (к примеру пароли входа в учётные записи пользователей в хешированном виде), требуется установленная и настроенная реляционная СУБД (система управления базой данных), которая будет предоставлять возможность взаимодействовать с этими данными при помощи SQL запросов. Наиболее популярными СУБД являются: MySQL, PostgreSQL и MongoDB. Для реализации сайта, описанного в ВКР, потребуется установленная MySQL [18].
• Язык программирования (ЯП) и фреймворк: для разработки бэкенда (внутренняя часть продукта, находящаяся на сервере и скрытая от пользователей сайта) необходимо использовать один из множества языков программирования: Python, PHP, Ruby, JavaScript, Go, С#; а также стоит выбрать фреймворк: Laravel, Django или Ruby on Rails. Для реализации ПО, представленного в ВКР, был выбран язык Python как наиболее лёгкий в понимании и гибкий ЯП [19].
• Безопасность: веб-сайты должны быть защищены от возможных угроз, таких как взломы, атаки DDoS или внедрение вредоносного кода. Для обеспечения защиты от взлома сервера по SSH, а также для защиты самого сайта от DDoS принято использовать такую программу, как fail2ban (при помощи анализа логов сервера помогает отслеживать подозрительные действия и вносить сетевые правила для блокировки IP адресов: данные действия помогают значительно снизить вредную нагрузку на сервер). Также возможны атаки типа MITM (man in the middle), для предотвращения которых нужно использовать SSL сертификат для шифрования всего важного трафика (к важному трафику относятся: логин и пароль пользователя на сайте и многие другие данные). SSL сертификаты выпускаются сертифицированными центрами. При помощи SSL сертификата браузер клиента понимает, была ли произведена подмена сервера или он общается с подлинным сервером. Также для выпуска SSL сертификата может использоваться программа Let’s Encrypt (центр сертификации, предоставляющий бесплатные криптографические сертификаты).

• Резервное копирование и восстановление: для обеспечения сохранности данных сайта в случае сбоев или аварийного отключения требуется системное ПО для резервного копирования и восстановления данных. К примеру, под Ubuntu можно использовать такие программы как DejaDup, Cronopete, Back in Time; Timeshift. Одним из наиболее надежных вариантов является создание отдельного бэкап сервера, который будет автоматически делать резервные копии сайта и всех БД.
• Использование CDN – хостинга. Если необходимо пользоваться сайтом из разных точек мира, то лучшим решением является CDN сервера, которые ускорят загрузку страниц у конечного пользователя, а также значительно снизит загрузку на корневой сервер [20].
• Модульность: хорошая архитектура должна быть модульной, состоящей из логически связанных компонентов или модулей. Каждый модуль должен выполнять четко определенную функцию и быть независимым от остальных. Это облегчает понимание, изменение и тестирование отдельных частей приложения.
• Расширяемость: архитектура должна обладать расширяемостью, то есть способностью поддерживать изменения и добавление новых функций без необходимости полной переделки системы.
• Понятность: хорошая архитектура должна быть легко понятной и читаемой. Четкая структура и организация кода помогают разработчикам быстро овладеть системой и обнаруживать ошибки с легкостью. Так для разработки Python-кода существуют определённые правила, а именно: функции и переменные стоит называть в соответствие с их предназначением; если используются внешние библиотеки, то они должны быть прописаны в коде в алфавитном порядке. Все эти правила обеспечивают понятность и простоту кода, что в свою очередь позволяет программистам нае работающим ранее с приложением с лёгкостью в нём разобраться.
• Производительность: архитектура должна обеспечивать высокую производительность и эффективное использование ресурсов. Это достигается правильным выбором алгоритмов, оптимизацией запросов к базе данных, распределением нагрузки и другими соответствующими мерами. К примеру, после выполнения SQL запросов к БД следует закрывать соединение с БД – для экономии ресурсов. Либо же правильное индексирование таблиц БД – для быстрой обработки SQL команд (таким образом сокращается время ответа на запрос).
• Масштабируемость: архитектура должна быть масштабируемой и способной поддерживать рост объема данных и пользовательской нагрузки.
• Безопасность: архитектура должна учитывать безопасность веб сайта, а также отдельных его компонентов. Комплексная безопасность включает защиту от внешних угроз, аутентификацию и авторизацию пользователей, а также обработку конфиденциальных данных с учетом соответствующих стандартов и нормативов. Комплексная безопасность включает в себя использование TLS шифрования трафика, а также грамотную настройку файрволла сервера.
• Тестируемость: код должен быть организован таким образом, чтобы тестирование отдельных компонентов или модулей было простым и автоматизированным. Это способствует обеспечению надежности и устойчивости приложения.
  

5.2 Общие требования для разработки прикладного ПО

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

5.3 Описание интерфейса разрабатываемого программного обеспечения

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

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

Ниже на рисунках 5.1.-5.5. представлен основной интерфейс разрабатываемого программного обеспечения. При разработке интерфейса веб-сайта необходимо предусмотреть то, что сайт может быть открыт не только на стационарном ПК, а к примеру на мобильных устройствах. Важно понимать, что элементы сайта не вступят в коллизию между собой и интерфейс будет непосредственно удобным при любом разрешении экрана (это достигается путём написания конструкций типа @media screen and (max-width: 1670px) в CSS файле).

Рисунок 5.1 – Главная страница для неавторизованного пользователя

Рисунок 5.2 – Страница авторизации пользователя

Рисунок 5.3 – Страница после успешной авторизации

Рисунок 5.4 – Выпадающее меню для выбора решаемой задачи

Рисунок 5.5 – Выпадающее меню для выбора справочника

5.4 Программная реализация выбранного комплекса задач

5.4.1 Подключение к базам данных

Для работы непосредственно с базой данных MySQL и выполнения различных SQL запросов необходимо установить дополнительные библиотеки для Python, содержащие драйвер по работе с СУБД (такие драйверы обычно поставляются в виде отдельных модулей, содержащих функции и методы по работе с конкретной базой данных).

При помощи менеджера пакетов pip устанавливаем нужные нам библиотеки: pip install mysql-connector-python. Также необходимо упомянуть, что лучше всего создать отдельное виртуальное окружение для текущего проекта и устанавливать уже дополнительные сторонние библиотеки туда – данный подход позволит строго разграничивать среды разработки кода, позволяя избежать конфликты между отдельными модулями (можно использовать различные версии модулей для каждой из программ).

Чтобы установить соединение, используем метод connect() из модуля mysql.connector. Эта функция принимает параметры localhost (IP адрес и порт, на котором развёрнута БД), yourusername (имя пользователя) и yourpassword (пароль выбранного пользователя), а возвращает объект MySQLConnection. Стоит отметить, что при помощи средств администрирования MySQL заранее создаются пользователи БД и им назначаются права на внесение изменений в те или иные уже существующие таблицы. Код Python для подключения к уже развёрнутой БД MySQL:

import mysql.connector

maindb = mysql.connector.connect (host="localhost", user="yourusername", password="yourpassword")

Подключение к БД выполнено успешно, но для выполнения SQL команд необходимо создать курсор:

firstcursor = maindb.cursor()

Теперь при помощи курсора можно взаимодействовать с уже существующими таблицами, либо же создать новые (если это разрешено пользователю):

firstcursor.execute (CREATE TABLE Staff (

id INT,

name VARCHAR(255) NOT NULL,

position VARCHAR(30),

birthday Date

);)

Стоит помнить, что для экономии ресурсов необходимо закрывать соединение с сервером MySQL после выполнения всех необходимых операций с данными:

maindb.close()

5.4.2 Работа со справочниками

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

Важно отметить, что не все пользователи могут вносить изменения в справочники (это определяется непосредственно группой, в которой состоит пользователь; каждой группе присвоены права на редактирование). В случае если группа пользователя подразумевает только просмотр справочников, то кнопки “Добавить”, “Изменить”, “Удалить” будут неактивными. Ниже на рисунках 5.6. – 5.7. рассмотрен процесс взаимодействия со справочником, от лица пользователя с наивысшими права доступа.

Рисунок 5.6 – Выпадающее меню для выбора справочника

Рисунок 5.7 – Странница взаимодействия со справочником.

5.4.3 Работа с входными документами

Для начала работы с входными документами необходимо выбрать задачу путём наведения на блок “Задачи” и кликнув на интересующую задачу из выпадающего меню. Таким образом, откроется страница определённой задачи, где можно будет просмотреть входные и выходные документы (нужно навестить на элемент “Входные документы” из левого меню и кликнуть по нему; ниже откроется список документов, при нажатии на которые можно их просмотреть). В случае если входной документ ещё не создавался – вместо него будет пустая форма документа. Над открывающимся документом доступны основные кнопки для редактирования, добавления и удаления записей непосредственно. Стоит помнить, что все действия на сайте производятся пользователем с наивысшими правами (у других пользователей может не быть доступа к некоторым функциям сайта). Ниже на рисунках 5.8. – 5.11. показан процесс взаимодействия с входными документами, а также редактирование записей.

Рисунок 5.8 – Выбор необходимой задачи.

Рисунок 5.9 – Отображение входного документа.

Рисунок 5.10 – Функция удаления выделенной записи.

Рисунок 5.11 – Входной документ после удаления 2-ой записи.

5.4.4 Работа с выходными документами

Для начала работы с выходными документами необходимо выбрать задачу путём наведения на блок “Задачи” и кликнув на интересующую задачу из выпадающего меню. Таким образом, откроется страница определённой задачи, где можно будет просмотреть входные и выходные документы (нужно навестить на элемент “Выходные документы” из левого меню и кликнуть по нему; ниже откроется список документов, при нажатии на которые можно их просмотреть). В случае если выходной документ ещё не создавался – вместо него будет пустая форма документа. Над открывающимся документом доступны основные кнопки для редактирования, добавления и удаления записей непосредственно. По началу эти кнопки недоступны, так как надо сформировать сам документ перед его редактированием (это делается путём нажатия на кнопку “Сформировать”). Перед формированием выходного документа надо убедиться, в том, что все входные документы уже заполнены – в противном случае сайт выдаст ошибку.

Стоит помнить, что все действия на сайте производятся пользователем с наивысшими правами (у других пользователей может не быть доступа к некоторым функциям сайта). Ниже на рисунках 5.12. – 5.17. показан процесс создания выходного документа, а также редактирование записей.

Рисунок 5.12 – Выбор задачи при помощи навигационного меню.

Рисунок 5.13 – Страница взаимодействия с выходным документом.

Рисунок 5.14 – Функция добавления новой записи в выходной документ.

Рисунок 5.15 – Выходной документ после добавления новой записи.

Рисунок 5.16 – Функция редактирования записи выходного документа.

Рисунок 5.17 – Выходной документ после редактирования 2 записи.

5.5 Средства администрирования

5.5.1 Управление списком пользователей

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

• Регистрация: Предоставление возможности регистрации новым пользователям для создания учетных записей на сайте.
• Аутентификация и авторизация: Обеспечение безопасного входа в систему для пользователей с помощью аутентификации и проверка их прав доступа.
• Управление правами доступа: Назначение определенных прав доступа пользователям в зависимости от их роли или уровня доступа.
• Управление профилями: Предоставление пользователям возможности редактировать свои профили и обновлять информацию.
• Блокировка или удаление пользователей: Возможность администраторам блокировать или удалять пользователей в случае нарушения правил сайта или неактивности.
• Журналирование и мониторинг: Ведение записей о действиях пользователей и мониторинг их активности для обеспечения безопасности и обнаружения проблем.

В качестве инструмента для управления пользователями в ВКР будет использован фреймворк Django. Он обеспечивают готовую функциональность для регистрации, аутентификации, авторизации и других операций с пользователями.

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

5.5.2 Распределение прав доступа

Управление правами доступа на сайте включает назначение определенных привилегий и ограничений пользователям в соответствии с их ролями и функциями. Вот основные аспекты распределения прав доступа:

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

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

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

5.5.3 Инструкция по развертыванию/установке предлагаемого решения

Далее приведены шаги, которые необходимо выполнить для развертывания веб-сайта с использованием операционной системы Ubuntu, веб-сервера Nginx, языка программирования Python, базы данных PostgreSQL и фреймворка Django:

• Шаг 1. Арендовать VPS-сервер с уже установленной и актуальной версией Ubuntu. Либо же скачать образ ОС с официального сайта и вручную установить на арендованный сервер.
• Шаг 2. Настройка встроенного файрволла: необходимо переместить SSH службу с 22 порта на любой другой для предотвращения попыток несанкционированного доступа к серверу; также разрешить весь входящий и исходящий трафик на порт 443 по протоколу TCP.
• Шаг 3. Обновить все пакеты Ubuntu при помощи команды: sudo apt update && sudo apt full-upgrade. Перезапустить сервер командой: shutdown -r now.
• Шаг 4. Установить ПО для защиты от DDoS атак – fail2ban. Устанавливаем при помощи команды: sudo apt install fail2ban и проверяем, что запустилась служба: sudo systemctl status fail2ban. По умолчанию данная программа позволяет блокировать IP, которые не смогли подключиться по порту SSH определённое количество раз за установленное время. Для защиты самого порта 443 необходимо будет производить тонкие настройки в конфигурационном файле данной программы.
• Шаг 5. Установка сервера Nginx: sudo apt install nginx – устанавливаем само ПО; sudo ufw allow 'Nginx HTTPS' – говорим серверу, что придётся работать по протоколу HTTPS через 443 порт; проверяем статус сервера - systemctl status nginx; в случае если сервер не активен, надо перезапустить службу командой: systemctl restart nginx.
• Шаг 6. Установка Python и Django: устанавливаем Python при помощи команды - sudo apt install python3.9; устанавливаем Django для Python: pip3 install virtualenv django.
• Шаг 7. Установка MySQL: sudo apt install mysql-server.
• Шаг 8. Создаём базу данных при помощи MySQL: чтобы получить доступ к оболочке MySQL, используем команду - mysql -u root -p; создаём базу данных при помощи запроса: CREATE DATABASE database_name;
• Шаг 9. Настройка конфигурационного файла Django. В данном конфигурационном файле необходимо указать такие поля как 'ENGINE', 'NAME' – название базы данных, 'USER' – ранее созданный пользователь БД, 'PASSWORD' – пароль пользователя, 'HOST' – IP сервера MySQL; 'PORT' – номер порта, на котором работает сервер MySQL.
• Шаг 10. Настройка конфигурационного файла Nginx, где указывается порт и протокол, по которому будет работать наш сервер. Также следует помнить, что для корректной работы веб-сервера ему нужны сертификаты шифрования: их можно выпустить бесплатно при помощи программы Let's Encrypt.
• Шаг 11. Запуск Django проекта.

ЗАКЛЮЧЕНИЕ

В данной выпускной квалификационной работе было разработано проектное решение по автоматизации комплекса задач подсистемы управления процессом проектирования ООО «Параметрика».

Проектное решение включает в себя общую характеристику организации, организационную и функциональную структуры. Также были выявлены цели организации, произведена декомпозиция АСУ на подсистемы, обоснован выбор подсистемы, разработана логико-информационная схема, схема взаимосвязи комплекса задач, функциональная матрица.

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

• Федеральный закон от 08.02.1998 N 14-ФЗ (ред. от 16.04.2022) "Об обществах с ограниченной ответственностью". КонсультантПлюс [Электронный ресурс]. URL: https://www.consultant.ru/document/cons_doc_LAW_17819/ (Дата обращения 14.03.2023)
• Индивидуальное проектирование домов и коттеджей. [Электронный ресурс]. URL: https://www.topdom.info/economics26 (Дата обращения 14.03.2023)
• Коноков Д.Г. Организационная структура предприятий / Рожков М.А., Смирнов А.О., Яниковская О.Н. - М.: ИСАРП, 1999. - 176 с.
• Метод дерева целей. [Электронный ресурс]. URL: https://studfile.net/preview/6808792/page:10/ (Дата обращения 17.03.2023)
• Гутгарц, Р. Д. Проектирование автоматизированных систем обработки информации и управления : учебное пособие для вузов / Р. Д. Гутгарц. — 2-е изд., перераб. и доп. — Москва : Издательство Юрайт, 2023. — 351 с. — (Высшее образование). — ISBN 978-5-534-15761-1. — Текст : электронный // Образовательная платформа Юрайт [сайт]. — URL: https://urait.ru/bcode/509638 (дата обращения: 17.03.2023).
• Хетагуров Я. А. Проектирование автоматизированных систем обработки информации и управления (АСОИУ) : учебник / Я. А. Хетагуров. — 2-е изд., электрон. —М. : Лаборатория знаний, 2020. — 243 с. — (Учебник для высшей школы). — Систем. требования: AdobeReader XI ; экран 10".— Загл. с титул. экрана. — Текст : электронный.
• Управление и автоматизированные системы управления строительством. Методические указания к выполнению курсового проекта (курсовой работы) для обучающихся по направлениям подготовки 09.03.01 и 09.03.02 Информационные системы и технологии в строительстве – [Электронный ресурс]. URL: http://lib-04.gic.mgsu.ru/lib/Metod2018/58.pdf (Дата обращения: 21.03.2023)
• ГОСТ 24.104-85 «Единая система стандартов автоматизированных систем управления. Автоматизированные системы управления. Общие требования». – М.: Стандартинформ, 2009. – 11 с.
• ГОСТ 34.003-90 Автоматизированные системы. Термины и определения. – М.: Стандартинформ, 2009. – 16 с.
• Логико-информационная модель. [Электронный ресурс]. URL: https://studfile.net/preview/1937805/page:13/ (Дата обращения 30.03.2023)
• Катаев А.В. Виртуальные бизнес-организации. – СПб.: Изд-во Политехнического университета, 2009. – 120 с
• Описание структурированного языка запросов (SQL). [Электронный ресурс]. URL:https://aws.amazon.com/ru/what-is/sql/ (Дата обращения 15.04.2023)
• Концептуальная модель предметной области. [Электронный ресурс]. URL: https://studref.com/316122/informatika/kontseptualnaya_model_predmetnoy_oblasti (Дата обращения 21.04.2023)
• Описание основных приемов нормализации базы данных. [Электронный ресурс]. URL: https://learn.microsoft.com/ru-ru/office/troubleshoot/access/database-normalization-description (Дата обращения 22.04.2023)
• MySQL: для чего нужна, как устроена, основные преимущества и недостатки [Электронный ресурс]. URL: https://timeweb.cloud/blog/mysql-preimushchestva-i-nedostatki (Дата обращения 23.04.2023)
• Nginx: документация [Электронный ресурс]. URL: https://nginx.org/ru/docs (Дата обращения 25.04.2023)
• Что такое операционная система [Электронный ресурс]. URL: https://help.reg.ru/support/servery-vps/oblachnyye-servery/ustanovka-programmnogo-obespecheniya/chto-takoye-operatsionnaya-sistema (Дата обращения 05.05.2023)
• Что такое база данных [Электронный ресурс]. URL: https://www.oracle.com/cis/database/what-is-database (Дата обращения 15.05.2023)
• Языки программирования для создания сайтов [Электронный ресурс]. URL: https://studiobit.ru/blog/sozdanie-web-saytov/yazyki-programmirovaniya-dlya-sozdaniya-saytov (Дата обращения 25.05.2023)
• Что такое CDN [Электронный ресурс]. URL: https://help.reg.ru/support/vydelennyye-servery-i-dc/administrirovaniye-vydelennykh-serverov/chto-takoye-cdn (Дата обращения 30.05.2023)

Приложение А

Справка о результатах проверки текстового документа на наличие заимствований

Приложение Б

Организационная структура предприятия

Приложение В

Функциональная структура организации

Приложение Г

Декомпозиция функциональной части АСУ предприятия на подсистемы и комплексы задач

Приложение Д. Часть 1

Логико-информационная схема решения задач подсистемы управления процессом проектирования. Часть 1

Приложение Д. Часть 2

Логико-информационная схема решения задач подсистемы управления процессом проектирования. Часть 2

Приложение Е

Схема взаимосвязи задач

Приложение Ж

Концептуальная модель предметной области

Приложение З

Логическая модель базы данных для предметной области