ДИПЛОМ М Артем Ш - НКФ

Министерство науки и высшего образования Российской Федерации
Федеральное государственное автономное

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

Высшая инженерная школа
ДОПУСТИТЬ К ЗАЩИТЕ ПЕРЕД ГЭК
Зав. кафедрой ____________ Ребрин О.

И.
( подпись) (Ф.И.О.)
«______»________________2019 г.
ПРОЕКТИРОВАНИЕ СИСТЕМЫ ОПТИМИЗАЦИИ ПОТРЕБЛЕНИЯ

ЭЛЕКТРОЭНЕРГИИ
Выпускная квалификационная работа
Направление подготовки 27.04.03 – «Системный анализ и управление»
Студент гр. НМТМ-272701 А.А. Шайдуров

Руководитель, к. т. н. В.В. Мизгулин
Нормоконтролер В. Р. Ялунина
Екатеринбург
2019
РЕФЕРАТ
Выпускная квалификационная работа содержит 97 с., 29 табл., 33 рис.,

21 источник, 3 прил.
СИСТЕМА, ЭЛЕКТРОПОТРЕБЛЕНИЕ, ЭКОНОМИЯ,
ПРОГНОЗИРОВАНИЕ, РАЗРАБОТКА.
Учитывая возможность предсказания пиковых часов для каждого дня
выбранного субъекта Российской Федерации и составления плана
маневрирования электроэнергии предприятия необходимо разработать и
создать систему оптимизации потребления электроэнергии для юридических
лиц мелких и средних предприятий.
Целью ВКР является разработка и создание эффективной системы
оптимизации потребления электроэнергии.
Объект исследования – системы прогнозирование нагрузки
электроэнергии.
Предмет исследования – система прогнозирования пиковых часов
нагрузки и оптимизации потребления электроэнергии для юридических лиц.
Была разработана система оптимизации потребления электроэнергии,
для юридических лиц владельцев предприятий, имеющих возможность
маневрировать энергопотреблением. Разработанная система за счет своей
эффективности и точности прогнозирования помогает снизить траты на
электропотребление юридическими лицами, владельцами предприятий,
имеющих возможность маневрирования электроэнергии в среднем на 20%.
Это достигается точностью прогнозирования пиковых часов в 80%
расчетного месяца в каждом из 75 субъектов РФ.
5
6
СОДЕРЖАНИЕ
ВВЕДЕНИЕ..............................................................................................................7
1 ПРОБЛЕМАТИКА...............................................................................................9
2 ПРОЕКТИРОВАНИЕ.........................................................................................11
2.1 Определение потребностей и требований.................................................11
3 ТЕХНИЧЕСКОЕ ЗАДАНИЕ.............................................................................31
3.1 Общие сведения............................................................................................31
3.1.1 Наименование.........................................................................................31
3.1.2 Заказчик системы...................................................................................31
3.1.3 Основания разработки...........................................................................31
3.1.4 Сроки работ............................................................................................31
3.1.5 Сведения об источниках финансирования работ................................31
3.1.6 Порядок предъявления результатов работ..........................................31
3.1.7 Нормативные документы и акты ФЗ....................................................32
3.2 Назначение и цель создания системы........................................................33
3.2.1 Назначение..............................................................................................33
3.2.2 Основные цели создания системы........................................................34
3.3 Требования к системе..................................................................................35
3.3.1 Общие требования к системе................................................................35
3.3.2 Функциональные системные требования............................................43
3.3.3 Требования к общим видам обеспечения............................................50
3.4 Состав работ по созданию системы...........................................................56
3.5. Требования к составу работ по вводу системы в эксплуатацию............59
3.6 Требования к ведению документации........................................................60
7
4 РАЗРАБОТКА.....................................................................................................62
4.1. Эскизное представление.............................................................................62
4.2 Разработка системы......................................................................................62
4.2.1 Модели web-приложения......................................................................65
4.2.2 Представления web-приложения..........................................................66
4.2.3 Контроллеры web-приложения.............................................................66
4.2.4 Модуль прогнозирования......................................................................67
4.2.5 Личный кабинет пользователя..............................................................68
4.2.6 Панель управления web-приложением................................................71
4.3 Решения по режимам функционирования и диагностированию системы

..............................................................................................................................74
4.4 Решения по пользовательскому интерфейсу и дизайну...........................75
4.5 Решения по техническому и информационному обеспечению...............77
4.6 Решения по персоналу.................................................................................79
4.7 Создание рабочей документации................................................................79
4.7.1 Рекомендации по освоению..................................................................82
4.7.2 Руководство пользователя.....................................................................82
5 ВЕРИФИКАЦИЯ................................................................................................84
6 ВАЛИДАЦИЯ.....................................................................................................86
ЗАКЛЮЧЕНИЕ.....................................................................................................91
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ............................................93
ПРИЛОЖЕНИЕ А.................................................................................................95
ПРИЛОЖЕНИЕ Б..................................................................................................96
ПРИЛОЖЕНИЕ В.................................................................................................97
8
ВВЕДЕНИЕ
Наверное, многим знакомо высказывание «ради экономии никаких

денег не жалко». Лозунг интересный, но любая организация непременно
задумывается об экономии, ведь это способствует увеличению чистой
прибыли. Электроэнергия – это та часть расходов, без которой не может
существовать ни одно предприятие.
В интересах предприятия закупать электроэнергию в необходимых
объемах по самой низкой стоимости. Государственные органы
предусмотрели и разработали 6 ценовых категорий (сокращенно "ЦК").
Потребители промышленной электроэнергии должны закупать
электроэнергию у гарантирующих поставщиков. Например, в Москве это
ОАО "Мосэнергосбыт", а в Новосибирской области – ОАО
"Новосибирскэнергосбыт"
Что касается ЦК, то, например, первая ценовая категория – цена за 1
кВт/ч не меняется (одностоечная). Вторая ценовая категория, которая делит
оплату по зонам суток (день или ночь). Если на ночь отключать высоко
потребляемые приборы, то уже можно получить небольшую экономию.
Стоит учесть, что потребление электроэнергии для 1 и 2 ЦК не должно
превышать 670 кВт/ч в любой час.
В основном юридические потребители промышленной электроэнергии
соглашаются выбирать между третьей и шестой ценовой категории. При
расчётах оплаты на электроэнергию для 3-6 ЦК используются 2 величины –
объём электроэнергии и величина мощности (двухставочный расчёт). Объём
электроэнергии определяется по показаниям приборов учёта, мощность –
величина расчётная. Для этих категорий цена на электроэнергию
определяется индивидуально для каждого предприятия, в каждый час месяца,
а за мощность (1 МВт) цена одна для всего месяца. Причем, необходимо
отметить, что чем меньше потребление в час пиковой нагрузки, тем меньше
объем оплачиваемой мощности.
9
Учитывая возможность предсказания пиковых часов для каждого дня
выбранного субъекта Российской Федерации и составления плана
маневрирования электроэнергии предприятия необходимо разработать и
создать систему оптимизации потребления электроэнергии для юридических
лиц мелких и средних предприятий.
Целью ВКР является разработка и создание эффективной системы
оптимизации потребления электроэнергии.
Объект исследования – системы прогнозирование нагрузки,
электроэнергия.
Предмет исследования – система прогнозирования пиковых часов
нагрузки и оптимизации потребления электроэнергии для юридических лиц.
Для достижения этой цели в дипломной работе поставлены следующие
задачи:
1. Раскрыть основные принципы организации проектировании систем
прогнозирования пикового электропотребления.
2. Спроектировать и разработать систему прогнозирования пиковых
часов нагрузки и оптимизации потребления электроэнергии для
юридических лиц.
3. Создать рабочую документацию для разработанной системы.
4. Обеспечить условия для внедрения системы в структуру заказчика.
Новизна исследования характеризуется тем, что в дипломной работе
рассмотрена разработка системы оптимизации потребления электроэнергии
для семидесяти пяти субъектов Российской федерации с применением
методов системной инженерии.
10
1 ПРОБЛЕМАТИКА
На сегодняшний день энергетическая сфера играет важную роль в

коммерческом мире и является жизненно необходимой частью человечества.
Исследования, проведенные компанией ООО «ЭНЕРГОСФЕРУМ» в
сфере реализации договорных отношений между потребителями и
гарантирующими поставщиками, показали, что каждое третье российское
юридическое лицо, владелец мелкого и среднего бизнеса, являющиеся
потребителем на рынке электроэнергии переплачивает за потребленную
электрическую энергию от 5% до 20% как вследствие собственной
неосведомленности относительно процессов ценообразования на розничном
рынке, так и в результате незаинтересованности гарантирующих
поставщиков в оптимизации цены на электрическую энергию для своих
потребителей [1].
Экономия в общей структуре предприятий, имеющих возможность
свободно маневрировать потребляемую нагрузку, может достигать 25%.
Естественно, уменьшив показатели затрачиваемой мощности без снижения
объемов потребления, потребитель может весомо сократить свои затраты на
покупку электроэнергии. Пример нерационального использования
почасового потребления представлен на рисунке 1.1.
11
Рисунок 1.1 – Пример нерационального использования почасового
потребления электроэнергии предприятия
В соответствии с действующим законодательством мощность,

оплачиваемая потребителем на розничном рынке, рассчитывается в часы
пиковой нагрузки в каждом субъекте РФ, определяемые и публикуемые
коммерческим оператором АО «АТС» по окончании каждого расчетного
периода, то есть по факту. Учитывая данную проблему и особенности во
взаимоотношениях с гарантирующими поставщиками и сетевыми
организациями, необходимо создать решение для юридических лиц по
оптимизации затрат на электрическую энергию.
12
2 ПРОЕКТИРОВАНИЕ
Данная глава описывает процессы определения архитектуры,

компонентов, интерфейсов и других характеристик системы или её части
(ISO 24765) [3].
2.1 Определение потребностей и требований
Первым этапом проектирование системы являлась определение всех

стейкхолдеров системы. На текущем этапе был полезен мозговой штурм,
позволивший определить наиболее полный перечень лиц, которые способны
повлиять на результаты работы.
В определении стейкхолдеров, команде помогли помочь следующие
вопросы [4]:
1. «Кто может повилять на не достижение основных целей?»
2. «Кто больше заинтересован в успешном результате?»
3. «Был ли реализован похожий проект в прошлом, был ли этот проект
успешным?»
4. «Какие вопросы, необходимо решить для достижения целей?»
5. «Кто лучше всего разбирается в данных типах проекта?»
После проведения анализа множества различных вариантов, были
определены стейкхолдеры проекта, результаты приведены в таблице 2.1.
Таблица 2.1 – Стейкхолдеры системы с рабочим названием «СОПЭ»

ID Стейкхолдер (роль) Комментарий
СХ Заказчик и инвестор Федеральная розничная энергосбытовая
1 проекта компания «Энерго-март»
СХ Пользователь системы Организация, которая решила
2 Директор оптимизировать затраты на электроэнергию.
Получить экономическую выгоду
СХ Пользователь системы Организация, которая решила

3 Финансист оптимизировать затраты на электроэнергию.
Специалист организация по ведению
13
финансовых операций
Окончание таблицы 2.1
СХ Разработчик/Программис Представитель отдела WEB разработки

4 т
СХ Специалист по Представитель компании по автоматизации
5 построению производства
промышленных сетей
СХ Системный Представитель отдела разработки
6 администратор
СХ Руководитель Представитель аналитической группы
7 направления анализа
данных
СХ Контролирующий орган Гарантирующий поставщик (сокращенно
8 ГП) электрической энергии
Статус гарантирующего поставщика
распространяется на определенную
территорию, согласно реестру.
После определения стейкхолдеров проекта была проведена оценка

влияния и важности стейкхолдеров (оценка степени их важности и
возможностей повлиять на успех проекта). Влияние – целенаправленное
воздействия и манипулирования стейкхолдера в управлении проектом [5].
К влиянию причисляют:
 принятие участие в составление бюджета проекта;
 возможность влиять на степень инвестирования проекта;
 влияние на ключевых лиц, которые могут принять решения по
ключевым вопросам в ходе проекта.
Важность – это поведение, вклад и обращение стейкхолдера в
возможный результат всего проекта. Определяется тем, насколько
удовлетворение потребностей и интересов каждого стейкхолдера может
повлиять на результат проекта. К важности относят:
 особые умения стейкхолдера;
 особые знания стейкхолдера;
14
 интересы или потребности, которые должны быть удовлетворены
