- масштабируемые средства для построения баз данных.

Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений. Этот компилятор в настоящее время является самым быстрым в мире. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL.

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

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

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

Cреда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений RAD, поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных. VCL - библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление DDE и OLE. Единственное, что можно поставить в вину Delphi, это то, что готовых компонент, поставляемых Borland, могло бы быть и больше. Однако, разработки других фирм, а также свободно распространяемые программистами freeware-компоненты уже восполнили этот недостаток. В Visual Basic соответствующий стандарт компонент назывался VBX. И этот стандарт так же поддерживается в Delphi. Однако, визуальные компоненты в Delphi обладают большей гибкостью. Вспомним, в чем была проблема в VB. Прикладной программист программировал, вообще говоря, в среде языка Бэйсик. А компоненты в стандарте VBX готовили ему его коллеги-профессионалы на С++. В Delphi визуальные компоненты пишутся на объектном Паскале, на том же Паскале, на котором пишется алгоритмическая часть приложения. И визуальные компоненты Delphi получаются открытыми для надстройки и переписывания.

Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер. В этом и заключается масштабируемость на практике - одно и то же приложение можно использовать как для локального, так и для более серьезного клиент-серверного вариантов.

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

- создание справочной системы средствами НТМL;

- создание справочной системы средствами JavaScript;

- создание справочной системы средствами Word;

- создание контестных малых сообщений (Hint).

При создании программного приложения в курсовой работе использовалась технология создания контекстной помощи средствами HTML.

В качестве СУБД была выбрана система MS Access 2002, которая является частью пакета MS Office 2002, установленного на компьютерах автоматизированного предприятия. При внедрении системы нет необходимости устанавливать дополнительное программное обеспечение для управления базой данных, которое зачастую требует много ресурсов, тщательной настройки и может вступать в конфликт с другими программными средствами, работающими в настоящее время.

Данная СУБД предоставляет удобные средства разработки базы данных, средства защиты данных от несанкционированного доступа, включая шифрование и назначение прав пользователям и группам пользователей [5]. Средства репликации позволяют разделить базу данных на реплики с периодической синхронизацией с основной репликой для большей защищённости данных, устранения конфликтов и возможности изменения структуры базы данных без прерывания работы системы. MS Access 2002 поддерживает язык запросов SQL, на ядре Microsoft Jet 4. Запросы могут выполняться как из приложения, работающего с базой данных, так и храниться в самой базе данных. При этом допускается использование параметров. Обращение к параметризованным запросам осуществляется, как к хранимым процедурам.

Для разработки и эксплуатации системы по учету аппаратного обеспечения, необходимо следующее программное обеспечение:

- операционная система MS Windows 2000 или более поздняя версия;

- система управления БД MS Access 2002 или более поздняя версия;

- среда разработки Delphi 7.0;

- сервер формирования отчётов MS Excel 2002 или более поздняя версия;

- текстовый процессор MS Word 2002 или более поздняя версия;

- компилятор файлов справки MS Help Workshop.

2.2 Моделирование ИСУАО

Задачи, стоящие перед проектом можно представить в виде диаграммы вариантов использования (рисунок 2.1), где роль «актера» играет системный администратор предприятия.

Системному администратору предоставляются:

- справочная информации, где представляется каталог компьютерной техники и справочник производителей;

- регистрация компьютерной техники и ее комплектующих;

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

- изменение состава комплектующих компьютерной техники;

- учет ремонта техники;

- снятие техники с учета;

- регистрация и редактирование каталога рабочих мест предприятия;

- анализ учета техники.

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

Основными объектами автоматизации являются: устройства и пользователи.

Основными ограничения являются:

- нельзя удалить устройства, которого нет в учете;

- нельзя ввести инвентарный номер устройства, который уже имеется;

- дата списание не может быть раньше даты поступления;

- дата ремонта не может быть меньше даты поступления.

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

Процессы с устройствами: регистрируют, приходуют, выписывают счет, расходуют, эксплуатируют, ремонтируют, списывают.

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

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

