II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Далее в рамках проектирования информационной системы учета обращений пользователей необходимо провести планирование процесса разработки, выбрать модель жизненного цикла [2].
В рамках реализации ИТ-проектов проводится расчет сметы, в рамках которого учитывается объем необходимых денежных средств на создание системы, расчет заработной платы участников ИТ-проекта, учитываются затраты на приобретение лицензий на программные средства, используемые при реализации проекта, а также накладные расходы [25].
Схема каскадной модели представлена на рисунке 15.
Недостатками каскадной модели является вероятное затягивание сроков проекта, так как переход к последующей стадии производится только при полном завершении предыдущего этапа. На рисунке 16 приведена схема итерационной модели жизненного цикла.
Недостатком итерационной модели является затягивание сроков проекта, так как в рамках него предполагаются возможности постоянного возврата к предыдущим этапам при обнаружении ошибок [22].
Для разработки требуемого приложения автоматизации работы с заявками пользователей выбрана спиральная модель, представленная на рисунке 17. Структура модели жизненного цикла программного обеспечения приведена в соответствии со стандартом ГОСТ Р МЭК 62304 —2013. Информационная технология. Процессы жизненного цикла программных средств. Стратегия внедрения «Скачок» предполагает одномоментный переход к новой технологии с отказом от использования используемой ранее технологии. При использовании стратегии подобного типа определённый период наблюдаются проблемы, связанные с наличием ошибок в программном обеспечении, необходимости адаптации пользователей к новой технологии работы. Ошибки, выявляемые в процессе эксплуатации, оперативно устраняются ИТ-специалистами. Результатом перехода по прошествии периода адаптации является получение преимуществ новой технологии в кратчайшие сроки (при этом необходимо учитывать затраты, связанные со снижением производительности работы специалистов в первоначальный период внедрения).
Рисунок 17 – Спиральная модель
Подобный тип внедрения системы эффективен в случае работы с системами, не предполагающими работу с финансовыми операциями, защищаемой информацией или данными, не представляющими высокий уровень ценности.
Стратегия внедрения «Опытная эксплуатация» предполагает разработку новой технологии и ее использование на рабочем месте выбранных специалистов (при этом работа в системе не затрагивает существующую технология работы – назначенные специалисты проводят изучение и тестирование режимов работы программы, выявляют ошибки, которые исправляются разработчиками). В момент достижения работоспособного состояния системы осуществляется переход к новой технологии на рабочих местах специалистов, которые проводили тестирование продукта. При этом сотрудники, не принимавшие участие в тестировании новой технологии, проводят изучение новой технологии и постепенно включаются в рабочий процесс. Таким образом, данный способ внедрения требует больших временных затрат и снижение производительности работы специалистов на период изменения технологии.
Стратегия внедрения «Параллельная стратегия» предполагает параллельное использование существующей и внедряемой технологий в параллельном режиме всеми сотрудниками, задействованными в работе с автоматизируемой технологией. Работа в параллельном режиме проводится до момента достижения внедряемой системой работоспособного состояния. Данный способ внедрения также связан с высокой длительностью проекта и является оптимальным для работы с информацией, имеющей высокий уровень ценности (например, в системах, обрабатывающих денежный транзакции).
Стратегия «Узкое место» предполагает внедрение на рабочие места специалистов, не предполагающие участие большого количества сотрудников. В данном случае возможна совместная работа ИТ-специалиста с сотрудником, использующим программу и быстрое устранение ошибок без остановки большого количества направлений работы.
В рамках данной работы в качестве стратегии внедрения выбрана опытная эксплуатация.
При разработке проекта автоматизации технологии управления обращений пользователей был составлен календарный план внедрения автоматизированной информационной системы, представленный в таблице 7, содержащий описание этапов разработки и внедрения системы автоматизации, сроки начала и завершения работ, перечень ответственных специалистов, привлекаемых для выполнения работ.
Таблица 7
Хронологический порядок внедрения программного продукта в технологию работы
| Стадия проекта | Начало | Окончание | Задействованные специалисты |
| Определение функций для автоматизируемой системы | 10.09.2022 | 16.09.2022 | |
| Анализ технологии учета заявок в службу технической поддержки | 10.09.2022 | 11.09.2022 | Программист; Администратор БД |
| Определение недостатков организации учета заявок в службу технической поддержки | 14.09.2022 | 15.09.2022 | Администратор БД; Программист |
| Анализ алгоритмов решения задач в автоматизированном режиме | 16.09.2022 | 16.09.2022 | Администратор БД; Программист |
| Утверждение ТЗ на разработку системы | 17.09.2022 | 21.09.2022 | Руководитель группы; Директор; Программист |
| Определение требований к архитектуре ИС | 22.09.2022 | 19.10.2022 | |
| Выбор инструментария для создания системы | 22.09.2022 | 24.09.2022 | Программист |
| Разработка системы в выбранной среде | 25.09.2022 | 04.10.2022 | Программист |
| Опытная эксплуатация | 05.10.2022 | 11.10.2022 | Программист; руководитель группы |
| Развертывание системы на сервере | 12.10.2022 | 19.10.2022 | Программист |
| Развертывание информационной системы на рабочих местах | 20.10.2022 | 26.10.2022 | руководитель группы; Программист; Администратор |
| Определение ролей и полномочий для доступа к системе | 27.10.2022 | 08.11.2022 | |
| Разработка руководства пользователя | 27.10.2022 | 04.11.2022 | Программист; Администратор БД |
| Разработка руководства администратора | 05.11.2022 | 06.11.2022 | Программист |
| Оформление акта ввода в эксплуатацию | 07.11.2022 | 08.11.2022 | Руководитель группы; Директор |
Таким образом, реализация системы предполагает выполнение работ, связанных с привлечением к проекту как разработчиков ПО, так и представителей профильных отделов, в которых предполагается использование системы автоматизации.
Разработка и управление ИТ-решениями связаны со сложностями организационного характера, связанными с обеспечением эффективности взаимодействия специалистов, привлеченных к созданию информационных систем, администраторов, осуществляющих управление базой данных и файловыми ресурсами.
Основные проблемы, связанные с проектированием информационных систем, определяются факторами [6]:
- разграничением ответственности между разработчиками;
- определение календарных планов разработки ИТ-продуктов;
- определением этапов разработки и критериев приемки.
При ошибках в организации проектирования информационных систем возможны задержки, связанные с:
- необходимостью дублирования функций (назначением основного и дублирующего специалиста);
- ошибками в разделении полномочий, что может привести к нерациональному расходу ресурсов времени специалистов.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Для каждого из этапов создания информационной системы характерно наличие рисков, которые создают вероятность срыва сроков и увеличения бюджета проекта.
Далее проведена оценка степени влияния каждого из видов рисков, характерных для каждой из стадий жизненного цикла информационной системы (таблица 8).
Таблица 8
Оценка влияния рисков реализации проекта автоматизации
| № этапа | Стадия жизненного цикла | Тип риска | Перечень мер по предотвращению негативного влияния факторов риска |
| 1 | Этап обследования предметной области | Риски, связанные с некорректной постановкой задачи, неполным объемом предоставленных данных по предметной области, ошибок в формулировках задач автоматизации | Проведение аудита технологии работы сторонней организацией, имеющей сертификат на данный вид деятельности |
| 2 | Этап разработки концептуальной модели | Риски ошибок проектирования, архитектуры системы | Проведение деятельной экспертизы технического задания, предоставление отчетности по результатам создания концепции проекта |
| 3 | Стадия разработки прототипа | Риски ошибок в программе и использованных алгоритмах | Выделение тестовой системы для проведения нагрузочных испытаний системы на каждом из этапов проекта |
| 4 | Внедрение | Риски ошибок определения полномочий пользователей, ошибок в выходных документах | Тестирование функциональности, оперативное внесение изменений в функционал системы и программный код |
| 5 | Эксплуатация и сопровождение | Риски, связанные с уходом сотрудников – разработчиков проекта | Организация командной работы, документирование работы системы |
Таким образом, на всех этапах жизненного цикла системы необходимо минимизировать негативное влияние рисков указанного типа.
2.1.3 Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации
При внедрении информационной системы учета обращений пользователей необходимо определить пользовательские роли и комплекс их полномочий, что позволит организовать эффективную систему разграничения доступа к системе.
В таблице 9 приведено описание пользовательских ролей разрабатываемой системы.
Таблица 9
Описание пользовательских ролей разрабатываемой системы
| Функции / Роли | Специалист | Администратор | Руководитель |
| Учет пользователей | Чтение | Полный | Чтение |
| Учет объектов ИТ-инфраструктуры | Чтение | Полный | Чтение |
| Учет заявок на доступ | Полный | Полный | Полный |
| Учет данных об отработке обращений пользователей | Чтение | Полный | Чтение |
| Формирование таблиц управления доступом | Нет | Полный | Нет |
| Формирование сводного отчета | + | + | |
| Формирование отчета по сотрудникам | + | + |
В системе проведено разделение на пользовательский и административный уровни доступа, что позволяет обеспечить защиту от ошибочных действий пользователей, от утечек информации, несанкционированного копирования данных.
При проведении выбора стратегии проектирования системы информационной безопасности различаются следующие стратегии [4]:
- оборонительная;
- наступательная;
- упреждающая.
Предпочтение в сторону оборонительной стратегии предполагает, что при исключении вмешательства в технологию функционирования информационной системы, можно проводить лишь нейтрализацию наиболее опасных угроз. Как правило, это можно достичь путем построения «защитных оболочек», включающих возможность разработки дополнительных организационных мер, создания программных технологий по разграничению доступа информационным ресурсам, использования технических средств для осуществления контроля помещений, где располагается терминальное и серверное оборудование [1].
Использование наступательной стратегии предполагает возможность активного противодействия наиболее известным угрозам, которые могут оказать влияние на состояние информационной безопасности системы. Наступательная стратегия предполагает необходимость установки дополнительных средств пользовательской аутентификации на программном и аппаратом уровнях, внедрения более современных технологий по резервированию и восстановлению информации, рост уровня доступности системы с применением систем по горячему и холодному резервированию [8].
Использование упреждающей стратегии предполагает возможность тщательного исследования возможных угроз для систем обработки данных и разработку мероприятий по их нейтрализации еще на этапе проектирования и тестирования системы.
Изучение структуры информационной системы показало, что оптимальной стратегией разработки системы информационной безопасности будет являться наступательная стратегия, что предполагает наличие следующих этапов проектирования [7]:
- внедрение дополнительных средств антивирусной защиты (проверка внешних носителей информации на выделенной рабочей станции с установленным альтернативным антивирусным ПО);
- управление использованием внешних носителей информации (допуск к использованию USB-подключений носителей информации на рабочих станциях, где это технологически необходимо);
- внедрение корпоративной версии антивирусного ПО (что позволит автоматизировать процессы централизованного управления системой антивирусной защиты);
- внедрение почтового антивируса, позволяющего блокировать вложения, содержащие вредоносные файлы.
- организационные меры защиты информации включают в себя [5]:
- изменение положений инструкции по антивирусной защите в соответствии с внесенными изменениями;
- ознакомление сотрудников под роспись с требованиями антивирусной защиты;
- определение ответственности специалистов в рамках нормативных документов в области защиты информации;
- определение групп пользователей по уровню доступа к рискованным операциям (подключению внешних USB-накопителей, работе с внешней электронной почтой, наличию прав локального администратора на рабочих станциях).
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
На рисунке 19 приведена информационная модель системы, в которой определены сценарии работы с системой, описаны экранные формы и объекты базы данных, с которыми работает система, а также формируемая отчетность.
Рисунок 18 – Информационная модель системы
Как показано на рисунке 18, информационная модель системы включает области:
1– Область администратора, связанная с заполнением базы данных, куда вводится информация о сотрудниках компании, настройки ролей доступа;
2 – Область работы пользователя, в которой проводится ввод данных по заявкам и учету выполненных работ.
3 – Область формирования отчетности.
2.2.2. Характеристика нормативно-справочной, входной и оперативной информации
В рамках анализа информационной системы учета заявок в службу технической поддержки на выполнение работ с оборудованием АО «КИВИ», определим ключевые сущности информационной системы, их атрибуты, установим связи между ними.
Нормативно-справочная информация в работе системы включает следующие сущности:
— заявки;
— клиенты;
— виды работ;
— специалисты;
— модели оборудования;
— оборудование;
— ремонтные работы.
Далее приведем описание реквизитного состава входных данных.
Таблица 10
Реквизитный состав справочной информации «Виды работ»
| Атрибут | Тип данных | Ограничения |
| Идентификатор вида работ | Целочисленный | Первичный ключ |
| Наименование вида работ | Текстовый | Текстовый |
| Стоимость | Денежный |
Таблица 11
Реквизитный состав справочника «Модели коммуникационного оборудования»
| Атрибут | Тип данных | Ограничения |
| Идентификатор модели оборудования | Целочисленный | Первичный ключ |
| Наименование модели | Текстовый | Текстовый |
| Код вида оборудования | Целый | Целый |
Таблица 12
Реквизитный состав справочника «Специалисты»
| Наименование параметра | Тип данных | Ограничения |
| Идентификатор специалиста | Целое | Первичный ключ |
| ФИО специалиста | Текстовый | 200 |
| Должность | Текстовый | 200 |
Таблица 13
Реквизитный состав справочника «Клиенты»
| Наименование параметра | Тип данных | Ограничения |
| Идентификатор клиента | Целое | Первичный ключ |
| Наименование | Текстовый | 200 |
| Адрес | Текстовый | 200 |
| Телефон | Текстовый | 20 |
Таблица 14
Реквизитный состав справочника «Оборудование»
| Атрибут | Тип данных | Ограничения |
| Идентификатор объекта | Целое | Первичный ключ |
| Код модели | Целое | Целый |
| Инвентарный номер | Текстовый | 200 |
| Заводской номер | Текстовый | 200 |
| Дата продажи | Дата | Дата |
| Код клиента | Целый | Целый |
| Описание | Текстовый | 200 |
| Стоимость | Денежный | Денежный |
Таблица 15
Реквизитный состав входного документа «Обращение пользователя»
| Наименование параметра | Тип данных | Ограничения |
| Идентификатор заявки | Целое | Первичный ключ |
| Код объекта | Целое | |
| Дата заявки | Дата | |
| Содержание заявки | Текстовый | 200 |
| Состояние заявки | Целый |
Таблица 16
Реквизитный состав табличной части входного документа «Работы по заявкам»
| Наименование параметра | Тип данных | Ограничения |
| Идентификатор работы | Целое | Первичный ключ |
| Идентификатор заявки | Целое | |
| Идентификатор специалиста | Целое | |
| Содержание работы | Текстовый | 200 |
| Дата работы | Дата |
Инфологическая модель приведена на рисунке 19.
Рисунок 19 — Логическая модель базы данных
2.2.3. Характеристика результатной информации
Результативная информация содержит информацию о порядке решения проблемы и включает реквизиты:
- свод по обращениям с реквизитами: Тип обращений, интервал дат, статус отработки;
- свод по специалистам: ФИО специалиста, виды работ, объемы выполненных работ.
Отчет по работе с заявками содержит поля:
- код проблемной ситуации;
- наименование проблемной ситуации;
- алгоритм решения;
- данные о результативности решения.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Схема «Дерево функций» позволяет наглядно показать иерархию функций управления и обработки данных, которые автоматизированы в разработанном программном продукте.
В системе определены следующие типы функциональных возможностей системы (рисунок 20) [9]:
- служебные функции, связанные с авторизацией пользователей, настройкой интерфейса и др.;
- функционал, связанный с обработкой информации, включающий ведение справочной, оперативной информацией по учету заявок на выполнение работ с коммуникационным оборудованием.
Рисунок 20 — Дерево функций
На рисунке 21 приведен сценарий диалога системы.
Рисунок 21 — Сценарий диалога системы
Таким образом, интерфейс разрабатываемого программного продукта должен соответствовать показанной структуре и включать перечень указанных основных и служебных функций.
На рисунке 22 показана диаграмма вариантов использования. На рисунке 23 приведена диаграмма кооперации. На рисунке 24 показана диаграмма деятельности. Как показано на рис.22, в системе предполагается наличие вариантов использования для:
- менеджера по работе с клиентами, в функции которого входит учета данных о клиентах, используемом оборудовании, прием заявок и передача их для отработки;
- специалиста с правами учета данных о выполненных работах, формирования отчетности по мониторингу исполнения заявок.
Рисунок 22 — Диаграмма вариантов использования
Рисунок 23 — Диаграмма кооперации
Рисунок 24 — Диаграмма деятельности
Рисунок 25 — Диаграмма компонентов
2.3.2. Характеристика базы данных
В качестве среды разработки выбрана система «1С: Предприятие 8.3».
Структура таблиц создаваемой базы данных приведена ниже.
Таблица 17
Структура таблицы «vid_rab»
| Наименование поля | Тип | Размер поля |
| id_vid | longint | 8 |
| nam | text | 200 |
| stm | money |
Таблица 18
Структура таблицы «vid_obor»
| Наименование поля | Тип | Размер поля |
| typ | text | 18 |
| nam | text | 100 |
| id_vid | text | 50 |
Таблица 19
Структура таблицы «clients»
| Наименование поля | Тип | Размер поля |
| id_cli | longint | 50 |
| fio | text | 100 |
| adr | text | 100 |
| tel | text | 100 |
Таблица 20
Структура таблицы «kartotek»
| Наименование поля | Тип | Размер поля |
| id_obj | longint | 50 |
| id_vid | text | 50 |
| prim_kar | text | 100 |
| zavnum | text | 20 |
| stm | money | 30 |
| date | date | 25 |
Таблица 21
Структура таблицы «spc»
| Наименование поля | Тип данных | Размер поля |
| id_spc | longint | 50 |
| fio_spc | text | 100 |
| dolgn | text | 50 |
Таблица 22
Структура таблицы «zayav»
| Наименование поля | Тип данных | Размер поля |
| id_zay | longint | 50 |
| date | date | 25 |
| id_obj | longint | 50 |
| status | text | 12 |
| id_cli | longint | 50 |
Таблица 23
Структура таблицы «gur_rab»
| Наименование поля | Тип данных | Размер поля |
| id_rab | longint | 50 |
| date | date | 25 |
| id_zay | longint | 50 |
| vol | longint | 100 |
| id_spc | longint | 50 |
| id_vid | longint | 50 |
Физическая модель данных приведена на рисунке 26.
Рисунок 26 — Физическая модель данных
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
На рисунке 27 показано дерево вызова программных модулей.
Рисунок 27 — Дерево вызова программных модулей
В таблице 24 приведено описание программных модулей системы.
Таблица 24
Описание программных модулей
| № п/п | Наименование подсистемы | Функции подсистемы |
| 1 | Подсистема безопасности | Анализ полномочий пользователя |
| 2 | Подсистема инициализации интерфейса программы | После успешного входа в систему, запускает программу, используя настройки прав доступа |
| 3 | Подсистема управления деревом объектов | Управление пунктами меню |
| 4 | Подсистема взаимодействия с базой данных | Взаимодействие с базой данных |
| 5 | Справочный модуль | Справка по работе с системой |
| 6 | Модуль отчета «Отчёт по заявкам» | Формирование отчета по заявкам |
| 7 | Подсистема «Отчеты» | Формирование отчетности |
2.3.4. Описание программных модулей
Рассмотрен программный модуль М6 «Отчет по заявкам».
При вызове модуля производится формирование и вывод на экран отчета, содержащего отчет по выполнению заявок. Специалист по поставкам, ознакомившись с документом, может его распечатать или сохранить на жесткий диск в формате Microsoft Word (Текст RTF). Развернутая блок-схема работы модуля М6 представлена на рисунке 28.
Структура представления (VIEW) SVOD_3, предназначенного для получения отчета, представлена в таблице 25.
Таблица 25
Структура записи представления SVOD_3
| № п/п | Наименование показателя | Идентификатор | Тип |
| 1 | Код строки | id | Int |
| 2 | ФИО сотрудника | FIO | Varchar (100) |
| 3 | Модель оборудования | Nam_pr | Varchar(60) |
| 4 | Дата отчета | STM | Int |
| 5 | Количество заявок | kol | Int |
Рисунок 28 — Блок-схема модуля М6
Как показано на блок-схеме алгоритма, приведенной на рисунке 28, работа с системой по формированию отчета по заявкам на доступ к серверным ресурсам включает этапы:
— открытие главной формы;
— выбор режима формирования отчета;
— просмотр результатов выборки;
— сохранение результатов.
Таким образом, интерфейс разрабатываемого программного продукта должен соответствовать показанной структуре и включать перечень указанных основных и служебных функций.
2.4. Контрольный пример реализации проекта и его описание
Рассмотрим основные режимы работы созданного программного обеспечения для автоматизации работы с обращениями пользователей в условиях АО «КИВИ». На рисунке 29 приведена главная форма.
Рисунок 29 — Главная форма
На рисунке 30 приведен справочник видов работ по обращениям пользователей.
Рисунок 30 — Справочник видов работ по обращениям пользователей
На рисунках 31-32 показан справочник пользователей.
Рисунок 31 — Справочник пользователей (режим списка)
Рисунок 32 — Справочник пользователей (добавление)
На рисунках 33-34 показан режим справочника оборудования, с которым проводятся ремонтные работы.
Рисунок 33 — Режим справочника оборудования (список)
Рисунок 34 — Режим справочника оборудования (добавление)
На рис. 35 приведен режим ввода обращения пользователя.
Рисунок 35 — Режим ввода обращения пользователя
На рисунках 36-37 приведен режим справочника сотрудников.
Рисунок 36 — Справочник сотрудников (список)
Рисунок 37 — Режим списка обращений пользователей
Рисунок 38 — Справочник сотрудников (добавление)
На рис.39 показан режим учета выполненных работ по заявкам.
Рисунок 39 — Ввод данных о ремонтных работах
На рисунке 40 приведен отчет «Список оборудования в ремонте».
| Отбор: | Статус Равно «В работе» |
| Заводской номер | Клиент | Оборудование | Статус |
| ФФ02585100 | Ларионов Владимиро Петрович | Предохранитель Airline | В работе |
| SZ03205600174 | Белкина Ольга Николаевна | Предохранитель Актив Хант | В работе |
| AS589223000 | Белкина Ольга Николаевна | Система проводов | В работе |
| 46757858 | Белкина Ольга Николаевна | Трансформатор ТМ-1000 | В работе |
| ООО256022 | Белкина Ольга Николаевна | Электросчетчик Меркурий 201 | В работе |
| КК002563 | Мамаева Ирина Егоровна | Электросчетчик Меркурий 201 | В работе |
| 0002220415 | Мамаева Ирина Егоровна | Электросчетчик Меркурий 201 | В работе |
| 000222454 | Мамаева Ирина Егоровна | Принтер Xerox 2525 | В работе |
Рисунок 40 — Отчет «Список оборудования в ремонте»
На рисунке 41 приведен отчет «Список оборудования к выдаче».
| Отбор: | Статус Равно «К выдаче» |
| Заводской номер | Клиент | Оборудование | Статус |
| ООА55521201 | Ларионов Владимир Петрович | Счетчик СЕО-101 | К выдаче |
Рисунок 41 — Отчет «Список оборудования к выдаче»
На рисунке 42 приведен отчет «Стоимость работ по сотрудникам»
| Параметры: | Дата1: 01.09.2022 |
| Дата2: 30.09.2022 | |
| Сотрудник | Замена трансформаторов | Монтаж электропроводки | Настройка обмена данными с счетчиками | Проверка напряжения | Профилактические работы | Ремонт блоков питания | Ремонт оборудования | Установка электросчетчиков | Экспертиза ущерба от скачков напряжения | Итого |
| Стоимость работ | Стоимость работ | Стоимость работ | Стоимость работ | Стоимость работ | Стоимость работ | Стоимость работ | Стоимость работ | Стоимость работ | Стоимость работ | |
| Иванов Иван Петрович | 1 400 | 300 | 2 200 | 2 300 | 6 200 | |||||
| Калеев Дмитрий Викторович | 900 | 1 900 | 1 400 | 4 200 | ||||||
| Селин Олег Петрович | 1 600 | 800 | 2 400 | |||||||
| Трифонов Валерий Петрович | 1 300 | 900 | 650 | 100 | 2 950 | |||||
| Фефелов Сергей Иванович | 600 | 7 500 | 1 800 | 500 | 10 400 | |||||
| Итого | 1 900 | 900 | 9 750 | 100 | 4 000 | 1 200 | 4 100 | 2 300 | 1 900 | 26 150 |
| Итого | |
| Стоимость работ | 26 150 |
Рисунок 42 — Отчет «Стоимость работ по сотрудникам»
На рисунке 43 приведен отчет «Стоимость работ по заявкам»
Рисунок 43 — Отчет «Стоимость работ по заявкам»
Выводы по разделу
В практической части работы проведено построение структуры данных информационной системы учета обращений пользователей. Проведен выбор модели жизненного цикла (спиральная), стратегия внедрения разработанной системы – опытная эксплуатация. Определен перечень сущностей информационной системы, установлены межтабличные связи. Проведено построение логической, физической моделей. Далее определены требования к архитектуре системы, проведено описание пользовательских сценариев использования системы. Далее проведено обоснование выбора средства разработки, описан прототип созданного программного обеспечения, в котором реализованы возможности работы со справочной, оперативной и отчетной информацией, проведено тестирование разработанной системы, в котором проведен анализ соответствия реализованного функционала поставленным задачам. В ходе проведенного тестирования ошибок не выявлено.
Таким образом, все поставленные задачи автоматизации выполнены.