для того, чтобы проект стал эффективным и успешным.
На основе оценки влияние и важности стейкхолдеров была выбрана
стратегия работы со стейкхолдерами. Выбор стратегии работы со
стейкхолдерами – определение принципов вмешательства каждого из
стейкхолдеров в проект и способов управления его действиями. На практике
существует четыре стратегии управления стейкхолдерами.
Стратегии управления описаны в матрице, представленной на рисунке
2.1.
Рисунок 2.1 – Стратегия управления стейкхолдерами
1. Партнеры – основные заинтересованные лица проекта. Партнеры

должны по максимуму привлекаться к принятию решений в ходе
работы над проектом. Необходимо постепенно повышать
заинтересованность групп в проекте и удовлетворять ее ключевые
15
потребности. Рекомендуется использовать принцип партнерства в
коммуникации при ведении переговоров по проекту с этой группой.
2. Консультанты – второстепенные стейкхолдеры. Необходимо
привлекать их в качестве специалистов и согласовывать с ними
только важные стратегические решения по проекту.
3. Поддержка – второстепенные стейкхолдеры. Данная группа обязана
быть ознакомлена со всеми значимыми решениями по проекту
несмотря на то, что она не принимает прямого участия в этих
решениях. При этом рекомендуется эту группу вовлекать в
обсуждение допустимых проблем и заручаться у нее
вспомогательной поддержкой по ключевым решениям.
4. Временные работники – второстепенные стейкхолдеры.
Необходимо исключительно привлекать текущую группу к
выполнению требуемых задач, не погружая ее в детали проекта и
используя самый низкий уровень информирования. Стратегия
"игнорирование".
Оценка степени важности стейкхолдеров и возможностей повлиять на
успех проекта приведена в таблице 2.2.
Таблица 2.2 – Оценка степени важности и стратегия работы со

стейкхолдерами
ID Стейкхолдер (роль) Стратегии Классификация
работы
СХ Заказчик и инвестор Партнеры Внутренний
1 проекта
СХ Пользователь системы Партнеры Внешний

2 Директор
СХ Пользователь системы Партнеры Внешний

3 Финансист
16
СХ Разработчик/Программист Поддержка Внутренний
4
СХ Специалист по Поддержка Внутренний
5 построению
промышленных сетей
СХ Системный Консультанты Внутренний

6 администратор
СХ Руководитель Консультанты Внешний

7 направления анализа
данных
СХ Контролирующий орган Консультанты Внешний

8
В столбце квалификация, указано условное деление стейкхолдеров на

“внешних” и “внутренних”. К внутренним относятся члены команды и
штатные работники компании. К внешним относятся все остальные
стейкхолдеры. Хороший анализ видов внешних стейкхолдеров при крупных
продажах дан в книге Нила Рэкхема “Стратегия работы с клиентами в
больших продажах”. В этой книге говорится, что в крупной организации за
простым словом “ внешний стейкхолдер” могут скрываться самые разные
стейкхолдеры – и со всеми ними нужно работать по-разному.
После определения стейкхолдеров проекта был проведен анализ
потребностей [6]. Обычно выявлением потребностей занимаются отдельные
специалисты, но в нашем проекте за это отвечал системный инженер. Задача
системного инженера состояла в структурировании потребностей
относительно стейкхолдеров системы, а затем для каждой потребности
сформулировать набор требований.
17
Требование формулировались относительно самой системы или ее
частей. Принципиальная разница заключается в том, что потребность должна
оставаться актуальной вне зависимости от Вашей целевой системы.
В результате переговоров и переписок удалось сформировать
потребности стейкхолдеров системы, которые представлены в таблице 2.3.
Таблица 2.3 – Потребности стейкхолдеров системы

ID Стейкхолдер Потребность Проблема
П1 (СХ1) Заказчик и Вывести новый Существующая
инвестор проекта продукт на деятельность компании не
всероссийский рынок
затрагивает обширную
часть B2B рынка малых и
средних потребителей
электроэнергии
П2 (СХ2) Пользователь Сократить затраты на — траты на
системы. Директор электроэнергию электроэнергию
возрастают с каждым
кварталом
— нет удобного
инструмента для
оптимизации
электропотребления
П3 (СХ3) Пользователь Оценить Нет решения по контролю
системы. Финансист эффективность и ведению финансовых
решений по операций связанных с
оптимизации электроэнергией
П4 (СХ4) Разработать новый В портфолио
Разработчик программный недостаточно проектов от
/Программист продукт крупных заказчиков
П5 (СХ5) Специалист Поучаствовать в В портфолио
по построению инновационном недостаточно проектов от
промышленных проекте крупных заказчиков
сетей
П6 (СХ6) Системный Повышение Проекты, проекты
администратор заработной платы которые я сопровождаю
приносят мне мало
18
средств
П7 (СХ7) Руководитель Применить свои В последнее время
направления знания на практике слишком много рутиной
анализа данных работы
П8 (СХ8) Контролировать Большие денежные
Контролирующий электропотребление издержки за
орган несоблюдение планов
Исходя из таблицы 2.3 и цели создания системы, были определены

требования для каждой потребности.
Разработка требований является отправной точкой всего процесса
создания технического задания и создания системы. Действительно, имея на
входе концептуальное представление о продукте, на выходе аналитической
фазы проектная команда получает документ требований, описывающий
продукт настолько детально, как это необходимо для дальнейшего
проектирования [7].
Таким образом, документ требований представляется своеобразной
основой и порождает целое дерево других проектных документов (рисунок
2.2).
Рисунок 2.2 – Дерево проектных документов
19
Исходя из этого можно утверждать, что качественно разработанный
документ требований позволит избежать ненужных переделок уже готовой
системы, снизить стоимость и скорость непосредственно разработки и
тестирования, не допустить расползания границ проекта и, наконец, добиться
большей удовлетворенности заказчиков.
В данном проекте используется верхнеуровневая структура документа
требований (рисунок 2.3), которая определяется структурой требований,
выявление которых является необходимым условием успешного
проектирования автоматизированной системы.
Рисунок 2.3 – Верхнеуровневая структура документа требований
К функциональным требованиям относится все то, что описывает

функциональность системы, помогает ответить на вопросы «что, как и когда»
делает система, а также, кто принимает в этом участие.
Нефункциональные требования – это характеристики системы, которые
не имеют прямого отношения к автоматизируемым процессам, но, тем не
20
менее, без которых работать с системой было бы, мягко говоря,
проблематично. Как пример, сюда можно отнести требования по удобству в
использовании, производительности, масштабируемости, требования к
документированию, к организационному и методическому обеспечению, к
интеграции с внешними системами.
Функциональные требования включают в себя, требования
пользователей и системные требования.
Требования пользователей (Customer requirements) - это те требования
верхнего уровня, которые предъявляют к системе будущие бизнес-
пользователи системы. Другими словами, те задачи, которые система должна
решать с точки зрения бизнеса заказчика. В качестве примера можно
привести такие требования, как "Система должна позволять создавать новые
договоры", "Система должна позволять менять статус существующего
договора", "Система должна позволять создавать новое дополнительное
соглашение к существующему договору" и т.д. Еще раз необходимо
подчеркнуть, что требования пользователей описывают верхнеуровневая
функциональность системы, не вдаваясь в подробности ее технической
реализации.
Системные требования (System requirements) имеют ровно такой же
смысл, что и пользовательские требования, с той разницей, что в большей
степени продиктованы не потребностями бизнеса, а особенностями IT
-инфраструктуры Заказчика. Т.е., это требования, которые определяют
регламент взаимодействия, создаваемого ПО с внешними системами,
регламентируют программно-аппаратные платформы функционирования
продукта и т.п., например, "Система должна иметь возможность
осуществлять автоматический обмен данными с системой учета персонала".
В то время как требования пользователей и системные требования, как
правило, отвечают на вопрос: «что должна делать система», то
детализированные функциональные требования (Functional requirements)
отвечают на вопросы: «кто, как и когда». Требования этого типа
21
определяются на основе анализа и детального описания процессов,
озвученных в требованиях верхнего уровня – пользовательских и системных.
Со всеми соответствующими атрибутами – функциями, условиями,
событиями, исполнителями, входами и выходами. Т.е., фактически,
представляют собой детальное описание реализуемых системой потоков
задач и данных. Требования представлены в таблицах 2.4 – 2.11.
Таблица 2.4 – Требования к разрабатываемой системе для потребности П1

ID Требование
Потребность П1 [Заказчик и инвестор проекта]
Т1.1 Система должна предоставляться как инновационный WEB-продукт

B2B рынка
Т1.2 Прогнозировать часы пиковой нагрузки для объединенных
энергетических систем: Востока, Сибири, Урала, Средней Волги,
Юга, Центра и Северо-Запада
Т1.3 Извлечение прибыли из проекта должно осуществляться за счёт
введения модели подписки
Т1.4 Обладать возможностью внесения изменений и модернизации
Т1.5 Система эксплуатируется и обслуживается ресурсами и кадрами
заказчика
Потребность П2 [Пользователь системы. Директор]
Т2.1 Система должна иметь личный кабинет пользователя на портальной
части
Т2.2 Система должна своевременно предоставлять прогнозы о часах, в
которые будет пик потребления в регионе расположения организации
Т2.3 Система должна уведомлять ответственных лиц организации о
публикации актуальных прогнозов
Т2.4 Предоставлять рекомендации по уменьшению нагрузки в данные
часы, в соответствии с особенностью электропотребления
организации и возможностью маневрирования нагрузкой
Т2.5 Обладать точностью прогнозирования не менее 80% за календарный
год
Т2.6 Иметь интерфейсы для взаимодействия с АСКУЭ
Т2.7 Иметь интерфейс прикладного программирования для
22
взаимодействия с основными функциями системы
Т2.7 Использовать протоколы для защищённого обмена данных
Потребность П3 [Пользователь системы. Финансист]
Т3.1 Предоставлять рекомендации по уменьшению нагрузки в данные
часы, в соответствии с особенностью электропотребления
организации и возможностью маневрирования нагрузкой
Т3.2 Система должна предоставлять отчетность о фактических данных
энергосбытовых компаниях
Т3.3 Система должна предоставлять данные об индикаторах работы для
каждого региона РФ

Потребность П4 [Разработчик/Программист]
Т4.1 Система должна быть программным продуктом
Т4.2 Реализация системы должна быть осуществлена на современном веб-
фреймворке
Т4.3 Веб-фреймворк системы должен подходить для разработки с
использованием архитектурной модели MVC.
Т4.4 Веб окружение заказчика должно быть корректно обозначено
Т4.5 Реализация должна поддерживать разграничение прав доступа.
Иметь возможности для работы с ролями администраторов и
пользователей.
Т4.6 Система должна выполнять свои функции в непрерывном режиме
Т4.7 Система должна обеспечивать корректную обработку аварийных
ситуаций
Т4.8 Система должна удовлетворять современным требованиям по
эргономике и дизайну. (обозначаются на стадии MVP)
Потребность П5 [Специалист по построению промышленных сетей]
Т5.1 Система должна взаимодействовать с оборудованием заказчика,
23
устройства должны иметь одинаковый протокол обмена
Т5.2 Взаимодействие устройств должно выполняется в соответствии с
моделями клиент-сервер
Т5.3 Устройства заказчика должны быть построены с условиями и
нормами проектирования промышленных сетей
Потребность П6 [Системный администратор]
Т6.1 Система должна быть построена на современном оборудовании и
программном обеспечении
Т6.2 Все данные сайта должны храниться в структурированном виде под

управлением реляционной СУБД
Т6.3 Система должна работать на основе современного серверного
программного обеспечения
Потребность П7 [Руководитель направления анализа данных]
Т7.1 Система должна использовать современные технологии для
осуществления сбора и структурирования данных
Т7.2 Система должна иметь возможность использовать методы
машинного обучения для предсказания выходных значений
Потребность П8 [Контролирующий орган]
Т8.1 Система должна снижать потребление электроэнергии в пиковые
часы установленного региона
В данном разделе был составлен список стейкхолдеров и в ходе

переговоров и проведения исследований удалось составить список их
основных потребностей.
24
2.2 Функциональное моделирование
Сбор и анализ требований сильно упрощается, если требования

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

# Описание входных потоков
1 Требования учета гарантирующим поставщиком
2 Внешние условия, такие как: Температура на улице; Время восхода,
заката; Время года
3 Запросы компании на требуемый объем электроэнергии
Также были определены выходные потоки системы, которые