2.3 Используемые классификаторы и системы кодирования

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

Таблица 2.1. Состав классификаторов для комплекса задач ИСУАО

Наименование кодируемого множества объектов	Значность кода	Система кодирования	Система классификации	Вид классификатора
Номер Заявки	4	Порядковая	Отсутствует	Локальный
Код отдела	3	Порядковая	Отсутствует	Корпоративный
Табельный номер работника	4	Порядковая	Отсутствует	Корпоративный
Код устройства	4	Порядковая	Отсутствует	Локальный
Код вида техники	3	Порядковая	Отсутствует	Локальный
Код поставщика	3	Порядковая	Отсутствует	Корпоративный

В системе используется два вида классификаторов:

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

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

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

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

2.4 Проектирование базы данных

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

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

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

других, взаимосвязанных с ним объектов.

Между информационными объектами могут быть связи трех типов: 1:1, 1:М. М:N. Д ля замены связей типа М: N на связь типа 1:М, вводят объекты - связки.

Схема инфологической модели комплекса задач "Учет оргтехники", разрабатываемого для АРМ инженера АСУ, представлена на рисунке 2.2. В данной инфологической модели можно выделить такие простые информационные объекты, как "УСТРОЙСТВА", "ПОСТАВЩИКИ", "СОТРУДНИКИ", "ПОСТАВКИ", "РЕМОНТЫ", "МАТЕРИАЛЫ", "ВИДЫ УСТРОЙСТВ", "ОТДЕЛЫ".

К числу агрегированных объектов первого уровня относятся такие, как: "РЕЕСТР ПОСТАВОК", "РЕЕСТР РЕМОНТОВ", "ПЛАН ОБСЛУЖИВАНИЯ", "РЕЕСТР ОРГТЕХНИКИ".

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

Даталогическая модель базы должна отражать требования конкретной СУБД, данном случае MS Access, поэтому в ее состав входят таблицы, содержащие сведения об информационных объектах и связях между ними. Все таблицы даталогической модели можно разбить на таблицы с оперативной информацией и таблицы с условно-постоянной информацией.

Информационная модель подразделяется на:

- справочную модель;

- модель оперативной информации.

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

- таблица «Тип устройства»;

- таблица «Поставщик»;

- таблица «Сотрудник»;

- таблица «Отдел».

В модель оперативной информации включаются:

- таблица «Устройства»;

- таблица «Размещение»;

- таблица «Ремонт»;

- таблица «Материалы».

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

Замечания в колонке «Ключ», для всех таблиц:

¦ - первичный ключ ? - внешний ключ

Таблица 2.2 Таблица «Компьютерная техника» (CompTech)

Ключ	Имя	Тип	Описание
¦	ID	число	Код записи
?	ID_Dev_Name	число	Код названия техники
	InvNum	строка	Инвентаризационный номер техники
	Dev_State	число	Состояние техники: свободное| на раб.месте| в ремонте| снято с учета
	Date_In	Дата	Дата поступления техники на склад
	Date_Out	Дата	Дата снятия техники с предприятия
	Notes	строка	Заметки о технике

Таблица 2.3 Таблица «Элементы ком.техники» (CompTech_Elems)

Ключ	Имя	Тип	Описание
¦	ID	число	Код записи
?	ID_CompTech	число	Код родителя данного элемента
?	ID_DevDescr	число	Код техники в справочнике описаний
	Date_Reg	Дата	Дата поступления техники
	Date_Disch	Дата	Дата снятия техники

Таблица 2.4 Таблица «Описание ком.техники» (DevDescr)

Ключ	Имя	Тип	Описание
¦	ID	число	Код записи
?	ID_DevDescName	число	Код названия техники в каталоге
?	ID_Producer	число	Код производителя техники
	Description	строка	Описание техники

Таблица 2.5 Таблица «Каталога названий техники» (RefUni)

