АСУ отдела информационных технологий

Рисунок 3.1 – Контекстная диаграмма

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

Функциональная декомпозиция (рисунок 3.2) активности «АСУ отдела информационных технологий» проводится также на основе методологии DFD. На этой стадии определены следующие работы:

- обработка заявки;

- учет комплектующих и расходных  материалов;

- ремонт и обслуживание техники;

- подготовка отчетных данных  о результатах работы.

- выполнение работ по проекту

Рисунок 3.2 – Диаграмма декомпозиции

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

На входе работы «Обработка заявки»  – заявка на разработку того или  иного проекта. На выходе – сведения необходимые для выполнения проекта. Для данной работы также была проведена  декомпозиция (рисунок 3.3). Были определены следующие работы:

а) «Оформление договора». На входе  данной работы сведения о заявке на разработку проекта, на выходе – сведения о новом договоре. Работа использует данные из хранилища «Заказчики». 

б) «Определение плана работ». На вход данной работы поступают сведения о  договоре по разработке проекта, на выходе – план работ. Работа использует данные из хранилища «Виды работ».

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

Рисунок 3.3 – Диаграмма декомпозиции процесса «Обработка заявки»

Сведения о требуемых ресурсах поступают на вход работы «Заказ комплектующих  или расходных материалов». Здесь  происходит получение информации от внешней сущностью «Поставщик». При выполнении этой работы происходит заказ необходимых по комплектующих  и расходных материалов. На выходе данной работы сведения об имеющихся  в распоряжении ресурсах.

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

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

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

 

2. Специальная часть

 

1. Описание постановки задачи

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

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

 

 

 

 

 

 

 

 

Рисунок 1.1 - Схема основных модулей программы

Входными данными должны быть:

а) по разрабатываемым проектам – наименование клиента, название проекта, описание проекта, дата начала работ, дата окончания работ, стоимость разрабатываемого проекта;

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

Входными данными должны быть:

а) Сотрудники, задействованные  в каждом из проектов

б) История сервиса каждого  компьютера

в) Список всех комплектующих, находящихся на гарантии

г) Комплектующие, которые  необходимо заказать

д) Комплектующие, которые  необходимо заменить

е) Список проектов по заказчикам

ж) Рейтинг сотрудников

Все выходные данные должны иметь возможность выгрузки в  MS Excel. Также должна быть возможность графического отображения выходных данных (в виде диаграммы).

 

 

 

 

 

 

 

 

 

 

 

 

2. Разработка функциональной модели АСУ 

 

На основе модели, построенной в BРWin, можно построить модель данных. Для построения модели данных используется удобный инструмент – ERWin (средство разработки структуры базы данных). Обычно разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической модели. ERwin полностью поддерживает такой процесс, он имеет два представления модели: логическое и физическое. Таким образом, разработчик может строить логическую модель базы данных, не задумываясь над деталями физической реализации, т. е. уделяя основное внимание требованиям к информации и бизнес-процессам, которые будет поддерживать будущая база данных.

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

В результате анализа были выделены 11 объектов, которые описывают данную предметную область.

Сущность «Клиент». Она  включает в себя основные сведения о поставщиках и клиентах организации. Атрибутами сущности являются «id клиента» (первичный ключ), «Наименование», «Контактная информация», «ИНН», «КПП», «Банк», «Руководитель».

Сущность «Комплект». Она  включает в себя сведения о комплектующих  и расходных материалах. Атрибутами сущности являются «id комплект» (первичный ключ), «Модель», «id сотрудника» (внешний ключ), «id типа» (внешний ключ), «id производителя» (внешний ключ), «id клиента» (внешний ключ), «Дата выпуска» , «Стоимость» и «Гарантия до».

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

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

Сущность «Типы», которая  содержит сведения о типах комплектующих  и расходных материалов. Атрибутами являются «Id типа» (первичный ключ), «Тип» и «Характеристика».

Сущность «Осмотр», которая  включает в себя сведения о сервисном  обслуживании комплектующих. Атрибутами сущности являются «id» (первичный ключ), «Дата осмотра»,  «id комп» (внешний ключ), «id мастера» (внешний ключ), «Неисправность», «Замена», «Гарантия»  и «Заказ».

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

Сущность «Мастера» включает в себя сведения о мастерах, производящих сервисное обслуживание. Атрибутами сущности являются «id мастера» (первичный ключ), «ФИО мастера», «Квалификация».

Сущность «Работы», которая  включает в себя сведения о выполняемых  по проектам работах. Атрибутами являются «id работы» (первичный ключ), «Дата», «Характеристика», «id выполнения» (внешний ключ).

Сущность «Выполнение», которая  содержит сведения о выполнении работ  по проекту. Атрибутами являются «id выполн» (первичный ключ), «id проекта» (внешний ключ), «id сотрудника» (внешний ключ) и «Характеристика».

Сущность «Производители», которая включает в себя сведения о производителях комплектующих. Атрибутами сущности являются «Id производит» (первичный ключ), «Производитель» и «Страна».

Описание атрибутов каждой сущности приведено в таблицах 4.1-4.11.

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

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

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

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

В сущности «Типы» содержатся наименования типов (категорий) комплектующих. Описания сущности представлено в таблице 4.5 Приложения В.

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

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

В сущности «Выполнение» содержатся сведения о сотрудниках, задействованных  в выполнении проекта. Описания сущности представлено в таблице 4.8 Приложения В.

В сущности «Работы» содержатся данные о работе сотрудника по проекту. Описания сущности представлено в таблице 4.9 Приложения В.

В сущности «Клиенты» содержатся данные о поставщиках и заказчиках (клиентах) предприятия. Описания полей представлено в таблице 4.10 Приложения В.

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

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

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

Различают идентифицирующую связь и неидентифицирующую связь. При установлении неидентифицирующей связи дочерняя сущность остается независимой. Экземпляр сущности родителя может существовать безотносительно к какому-либо экземпляру дочерней сущности. При идентифицирующей связи экземпляр подчиненной сущности зависит от родительской сущности и не может существовать без экземпляра родительской сущности.

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

Исходя из особенностей предметной области, выделенных объектов и их атрибутов, разработанной структуры связей была построена ЕR-диаграмма на логическом уровне (рисунок 4.1) Приложения Г.

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