представлены в таблице 2.13.
Таблица 2.13 – Выходные потоки использующей системы

# Описание выходных потоков
1 Предоставление отчетов о результатах электропотребления
2 Обеспечить оптимальный режим электропотребления
25
Важно представить использующую систему до внедрения
разрабатываемой нами целевой системы. Это необходимо для того, чтоб
определить, как будут преобразовываться входные потоки в выходные.
Функциональная диаграмма представлена на рисунке 2.4.
Рисунок 2.4 – Функциональная диаграмма использующей системы исключая

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

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

идентификаторы. В таблице 2.14 представлено описание идентификаторов,
используемых в функциональной диаграмме.
Таблица 2.14 – Описание идентификаторов

Название Описание
ПТ Потоки данных
ИС Использующая система
СОО Системы в операционном окружении
ЦС Разрабатываемая система
При разработке системы на начальном этапе удобно использовать

структурную схему [9]. Благодаря упрощению схемы системы удается на
раннем этапе обнаружить ошибки проектирования, перераспределять
требования к элементам системы. На структурных задаются требования к
параметрам входных и выходных сигналов, проверяется реализуемость
блоков. В результате значительно сокращаются усилия по дальнейшей
реализации функционального моделирование системы. На рисунке 2.6
представлена структурная схема системы.
27
Рисунок 2.6 – Структурная схема системы
Данная структурная схема позволяет рассмотреть принцип работы

систем в самом общем виде. На структурной схеме изображены основные
функциональные части системы и линии связи между ними.
Для упрощения понимания работы системы и помощи в более
правильном и точном определения требований к целевой системе была
составлена функциональная модель системы (рисунок 2.7).
28
Рисунок 2.7 – Функциональная модель системы оптимизации
потребления электроэнергии. (Ф- функции, С – связи)
Функциональная модель представляет потоки информации в системе.

Она показывает, каким образом выходные данные преобразуются по
входным, не рассматривая порядок и способ реализации вычислений.
Функциональная модель состоит из набора диаграмм потока данных,
показывающих потоки значений от внешних входов через операции и
внутренние хранилища данных к внешним выходам.
Матрица требований, а также трассировка функций и структуры
системы приведены в приложении А.
2.3 Концепция системы
29
Если для 3-6 ЦК стоимость электроэнергии устанавливается
индивидуально для каждого часа месяца, следовательно, необходимо
определить самые выгодные часы потребления и принять в расчет
максимальное электропотребление именно в эти часы [10].
А если знать часы пикового потребления своей энергосбытовой
компании в своем же регионе, то на предприятии можно получить самую
дешевую стоимость электроэнергии.
Значит, для потребителей 3-6 ЦК необходимо создать единую систему,
позволяющую определять выгодные часы потребления электроэнергии и
часы пиковой нагрузки, а также, предоставлять информацию по тарифам
энергосбытовым компаниям в регионе клиента.
Разрабатываемая система представляет из себя веб-решение. Для
получения индикаторов работы по энергосбытовым компаниям возможно
использовать микро-сервис, который будет получать данные по всем
регионам Росси в реальном времени. В качестве сервиса предсказания может
использоваться модель машинного обучения. Для взаимодействия с системой
используется веб сайт, состоящий из новостного портала, личного кабинета
пользователя, кабинет администрации (панель управления системой).
Для возможности автоматизации процесса управления нагрузкой на
предприятии клиента используется автоматизированная система контроля и
учёта энергоресурсов (АСКУЭ) [11]. Взаимодействие разрабатываемой
системы с АСКУЭ клиента осуществляется по защищенному протоколу
передачи данных (Т2.6, Т2.7).
Ключевые особенности концепции системы:
1. Веб сайт могут быть реализованы средствами языков
программирования и фреймворками JavaScript, Laravel, VueJS
(альтернативный вариант реализации программной системы – Java).
2. В качестве сервиса сбора и прогнозирования данных используется
модуль Python с библиотеками машинного обучения.
3. В качестве главного хранилища используется база данных MySQL.
30
4. Для реализации кэшей, брокеров сообщений используется Redis:
резидентная система управления базами данных класса NoSQL с
открытым исходным кодом.
При принятии данной концепции минимальные требования к
окружению заказчика составят:
 PHP >= 7.1.0;
 PDO расширение для PHP;
 MCrypt расширение для PHP;
 OpenSSL (расширение для PHP);
 Mbstring (расширение для PHP);
 Tokenizer (расширение для PHP);
 XML (расширение для PHP);
 Composer (getcomposer.org);
 Python >= 3.6;
 Redis – система управления базами данных класса NoSQL.
Концепция системы представлена рисунке 2.8.
31
Рисунок 2.8 – Концепция работы системы оптимизации потребления
электроэнергии
На основе определенных ранее потребностей стейкхолдеров была

предложена возможная реализация системы. Концепция была предоставлена
заказчику для утверждения.
32
3 ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Данный раздел дипломной работы содержит описание технического

задания на проектирование и разработку системы оптимизации потребления
электроэнергии [12].
3.1 Общие сведения
3.1.1 Наименование
Наименование системы: «Система оптимизации потребления

электроэнергии». Кратное наименование системы: «СОПЭ».
3.1.2 Заказчик системы
Заказчиком является ООО «Энерго-март».
3.1.3 Основания разработки
Основанием для проектирования и разработки «СОПЭ» являются

следующий нормативный документ: контракт от 08.01.2019 года на
выполнение работ по созданию информационной системы «СОПЭ.
3.1.4 Сроки работ
Плановый срок окончания работ по созданию информационной

системы «Система оптимизации потребления электроэнергии» – 24 мая 2019
года.
3.1.5 Сведения об источниках финансирования работ
Источником финансирования является бюджет компании «Энерго-

март». Порядок финансирования определяется условиями договора.
3.1.6 Порядок предъявления результатов работ
Система передается в виде информационного продукта,

функционирующего комплекса на базе средств вычислительной техники
33
заказчика и исполнителя в сроки, установленные контрактом. Приемка и
верификация системы осуществляется комиссией в составе уполномоченных
представителей компании исполнителя и компании заказчика.
Условия предоставления системы, ее испытаний и окончательной
приемки определен в п. 3.6 настоящего ТЗ, также исполнитель должен
передать документацию к разработанной системе и ее модулям.
3.1.7 Нормативные документы и акты ФЗ
Нормативные документы РФ:

1. ГОСТ 34.601-90. Комплекс стандартов на автоматизированные
системы. Автоматизированные системы. Стадии создания.
2. ГОСТ 19.201-78. ТЗ. Требования к содержанию и оформлению.
3. ГОСТ Р ИСО/МЭК 12207-2010. Системная и программная
инженерия. Процессы ЖЦ программных средств (см. ISO/IEC
12207:2008).
4. ГОСТ Р ИСО/МЭК 15288-2005 (ISO/IEC 15288:2008).
Информационная технология. Системная инженерия. Процессы
жизненного цикла систем.
5. ГОСТ 34.602-89 Техническое задание на создание АС.
Федеральные законы РФ:
1. Федеральный закон "Об информации" от 2006г.
2. Федеральный закон № 126 от 7 июля 2003 г. "О связи".
3. Федеральный закон №3523-1 от 1992г. "О правовой охране
программ" (поправки от 2002 г. № 177-ФЗ).
4. Федеральный закон №85 от 4 июля 1996г. "Об участии в
международном информационном обмене".
5. Федеральный закон №110 от 19 июля 1995г. "Об авторском праве"
(изменения внесены по постановлению № 207-СФ от 2004 года).
3.1.8 Сокращения, определения и обозначения
34
В таблице 3.1 приведены сокращения, определения и обозначения.
Таблица 3.1 – Определения, обозначения, сокращения

СОПЭ Система оптимизации потребления электроэнергии
АСКУЭ автоматизированная система контроля и учёта
энергоресурсов
ПО программное обеспечение
АС автоматизированная система
БД база данных
ГОСТ межгосударственная система стандартизации
СОПЭ система оптимизации потребления электроэнергии
ИС информационная система
web интернет-пространство
ЭД эксплуатационная документация
TCP/IP сетевая модель передачи данных, представленных в
цифровом виде
HTTPS расширение протокола HTTP для поддержки шифрования в
целях повышения безопасности
SQL декларативный язык программирования, применяемый для
создания, модификации и управления данными в
реляционной базе данных, управляемой соответствующей
системой управления базами данных.
GUI графический интерфейс пользователя
НСД несанкционированный доступ
АТС администратор торговой системы
СО ЕЭС Системный оператор Единой энергетической системы
АИС автоматизированная информационная система
ЯП язык программирования
3.2 Назначение и цель создания системы
3.2.1 Назначение
«СОПЭ» предназначена для комплексной оптимизации потребления

электроэнергии юридическими лицами Российской Федерации.
35
ИС «СОПЭ» предполагается использовать на базе ООО «Энерго-март -
федеральная розничная энергосбытовая компания, задействованных в
исполнении вышеперечисленных процессов.
3.2.2 Основные цели создания системы
Основными целями создания ИС «СОПЭ» являются:

 обеспечить снижение трат юридическими лицами на оплату
электроэнергии, путем сокращения потребления электроэнергии в
пиковые часы (Т8.1);
 обеспечить свободный доступ группам потребителей к индикаторам
работы энергосбытовых компаниях для субъектов Российской
Федерации, представленных в приложении (Т3.7);
 обеспечить доступ группам потребителей к структурированным
данным о фактических пиковых часах для субъектов Российской
Федерации, согласно платной подписке (Т1.3);
 обеспечить возможность выполнения функций интегрирования
системы «СОПЭ» и АСКУЭ клиента (Т2.6).
Для реализации поставленных целей система должна решать
следующие задачи:
 сбор и структурирования данных о фактических пиковых часах для
субъектов Российской Федерации (Т3.2, Т3.7);
 сбор и структурирования данных о индикаторах работах для
субъектов Российской Федерации (Т3.7);
 составление прогнозов пиковых часов для субъектов Российской
Федерации (Т1.2);
 возможность регистрации и доступа в личный кабинет
пользователям системы (осуществление подтверждения адреса,
сброса пароля) (Т4.3);
 предоставление панели администратора для управления и
администрирования (Т2.1).
36
3.3 Требования к системе
3.3.1 Общие требования к системе
3.3.1.1 Требования к функционированию и структуре системы
Для взаимодействия с системой должен иметься web-интерфейс, а

также интересы ввода-вывода. Для хранения информации система должна
иметь базу данных (Т1.1, Т4.1).
Система должна иметь возможность формировать группы
пользователей и администраторов, а также назначение каждой группе
определенных прав на доступ и взаимодействия с данными системы. (Т4.5).
Система, разрабатываемая заказчиком, должна интегрировать
техническо-организационные модули, обеспечивающие полное
функционирование системы, каждый из которых может объединять
подсистемы (п. 2.2):
1. Модуль взаимодействия с базами данных непосредственной из WEB
интерфейса административной панели:
 администрирование БД;
 подсистема информационного ввода и вывода;
 подсистема для импорта и экспорта данных.
2. Модуль назначения и администрирования доступа:
 подсистема управления информационными ресурсами;
 подсистема действия по назначению и оказанию услуг.
3. Модуль прогнозирования временных рамок максимальных пиковых
часов для субъектов Российской Федерации:
 подсистема сбора и структурирования данных фактических
пиковых часах для субъектов Российской Федерации;
 подсистема сбора и структурирования данных индикаторов
работы для субъектов Российской Федерации;
 подсистема анализа данных;
37
 подсистема уведомления;
 подсистема взаимодействия с АСКУЭ.