Ключ	Имя	Тип	Описание
¦	ID	число	Код записи
?	Name	строка	Название техники в дереве
	Level	число	Уровень техники в дереве
	Parent	число	Предок техники в дереве

Таблица 2.6 Таблица «Каталог Рабочих мест» (WorkPlace)

Ключ	Имя	Тип	Описание
¦	ID	число	Код записи
?	Name	строка	Название рабочего места в дереве
	Level	число	Уровень рабочего места в дереве
	Parent	число	Предок рабочего места в дереве

Таблица 2.7 Таблица «Техника на рабочем месте» (CompTech_WkPl)

Ключ	Имя	Тип	Описание
¦	ID	число	Код записи
?	ID_WkPl	число	Код рабочего места
?	ID_ComTech	число	Код компьютерной техники
	Date_In	дата	Дата размещения техники на раб. месте
	Date_Out	дата	Дата снятия техники с раб. места

Таблица 2.8 Таблица «Техника в ремонте» (CompTech_Repair)

Ключ	Имя	Тип	Описание
¦	ID	число	Код записи
?	ID_CompTech	число	Код рабочего места
?	Cause	число	Код компьютерной техники
	RepairOrg	дата	Дата размещения техники на раб. месте
	Date_Registry	дата	Дата снятия техники с раб. места
	Date_Return	дата	Дата возврата техники
	Oper	число	операция возврата: 0 - ремонт выполнен, 1 - аппаратура не может быть восстановлена (дешевле поменять)
	Notes	строка	замечания

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

2.4 Описание программной реализации

Система работает по принципу файл серверной СУБД. Так как система УАО является однопользовательской, то серверная и клиентская части устанавливаются только на один компьютер клиента, рис.2.3



Система СУАО состоит из двух основных модулей:

- модуль хранения базы данных;

- интерфейс работы с базой данных.

В систему СУАО включаются следующие файлы:

- HWAccount.mdb - база данных системы СУАО;

- HWAccount.exe - клиентское приложение работы с базой данных СУАО;

- HWAccount.chm - справочная информация пользователю приложения;

HWAccount.ini - файл системных настроек HWAccount приложения.Программа построена на основе методики ООП. При разработке программы не использовались глобальные переменные - только объекты, объединённые в иерархическую структуру. Структура программы приведена на рисунке 2.3.



Вкратце рассмотрим каждый из модулей, показанных на рисунке 2.3.

Модуль приложения - WHAccount.

Данный модуль выполняется при запуске программы. Его основные функции: создание главной формы приложения и обработка сообщений операционной системы. Главный модуль - main.pas.

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

В главном модуле заложены компоненты работы с наборами данных, которые используются в остальных модулях. Модуль описаний - desc.pas (description). Универсальны модуль, открывающий разные формы в зависимости от выбранной:

- каталог оборудования и описание оборудования;

- редактирование оборудования;

- справочник компьютерной техника;

- форма элементов компьютерной техники;

- справочник производителей.

Модуль настроек - setup.pas.

В данном модуле задается путь к БД HWAccount.mdb.

Модуль сортировки и фильтрации - filterCol.pas.

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

Модуль экспорта - ExcelModule.pas.

Экспорт в MS Excel выбранного набора данных.

2.5 Результаты реализации проекта

После запуска приложения HWAccount.exe на экране появляется главная форма, рисунок 2.4.

Главной форма включает панели:

- рабочие места;

- компьютерная техника (КТ);

- составляющие элементы;

- ремонт техники.

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

Здесь пользователю дается возможность:

- изменять содержимое элемента каталога (отдел, рабочие место, кабинет);

- добавить раздел (рабочее места) в текущем каталоге;

- добавить подраздел от текущего каталога;

- удалить элемент дерева или целую ветвь с набором узлов.

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

Для редактирования нужной таблицы, она выбирается курсором мыши и двойным щелчком или кнопкой «Enter» открывается форма редактирования, например «Компьютерная техника» рисунок 2.6

Для добавления или удаления записи можно пользоваться кнопками навигатора: «+», «-» или кнопками клавиатуры «Ctrl Insert», «Ctrl Del».



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

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

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