4. Портальная часть (Web) ИС узла СОПЭ.
Модуль ведения базы данных непосредственной из WEB интерфейса
административной панели.
Модуль позволяет выполнять стандартные действия для работы с БД
CRUD (Создание чтение обновление удаление) по средствам веб интерфейса.
Администрирования БД.
Данная подсистема обеспечивает функции для взаимодействия и
администрирования баз данных «СОПЭ», а также отвечает за целостность
данных. Решения систем управления базами данных в области по хранению и
обработке данных должны использоваться как основания для
функциональности данной подсистемы.
Подсистема информационного ввода и вывода.
Подсистема информационного ввода и вывода используется для
осуществления функций взаимодействия с данными БД, а также
осуществляет процессы, связанные с правами доступа к БД.
Подсистема для импорта и экспорта данных.
Подсистема необходима для осуществления функций преобразования
данных «СОПЭ» и должна обеспечивать:
1. Осуществлять импорт данных и настроек включая данные БД.
2. Осуществлять экспорта данных и настроек включая данные БД.
Модуль назначения и администрирования доступа.
Модуль назначения и администрирования доступа осуществляет
разделение прав доступа групп с возможностью назначение группе и
отдельному пользователю индивидуальных полномочий и времени их
действия на доступ к данным системы.
По умолчанию необходимо выделить 3 группы пользователей (Т4.5):
1. Администраторы – обладают полными правами доступа и имеют
доступ ко всем ресурсам системы.
38
2. Редакторы – обладают ограниченным доступом. Политика доступа
позволяет выполнять редактирование контента сайта.
3. Пользователи – обладают ограниченным доступом. После
регистрации все пользователи прикрепляются к данной группе.
Политика доступа позволяет редактировать личные данные профиля
и просматривать системные данные о электропотреблении только
для своего региона, указанного при регистрации.
Модуль сбора данных и структурирования о фактических пиковых
часах для субъектов Российской Федерации.
Модуль осуществляет сбор и структурирование данных с портала
администратора торговой системы оптового рынка.
Модуль сбора и структурирования данных о индикаторах работах для
субъектов Российской Федерации.
Модуль осуществляет сбор и структурирование данных с портала
системного оператора Единой энергетической системы
Модуль прогнозирования временных рамок максимальных пиковых
часов для субъектов Российской Федерации.
Модуль осуществляет прогнозирование временных рамок, в которые
ожидается максимальное электропотребления отдельного региона
Российской федерации.
3.3.1.1.1 Требования к средствам для информационной передачи

данных
Программные действия компонентов системы должны находиться в

соответствии с современными стандартами обменом данных. (Т4.4).
Модули системы для обмена информации должны использовать
протокол TCP-IP (Т4.4).
3.3.1.1.2 Требования к взаимосвязям модулей с использующими

системами
39
Основным протоколом для поддержки прима и передачи данных
должен являться: HTTP/HTTPS. Используемый системой
специализированный компьютер или специализированное оборудование, на
котором размещается исполняемый код системы, должен иметь подключение
по протоколам TCP/IP.
Обеспечение системы должно иметь функции для совместимости на
информационном уровне данных с другими IT системами. Информационная
коллегиальность должна обеспечивается на уровне стандартов форматов
данных SQL, Json.
Функции экспорта и импорта должны быть обозначены на этапе
внедрения системы (Т4.4).
3.3.1.1.3 Требования к режимам работы
Система работает в непрерывном режиме (Т4.6).

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

состояния. Проводимая диагностика должна обеспечивать возможность
определения корректности и правильности функционирования системы и ее
компонентов, а также определения возможных сбоев в системы.
Должна обеспечиваться система логирования (Т4.2), которая
поддерживает следующие уровни журналирования описанных в «RFC 5424»:
 отладка;
 информация;
 уведомление;
 предупреждение;
 ошибка;
40
 критическое состояние;
 аварийная ситуация.
3.3.1.1.5 Перспективы усовершенствования системы
Система должна иметь возможность дальнейшего усовершенствования

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

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

к внешним пользователям (Т2.1, Т4.5):
1. Посетитель web-части СОПЭ.
2. Пользователь web-части СОПЭ.
Квалификация и компетенции пользователей в функциях и
особенностях системы, инфицируется исходя из уставов и должностных
полномочий, а также нормативными документами, которые утверждаются на
стадии проектирования эксплуатационной документации (Т1.5).
3.3.2.2 Администрирующие группы системы
41
Операции по обслуживанию системы исполняются службами,
ответственными за сопровождение, информационными отделами заказчика,
назначенными в штате или нанятые по договору заказчика.
Квалификация и компетенции администрирующих лиц в функциях и
особенностях системы утверждаются на стадии проектирования
эксплуатационной документации (Т1.5).
3.3.3 Требования к безотказности и сохраняемости
Система должна корректно реагировать на сбои в аппаратном

обеспечении, например, выключение электропитания, так система обязана
регулировать свою работу после устранения нештатной ситуации и
последующей перезагрузке аппаратной части. Исключительными ситуациями
является случаи повреждения или уничтожения носителей информации, на
которых находиться программный код, ответственный за запуск и работу
системы (Т4.7).
Для обработки аварийных ситуаций, например, от некорректных
действий администрирующих лиц, недопустимым форматом, стандартом или
значением входных данных. В таких случаях система должна инициировать
соответствующие исключение, а также корректно его обработать, путем
отправки уведомления пользователю, логирования ошибки, возврату в
предыдущее состояние. Логирование ошибок ведется согласно уровню
описанного в п. 3.3.1.1.4.
3.3.4 Общие требования по безопасности
Технические разрешение, которые будут использоваться при

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

должен удовлетворять следующим требованиям (Т4.8):
 взаимодействие системы и групп пользователей или
администраторов необходимо осуществлять на русском языке
(исключениями являются системные сообщения, которые не
подлежат русификации);
 работа должна осуществляться посредством визуального
графического интерфейса (GUI);
 интерфейс системы должен удовлетворять современным
эргономическим требованиям и предоставлять удобный доступ к
главным функциям и операциям, которые выполняет подсистемами
на разных устройствах, имеющих различные экранные формы, такие
как персональные компьютеры, планшеты и смартфоны;
 представление управляющих элементов, экранных форм и их
информационных элементов (окон, панелей и т.п.) должно быть
унифицировано. Экранные формы должны полностью находиться в
видимой площади экрана монитора с диагональю 17’ при
разрешении экрана 1280 х 1024 и выше;
 при работе с интерфейсом пользователь должен быть ориентирован
на основную работу с клавиатурой и манипулятором графической
информации «мышь». Клавиатурный режим ввода должен
использоваться преимущественно при заполнении/редактировании
текстовых и числовых полей экранных форм. В соответствии с
Трудовым кодексом РФ, должна быть предусмотрена возможность
использования манипулятора типа «мышь» в специальном
исполнении для сотрудников-левшей;
43
 должно быть реализовано отображение на экране только тех
возможностей, которые доступны определенному пользователю в
соответствии с его функциональной ролью в системе;
 должна быть реализована возможность работы с системой при двух
мониторной конфигурации дисплеев (как пример, для некоторых
заказчиков).
Требования унификации, предъявляемые к страницам
пользовательского интерфейса:
 для проектирования страниц должен использоваться идентичный
графический дизайн, который имеет единый стиль отображения
основных элементов управления и навигации;
 для отображения в разделах интерфейса операций (добавление
информационной сущности, редактирование поля данных и т.п.),
должны использоваться схожие управляющие (навигационные)
элементы;
 реакция на взаимодействие с элементами дизайна страниц (смена
фокуса, нажатие кнопки) должны реализовываться идентично для
одинаковых групп элементов;
 нужна стандартизация с формами и страницами графического
интерфейса, которые используют в базовом или системном ПО, а
также с ПО аналогичные назначения.
3.3.6 Требования к обслуживанию и эксплуатации компонентов

системы
Для эксплуатации разрабатываемой информационной системы

необходим сервер со следующем ПО (Т1.5, Т4.4):
1. Сеть Ethernet со скоростью передачи данных между конечными
узлами серверного комплекта сети не менее 100 Мбит/сек (Fast
Ethernet).
44
2. Электропитание от сети напряжением 220В с частотой 50 Гц. По
определениям электроэнергии системы первичного электропитания
должны соответствовать ГОСТ 13109–87, ГОСТ Р50628–93 и МЭК–
555–2.
3. Защита аппаратных компонентов системы, носителей данных,
резервирование ресурсов и текущее обслуживание осуществляется
техническими и организационными средствами, которые
предусмотрены в структуре площадки, предоставленной
Заказчиком.
3.3.7 Требования к охране информации
Должна обеспечиваться защита от доступа к информации в нарушение

должностных полномочий сотрудника (НСД). (Т4.4).
3.3.8 Требования по сохранности информации
Программному обеспечению информационной системы необходимо

автоматически восстанавливать свое функционирование после перезагрузки
сервера и при корректном возобновлении работы аппаратных средств. В
система должна быть возможность организации автоматического
копирования данных. (Т4.7).
3.3.2 Функциональные системные требования
3.4.1 Функции пользователей системы
Согласно п. Т4.5.
3.4.1.1 Посетитель портала СОПЭ
«Посетитель портала СОПЭ» устанавливается по умолчанию всем

пользователям, взаимодействующим с системой, но не совершившим
авторизацию. Пользователи, которые выполняют данную роль, имеют право
ознакамливаться с информацией, опубликованной на портале СОПЭ –
45
новостями и документами, а также с метаданными и другими
опубликованными данными СОПЭ.
Роль взаимодействует с подсистемой Подсистема предоставления
доступа к информационным ресурсам СОПЭ.
3.4.1.2 Внешний пользователь
Пользователь ИС СОПЭ получает роль «Пользователь» после его

регистрации в системе и подтверждении авторотационного Email-адреса
путем перехода по ссылке в письме, которое отправляется после
регистрации. Роль взаимодействует с модулями web-части СОПЭ и
подсистемой предоставления доступа к информационным ресурсам СОПЭ, и
имеет доступ к запросам на просмотр метаданных из баз данных СОПЭ в
соответствии с его группой и назначенными полномочиями. (Т2.1).
3.4.1.3 Администратор СОПЭ
Данная роль относится к системной категории. Администратор СОПЭ

функционирует со всеми Подсистемами. Он отвечает за работоспособность
системы в целом и ее составными модулями.
3.4.1.4 Администратор баз данных
Роль относится к системной категории. Администратор баз данных

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

осуществляет работу с Подсистемами ведения базы данных
пространственных данных, подсистемой ведения метаданных, подсистемой
импорта/экспорта данных. Он ответственен за достоверность и актуальность
46
базы данных. Кроме того, оператор выполняет функции, которые связаны с
обработкой запросов на предоставление данных.
3.4.1.6 Эксперт-аналитик
Данная роль принадлежит категории обслуживания. Эксперт-аналитик

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

приведены в разбивке по подсистемам.
1. Подсистема сбора и структурирования данных фактических
пиковых часах для субъектов Российской Федерации.
2. Подсистема сбора и структурирования данных индикаторов работы
для субъектов Российской Федерации.
3. Подсистема анализа данных.
4. Подсистема уведомления.
5. Подсистема взаимодействия с АСКУЭ.
6. Подсистема администрирования доступа.
7. Подсистема предоставления услуг.
8. Подсистема администрирования БД.
9. Подсистема информационного ввода и вывода.
10.Подсистема для импорта и экспорта данных.
Процессы, выполняемые под управлением различных подсистем
СОПЭ, реализуются на основе системных процедур, которые являются
47
составной частью функций пользователей системы. Системные процедуры
группируются в соответствии с их назначением:
 занесение данных;
 поиск данных;
 редактирование записей БД;
 анализ данных;
 предоставление данных.
3.4.2.1 Подсистема сбора и структурирования данных фактических

пиковых часах для субъектов Российской федерации
Подсистема сбора и структурирование данных о фактических пиковых

часах для субъектов Российской федерации, необходима как
вспомогательный элемент для определения прогноза максимальной нагрузки
и последующей оценки качества прогнозируемых данных (Т1.2, Т7.1).
Данная подсистема включает следующие функции:
1. Подключение к серверу «АТС».
2. Получение данных «АТС» за предыдущей месяц по всем доступным
субъектам РФ.
3. Преобразование и структурирование полученных данных.
4. Запись данных в соответствующей раздел БД с указанием
временной отметки.
3.4.2.2 Подсистема сбора и структурирования данных индикаторов

работы для субъектов Российской федерации
Подсистема (Т1.2, Т7.1) включает следующие функции:

1. Подключение к серверу «СО ЕЭС».
2. Возможность получение данных «СО ЕЭС» в реальном времени или
с заданным периодом обращения.
3. Преобразование и структурирование полученных данных.
48
4. Запись данных в соответствующей раздел БД с указанием
временной отметки.
3.4.2.3 Подсистема анализа данных
Подсистема осуществляет прогнозирование временных рамок, в

которые ожидается максимальное электропотребления отдельного региона
Российской федерации и выполняет следующие функции (Т2.5, Т5.1, Т7.1,
Т7.2):
 осуществление выборки данных необходимых для прогнозирования
для каждого региона РФ;
 осуществление прогнозирования данных согласно заданному