Глава 3. Организация работ по разработке системы

3.1 Разработка и описание проекта автоматизации, плана-графика автоматизации

Основное содержание работ по созданию проекта автоматизации:

1) Анализ требований к системе;

2) Проектирование системной архитектуры;

3) Разработка структуры базы данных;

4) Разработка инфологической модели информационной системы;

5) Разработка алгоритма обработки запросов;

6) Разработка текста программ;

7) Разработка выходных документов системы;

8) Разработка форм, отвечающего за взаимодействие с пользователем (интерфейса программы);

9) Тестирование системы;

10) Разработка руководства пользователя.

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

Для заполнения столбцов “Трудоемкость” таблицы воспользовались помощью экспертных оценок. Ожидаемая продолжительность работ вычисляется по формуле (1), где ожидаемая продолжительность работы рассчитывается как математическое ожидание для  - распределения.

Общие затраты труда на разработку и внедрение изделия (проекта) определяются по формуле:

, (3.1)

где t_i - затраты труда на выполнение i -го этапа проекта.

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

Этап ti	№ рабо-ты	Содержание работы	Трудоемкость	Исп
			(чел-час)	(чел-дни)
			tmin	tmax	tож	tож
1	1	Анализ требований к системе	6	12	8,4	1,05	2
2	2	Проектирование системной архитектуры	12	23	16,4	2,05	2
3	3	Разработка структуры базы данных	8	24	14,4	1,8	1
4	4	Разработка инфологической модели	16	48	28,8	3,6	1
5	5	Разработка алгоритма обработки запросов	32	80	51,2	6,4	2
6	6	Написание текста программ	24	80	46,4	5,8	1
7	7	Разработка механизма логического вывода системы	56	80	65,6	8,2	1
8	8	Разработка модуля, отвечающего за взаимодействие с пользователем	40	64	49,6	6,2	1
9	9	Общее тестирование системы	16	40	25,6	3,2	1
	10	Тестирование механизма распознавания	16	40	25,6	3,2	1
	11	Тестирование интерфейса пользователя	16	40	25,6	3,2	2
10	12	Разработка руководства пользователя	12	23	16,4	2,05	1
		Итог				46,75

Полный перечень работ с разделением их по этапам выполнения проекта приведен в таблице 3.1. В данном случае общие затраты труда на разработку= 46,75 человеко-дней.

Средняя численность исполнителей при реализации проекта разработки и внедрения ПО определяется соотношением:

 (3.2)

где Q_p - затраты труда на выполнение проекта (разработка и внедрение),

F - фонд рабочего времени.

Величина фонда рабочего времени определяется соотношением:

(3.3)

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

(3.4)

где t_p - продолжительность рабочего дня,

D_K - общее число дней в году, D_B - число выходных дней в году,

D_П - число праздничных дней в году.

Тогда фонд времени в текущем месяце = 168 часов.

Фонд рабочего времени 2 168 = 324 часов.

Средняя численность исполнителей 1,13. Таким образом, есть необходимость использовать двух исполнителей на отдельных работах.

Продолжительность отдельных работ при одновременном выполнении их несколькими исполнителями (t_i) определяется из соотношения:

 (3.5)

где t_pp - расчетная продолжительность работы,

W_исп - количество исполнителей,

К_Н - коэффициент выполнения нормы.

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

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

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

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

В таблице 3.2 представлены основные события и работы проекта.

Таблица 3.2 Основные события и работы проекта

№	Событие	Код работы	Работа	t
				чел.- часы	чел.-дни