алгоритму (точность не менее 80%);
 поддержка методов машинного обучения для предсказания данных;
 запись результатов в соответствующей раздел БД;
 вызов события, уведомления о статусе прогноза.
3.4.2.4 Подсистема уведомления
Подсистема уведомления должна производить оповещение

пользователей системы при наступления определенных событий и
поддерживать выполнение функций (Т2.2, Т2.3):
 иметь возможность подписываться и прослушивать различные
события, возникающие в системе;
 реагировать на события путем отправки уведомлений;
 производить отправку Email уведомлений для пользователей с
системной информацией по заданному расписанию.
3.4.2.5 Подсистема взаимодействия с АСКУЭ
Данная подсистема позволяет выполнять команды на удаленном

оборудовании клиентов «СОПЭ». Подсистема должна выполнять следующие
функции (Т4.1, Т4.3, Т2.7):
49
1. Добавление оборудования пользователя поддерживающие
протоколы (Modbus TCP, HTTP, MQTT) (Т5.2).
2. Отправка тестовых запросов.
3. Получение обратной связи о статусе выполнения запроса.
4. Логирования операция на стороне «СОПЭ».
3.4.2.6 Подсистема назначения и администрирования доступа
Функции подсистемы администрирования доступа объединяют

средства системы, направленные на обеспечение функций ограничения
доступа к ресурсам системы, а также их сохранности.
Система должна обеспечивать выполнение следующих функций:
1. Создание данных пользователей.
2. Уничтожение данных пользователей.
3. Редактирование групп пользователей и определение прав.
4. Функция идентификации доступа заданного пользователя к
обозначенному ресурсу системы по требуемому способу доступа
(создание, просмотр, редактирование, удаление).
3.4.2.7 Подсистема действия по назначению и оказанию услуг
Подсистема действия по назначению и оказанию услуг может

взаимодействовать с подсистемой ведения БД, администрирования доступа,
web-порталом и выполняет функции установления связи пользователей или
администраторов с базой данной «СОПЭ» в соответствии с определенными
правами доступа. Подсистема реализует внутренние функции системы
управления ресурсами «СОПЭ», а также оказывает взаимодействие
пользователя или интерфейса с подсистемой подсистема назначения и
администрирования доступа, подсистемой баз данных, а также включает в
себя функции по подготовке выходных данных и шаблонов отображения.
Подсистема обеспечивает выполнение следующих функций (Т3.2, Т3.3,
Т3.4):
50
1. Предоставление данных (прогнозы, индикаторы, фактические
данные).
2. Предоставления отчетных данных о фактическом потреблении и
значении пиковых часов (Т8.2, Т8.3, Т3.4).
3. Поиск данных.
4. Просмотр данных.
5. Просмотр и изменение личных параметров пользователя в
собственном кабинете.
3.4.2.8 Подсистема администрирования БД
Администрирование БД предполагает реализацию процессов,

связанных с управлением БД «СОПЭ», и включает следующие функции
(Т1.5, Т4.5):
1. Валидация целостности и работоспособности базы данных «СОПЭ».
2. Создание БД.
3. Создание резервных копий баз данных на локальных или удалённых
хранилищах.
4. Отделение прав доступа к базе данных «СОПЭ».
3.4.2.9 Подсистема информационного ввода и вывода
Подсистема информационного ввода и вывода соединяет процессы,

указанные на создание информационного ресурса, выполнение его
актуализации и обеспечение доступа к этим данным. Подсистема управляет
процессами:
 поиска данных;
 предоставления данных;
 внесение данных в базу данных;
 редактирования данных (обновление, удаление).
3.4.2.10 Подсистема для импорта и экспорта данных
51
Подсистема должна позволять производить конвертацию (импорт и
экспорт) и в следующие форматы:
 SQL;
 JSON;
 CSV.
Данные БД при импорте/экспорте должны представляться в
общедоступных форматах.
3.4.2.11 Портальная web-часть ИС
Web-составляющая предполагает унифицированный вход удаленного

пользователя и обозначает интерфейсы для исполнения следующих функций
(Т3.1, Т2.4):
1. Доступ к информации о проекте и новостным статьям.
2. Навигация по сервисам.
3. Управление запросами по выбору данных.
4. Предоставление рекомендаций по оптимизации электроэнергии на
предприятиях.
Портал должен предусматривать реализацию публикаций постов и
страниц на для широкого круга пользователей.
3.3.3 Требования к общим видам обеспечения
3.3.3.1 Требования к математическим ресурсам
Математическое обеспечение АИС должно обеспечивать (Т6.1):

 поддержку операций с БД;
 функционирование системы прогнозирования и обработки данных;
 эксплуатацию системы в вычислительной среде.
3.3.3.2 Требования к информационному обеспечению
Обеспечение функционирования системы обязано определять

требованиям точности, актуальности и непротиворечивости.
52
Необходимо хранить все данные сайта в структурированном виде под
управлением реляционной СУБД. Исключение составляют файлы данных,
которые предназначены для просмотра и скачивания (изображения, видео,
документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД
размещаются соответствующие им ссылки (Т6.2).
3.3.3.2.1 Требования к графическому дизайну сайта
Дизайн-концепция понимается как комплексное, специально

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

полосы прокрутки и без пустых (белых) полей для основных типов
разрешения (Т4.8).
Элементы управления группируются горизонтально или вертикально
на всех страницах сайта.
На каждой странице должны отображаться логотип компании.
В футере страниц необходимо отобразить контактную информацию.
Для обеспечения удобного перемещения администратора или
пользователя системы между страницами интерфейс необходимо выполнить
в едином стиле системы и использовать идентичные функции управления и
навигационных элементов для выполнения однотипных операций.
53
3.3.3.2.3 Общие требования к информационному наполнению
Исполнитель обеспечивает заполнение разделов сайта

предоставленными заказчиком материалами и данными (Т1.4, Т1.5).
Исполнитель обеспечивает редактирование изображений для
приведения их в соответствие с техническими требованиями к верстке.
Набор и правка текстов, обработка изображений, перевод текстов заказчика и
другие работы могут быть выполнены исполнителем на основании
дополнительного соглашения.
После сдачи системы в эксплуатацию информационное наполнение
разделов, осуществляется на основании договора на поддержку сайта.
Объем текста и количество иллюстраций в других типах разделов
определяется предусмотренной настоящим ТЗ структурой данных и
уточняется на этапе согласования дизайн-концепции.
3.3.3.3 Требования по использованию языков программирования
Для разработки модулей системы преимущественно должны

использоваться программные продукты, которые (Т4.2, Т4.8):
 обладают возможностью осуществлять коллективную разработку и
внедрение системы;
 функциональные возможности сбора, хранения, обработки, доступа
к информации;
 обеспечивают гибкость платформы;
 уменьшают время разработки приложений;
 исполняют рамки стоимости и сроков программного продукта.
3.3.3.3.1 Требования к языкам манипулирования данными
Для манипулирования и взаимодействия с данными преимущественно

должны использоваться средства языков высокого уровня (Т4.8).
54
3.3.3.4 Требования к программному обеспечению
Система оптимизации потребления электроэнергии рассчитана на

функционирование в следующей программной среде (Т6.3, Т4.8).
3.3.3.4.1 Серверная часть
Программное обеспечение сервера СОПЭ следующее приведено в

таблице 3.2.
Таблица 3.2 – Программное обеспечение сервера

№ Вид Программный продукт
1 OC Ubuntu 17.04
2. Серверное программного обеспечение Apache или Nginx,CGI, Perl 5
3. БД MySQL 5.6
4. Панель управления ISPManager
5. Поддерживаемые ЯП PHP7.2, Python 3
6. БД класса NoSQL Redis
7. Удаленный доступ к серверу SSH доступ
8. Распределённая система управления Git
версиями
9. пакетный менеджеры Yarn, Composer, pip
Спецификации серверного программного обеспечения (WEB-сервер)

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

таблице 3.3.
Таблица 3.3 – Программное обеспечение рабочих станций

№ Вид Программный продукт
1 ОС Microsoft Windows/
Linux
2 Web-браузер Mozilla Firefox
3 Файловый менеджер, FTP-клиент FileZilla
55
3.3.3.5 Требования к техническому обеспечению
Характеристики и потребности одной рабочей единицы системы.

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

обеспечение, представленное в таблице 3.4 (Т4.3, Т6.3).
Таблица 3.4 – Аппаратное обеспечение сервера БД

№ Параметр/Характеристика Рекомендуемое значение
1. Архитектура Intel
2. Процессор Intel Corei3
3. Минимальная частота 3 Ггц
процессора
4. Запоминающее устройство с 2048Mb DDR
произвольным доступом
5. Хранение данных 500 Гб HDD
6. Сетевой адаптер FastEthernet
Для увеличения производительности можно использовать внешние

массивы с разными интерфейсами, также возможна установка нескольких
сетевых адаптеров.
3.3.3.5.2 Сервер приложений
Характеристика и минимальные значения для сервера приведены в

таблице 3.5
Таблица 3.1 – Обеспечение сервера приложений
56
№ Параметр/Характеристика Минимальное значение
1. Архитектура Intel
2. Процессор Intel Corei3

3. Минимальная частота 3 Ггц
4. Запоминающее устройство 4096Mb DDR
с произвольным доступом
Для увеличения показателей отказоустойчивости, может применятся

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

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

нее, необходимо руководствоваться базовыми требованиями следующих
нормативных документов:
1. ГОСТ-19. ЕСПД.
2. ГОСТ-34. Информационная технология.
3. РД-50-34.698-90. Методические указания.
4. Разработанные для проекта классификаторы, справочники реестры.
При разработке подсистемы защиты от несанкционированного доступа
следует руководствоваться следующими нормативными документами:
1. ГОСТ 50922-96 Защита информации. Основные термины и
определения.
2. ГОСТ 51583-2000 Порядок создания АС в защищенном исполнении.
3.4 Состав работ по созданию системы
Этапы работ над проектом выполняются в соответствии с ГОСТ 34 и

перечислены в таблице 3.6.
Таблица 3.6 – Этапы работ

Этапы Этапы работ Результаты Сроки
выполнения
Этап 1
Техническое Разработка Техническое 01.02.19-
задание технического задания в задание на 15.02.19
целом на «Систему создание
оптимизации информационной
потребления системы.
электроэнергии»
согласно ГОСТу 19.201.
58
Согласование и
утверждение ТЗ
Этап 2
Технический Разработка проектных Документирование 15.02.19-
проект решений по системе и технического 15.03.19
ее частям проекта согласно
Разработка разделу 3.3.3.6 ТЗ
документации на ИС, ее
подсистемы и модули
Разработка базы Проектирование Физическая БД 15.03.19-
данных системы архитектуры 15.04.19
физической БД,
проектирования
структуры таблиц,
моделей объектно-
реляционных
отображений и их
взаимосвязей
Подготовка материалов
для наполнения БД.
Наполнения таблиц
начальными данными
Разработка Создания подсистем Модуль 15.03.19-
модуля сбора, прогнозирования 15.04.19
прогнозировани структурирования и данных
я данных прогнозирования
Разработка Разработка Рабочие 01.03.19-

программных программных модулей программные 20.03.19
59
модулей для реализации модули
функций системы,
приведенных в пункте
3.1 настоящего ТЗ
Опытная Отладка и проверка Требования и 20.03.19-
эксплуатация программных модулей материалы для 20.04.19
разработки рабочей
документации на
разрабатываемую
систему
Рабочая Разработка РД на РД на систему 15.03.19-
документация «СОПЭ» ГОСТ 34.201- согласно 3.3.3.6 15.03.19
89 и ГОСТ 19.101-77 в настоящего ТЗ
соответствии с ТЗ.
Этап 3
Внедрение Подготовка объекта Программы 15.04.19-
заказчика к вводу ИС в внедрения, 30.04.19
действие документ о
Подготовка результатах
администрирующего проведенного
персонала обучения
Комплектация ИС персонала
поставляемыми Протокол
программными и испытаний
техническими Акт внедрения
средствами
информационными
продуктами.
Проведение
тестирования и
60
испытаний
Проведение опытной
эксплуатации
Этап 4
Сопровождение Выполнение действий в Проекты 15.04.19-
ИС положении о административных 31.12.19
гарантийных и технических
обязательствах. регламентов,
Правка нормативных других
документов, ТЗ и ТП. нормативных
правовых
документов.
3.5. Требования к составу работ по вводу системы в эксплуатацию
Для подготовки к вводу в действие ИС «СОПЭ» необходимо провести

следующие работы:
 идентифицировать подразделение, которое будет ответственное за
проведение опытной эксплуатации;
 обозначить список возможностей и функций систем, которые
используются при работе;
 обозначить список схем документов, которые определяют
взаимодействие при работе системы;
 обозначить список регламентов и особенностей реализуемых
деловых бизнес-процессов при эксплуатации системы (Т1.1);
 установить должностные инструкции обслуживающего персонала
системы;
 провести опытную эксплуатацию системы, с отчетом о точности
прогнозирования данных для определенных регионов РФ.
Требования к составу и содержанию работ по подготовке к вводу в
действие ИС, включая перечень основных мероприятий и их исполнителей,
61
необходимо уточнить на стадии подготовки рабочей документации и по
результатам опытной эксплуатации.
Обеспечение работ по подготовке к вводу системы осуществляет
Заказчик.
3.6 Требования к ведению документации
Документы, из числа обозначенных ГОСТом 34.201-89 должны быть

седаны на разных этапах проектировании системы.
На этапах разработки системы создаются документы в объеме и форме,
необходимом для выполнения следующего этапа создания.
На этапе технического проектирования ИС в рамках работ:
 осуществляется установка задачи;
 определяются пользователи системы и их функции;
 описывается структура и функциональная схема;
 обозначаются функции системы.
На проект разрабатываются документы технического проекта, которые
представлены в таблице 3.7
Таблица 3.7 – Документы технического проекта

№ Наименование Описание
1 Ведомость ТП
2 Пояснительная записка Назначение системы
Общие положения
Описание процессов
деятельности
Информационное обеспечение
системы
Схема организационной
структуры заказчика
62
3 Описание комплекса технических и
вычислительных средств
4 Схема функциональной структуры Обобщенная архитектура
«СОПЭ»
Функциональная структура
«СОПЭ»
5 Описание функций программных Описание алгоритмов
модулей «СОПЭ» функциональных модулей
6 Описание программных решений
7 Описание информационного
обеспечения
На последующих этапах проекта указанные документы должны быть

проверены, уточнены и откорректированы. При выполнении работ по
созданию модулей и подготовке системы к эксплуатации должны быть
подготовлены программные и эксплуатационные документы,
обеспечивающие внедрение системы.
63
4 РАЗРАБОТКА
Данная глава дает описание решенных задач, поставленных в ходе

работы над созданием системы оптимизации потребления электроэнергии.
4.1. Эскизное представление
На данной стадии разработки эскизного проекта были рассмотрены

различные варианты реализации системы. Согласно ГОСТ 2.119-2013,
при разработке эскизного проекта были выполнены работы, необходимые
для обеспечения предъявляемых к системе основных требований и
позволяющие установить принципиальные решения [13].
Программная система состоит из трех основных, взаимодействующих
между собой подсистем: подсистема анализа данных, панель управления
администратора, личный кабинет пользователей.
Программная система позволяет выполнять администраторам системы
настройку и полный функционал создания, изменения и удаления ресурсов.
Для клиентов предусмотрена возможность регистрации, авторизации,
сброс пароля. Личный кабинет пользователя позволяет ознакомиться с
прогнозируемыми данными, отследить динамику индикаторов, настроить
политику отправки уведомлений.
Подсистема интеграции АСКУЭ позволяет подключить собственное
оборудования клиента к серверам системы.
Эскизный проект и перечень необходимых работ был согласован с
заказчиком.
4.2 Разработка системы
Данный раздел описывает окончательные решения, дающих полное

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

используется web фреймворк Laravel 5.
Laravel — это бесплатный web-фреймворк с открытым исходным
кодом, предназначенный для разработки приложений с использованием
архитектурной модели MVC. В 2015 году в результате опроса sitepoint.com
по использованию PHP-фреймворков среди программистов занял первое
место в номинации «Фреймворк корпоративного уровня» [14].
Вся информационная система построена на архитектуре MVC
«Модель-Представление-Контроллер».
1. Модель (Model) предоставляет данные и реагирует на команды
контроллера, изменяя своё состояние.
2. Представление (View) необходимо для отображения данных модели
пользователю, реагируя на изменения модели.
3. Контроллер (Controller) интерпретирует действия, оповещая модель
о обязанности ее изменений.
65
Схема взаимодействия пользователя с WEB составляющей системы
представлены на рисунке 4.2.
Рисунок 4.2 – Взаимодействия пользователя c WEB частью ИС
Диаграмма архитектуры WEB приложения представлена на рисунке

4.3.
Рисунок 4.3 – Диаграмма архитектуры приложения
66
4.2.1 Модели web-приложения
Модель предоставляет данные и методы работы с ними: запросы в базу

данных, проверка на корректность [18]. Модель не зависит от представления
(не знает, как данные визуализировать) и контроллера (не имеет точек
взаимодействия с пользователем) просто предоставляя доступ к данным и
управлению ими.
Модель проектируется так, чтобы отвечать на запросы, изменяя своё
состояние, при этом может быть встроено уведомление «наблюдателей».
Модель, за счёт независимости от визуального представления, может
содержать несколько различных представлений для одной «модели».
Список моделей информационной системы представлен в таблице 4.1.
Таблица 4.1 – Список моделей информационной системы

Имя Используемая таблица Описание
БД
Area areas Список из 75 субъектов РФ
Askue askues Настройки АСКУЭ клиентов
Calcfacthour calcfacthour Фактические пиковые часы
District districts Регионы РФ
ForecastHour forecast_hour Прогноз пиковых часов
SoupFact soups_fact Индикаторы факта
потребления
SoupPlan soups_plan Индикаторы плана
потребления
SoupTemperatur soups_temperature Температура в регионах РФ
e
Сompanie companies Список поставщиков
электроэнергии в РФ
Исходя из пункта 3.3.3 ТЗ в качестве сервиса БД используется MySQL

сервис баз данных. Настройки работы с БД хранятся в файле
config/database.php. Здесь указываются все используемые вами соединения к
67
БД, а также задаются соединение по умолчанию. Примеры настройки
подключений находятся в этом же файле.
В разрабатываемой системе используется 25 таблиц, диаграмма их
связей представлена на рисунке 4.4.
Рисунок 4.4 – Диаграмма взаимодействия таблиц БД системы
4.2.2 Представления web-приложения
В качестве инструмента, отвечающего за отображение данных модели

пользователю, используется шаблонизатор «Blade».
Blade — простой, но мощный шаблонизатор, поставляемый с Laravel. В
отличие от других популярных шаблонизаторов для PHP Blade не
ограничивает разработчика в использовании чистого PHP-кода. На самом
деле все представления Blade скомпилированы в чистый PHP-код и
кешированы, пока в них нет изменений, а значит, Blade практически не
нагружает приложение. Файлы представлений системы Blade используют
расширение «.blade.php» и обычно хранятся в папке «resources/views».
4.2.3 Контроллеры web-приложения
Контроллеры интерпретирует действия пользователя, оповещая модель

о необходимости изменений. Контроллеры могут группировать связанную с
68
обработкой HTTP-запросов логику в отдельный класс. Контроллеры хранятся
в папке app/Http/Controllers.
Список контроллеров системы приведен в таблице 4.2.
Таблица 4.2 – Список контроллеров системы

Имя Посредник Описание
ApiController web, auth Работа с API личного кабинета
пользователя
AskueController web, auth Управление АСКУЭ
DashboardController web, auth Работа с личным кабинетом
DocsController web, auth Предоставление документации
PricingController web, auth Управлнеи платной подпиской
SettingsController web, auth Изменение настроек
SiteController web Отображения главной страницы
и открытых разделов сайта
Все маршруты HTTP запросов содержаться в файле «web.php» и

определены к каждому контроллеру.
Список маршрутов приводится в приложении А.
4.2.4 Модуль прогнозирования
Модуль прогнозирования позволяет позволять прогнозировать

диаграммы потребления и пиковые часы для 75 регионов РФ. Входные
данные модуль получает с удаленных серверов «АТС» и «СО ЕЭС» в
реальном времени или с заданным периодом обращения. Также модуль
трансформирует полученные данные в доступный для дальнейших
манипуляций вид.
Техническая реализация модуля прогнозирования осуществляется на
языке разработки Python 3.6. И библиотеки Keras. Keras – это открытая
69
нейросетевая библиотека, написанная на языке Python [19]. Она представляет
собой надстройку над фреймворками Deeplearning4j, TensorFlow и Theano.
Модуль прогнозирования реализован командой опытных инженеров во
главе с Романом Мальцевым. Также были изучены и использованы метрики
и визуализации для возможности ведения правильного анализа данных и
оценки результатов.
4.2.5 Личный кабинет пользователя
Личный кабинет пользователя доступен только авторизованным

пользователям. Для регистрации в статусе клиента необходимо заполнить и
отправить форму, представленную на рисунке 4.5.
Рисунок 4.5 – Форма регистрация клиентов
70
При регистрации пользователь системы указывает свое имя, email,
пароль. Также указывается один из семидесяти пяти субъектов РФ.
Указанный субъект закрепляется за пользователем и становится неизменным
при редактировании настроек. Так возможно избежать неправомерной
ситуации, когда один пользователь (владелец одного аккаунта) имеет данные
по всем субъектам РФ.
После регистрации пользователю предоставляется уведомление о
необходимости подтвердить указанный при регистрации Email. В результате
успешного подтверждения, пользователь получает доступ к своему личному
кабинету, путем авторизации через отправку логину и пароля через web-
форму.
Личный кабинет пользователя позволяет выполнять следующие
действия.
1. Изменения личных данных. В разделе настройки, пользователь
может изменить пароль, название своей кампании или настроить
политику отправки уведомлений. Скриншот раздела «Настройки»
представлен на рисунке 4.6.
Рисунок 4.6 – Скриншот раздела «Настройки»
71
2. Выбор плана подписки. В разделе подписка пользователь может
выбрать и оплатить один из трех платных решений. После оплаты
пользователь получает расширенный функционал системы на срок,
соответствующий выбранному плану.
3. Получение отчетных данных и индикаторов работы. Легитимный
пользователь, с активной подпиской получает возможность
просматривать следующие категории данных:
 прогнозы пиковых часов;
 фактические данные пиковых часов;
 температура в ОЭС;
 план генерации и потребления;
 факт генерации и потребления.
Пример отображения индикаторов представлен на рисунке 4.7.
Рисунок 4.7 – Пример отображения индикаторов
4. Добавления «АСКУЭ» и интеграция с оборудованием компании

клиента. Пользователь может интегрировать «АСКУЭ» для
72
автоматического маневрирования нагрузкой электрической энергии
компании.
5. Просмотр документации и руководство пользователя.
4.2.6 Панель управления web-приложением
Для взаимодействия с сервером и Web-приложением была создана

панель управления для администрирующих лиц. Панель управления Web-
приложением позволяет доверенным ролям производить просмотр и
редактирование ресурсов приложения в соответствии с установленной
политикой доступа.
Общие функции и возможности панели администратора:
 интерфейс администратора;
 простой способ добавлять, редактировать, удалять данные
приложения;
 конструктор меню;
 медиа менеджер файлов;
 генератор CRUD / BREAD.
Важной функцией панели администратора является разделение прав
доступа. Администратор может назначать каждой роли отдельные права
доступа на просмотр, чтение, редактирование, добавления и удаление
ресурсов. Пример настройки прав доступа представлен на рисунке 4.8.
73
Рисунок 4.8 – Пример настройки прав доступа
Для решения принципиальных задач по управлению базой данных был

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

управления приложением. Администратор может отправить на исполнение
серверную консольную команду, передав необходимые аргументы. Результат
74
работы команды будет отображен в соответствующем окне. Пример работы с
консольными командами из панели управления представлен на рисунке 4.10.
Рисунок 4.10 – Пример работы с консольными командами
В качестве взаимодействия с ресурсами системы имеется мощный

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

системы
Исходя из требований ТЗ 3.3.1.1.3, предлагается следующая реализация

решений по режимам функционирования системы:
1. Основной режим, в котором все подсистемы выполняют свои
основные функции. Данный режим является основным режимом
работы. В основном режиме функционирования система
обеспечивает:
 работу пользователей в режиме – 24 часа в день, 7 дней в
неделю, согласно метрикам хостинга серверных решений;
 выполнение своих функций – сбор, обработка и загрузка данных;
хранение данных, администрирование.
2. Профилактический режим, где одна или все подсистемы не
выполняют своих функций. В данный режим работы система
переходит в следующих случаях:
 появление необходимости модернизации аппаратно-
программного комплекса;
 требование проведения технического обслуживания;
 выход из строя аппаратно-программного комплекса, который
вызван выходом из строя элементов аппаратной или
программной базы;
 выход из строя сети передачи данных и другие аварийные
ситуации.
В профилактическом режиме система обеспечивает возможность
проведения следующих работ:
 техническое обслуживание;
 модернизацию и обновление программного комплекса;
76
 устранение аварийных ситуаций.
Для журналирования система использует библиотеку «Monolog» и
интегрированный модуль «Rollbar». Rollbar предоставляет в реальном
времени отчеты об исключениях и постоянный мониторинг развертывания
для администраторов. Система логирует все изменения в соответствии со
стандартом, описанным в «RFC 5424» [20]. В личные кабинеты доступны
расширенные отчеты и журналы о изменениях или предупреждения об
ошибках, возникших во время работы системы. Пример отображения
журнала представлен на рисунке 4.12
Рисунок 4.12 – Пример отображения журнала
4.4 Решения по пользовательскому интерфейсу и дизайну
В качестве основы для реализации пользовательского интерфейса

приложения используется «Bootstrap 4». Bootstrap — свободный набор
инструментов для создания сайтов и веб-приложений. Включает в себя
HTML- и CSS-шаблоны оформления для типографики, веб-форм, кнопок,
меток, блоков навигации и прочих компонентов веб-интерфейса, включая
JavaScript-расширения.
Как упоминалось в разделе «4.2. Разработка системы» все файлы
представления находятся в папке «resources/views». Они имеют иерархичную
структуру и наследуют основной шаблон темы. Пример главной страницы
77
Рисунок 4.13 – Пример главной страницы приложения
Личный кабинет пользователя построен с использованием шаблона

«Tabler».
Web-приложение, включая личный кабинет пользователя и панель
управления администратора, имеют поддержку мобильных устройств,
планшетов и настольных ПК. Шаблоны отображения работают с последними
версиями Chrome, Firefox +, последними версиями Safari, Opera, Internet
Explorer 10+ и мобильными браузерами.
При построении шаблонов использовались только современные веб-
технологии, такие как HTML5 и CSS3. Строгое следование рекомендациям
Bootstrap позволяют в дальнейшем упростить интеграцию новых
функциональных возможностей.
Пользовательский интерфейс личного кабинета пользователя
78
Рисунок 4.14 – Пользовательский интерфейс личного кабинета
4.5 Решения по техническому и информационному обеспечению
Для развертывания приложения и обеспечения его бесперебойной

работы используется арендованный виртуальный частный сервер со
следующими характеристиками:
 CPU: 2400 MHz;
 RAM: 1024 Mb;
 SSD: 15 Gb;
 операционная система Linux.
Заключен договор на годовую аренду с ООО «ЗЕНОН Н.С.П.», 125040,
г. Москва, ул. Ямского поля 1-я, д. 19, стр. 1.
На сервере были проведены начальные настройки сервера c Ubuntu
16.04, такие как: настройка привилегий пользователя "root", авторизации по
открытому ключу и настройка базового файрвола. Установлен стек LAMP
(Linux, Nginx, MySQL, PHP).
79
Так же были установлены и настроено следующие программное
обеспечение:
 PostgreSQL 9.5 x64;
 Redis 3.0;
 Python3.
Также был пробредён домен и произведено делегирование домена и
привязка IP адреса сервера. В качестве криптографической защиты
пользователя и сервиса использовалось технология CDN и сертификат
HTTPS.
Защита от DDoS-атак организована по средствам обратного прокси для
сайта с помощью сервиса Cloudflare.
Диаграмма развертывания приложения представлена на рисунке 4.15.
Рисунок 4.15 – Диаграмма развертывания приложения
80
После проведения развертывания приложения с удаленных
репозиториев были произведены миграции таблиц базы данных, а также
наполнение их начальными значениями. По окончанию работ были
произведены автоматические тесты работоспособности системы.
Все авторотационные данные были переданы заказчику.
4.6 Решения по персоналу
В таблице 4.3 приведена взаимосвязь с возможными вариантами

привязки ролей пользователей и администраторов системы к
организационной структуре заказчика.
Таблица 4.3 – Привязка ролей пользователей и администраторов

Роль Подразделение
Администратор системы Администрирующая группа.
Системный администратор
заказчика.
Редактор контента Администрирующая группа.
Редактор контента.
Список ролей имеет предопределенный характер и может быть

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

администрирующих лиц организации заказчика. Основные разделы
документации представлены ниже.
Требования данного документа применяются при (ГОСТ Р 15910-
2002):
 предварительных комплексных испытаниях;
 опытной эксплуатации;
 приемочных испытаниях;
 промышленной эксплуатации.
81
Автоматизированная система контроля и учёта энергоресурсов
предназначена для юридических лиц, владельцев компаний, имеющих
возможность маневрировать электрической нагрузкой предприятия. ИС
«СОПЭ» решает следующие задачи:
 обеспечивает снижение трат юридическими лицами на оплату
электроэнергии;
 обеспечивает свободный доступ группам потребителей к
индикаторам работы энергосбытовых компаниях для субъектов
Российской федерации, представленных в приложении;
 обеспечивает свободный доступ группам потребителей к
структурированным данным о фактических пиковых часах для
субъектов Российской федерации, представленных в приложении;
 обеспечивает возможность выполнения функций интегрирования
системы «СОПЭ» и АСКУЭ клиента.
Уровень подготовки администрирующих лиц зависит от занимаемой
роли. Общий уровень подготовки следующий: администраторы «СОПЭ»
должны иметь опыт работы с ОС MS Windows (XP/7/8/10), навык работы с
ПО «Google Chrome», а также обладать следующими знаниями:
 знать соответствующую предметную область;
 проводить общий мониторинг работоспособности системы.
Работа с «СОПЭ» доступна всем пользователям с установленными
правами доступа. Для работы с «СОПЭ» в качестве администратора
необходимо следующее программное обеспечение:
 Google Chrome;
 PuTTY.
Перед началом работы с «СОПЭ» на рабочем месте пользователя
необходимо выполнить следующие действия:
 установить Google Chrome или любой другой веб-браузер;
 набрать в адресной строке браузера название домена системы.
82
Для проверки доступности АС «Стоматология» с рабочего места
пользователя нужно выполнить следующие действия:
 открыть Google Chrome, для этого необходимо кликнуть по ярлыку
«Google Chrome» на рабочем столе или вызвать из меню «Пуск»;
 ввести в адресную строку Google Chrome адрес сайта и нажать
«Переход»;
 убедиться, что в окне открылся сайт «СОПЭ».
В случае если сайт «СОПЭ». не запускается, то следует обратиться в
службу поддержки.
В случае обнаружения ошибок при работе «СОПЭ», не описанных
ниже в текущем разделе, нужно обращаться к сотруднику подразделения
технической поддержки ДИТ (HelpDesk) либо к ответственному
Администратору «СОПЭ».
Таблица 4.4 –Аварийные ситуации

Ошибка Описание ошибки Действия, требуемые от
пользователя по
устранению ошибки
Сервер не найден. Возможны проблемы с Для устранения
Невозможно с доступом к «СОПЭ». проблем с сетью
отобразить страницу обратиться к старшему
администратору
«СОПЭ».
Требуется ввести При регистрации на Ввести имя
действительное имя портале СОПЭ не пользователя или
пользователя или введено имя пароль.
пароль пользователя или
пароль.
Сбой аутентификации. Неверно введено имя Нужно повторить ввод
пользователя или имени пользователя и
пароль, или такая пароля. Восстановить
83
учетная запись не имя пользователя или
числится. пароль, по средствам
его сброса.
4.7.1 Рекомендации по освоению
Рекомендуемая литература:
1. Грешилов А.А. Математические методы построения прогнозов /
А.А. Грешилов, В.А. Стакун, А.А. Стакун. — М.: Радио и связь,
1997. — 112 с.
2. Дрейпер Н. Прикладной регрессионный анализ. Множественная
регрессия / Н. Дрейпер, Г. Смит. — 3-е изд. — М.: Диалектика, 2007.
— 912 с.
4.7.2 Руководство пользователя
Документация по работе системы представлена в разделе личного

кабинета. Она имеет логичный структурированный вид, позволяющий
пользователю легко разобраться с работой в системе. Представление
руководства пользователя системы представлено на рисунке 4.16.
84
Рисунок 4.16 – Представление руководства пользователя системы в личном
кабинете
В случае возникновения проблем, пользователь может обратиться в

службу поддержки клиентов системы, отправив запрос из соответствующего
раздела web-приложения.
85
5 ВЕРИФИКАЦИЯ
Верификация – это процесс для определения, выполняет ли ИС и её

компоненты требования, наложенные на них в этапах ЖЦ ИС Основная цель:
обнаружить, зарегистрировать и устранить дефекты и ошибки, которые
внесены во время разработки и модификации ИС [21].
Обычно верификация системы проводится сверху вниз, начиная от
общих требований, заданных в ТЗ и спецификации на всю ИС до детальных
требований на компоненты и подсистемы и их взаимодействие.
Приводится таблица 5.1 трассировки принципиальных требований,
заданных в техническом задании, и описанных проектных решений.
Таблица 5.1 – Таблица данных трассировки общих требований

Объявленное требование Описание метода реализации
Требования к средствам для Реализуется за счет современной система
информационной передачи объединённых компьютерных сетей,
данных построенная на базе протокола IP и
маршрутизации IP-пакетов.
Требования к взаимосвязям Реализуется путем коллегиальности и
модулей с использующими использования общепринятых форматов
системами передачи данных.
Требования к режимам работы Реализуется путем базирования системы
на виртуальном выделенном сервере. И
использования фреймворке
позволяющего измени статус системы.
Требования по определению Реализуется за счет использования в
технического состояния модулях системы мощной библиотекой
Monolog, которая предоставляет восемь
уровней журналирования, описанных в
RFC 5424: debug, info, notice, warning,
error.
Требования по дальнейшему При проектировании системы были
усовершенствованию и заложены принципиальные возможности
развитию системы по добавлению нового функционала, за
счет слабосвязанных модулей и классов
86
Требования к численности Реализуется за счет четкого
персонала заказчика утверждаются на стадии проектирования
квалификация и компетенции
администрирующих лиц
Требования к безотказности и Реализуется за счет надежной настройке
сохраняемости системы создания резервных копий и
реакции обработок исключений
Требования по безопасности Реализуется за счет соблюдения уставов
и актов по технике безопасности
Требования, предъявляемые к Реализуется за счет применения
технической эстетике и современных подходов при
эргономике проектировании человеко-машинных
интерфейсов
Требования к обслуживанию и Реализуется за счет современного
эксплуатации компонентов решения на базе выделенного сервера
системы
Требования к охране Осуществляется путем разграничения
информации прав доступа к администрирующей части
системы и панели управления
виртуальным выделенным сервером
Требования по сохранности Реализуется за счет резервного
информации копирования данных по
соответствующему расписанию
87
6 ВАЛИДАЦИЯ
Данный раздел дипломной работы описывает результаты внедрения и

проведения испытаний автоматизированной система контроля и учёта
энергоресурсов, а также сбор и анализ отзывов пользователей системы [22].
Этапы внедрения информационной системы представлены на рисунке 6.1.
Рисунок 6.1 – Этапы внедрения информационной системы
Список должностных лиц, проводивших внедрение и проведения

испытаний представлен в таблице 6.1.
Таблица 6.1 – Список должностных лиц, проводивших внедрение и

испытания
Ф. И. О. Наименование Должность
организации
Борисов Н.Ю. ООО «Энерго-март» Директор организации
88
Павел Онохов ИП Batyukov Программист
Егор Ковалев ИП Batyukov Тестировщик
Никита Головин ИП Batyukov Аналитик
Павел Онохов ИП Batyukov Специалист по

хостингу
Целью предварительных комплексных испытаний является:

 проверка взаимодействия подсистем системы;
 проверка работоспособности системы;
 проверка соответствия системы требованиям технического задания;
 проверка готовности системы к проведению опытной комплексной
эксплуатации.
Сведения о продолжительности испытаний:
Начало проведения испытаний – 15 апреля 2019г.
Окончание проведения испытаний – 30 апреля 2019г.
Общая продолжительность проведения испытаний – 19 рабочих дней.
Сведения о результатах наблюдений за правильностью
функционирования системы представлены в таблице 6.2.
Таблица 6.2 – Сведения о результатах наблюдений

№ Наименование Ответственны Дата Результат Оценка
испытания е за проведения проведения Результата
проведение испытания
89
1 Проверка Мышляев С.С. 15.04.19 Находятся в Успешно

реализации допустимых
подсистема пределах
математического
обеспечения
2 Проверка Головин Н.С. 15.04.19 Находятся в Успешно

реализации допустимых
подсистема пределах
управления
3 Проверка Пописташ 23.04.19 Находятся в Успешно

реализации И.О. допустимых
Подсистемы пределах
сбора, анализа и
структурировани
я данных
4 Проверка Лапшанов 23.04.19 Находятся в Успешно

реализации В.О. допустимых
подсистемы пределах
взаимодействия с
АКУЭ
Оценка точности прогнозирования приводится в приложении В. Состав

приемочной комиссии и основания для ее работы приводится в таблице 6.3.
Таблица 6.3 – Состав приемочной комиссии

Ф. И. О. Наименование Должность
организации
Серебряков Н.Ю. ООО «Энерго-март» Директор организации
Скворцов Ю.С. ИП Batyukov Представитель отдела
90
разработки
Начало проведения испытаний – 15 апреля 2019г.

Окончание проведения испытаний – 23 апреля 2019г.
Общая продолжительность проведения испытаний – 6 рабочих дней.
Организация-заказчик – ООО «Энерго-март»
Организация-исполнитель – «ИП Batyukov»
Перечень составляющих технического, программного,
информационного и организационного обеспечений, проверяемых в процессе
опытной эксплуатации приведен в таблице 6.4.
Таблица 6.4 – Перечень испытаний

№ Наименование испытания
1 Проверка реализации обеспечения системы
2 Проверка реализации подсистемы сбора и структурирования данных
фактических пиковых часах для субъектов Российской федерации
3 Проверка реализации подсистема взаимодействия с АСКУЭ
4 Проверка реализации подсистемы администрирования БД
5 Проверка реализации web-части ИС
Перечень документов, предъявляемых комиссии:

 инструкция по формированию и ведению базы данных версия 1 от
12.03.2019г;
 рабочая документация, версия 1 от 12.03.2019г.
По результатам проведения предварительных испытаний Система
соответствует требованиям, представленным в документе: «Техническое
задание на создание системы». По результатам проведения опытной
эксплуатации получены следующие основные результаты:
1. Система – работоспособна. Подсистемы – взаимодействуют.
2. Система соответствует требованиям документа «Техническое
задание на создание системы».
3. Все характеристики, подлежащие оценке, находятся в допустимых
пределах.
91
Решение комиссии о принятии ИС в опытную эксплуатацию: система
готова к проведению опытной эксплуатации в ООО «Энерго-март» с 30
апреля 2019г.
Отзывы полученные от пользователей системы представлены в
приложении Б.
92
ЗАКЛЮЧЕНИЕ
Работа была выполнена в соответствии с поставленной целью и

задачами.
В результате создания данной дипломной работы была спроектирована
и разработана система оптимизации потребления электроэнергии.
В ходе работы были решены следующие задачи:
1. Проведен анализ предметной области и определены основные
принципы организации проектировании систем прогнозирования
пикового электропотребления.
2. Проведена работа по определению стейкхолдеров, их потребностей
и требований, предъявляемых к разрабатываемой системе.
3. Составлено техническое задание, проведена трассировка требований
и потребностей.
4. Разработана система оптимизации потребления электроэнергии.
5. Создана рабочая документация для пользователей и
администрирующих лиц.
6. Обеспечены условия для внедрения системы в структуру заказчика.
Разработанная система за счет своей эффективности и точности
прогнозирования помогает снизить траты на электропотребление
юридическими лицами, владельцами предприятий, имеющих возможность
маневрирования электроэнергии в среднем на 20%. Это достигается
точностью прогнозирования пиковых часов в 80% расчетного месяца в
каждом из 75 субъектов РФ.
Система позволяет интегрировать АСКУЭ компании и поддерживает 5
основных протоколов обмена информации, это позволяет автоматизировать
маневрирование электроэнергии на предприятиях пользователей.
Для пользователей имеется возможность просматривать индикаторы
работы электропотребления и электрогенерации для своего региона в
реальном времени через личный кабинет в web-приложении.
93
Дальнейшие направления развития могут включать в себя:
 проведения маркетинговых компаний;
 расширение функционала личного кабинета пользователей;
 расширение протоколов взаимодействия с АСКУЭ;
 создания мобильного приложения для доступа и взаимодействия с
системой.
94
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1 Исследования, проведенные компанией ООО «ЭНЕРГОСФЕРУМ» –

[Электронный ресурс]. – Режим доступа: http://energosferum.ru, свободный
(дата последнего посещения 25.05.19).
2 ISO/IEC/IEEE 24765:2010 Systems and software engineering –
Vocabulary ISO/IEC/IEEE 24765:2010 Разработка программного обеспечения
и системотехника, 2010. – 418 с.
3 И.А. Нуль, А.Е. Фатеев. Выполнение организационной части
дипломного проекта. Методические указания для студентов всех
специальностей и всех форм обучения (технических факультетов) – М.:
МИРЭА, 2007. – 418 с.
4 Stakeholder Analysis [Электронный ресурс]. – Режим доступа:
http://powerbranding.ru/biznes-analiz/stakeholders/, свободный (дата последнего
посещения 25.05.19).
5 Руководство к cводу знаний по управлению проектами (Руководство
PMBOK). – 5-е изд. – Pennsylvania: Project Management Institute, 2013. – 614 с.
6 Системный инженер. Как начать карьеру в новом технологическом
укладе, Вячеслав Мизгулин, 2017. – 109 с.
7 Требования к автоматизированной системе. Структура и содержание
документа [Электронный ресурс]. – Режим доступа:
http://www.betec.ru/index.php?id=6&sid=88, свободный (дата последнего
8 Управление: энциклопедический словарь, Инфра-М, 1998. – 453 с.
9 Иванов А. А. Теория автоматического управления: Учебник. – М.:
Национальный горный университет, 2003. – 250 с.
10 АО «АТС». Участникам оптового рынка [Электронный ресурс]. –
Режим доступа: http://www.atsenergo.ru/uchastnikam-optovogo-rynka,
свободный (дата последнего посещения 25.05.19).
95
11 Коммерческая электроэнергетика. Словарь-справочник. – М.: Энас.
В.В. Красник, 2006.
12 Хорошев А.Н. Введение в управление проектированием
механических систем: Учебное пособие. – Белгород, 1999. – 372 с.
13 Системная и программная инженерия. Словарь-справочник, ДМК
Пресс, 2010. – 280 с.
14 Laravel - русскоязычное комьюнити [Электронный ресурс]. – Режим
доступа: http://laravel.su/, свободный (дата последнего посещения 25.05.19).
15 Дейт К. Дж. Введение в системы баз данных / К. Дж. Дейт. – 8-е
изд. – М.: Вильямс, 2006. – 1328 с.
16 Дрейпер Н. Прикладной регрессионный анализ. Множественная
регрессия / Н. Дрейпер, Г. Смит. – 3-е изд. – М.: Диалектика, 2007. – 912 с.
17 Eloquent ORM [Электронный ресурс]. – Режим доступа:
https://laravel.ru/docs/v5/eloquent свободный (дата последнего посещения
25.05.19).
18 Keras [Электронный ресурс]. – Режим доступа:
https://www.tensorflow.org/guide/keras?hl=ru свободный (дата последнего
19 The Syslog Protocol [Электронный ресурс]. – Режим доступа:
https://tools.ietf.org/html/rfc5424, свободный (дата последнего посещения
25.05.19).
20 Синицын С. В., Налютин Н. Ю. Верификация программного
обеспечения. М.:БИНОМ, 2008, 368 c.
21 Systems and software engineering – System life cycle processes
[Электронный ресурс]. – Режим доступа:
https://www.iso.org/standard/63711.html, свободный (дата последнего
96
ПРИЛОЖЕНИЕ А
Рисунок А.1 – Матрица требований системы
Рисунок А.2 – Матрица функций и структуры(Ф-С)
ПРИЛОЖЕНИЕ Б
97
Рисунок Б.1 – Отзыв пользователя системы (ОАО «КОМПАС-Store»)
Рисунок Б.2 – Отзыв пользователя системы (ООО «Белые росы»)
Рисунок Б.3 – Отзыв пользователя системы (ООО «Pelop»)
98
ПРИЛОЖЕНИЕ В
Рисунок В.1 – Оценка точности прогнозирования
Рисунок В.2 – Оценка точности прогнозирования
99