0	Начало работ	0-1	Анализ требований к системе	8,4	1,05
1	Проанализированы требования к системе	1-2	Проектирование системной архитектуры	16,4	2,05
2	Завершено проектирование системной архитектуры	2-3	Разработка структуры базы данных	14,4	1,8
3	Завершена разработка структуры базы данных	3-4	Разработка инфологической модели	28,8	3,6
4	Завершена разработка общего алгоритма работы системы	4-5	Разработка алгоритма обработки запросов	51,2	6,4
5	Завершена разработка алгоритма обработки запросов	5-6	Разработка программ	46,4	5,8
6	Завершена разработка алгоритма работы системы	6-7	Разработка механизма логического вывода системы	65,6	8,2
7	Завершена разработка механизма логического вывода системы		Разработка интерфейса	49,6	6,2
8	Завершена разработка модуля, отвечающего за взаимодействие с пользователем	8-9	Общее тестирование системы	25,6	3,2
		8-9	Тестирование выходных документов	25,6	3,2
		8-9	Тестирование интерфейса пользователя	25,6	3,2
9	Завершено тестирование системы	9-10	Разработка руководства пользователя	16,4	2,05
10	Завершена разработка руководства пользователя

3.2 Графическое отображение сетевой модели

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

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

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

На рисунке 3.1 показана графическая модель сетевого графика.



Рисунок 3.1 - Сетевой график процесса разработки

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

Обозначение основных элементов сетевого графика: N_i, N_j - номер события, T_i^P - ранний срок наступления события i, T_i^п - поздний срок наступления события i, R_i - резерв времени события i, t_i,j - продолжительность работы i-j, R_ij^п - полный резерв времени работы i-j, R_ij^c - свободный резерв времени работы i-j.

Ранний срок совершения события определяет минимальное время, необходимое для выполнения всех работ, предшествующих данному событию и равен продолжительности наибольшего из путей, ведущих от исходного события (0) к рассматриваемому и рассчитывается по соотношению:

(3.6)

Критический путь - максимальный путь от исходного события (0) до завершения проекта. Его определение позволяет обратить внимание на перечень событий, совокупность которых имеет нулевой резерв времени.

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

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

(3.7)

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

(3.8)

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

(3.9)

Свободный резерв времени можно определить, применяя соотношение

(3.10)

В результате исследования определяется критический путь на сетевом графике - путь, имеющий наибольшую суммарную длительность работ. В данной разработке критический путь проходит через вершины: 0-1-2-3-4-5-6-7-8-9-10 и имеет длину T_кр=91 рабочих дня.

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

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

Критерии и методы оптимизации:

- сокращение величины критического пути за счет перераспределения ресурсов;

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

- минимизация стоимости всего комплекса работ при заданном времени выполнения проекта.

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

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

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

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

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

Рисунок 3.2 - Диаграмма Гантта процесса разработки

Общая длительность работ по разработке системы автоматизации рабочего места инженера АСУ составляет 73 календарных дня.

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

С целью решения поставленной проблемы была разработана «Постановка комплекса задач», обоснован выбор технологии прототипного проектирования на основе использования средств прототипирования MS Access и объектно-ориентированного языка программирования Delphi 7.0. Кроме того, было проведено обоснование выбора технической базы проекта - архитектуры клиент - сервер, ПЭВМ Pentium II 400, 64 Мб ОП и лазерный принтер модели HP LaserJet 6L.

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

Для проектирования программного обеспечения было выполнено обоснование выбора типа операционной системы MS Windows 2000, СУБД MS Access 2000 для клиентского места и MS SQL Server для сервера, методы разработки программного обеспечения и язык Delphi 7.0 для разработки оригинальных программных модулей графического интерфейса программы.

Рассмотрены основные вопросы организации технологии решения комплекса задач в диалоговом режиме.

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

Программное обеспечение проекта АРМ инженера АСУ включило разработку состава функций и сценария диалога. Была разработана структура и состав программных модулей для АРМ, определена схема взаимосвязи программных модулей и таблиц БД. Кроме того, была составлена и дано описание блок-схемы технологического процесса диалоговой обработки данных с использованием разработанной системы.

Для осуществления проекта необходимы затраты предприятия в сумме 86,6 тыс. руб. Расчет эффективности проекта показал, что данный проект является эффективным, срок окупаемости проекта составляет 1,6 года.

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

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