ДИПЛОМ М Артем Ш - НКФ

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

ДИПЛОМ М Артем Ш - НКФ

Оригинальное название:

Загружено:

Авторское право:

Министерство науки и высшего образования Российской Федерации

Федеральное государственное автономное

Институт новых материалов и технологий

ДОПУСТИТЬ К ЗАЩИТЕ ПЕРЕД ГЭК

Зав. кафедрой ____________ Ребрин О.

ПРОЕКТИРОВАНИЕ СИСТЕМЫ ОПТИМИЗАЦИИ ПОТРЕБЛЕНИЯ

Выпускная квалификационная работа

Направление подготовки 27.04.03 – «Системный анализ и управление»

Студент гр. НМТМ-272701 А.А. Шайдуров

Выпускная квалификационная работа содержит 97 с., 29 табл., 33 рис.,

2.1 Определение потребностей и требований.................................................11

3.1 Общие сведения............................................................................................31

3.1.2 Заказчик системы...................................................................................31

3.1.3 Основания разработки...........................................................................31

3.1.4 Сроки работ............................................................................................31

3.1.5 Сведения об источниках финансирования работ................................31

3.1.6 Порядок предъявления результатов работ..........................................31

3.1.7 Нормативные документы и акты ФЗ....................................................32

3.2 Назначение и цель создания системы........................................................33