Список использованной литературы

1. ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы.

2. ОСТ 4.071.030. АСУП. Создание системы. Нормативы рабочего времени.

3. Microsoft Access 2000, М.: БИНОМ, 1999, 200 с.

4. DELPHI 7, Санкт-Петербург: ПИТЕР, 467 с.

5. Автоматизированные информационные технологии в экономике / Под ред. Г.А. Титоренко. - М.:ЮНИТИ, 2000.

6. Агальцов В.П. Базы данных: Учебное пособие. - М.: Мир, 2002.

7. Аглицкий И. Информационные технологии и бизнес // Эксперт автоматизации № 29, 1997.

8.

9. Багриновский К.А., Хрусталев Е.Ю. Новые информационные технологии // ЭКО №7, 1996.

10. Балдин К. В., Уткин В. Б. Информационные системы в экономике. - М. Финансы и статистика, 2004 г.

11. Бакаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2002. - СПб.: БХВ-Петербург, 2002

12. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем. Учеб.пособие. - М.: Финансы и статистика, 2004..

13. Гарсиа-Молина Г., Ульман Дж. Системы баз данных. - Изд. дом "Вильямс" М., 2003 - 1088 с.

14. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. - М.: Формум: ИНФРА-М, 2003. - 352 с.

15. Горев А., Ахаян Р., Макашарипов С. Эффективная работа с СУБД. -- СПб.: Питер, 1997. - 704 с.

16. Дженнингс Роджер. Использование Microsoft Access: Пер. с англ. - СПб.: БХВ, 2002. - 560 с.

17. Карабутов Н. Н. Информационные технологии в экономике. - М.: Экономика; 2003.

18. Карминский А. М., Нестеров П. В. Информатизация бизнеса. - М: Финансы и статистика, 1997. - 416с.

19. Карпова Т.С. Базы данных: модели, разработка, реализация 2002. - 304 с.

20. Карху Л. Объектно-ориентированный подход к автоматизации технологических процессов // Эксперт автоматизации №12, 1996.

21. Кондзюба С.П., Громов В.Н. Delphi 5. Базы данных и приложения: Лекции и упражнения. - Киев: ДиаСофт, 2001. - 592 с.

22. Компьютерные технологии обработки информации // под ред. Назарова С.В. М/ Финансы и статистика, 2002 г.

23. Марков А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию. Учебник. - М.: Финансы и статистика, 2004. - 442 с.

24. Маклаков С.В. Моделирование бизнес-процессов с BPWin 4.0. - М.: ДИАЛОГ-МИФИ, 2002. - 224с.

25. Мамиконов А.Г. Проектирование АСУ: Учебник для специальности АСУ вузов. - М.: Высшая школа, 1997.

26. Никитин А.В. Оптимизация учета на предприятии. Саратов, 1998.

27. Оптимизация информационных потоков // http://www.eme.ru.

28. Парамонов Ф. И., Колесниченко О. В. Основы проектирования АСУП: Учебное пособие. - М.: Изд-во МАИ, 1995. - 92с.

29. Позин Б.А. CASE: автоматизация проектирования программных средств // Человек и компьютер. - 1993. - № 5.

30. Проектирование ЭИС. / Г.Н. Смирнова, А.А Сорокин, Ю.Ф. Тельнов, Москва 2001, с. 443.

31. Родионов И. И., и др. Рынок информационных услуг и продуктов. - М.: МК-Периодика, 2002 г.

32. Фаронов В.В., Шумаков П.В. Delphi 4. Руководство разработчика баз данных. - М: Нолидж, 1999. - 560 с.

33. Федоров А.Г., Елманова Н.З. Базы данных для всех. - КомпьютерПресс, М., - 2001 - 256 с.

34. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. - Издание второе, дополненное и переработанное 2002. - 672 с.

35. Шмален Г. Основы и проблемы экономики предприятия, М., "Финансы и статистика", 1997.

Приложение

Моделирование существующих бизнес-процессов по учету аппаратного обеспечения