3.2.2 Основные цели создания системы........................................................34

3.3 Требования к системе..................................................................................35

3.3.1 Общие требования к системе................................................................35

3.3.2 Функциональные системные требования............................................43

3.3.3 Требования к общим видам обеспечения............................................50

3.4 Состав работ по созданию системы...........................................................56

3.5. Требования к составу работ по вводу системы в эксплуатацию............59

3.6 Требования к ведению документации........................................................60

4.1. Эскизное представление.............................................................................62

4.2 Разработка системы......................................................................................62

4.2.1 Модели web-приложения......................................................................65

4.2.2 Представления web-приложения..........................................................66

4.2.3 Контроллеры web-приложения.............................................................66

4.2.4 Модуль прогнозирования......................................................................67

4.2.5 Личный кабинет пользователя..............................................................68

4.2.6 Панель управления web-приложением................................................71

4.3 Решения по режимам функционирования и диагностированию системы

4.4 Решения по пользовательскому интерфейсу и дизайну...........................75

4.5 Решения по техническому и информационному обеспечению...............77

4.6 Решения по персоналу.................................................................................79

4.7 Создание рабочей документации................................................................79

4.7.1 Рекомендации по освоению..................................................................82

4.7.2 Руководство пользователя.....................................................................82

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ............................................93

Наверное, многим знакомо высказывание «ради экономии никаких

На сегодняшний день энергетическая сфера играет важную роль в

В соответствии с действующим законодательством мощность,

Данная глава описывает процессы определения архитектуры,

2.1 Определение потребностей и требований

Первым этапом проектирование системы являлась определение всех

Таблица 2.1 – Стейкхолдеры системы с рабочим названием «СОПЭ»

СХ Пользователь системы Организация, которая решила

СХ Разработчик/Программис Представитель отдела WEB разработки

После определения стейкхолдеров проекта была проведена оценка

Рисунок 2.1 – Стратегия управления стейкхолдерами

1. Партнеры – основные заинтересованные лица проекта. Партнеры

Таблица 2.2 – Оценка степени важности и стратегия работы со

СХ Пользователь системы Партнеры Внешний

СХ Пользователь системы Партнеры Внешний

Окончание таблицы 2.2

СХ Системный Консультанты Внутренний

СХ Руководитель Консультанты Внешний

СХ Контролирующий орган Консультанты Внешний

В столбце квалификация, указано условное деление стейкхолдеров на

Таблица 2.3 – Потребности стейкхолдеров системы

Исходя из таблицы 2.3 и цели создания системы, были определены