Создание автоматизированной информационной системы (АИС) для учета деятельности авторемонтного предприятия
Обоснование необходимости совершенствования информационной системы (ИС) ООО "Мехсервис". Анализ системы учета деятельности авторемонтного предприятия. Разработка концепции построения автоматизированной ИС. Описание продукта информационной технологии.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 22.05.2012 |
Размер файла | 2,7 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
С точки зрения последовательности выполняемых работ: еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий.
Наиболее удобным языком моделирования бизнес-процессов является IDEFO, называвшийся первоначально SADT Structured Analysis and Design Technique. В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их удобно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:
функции обработки информации (работы);
документы, объекты, сотрудников, которые участвуют в обработке информации;
таблицы для хранения документов (хранилище данных) [5].
Для инфологического проектирования базы данных было выбрано CASE_средство Computer Associates ERwin 4.0.
Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать и физическую, и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой.
Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. ERwin непосредственно поддерживает эту модель путем генерации системного каталога.
Для создания базы данных, а также самого разрабатываемого программного средства, осуществляющего доступ к данным базы, выбран Microsoft Access 2000 по совокупности его преимуществ.
База данных в составе разрабатываемой автоматизированной системы должна отвечать следующим требованиям:
хранение больших объёмов актуальной и достоверной информации;
простота обращений пользователей к БД;
возможность внесения, изменения, удаления, сортировки и других манипуляций с данными БД;
поиск информации по различным группам признаков;
возможность расширения и реорганизации данных в БД при изменениях предметной области.
Все вышесказанное говорит о необходимости использования БД и соответственно специализированной системы управления базами данных (СУБД).
Основываясь на перечисленных выше критериях выбора СУБД был сделан выбор в пользу MS Access, поскольку необходима СУБД в относительно небольшой корпоративной сети (<=10 ПК), объемы хранимой информации относительно невелики (измеряются мегабайтами), надежно работающая на сервере с техническими характеристиками обычного ПК. Также MS Access определяет минимальные сложности при настройке и администрировании системы.
Microsoft Access 2000 является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных. Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет использовать одновременно несколько таблиц базы данных. При этом можно существенно упростить структуру данных, облегчая тем самым выполнение поставленных задач. MS Access обеспечивает высокую степень универсальности и продуманности интерфейса для разработки БД, глубоко развитые возможности интеграции с другими программными продуктами, входящими в состав Microsoft Office, а также с любыми программными продуктами, поддерживающими технологию OLE. Специфической особенностью СУБД MS Access является то, что вся информация, относящаяся к одной базе данных, хранится в едином файле.
В Access в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных на уровне ядра (что предотвращает несовместимые операции обновления или удаления данных). Кроме того, таблицы в MS Access снабжены средствами проверки допустимости данных, предотвращающими некорректный ввод вне зависимости от того, как он осуществляется, а каждое поле таблицы имеет свой формат и стандартные описания, что существенно облегчает ввод данных. MS Access поддерживает все необходимые типы полей, в том числе текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка и поля объектов OLE. Если в процессе специальной обработки в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений [11].
Реляционная обработка данных в MS Access за счет гибкой архитектуры системы способна удовлетворить любые потребности. При этом MS Access может использоваться как автономная СУБД в режиме файл-сервера или клиентского компонента таких продуктов, как SQL Server.
Система MS Access поддерживает обработку транзакций с гарантией их целостности. Кроме того, предусмотрена защита на уровне пользователя, что позволяет контролировать доступ к данным отдельных пользователей и целых групп.
Минимальные системные требования для MS Access 2000:
Intel Pentium 300;
Windows 95/98/2000/XP/NT;
128 Мб оперативной памяти;
100 Мб дискового пространства.
Учитывая возможности современных компьютеров, данные требования можно назвать декларационными. MS Access 2000 обеспечивает эффективную работу на любом современном персональном компьютере, которыми оснащено ООО "Мехсервис".
В конечном итоге для АИС учета деятельности авторемонтного предприятия ООО "Мехсервис" были выбраны: операционная система - Windows XP Professional, СУБД и среда разработки приложения Microsoft Access 2000.
2.2 Разработка информационного и программного обеспечения
2.2.1 Разработка информационного обеспечения
Цель инфологического проектирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных.
Логическая структура базы данных - это описание состава, типа и длины информационных единиц базы данных и связей между ними.
Сущности и связи модели данных представляются в виде реляционной таблицы (отношения). Отношение, соответствующее сущности, содержит атрибуты (столбцы), являющиеся атрибутами сущности и описывающие сущность (объект). Атрибут или множество атрибутов, которые однозначно определяют объект называются ключом.
Удобно представлять отношение как таблицу, где каждая строка есть кортеж, и каждый столбец соответствует одному компоненту. Столбцы при этом называются атрибутами и им присваивают имена. Список имён атрибутов называется схемой отношения. Совокупность схем отношений, используемых для представления информации, называются схемой базы данных, а текущие значения соответствующих отношений - базой данных [3].
Процесс построения инфологической модели состоит из следующих шагов:
определение сущностей;
определение зависимостей между сущностями;
задание первичных и альтернативных ключей;
определение атрибутов сущностей;
приведение модели к требуемому уровню нормальной формы.
Логический уровень представления модели - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
ER-диаграмма системы на логическом уровне представлена на рисунке 2.1.
Рисунок 2.1 - ER-диаграмма системы на логическом уровне
Сущности Производители, Клиенты, Специализации и Диспетчеры хранят информацию об объектах системы, соответствующих их названиям. В качестве первичного ключа в сущностях Производители, Клиенты и Специализации введен атрибут ID, который представляет собой уникальный номер. Для сущности Диспетчеры первичным ключом является уникальный табельный номер диспетчера ТабN.
Сущность Мастера содержит информацию о мастерах на предприятии. Первичным ключом является уникальный табельный номер диспетчера ТабN.
Сущность МаркиАвто содержит информацию о марках и моделях автомобилей. В качестве первичного ключа в этой сущности введен атрибут ID, который представляет собой уникальный номер.
Сущность Авто содержит информацию об автомобилях клиентов. В качестве первичного ключа в этой сущности введен атрибут ID, который представляет собой уникальный номер.
Сущность МатЦенности представляется собой справочник запчастей и расходных материалов, хранящий также данные об их наличии на складе. В качестве первичного ключа в этой сущности введен атрибут Шифр, который представляет собой уникальный номер МЦ.
Сущность Прейскурант представляется собой выполняемых на предприятии работ с указанием нормы времени и стоимости выполнения. В качестве первичного ключа в этой сущности введен атрибут Шифр, который представляет собой уникальный инвентарный номер МЦ.
Сущность Заказы содержит информацию о всех сформированных заказах. В качестве первичного ключа в этой сущности введен атрибут NЗаказа, который представляет собой уникальный номер.
Сущность ЗаказыПоставщику содержит информацию о всех сформированных заказах поставщику. В качестве первичного ключа в этой сущности введен атрибут NЗаказа, который представляет собой уникальный номер.
Атрибуты сущности МатЦенностиПоЗаказу обеспечивают хранение данных о всех МЦ по каждому заказу. Сущность содержит уникальный идентификатор ID.
Атрибуты сущности РаботыПоЗаказу обеспечивают хранение данных о всех работах по каждому заказу. Сущность содержит уникальный идентификатор ID.
Сущность Заявки содержит информацию о всех сформированных заявках на закупку МЦ. В качестве первичного ключа в этой сущности введен атрибут NЗаявки, который представляет собой уникальный номер.
Атрибуты сущности СоставЗаявки обеспечивают хранение данных о всех МЦ по каждой заявке. Сущность содержит уникальный идентификатор ID.
Атрибуты сущности СоставЗаказаПоставщику обеспечивают хранение данных о всех МЦ по каждому заказу поставщику. Сущность содержит уникальный идентификатор ID.
Сущность Счета содержит информацию о всех сформированных счетах. В качестве первичного ключа в этой сущности введен атрибут NСчета, который представляет собой уникальный номер.
Атрибуты сущности СоставСчета обеспечивают хранение данных о каждой позиции каждого счета. Сущность содержит уникальный идентификатор ID.
В сущности Мастера выделен внешний ключ СпециализацияID поле связи с сущностью Специализации.
Сущность Авто содержит внешние ключи КлиентID (поле связи с сущностью Клиенты) и МаркаID (поле связи с сущностью МаркиАвто).
В сущности Заказы выделены внешние ключи:
КлиентID - поле связи с сущностью Клиенты;
МастерID - поле связи с сущностью Мастера;
ДиспетчерID - поле связи с сущностью Диспетчеры.
Сущность МатЦенностиПоЗаказу содержит внешние ключи МЦ_ID (поле связи с сущностью МатЦенности) и NЗаказа (поле связи с сущностью Заказы).
Сущность РаботыПоЗаказу содержит внешние ключи РаботаID (поле связи с сущностью Прейскурант) и NЗаказа (поле связи с сущностью Заказы).
В сущности Счета выделены внешние ключи NЗаказа (поле связи с сущностью Заказы) и ДиспетчерID (поле связи с сущностью Диспетчеры).
В сущности СоставСчета выделен внешний ключ NСчета - поле связи с сущностью Счета.
В сущности СоставЗаявки выделены внешние ключи NЗаявки (поле связи с сущностью Заявки) и МЦ_ID (поле связи с сущностью МатЦенности).
В сущности СоставЗаказаПоставщику выделены внешние ключи NЗаказа (поле связи с сущностью ЗаказыПоставщику) и МЦ_ID (поле связи с сущностью МатЦенности).
Нормализация предусматривает определение требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами. Отношение, в котором на пересечении каждой строки и каждого столбца содержится атомарное (или единственное) значение, находится в 1-й нормальной форме. При этом необходимо, чтобы отношение имело первичный ключ.
Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или больше атрибутов. Отношение с первичным ключом на основе единственного атрибута всегда находится в 2-й нормальной форме. Отношение, которое находится в 1-й нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, зависит только от полного значения ключа и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа, имеет вторую нормальную форму (каждый неключевой атрибут функционально полно зависит от ключа).
Отношение находится в 3-й нормальной форме, если оно представлено в 2-й нормальной форме и не имеет не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа [4].
Разработанная модель находится в 3-й нормальной форме, так как:
атрибуты сущностей являются атомарными;
каждый неключевой атрибут функционально полно зависит от первичного ключа;
в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.
Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей.
ER-диаграмма системы на физическом уровне представлена на рисунке 2.2 Соответствующая схема данных приведена в Приложении В.
Рисунок 2.2 - ER-диаграмма системы на физическом уровне
Физическое описание модели удобнее всего представить в виде таблиц. База данных проекта будет содержать таблицы, названия которых соответствуют именам сущностей инфологической модели. Структура БД описана в таблице 2.1.
Таблица 2.1 Описание таблиц базы данных
Название таблицы |
Поле |
Тип |
Комментарий |
|
ЗаказыПоставщику |
Заказы поставщику |
|||
NЗаказа Дата МОЛ |
Счетчик Дата/время Текстовый [50] |
Первичный ключ |
||
Реквизиты |
Справочник специализаций |
|||
Наименование Адрес Телефоны Реквизиты ИНН КПП ГенДиректор ГлавБух |
Текстовое (100) Текстовое (100) Текстовое (30) Текстовое (100) Текстовое (15) Текстовое (15) Текстовое (30) Текстовое (30) |
Первичный ключ |
||
Производители |
Справочник производителей |
|||
ID Производитель |
Счетчик Текстовый [20] |
Первичный ключ |
||
Специализации |
Справочник специализаций |
|||
ID Специализация |
Счетчик Текстовый [50] |
Первичный ключ |
||
Диспетчеры |
Справочник диспетчеров |
|||
ТабN ФИО |
Счетчик Текстовый [100] |
Первичный ключ |
||
Клиенты |
Справочник клиентов |
|||
ID ФИО NУдостоверения Информация Скидка |
Счетчик Текстовый [100] Текстовый [15] Текстовый [25] Длинное целое |
Первичный ключ |
||
МаркиАвто |
Хранение данных о марках и моделях авто |
|||
ID ПроизводительID Марка |
Счетчик Длинное целое Текстовый [50] |
Первичный ключ |
||
Авто |
Список авто клиентов |
|||
ID КлиентID МаркаID ГодВыпуска NДвигателя Nшасси Nкузова Цвет МощностьДвиг ОбъемДвигателя Паспорт |
Счетчик Длинное целое Длинное целое Длинное целое Текстовый [15] Текстовый [15] Текстовый [10] Текстовый [25] Текстовый [10] Текстовый [10] Текстовый [25] |
Первичный ключ Внешний ключ Внешний ключ |
||
Мастера |
Справочник мастеров |
|||
ID СпециализацияID ФИО |
Счетчик Длинное целое Текстовый [100] |
Первичный ключ Внешний ключ |
||
МатЦенности |
Справочник МЦ (склад) |
|||
Шифр Наименование МаркаID Информация Количество Цена |
Счетчик Текстовый [100] Длинное целое Текстовый [255] Длинное целое Денежный |
Первичный ключ Внешний ключ |
||
Заказы |
Журнал заказов |
|||
NЗаказа Дата КлиентID ДиспетчерID МастерID Сумма |
Счетчик Дата/время Длинное целое Длинное целое Длинное целое Денежный |
Первичный ключ Внешний ключ Внешний ключ Внешний ключ |
||
Прейскурант |
Справочник работ |
|||
Шифр Работа НормаВремени ОплатаЧас |
Счетчик Текстовый [50] Двойное с плавающей точкой Денежный |
Первичный ключ |
||
МатЦенностиПоЗаказу |
Список МЦ по заказу |
|||
ID NЗаказа МЦ_ID Количество Цена |
Счетчик Длинное целое Длинное целое Длинное целое Денежный |
Первичный ключ Внешний ключ Внешний ключ |
||
РаботыПоЗаказу |
Список работ по заказу |
|||
ID NЗаказа РаботаID Дата МастерID Часов ОплатаЧас |
Счетчик Длинное целое Длинное целое Дата/время Длинное целое Одинарное с плавающей точкой Денежный |
Первичный ключ Внешний ключ Внешний ключ Внешний ключ |
||
Счета |
Журнал счетов |
|||
NСчета Дата ЗаказID Сумма ДиспетчерID |
Счетчик Дата/время Длинное целое Денежный Длинное целое |
Первичный ключ Внешний ключ Внешний ключ |
||
СоставСчета |
Список позиций по счетам |
|||
ID NСчета Наименование Количество Цена |
Счетчик Длинное целое Текстовый [255] Одинарное с плавающей точкой Денежный |
Первичный ключ Внешний ключ |
||
Заявки |
Журнал заявок |
|||
NЗаявки Дата |
Счетчик Дата/время |
Первичный ключ |
||
СоставЗаявки |
МЦ по заявкам на закупку |
|||
ID NЗаявки МЦ_ID Количество |
Счетчик Длинное целое Длинное целое Длинное целое |
Первичный ключ Внешний ключ Внешний ключ |
||
СоставЗаказаПоставщику |
МЦ по заказам поставщику |
|||
ID NЗаказа МЦ_ID Количество |
Счетчик Длинное целое Длинное целое Длинное целое |
Первичный ключ Внешний ключ Внешний ключ |
2.2.2 Разработка программного обеспечения
При разработке АИС была использована СУБД Access.
Любая СУБД позволяет выполнять четыре простейшие операции с данными:
добавлять в таблицу одну или несколько записей;
удалять из таблицы одну или несколько записей;
обновлять значения некоторых полей в одной или нескольких записях;
находить одну или несколько записей, удовлетворяющих заданному условию.
Для выполнения этих операций часто используется механизм запросов. Результатом выполнения запросов является либо отобранное по определенным критериям множество записей, либо изменения в таблицах. Запросы к базе формируются на специально созданном для этого языке - языке структурированных запросов (Structured Query Language - SQL).
Еще одна функция СУБД - управление данными. Под управлением данными обычно понимают защиту данных от несанкционированного доступа, поддержку многопользовательского режима работы с данными и обеспечение целостности и согласованности данных.
Access 2000 позволяет организовать удобный и интуитивно понятный интерфейс пользователя для работы с данными с помощью форм. Формами называются настраиваемые диалоговые окна, сохраняемые в базе данных в виде объектов специального типа. Формы используются в приложении для ввода и отображения данных. Формами можно управлять программно с помощью процедур на Visual Basic for Application (VBA). Формы содержат так называемые элементы управления, с помощью которых осуществляется доступ к данным в таблицах. Элементами управления являются текстовые поля для ввода и правки данных, кнопки, флажки, переключатели, списки, надписи, а также рамки объектов для отображения графиков и объектов OLE. Создание форм, содержащих необходимые элементы управления, существенно упрощает процесс ввода данных и позволяет предотвратить ошибки. Формы Access 2000 предоставляют функциональные возможности для выполнения многих задач, которые нельзя выполнить другими средствами, позволяют выполнять проверку корректности данных при вводе, проводить вычисления, обеспечивают доступ к данным в связанных таблицах с помощью подчиненных форм [10].
Для предоставления пользователям необходимой информации на основе существующих данных в Access 2000 предусмотрены отчеты. Отчеты позволяют выбрать из базы данных требуемую пользователям информацию и оформить ее в виде документа, который можно просмотреть и напечатать. Источником данных для отчета может быть таблица или запрос. Кроме того, в отчете могут отображаться вычисленные по исходным данным значения, например итоговые суммы.
Каждый запрос может выполняться сразу несколькими реляционными операциями: соединение разных таблиц, проекцию (отбор нужных полей БД), селекцию (выбор записей по каждому критерию), а также некоторые вычисления. Результат запроса выглядит как таблица и называется набором записей. Набор записей физически не хранится в БД, а создается только на время выполнения запроса.
Перечень форм БД:
1)"Авто";
2)"АРМ_диспетчера";
3)"АРМ_мастера";
4)"АРМ_работника_МТС";
5)"Главная форма";
6)"Диспетчеры";
7)"Журнал_заказ_нарядов";
8)"Журнал_заказов_поставщику";
9)"Журнал_заявок";
10)"Журнал_счетов";
11)"Заказ_поставщику";
12)"Заказ_поставщику_пф";
13)"Заставка";
14)"Заявка_пф";
15)"Клиенты";
16)"МаркиАвто";
17)"Мастера";
18)"МатЦенности";
19)"МатЦенностиПоЗаказу_пф";
20)"Менеджеры";
21)"Прейскурант";
22)"Производители";
23)"РаботыПоЗаказу_пф";
24)"Реквизиты";
25)"СоставЗаказа";
26)"Специализации";
27)"Счет";
25)"Счет_пф".
Текст основных запросов представлен в таблице 2.2.
Таблица 2.2 - Текст запросов
Запрос |
Текст запроса |
Основные функции и назначение |
|
1 |
3 |
4 |
|
Запрос для отчета "Заказ-наряд" |
SELECT Заказы. NЗаказа, Заказы. ДатаПриема, Заказы. ДатаСдачи, Заказы. ДиспетчерID, Клиенты. ФИО, Авто. ГодВыпуска, Авто. NДвигателя, Авто. NКузова, Авто. Цвет, Заказы. Сумма, Реквизиты. Наименование, Реквизиты. Адрес, [Производители]. [Производитель] & " " & [МаркиАвто]. [Марка] AS Авто, Авто. ГосНомер, Авто. VIN, Клиенты. Скидка, Заказы. МастерID FROM Реквизиты, Производители INNER JOIN (МаркиАвто INNER JOIN (Клиенты INNER JOIN (Авто INNER JOIN Заказы ON Авто. ID = Заказы. АвтоID) ON Клиенты. ID = Заказы. КлиентID) ON МаркиАвто. ID = Авто. МаркаID) ON Производители. ID = МаркиАвто. ПроизводительID WHERE ( ( (Заказы. NЗаказа) = [Forms]! [СоставЗаказа]! [NЗаказа])); |
Формирует выборку по выбранному пользователем заказу-наряду для ее использования при построении соответствующего отчета |
|
Запрос для отчета "Прейскурант" |
SELECT Прейскурант. *, [Реквизиты]. [Наименование], [Реквизиты]. [Адрес] FROM Прейскурант, Реквизиты; |
Формирует выборку по прейскуранту работ для ее использования при построении соответствующего отчета |
|
Запрос для отчета "Доверенность" |
SELECT Заказы. *, [Клиенты]. [ФИО] & IIf (IsNull ([Клиенты]. [ИНН]),'',', ИНН ' & [Клиенты]. [ИНН]) & IIf (IsNull ([Клиенты]. [КПП]),'',', КПП ' & [Клиенты]. [КПП]) AS Клиент, [Реквизиты]. [Наименование], [Реквизиты]. [Адрес], Авто. *, [Производители]. [Производитель] & " " & [МаркиАвто]. [Марка] AS Авто, [Клиенты]. [Паспорт] FROM Реквизиты, Производители INNER JOIN (МаркиАвто INNER JOIN (Клиенты INNER JOIN (Авто INNER JOIN Заказы ON [Авто]. [ID] = [Заказы]. [АвтоID]) ON [Клиенты]. [ID] = [Заказы]. [КлиентID]) ON [МаркиАвто]. [ID] = [Авто]. [МаркаID]) ON [Производители]. [ID] = [МаркиАвто]. [ПроизводительID] WHERE ( ( ([Заказы]. [NЗаказа]) = [Forms]! [СоставЗаказа]! [NЗаказа])); |
Формирует выборку по выбранному пользователем заказу-наряду для ее использования при построении отчета "Доверенность", соответствующего выбранному заказу-наряду |
|
Запрос для отчета "Заказ на перемещение" |
SELECT [Заказы]. [NЗаказа], [Заказы]. [ДиспетчерID], [МатЦенности]. [Наименование], [МатЦенности]. [ЕдИзм], [МатЦенностиПоЗаказу]. [Количество] FROM МатЦенности INNER JOIN (Заказы INNER JOIN МатЦенностиПоЗаказу ON [Заказы]. [NЗаказа] = [МатЦенностиПоЗаказу]. [NЗаказа]) ON [МатЦенности]. [Шифр] = [МатЦенностиПоЗаказу]. [МЦ_ID] WHERE ( ( ([Заказы]. [NЗаказа]) = [Forms]! [СоставЗаказа]! [NЗаказа])); |
Формирует выборку по выбранному пользователем заказу-наряду для ее использования при построении отчета "Заказ на перемещение", соответствующего выбранному заказу-наряду |
|
Запрос для отчета "Заказ поставщику" |
SELECT [ЗаказыПоставщику]. [NЗаказа], [ЗаказыПоставщику]. [Дата], [ЗаказыПоставщику]. [МОЛ], [СоставЗаказаПоставщику]. [МЦ_ID], [МатЦенности]. [ЕдИзм], [СоставЗаказаПоставщику]. [Количество], [МатЦенности]. [Наименование] & IIf (IsNull ([Производители]. [Производитель]),''," " & [Производители]. [Производитель]) & IIf (IsNull ([МаркиАвто]. [Марка]),''," " & [МаркиАвто]. [Марка]) AS МЦ FROM Производители RIGHT JOIN (МаркиАвто RIGHT JOIN (МатЦенности INNER JOIN (ЗаказыПоставщику INNER JOIN СоставЗаказаПоставщику ON [ЗаказыПоставщику]. [NЗаказа] = [СоставЗаказаПоставщику]. [NЗаказа]) ON [МатЦенности]. [Шифр] = [СоставЗаказаПоставщику]. [МЦ_ID]) ON [МаркиАвто]. [ID] = [МатЦенности]. [МаркаID]) ON [Производители]. [ID] = [МаркиАвто]. [ПроизводительID] WHERE ( ( ([ЗаказыПоставщику]. [NЗаказа]) = [Forms]! [Заказ_поставщику]! [Шифр])); |
Формирует выборку по выбранному пользователем заказу поставщику для ее использования при построении соответствующего отчета |
|
Запрос для отчета "Материальные ценности на складе" |
SELECT МатЦенности. *, [МатЦенности]. [Наименование] & IIf (IsNull ([Производители]. [Производитель]),''," " & [Производители]. [Производитель]) & IIf (IsNull ([МаркиАвто]. [Марка]),''," " & [МаркиАвто]. [Марка]) AS МЦ FROM Производители RIGHT JOIN (МаркиАвто RIGHT JOIN МатЦенности ON [МаркиАвто]. [ID] = [МатЦенности]. [МаркаID]) ON [Производители]. [ID] = [МаркиАвто]. [ПроизводительID]; |
Формирует выборку по данным о наличии на складе материальных ценностей для ее использования при построении соответствующего отчета |
|
Запрос для отчета "Приемо-сдаточный акт передачи т/с Заказчику" |
SELECT Заказы. *, [Клиенты]. [ФИО] & IIf (IsNull ([Клиенты]. [ИНН]),'',', ИНН ' & [Клиенты]. [ИНН]) & IIf (IsNull ([Клиенты]. [КПП]),'',', КПП ' & [Клиенты]. [КПП]) AS Клиент, [Реквизиты]. [Наименование], [Реквизиты]. [Адрес], Авто. *, [Производители]. [Производитель] & " " & [МаркиАвто]. [Марка] AS Авто FROM Реквизиты, Производители INNER JOIN (МаркиАвто INNER JOIN (Клиенты INNER JOIN (Авто INNER JOIN Заказы ON [Авто]. [ID] = [Заказы]. [АвтоID]) ON [Клиенты]. [ID] = [Заказы]. [КлиентID]) ON [МаркиАвто]. [ID] = [Авто]. [МаркаID]) ON [Производители]. [ID] = [МаркиАвто]. [ПроизводительID] WHERE ( ( ([Заказы]. [NЗаказа]) = [Forms]! [СоставЗаказа]! [NЗаказа])); |
Формирует выборку по выбранному пользователем заказу-наряду для ее использования при построении отчета "Приемо-сдаточный акт передачи т/с Заказчику", соответствующего выбранному заказу-наряду |
|
Запрос для отчета "Приемо-сдаточный акт передачи т/с Исполнителю" |
SELECT Заказы. *, [Клиенты]. [ФИО] & IIf (IsNull ([Клиенты]. [ИНН]),'',', ИНН ' & [Клиенты]. [ИНН]) & IIf (IsNull ([Клиенты]. [КПП]),'',', КПП ' & [Клиенты]. [КПП]) AS Клиент, [Реквизиты]. [Наименование], [Реквизиты]. [Адрес], Авто. *, [Производители]. [Производитель] & " " & [МаркиАвто]. [Марка] AS Авто FROM Реквизиты, Производители INNER JOIN (МаркиАвто INNER JOIN (Клиенты INNER JOIN (Авто INNER JOIN Заказы ON [Авто]. [ID] = [Заказы]. [АвтоID]) ON [Клиенты]. [ID] = [Заказы]. [КлиентID]) ON [МаркиАвто]. [ID] = [Авто]. [МаркаID]) ON [Производители]. [ID] = [МаркиАвто]. [ПроизводительID] WHERE ( ( ([Заказы]. [NЗаказа]) = [Forms]! [СоставЗаказа]! [NЗаказа])); |
Формирует выборку по выбранному пользователем заказу-наряду для ее использования при построении отчета "Приемо-сдаточный акт передачи т/с Исполнителю", соответствующего выбранному заказу-наряду |
|
Запрос для отчета "Заявка" |
SELECT [Заявки]. [NЗаявки], [Заявки]. [Дата], [Заявки]. [ДиспетчерID], [СоставЗаявки]. [МЦ_ID], [СоставЗаявки]. [Количество], [МатЦенности]. [ЕдИзм], [МатЦенности]. [Наименование] & IIf (IsNull ([Производители]. [Производитель]),''," " & [Производители]. [Производитель]) & IIf (IsNull ([МаркиАвто]. [Марка]),''," " & [МаркиАвто]. [Марка]) AS МЦ FROM Производители RIGHT JOIN ( (МаркиАвто RIGHT JOIN МатЦенности ON [МаркиАвто]. [ID] = [МатЦенности]. [МаркаID]) INNER JOIN (Заявки INNER JOIN СоставЗаявки ON [Заявки]. [NЗаявки] = [СоставЗаявки]. [NЗаявки]) ON [МатЦенности]. [Шифр] = [СоставЗаявки]. [МЦ_ID]) ON [Производители]. [ID] = [МаркиАвто]. [ПроизводительID] WHERE ( ( ([Заявки]. [NЗаявки]) = [Forms]! [Заявка]! [Шифр])); |
Формирует выборку по выбранной пользователем заявке для ее использования при построении соответствующего отчета |
|
Запрос для отчета "Отчет о выполненных работах за период" |
SELECT [Мастера]. [ФИО], [Мастера]. [СпециализацияID], [Прейскурант]. [Работа], [Прейскурант]. [Шифр], Sum ([РаботыПоЗаказу]. [Часов]) AS [Sum-Часов], Sum ([Часов] * [РаботыПоЗаказу]. [ОплатаЧас]) AS Сумма, [Мастера]. [ТабN], " (" & [Специализация] & ")" AS Спец FROM Специализации INNER JOIN (Прейскурант INNER JOIN (Мастера INNER JOIN РаботыПоЗаказу ON [Мастера]. [ТабN] = [РаботыПоЗаказу]. [МастерID]) ON [Прейскурант]. [Шифр] = [РаботыПоЗаказу]. [РаботаID]) ON [Специализации]. [ID] = [Мастера]. [СпециализацияID] WHERE ( ( ([РаботыПоЗаказу]. [Дата]) >= [Введите дату начала периода:] And ([РаботыПоЗаказу]. [Дата]) <= [Введите дату конца периода:])) GROUP BY [Мастера]. [ФИО], [Мастера]. [СпециализацияID], [Прейскурант]. [Работа], [Прейскурант]. [Шифр], [Мастера]. [ТабN], " (" & [Специализация] & ")"; |
Формирует выборку по данным о выполненных работах для ее использования при построении отчета "Отчет о выполненных работах за период" |
Схема работы системы представлена в Приложении Г.
2.3 Разработка пользовательского интерфейса
Интерфейс разработанной базы данных можно отнести к стандартному интерфейсу MS Windows. Доступ ко всем экранным формам приложения осуществляется как главной формы приложения, так и из других форм и главного меню программы.
В процессе дипломного проектирования разработана структура пользовательского интерфейса "АРМ диспетчера", "АРМ мастера" и "АРМ сотрудника МТС".
Структура пользовательского интерфейса АИС трехуровневая. На первом уровне расположена "Заставка" и "Главная форма".
На втором уровне расположены следующие экранные формы для выбора групп функций:
1)"АРМ_диспетчера";
2)"АРМ_мастера";
3)"АРМ_работника_МТС";
На третьем уровне расположены остальные формы, отображающиеся на экране в зависимости от выбранного АРМ:
1)"Авто";
2)"Диспетчеры";
3)"Журнал_заказ_нарядов";
4)"Журнал_заказов_поставщику";
5)"Журнал_заявок";
6)"Журнал_счетов";
7)"Заказ_поставщику";
8)"Заказ_поставщику_пф";
9)"Заявка_пф";
10)"Клиенты";
11)"МаркиАвто";
12)"Мастера";
13)"МатЦенности";
14)"МатЦенностиПоЗаказу_пф";
15)"Менеджеры";
16)"Прейскурант";
17)"Производители";
18)"РаботыПоЗаказу_пф";
19)"Реквизиты";
20)"СоставЗаказа";
21)"Специализации";
22)"Счет";
23)"Счет_пф".
Для задания справочников системы предназначена группа окон, вызываемых выбором необходимого пункта меню "Справочники".
Для просмотра журналов заявок, счетов, прихода или расхода необходимо выбрать соответствующий пункт меню "Журналы".
Для регистрации новой заявки, счета, прихода или расхода необходимо выбрать соответствующий пункт меню "Работа".
С определенных форм при необходимости можно задать формирование отчета. Выходные документы представлены в Приложении Е.
Структура пользовательского интерфейса представлена в Приложении Д.
В пользовательском интерфейсе АИС предполагается использование простых форм, представленных в таблице 2.3.
Таблица 2.3 - Сведения о простых экранных формах
№ п/п |
Имя формы |
Назначение формы |
|
1 |
2 |
3 |
|
1 |
Главная форма |
Обеспечивает выбор АРМ пользователя |
|
2 |
Заставка |
Появляется при загрузке АИС, содержит краткую информацию о программе |
|
3 |
АРМ_диспетчера |
Главная форма АРМ диспетчера |
|
4 |
АРМ_мастера |
Главная форма АРМ мастера |
|
5 |
АРМ_работника_МТС |
Главная форма АРМ работника МТС |
|
6 |
Авто |
Просмотр и редактирование данных таблицы "Авто" |
|
7 |
Диспетчеры |
Просмотр и редактирование данных таблицы "Диспетчеры" |
|
8 |
Журнал_заказ_нарядов |
Просмотр и редактирование данных таблицы "Заказы", содержит краткую информацию о зказа-нарядах |
|
9 |
Журнал_заказов_поставщику |
Просмотр и редактирование данных таблицы "Заказы" |
|
10 |
Журнал_заявок |
Просмотр и редактирование данных таблицы "Заявки" |
|
11 |
МаркиАвто |
Просмотр и редактирование данных таблицы "МаркиАвто" |
|
11 |
Журнал_счетов |
Просмотр и редактирование данных таблицы "Счета" |
|
12 |
Клиенты |
Просмотр и редактирование данных таблицы "Клиенты" |
|
13 |
Мастера |
Просмотр и редактирование данных таблицы "Мастера" |
|
14 |
МатЦенности |
Просмотр и редактирование данных таблицы "МатЦенности" |
|
15 |
Менеджеры |
Просмотр и редактирование данных таблицы "Менеджеры" |
|
16 |
Прейскурант |
Просмотр и редактирование данных таблицы "Прейскурант" |
|
17 |
Производители |
Просмотр и редактирование данных таблицы "Производители" |
|
18 |
Реквизиты |
Просмотр и редактирование данных таблицы "Реквизиты" |
|
19 |
Специализации |
Просмотр и редактирование данных таблицы "Специализации" |
В пользовательском интерфейсе также АИС предполагается использование составных форм. Описание составных форм представлено в таблице 2.4.
Таблица 2.4 - Данные о составных формах
№ п\п |
Назначе-ние |
Форма |
Подчиненная форма |
|||
Имя |
Источник данных |
Имя |
Источник данных |
|||
1 |
2 |
3 |
4 |
5 |
6 |
|
1 |
Просмотр, редактирование и добавление данных, печать |
СоставЗаказа |
Таблица "СоставЗаказа" |
МатЦенностиПоЗаказу_пф РаботыПоЗаказу_пф |
Таблица "МатЦенностиПоЗаказу" Таблица "РаботыПоЗаказу_пф" |
|
2 |
Просмотр, редактирование и добавление данных, печать |
ЗаказПоставщику |
Таблица "ЗаказПоставщику" |
Заказ_поставщику_пф |
Таблица "ЗаказПоставщику" |
|
3 |
Просмотр, редактирование и добавление данных, печать |
Счет |
Таблица "Счет" |
Счет_пф |
Таблица "Счет" |
|
4 |
Просмотр, редактирование и добавление данных, печать |
Заявка |
Таблица "Заявка" |
Заявка_пф |
Таблица "Заявка" |
Формы для вывода сообщений об ошибках возникают в связи с нарушением ограничений целостности БД.
Для выделения, группировки элементов управления, данных, форм можно использовать стандартное оформление системы Windows.
В процессе работы будут использоваться следующие принципы организации пользовательского интерфейса:
естественность или интуитивность (отсутствие у пользователя сложностей в поиске необходимых директив или элементов интерфейса для управления процессом решения поставленной задачи);
непротиворечивость;
отсутствие избыточности (должен обеспечиваться ввод минимально необходимого объёма данных для решения производственных задач или управления системой; не должен требоваться повторный ввод данных или ввод вычисляемых данных);
структурирование информации на экране (количество элементов и данных на экране должно быть минимальным; информация на экране должна быть сгруппирована и упорядочена с помощью цветового кодирования, рамок, негативного изображения или других методов привлечения внимания);
выделение элементов интерфейса яркостью и цветом;
стандартизация (однотипные данные должны размещаться в одной и той же области экрана); информация, на которую следует немедленно обратить внимание, должна быть выделена цветом или яркостью, и всегда отображаться в видном месте, чтобы захватить внимание пользователя.
Для уменьшения ошибок при вводе информации в ПЭВМ в некоторых полях базы данных задаются условия на значение. В самом простом случае условие на значение должно гарантировать, что из-за ошибки ввода в числовом поле не окажутся буквенные символы. Другие условия могут определять область или диапазоны допустимых значений. Заданное условие на значение всегда будет проверяться при вводе или изменения значения поля в таблице. Кроме того, для уменьшения ошибок при вводе данных используется маска ввода. Маска ввода удобна при использовании полей, размер и смысловая нагрузка которых заранее известна.
Для взаимодействия с пользователем программы предполагается использование меню, подсказок, полей, отвечающих за ввод информации, а также кнопок, результатом нажатия на которые будет отображение того или иного запроса к базе данных.
2.4 Разработка руководства пользователя
2.4.1 Назначение и условия применения
Данная система позволяет осуществлять ввод, хранение информации, коррекцию данных в БД, реализацию запросов и вывод на экран выходных документов. Управление осуществляется с помощью главной кнопочной формы.
Для работы системы программы необходимы следующие условия:
операционная система Windows xp;
СУБД Microsoft Access 2000;
оперативная память 256 Мб;
принтер формата А4.
2.4.2 Подготовка к работе
Для установки и работы программы предназначена один дистрибутивный диск, которая содержит файл "Авторемонт. mdb", который необходимо переписать в любой каталог на ПЭВМ, выделить и нажать клавишу ENTER, либо дважды щелкнуть на указанный файл, тем самым открыв приложение в Microsoft Access.
2.4.2 Описание работы с программой
При загрузке программы на экран выводится форма "Заставка", на которой отражено название приложения и сведения о разработчике, представленная на рисунке 2.3.
Рисунок 2.3 - Заставка
По истечении пяти секунд форма "Заставка" закрывается и выводится форма "Главная форма", представленная на рисунке 2.4.
Рисунок 2.4 - Главная форма
Программа работает в диалоговом режиме, надписи всех кнопок соответствуют выполняющимся действиям. При нажатии любой кнопки на главной форме открывается форма, соответствующая выбранному АРМ.
Нажатие кнопки "Завершение работы" приведет к закрытию приложения.
После нажатия кнопки "АРМ диспетчера" открывается соответствующая форма, представленная на рисунке 2.5.
Рисунок 2.5 - АРМ диспетчера
После нажатия кнопки "Журнал заказ-нарядов" открывается одноименная форма, представленная на рисунке 2.6.
Данные на форме можно редактировать, а также осуществлять по ним поиск, используя для этого соответствующие кнопки навигации и работы с таблицей.
Рисунок 2.6 - Журнал заказ-нарядов
Для регистрации нового заказа-наряда следует нажать кнопку "Новый заказ", для просмотра существующего кнопку "Состав заказа". После этого откроется форма "Состав заказа", приведенная на рисунке 2.7.
Рисунок 2.7 - Состав заказа
В данной форме следует заполнить все поля, списки материальных ценностей по заказу и работ по заказу. Для выбранного из списка клиента отображается только список его автомобилей. Если регистрируется заказ-наряд для нового клиента, его следует предварительно внести в базу данных на форме, открывающейся при нажатии кнопки "Клиенты". Для получения справки о стоимости работ или услуг, а также материальных ценностей можно нажать соответствующую кнопку на форме "СоставЗаказа", после чего откроется нужная форма. Также эти формы можно загрузить из главной формы АРМ нажатием соответствующих кнопок. Формы "Прейскурант" и "Материальные ценности" приведены на рисунках 2.8 и 2.9 соответственно.
Рисунок 2.8 - Прейскурант
Рисунок 2.9 - Материальные ценности
Для формирования заказа-наряда, приемо-сдаточного акта передачи транспортного средства исполнителю и приемо-сдаточного акта передачи транспортного средства заказчику, доверенности, а также заказа на перемещение МЦ следует нажать соответствующую кнопку на форме "СоставЗаказа".
При нажатии кнопки "Журнал заявок в отдел МТС" на экране появляется форма "Журнал заявок", приведенная на рисунке 2.10.
Рисунок 2.10 - Журнал заявок
Данные на форме можно редактировать, а также осуществлять по ним поиск, используя для этого соответствующие кнопки навигации и работы с таблицей. Для регистрации новой заявки следует нажать кнопку "Новая заявка", для просмотра существующей кнопку "Состав заявки". После этого откроется форма "Заявка", приведенная на рисунке 2.11.
Рисунок 2.11 - Заявка
Для сохранения введенных данных следует нажать кнопку "OK". При добавлении новой заявки можно нажать кнопку "Отмена", после чего все введенные данные удалятся.
Экранная форма АРМ мастера приведена на рисунке 2.12.
Рисунок 2.12 - АРМ мастера
После нажатия кнопки "Журнал заказ-нарядов" открывается одноименная форма, представленная на рисунке 2.6 Для просмотра заказа-наряда следует нажать кнопку "Состав заказа". После этого откроется форма "Состав заказа", приведенная на рисунке 2.7.
При нажатии кнопок "Автомобили" и "Марки автомобилей" открываются одноименные формы, позволяющие редактировать соответствующие справочники базы данных.
Экранная форма АРМ работника службы материально-технического снабжения приведена на рисунке 2.13.
Рисунок 2.13 - АРМ работника службы МТС
При нажатии кнопки "Журнал заявок" открывается одноименная форма, приведенная на рисунке 2.10. По данным на форме можно осуществлять поиск, используя для этого соответствующие кнопки навигации и работы с таблицей. Для регистрации новой заявки следует нажать кнопку "Новая заявка", для просмотра существующей кнопку "Состав заявки". После этого откроется форма "Заявка", приведенная на рисунке 2.11.
При нажатии кнопки "Журнал заказов поставщику" открывается одноименная форма, приведенная на рисунке 2.14.
Данные на форме можно редактировать, а также осуществлять по ним поиск, используя для этого соответствующие кнопки навигации и работы с таблицей.
Для регистрации нового заказа следует нажать кнопку "Новый заказ", для просмотра существующего кнопку "Состав заказа". После этого откроется форма "Заказ", приведенная на рисунке 2.15.
Рисунок 2.14 - Журнал заказов поставщику
Рисунок 2.15 - Заказ поставщику
Для сохранения введенных данных следует нажать кнопку "OK". При добавлении новой заявки можно нажать кнопку "Отмена", после чего все введенные данные удалятся.
3. Оценка экономической эффективности инвестиционного проекта
3.1 Описание продукта информационной технологии
В данном дипломном проекте разработан программный продукт, предназначенный для автоматизации деятельности авторемонтного предприятия.
Цель разработки системы - обеспечение более высокой производительности труда, большей надежности и достоверности информации, лучшей ее сохранности.
Актуальность темы дипломного проекта обуславливается необходимостью снижения временных и денежных затрат на выполнение стандартных рутинных операций. Практическая значимость работы определяется разработкой реального программного средства, служащего для автоматизации деятельности авторемонтного предприятия.
Система обеспечивает:
ведение справочников клиентов, запчастей, автомобилей;
оформление заказов на сервисное обслуживание и ремонт;
контроль сроков выполнения работ мастерами;
определение работ на текущий день для мастера;
четкое планирование работ мастеров в соответствии с инструкциями по сервисным работам и пожеланиями клиентов;
оформление заказа-наряда, исходя из выполненных работ, времени ремонта, использованных запчастей;
оформление приемо-сдаточного акта передачи транспортного средства исполнителю и приемо-сдаточного акта передачи транспортного средства заказчику;
оформление доверенности на проведение технических испытаний транспортного средства;
оформление счета клиенту;
учет наличия запчастей и расходных материалов на складе;
формирование заявок на закупку запчастей и расходных материалов при их недостатке на складе;
оформление заказа на перемещение материальных ценностей;
оформление заказа поставщику;
формирование отчета о выполненных работах за период;
ведение журнала заказов, журнала заявок, журнала счетов.
В успешном завершении проекта и его эффективной эксплуатации заинтересованы все его участники, реализующие таким образом свои индивидуальные интересы, а именно:
заказчик проекта получает проект и доходы от его использования;
руководитель проекта и его команда получают плату по контракту, дополнительное вознаграждение по результатам работы, а также повышение профессионального рейтинга;
органы власти получают налоги со всех участников, а также удовлетворение общественных, социальных и прочих нужд и требований на вверенной им территории.
Правильное понимание экономических аспектов разработки, внедрения и эксплуатации программного продукта позволяют легче преодолеть помехи, связанные с такими внешними и внутренними факторами, характерными для переходного периода в России, как:
нестабильная экономика;
дефицит и ограниченность средств и ресурсов;
инфляция и возрастание стоимости проекта;
социальные проблемы и требования;
возрастающие требования к качеству программной продукции.
Если эти изменения не анализируются и не учитываются, то это приводит к таким негативным результатам, как:
превышение ранее установленной стоимости, продолжительности и сроков завершения проектов;
увеличение штрафов за нарушение обязательств;
отставание в реализации и практическом использовании результатов научных исследований и опытно-конструкторских разработок;
снижение эффективности и увеличение сроков окупаемости проекта.
В создавшихся условиях работа инженера подразумевает не только нахождение прогрессивных решений, но и их технико-экономическое обоснование, доказательство того, что выбранный вариант является наиболее выгодным и экономически эффективным.
Характерной чертой проводимых работ является их теоретическая направленность. В качестве конечного результата проектирования может рассматриваться прототип интеллектуальной системы, демонстрирующий возможность применения теоретических разработок и не предполагающий выход на рынок научно-технической продукции. Таким образом, основными источниками затрат при работе над темой как части этапа проектирования жизненного цикла целенаправленной интеллектуальной системы являются капитальные предпроизводственные затраты, которые в определенной степени могут быть учтены и минимизированы.
При выполнении проекта по информатизации для любого предприятия принципиально важен вопрос об экономической эффективности выполняемых работ. Проблема расчета экономической эффективности упирается в несколько ключевых точек:
заказчик, как правило, достаточно хорошо понимает, что существующая информационная система (или несуществующая) не устраивает его по некоторым параметрам, более того, эти параметры он достаточно четко готов сформулировать для себя, но как только дело доходит до разговора с подрядчиком данная четкость пропадает;
заказчик стремится решить максимальное количество проблем в минимальное время, не придавая значений четкой постановке вопроса о том, что и сколько стоит и в какие сроки может быть выполнено, более того, в какие сроки произойдет возврат вложенных в данный проект средств;
разработчик "не видит" по своей вине или по вине заказчика те ключевые точки, которые принципиально важны для реализации проекта и которые оказывают "видимое" влияние на параметры экономических показателей системы.
Таким образом, для реализации данного дипломного проекта необходимо четко определить, какие параметры и экономические показатели необходимо вывести в экономическое обоснование, для того чтобы показать необходимость проектирования или внедрения, которое также стоит рассматривать как проект информационной системы.
3.2 Расчет затрат на разработку системы
Затраты на разработку АЭИС представляют собой стоимостную оценку использованных в процессе разработки сырья, материалов, покупных комплектующих изделий и полуфабрикатов, расходов на оплату труда разработчиков и других видов расходов.
Затраты на разработку ПС () определяются по формуле:
где - стоимость сырья и материалов;
- стоимость покупных комплектующих и полуфабрикатов;
- основная зарплата разработчиков;
- дополнительная зарплата разработчиков;
- отчисления на социальные нужды;
- прочие прямые расходы;
- накладные расходы.
В расходы по статье "Стоимость сырья, материалов" включается стоимость необходимых вспомогательных материалов для документирования ПС в виде бумаги, канцелярских папок и др.
Стоимость используемых для разработки ПС материалов в общем виде рассчитывается по формуле:
где i - наименование соответствующего вида используемых материалов;
n - количество используемых материалов;
- расход на разработку материалов i-го наименования, руб.;
- цена приобретения i-го наименования;
- коэффициент, учитывающий транспортно-заготовительные расходы при приобретении материалов i-го наименования. Примем Ктi = 1,1.
В расходы по статье "Покупные комплектующие" следует включать стоимость необходимых для разработки покупных комплектующих и полуфабрикатов, необходимых для проведения работ.
Расчет стоимости покупных комплектующих и полуфабрикатов производится по следующей формуле:
где i - наименование покупных изделий;
n - количество видов покупных комплектующих;
- расход на изделие покупных комплектующих i-го наименования, шт;
- цена приобретения покупных комплектующих, руб.;
- коэффициент, учитывающий транспортно-заготовительные расходы при приобретении материалов i-го наименования. Примем .
Стоимость используемых для разработки материалов, а также покупных комплектующих рассчитывается исходя из таблицы 3.1 и составляет 1900 руб.
Таблица 3.1 Материалы
№ п/п |
Наименование материала |
Единица измерения |
Цена за ед., руб. |
Расход на разработку |
Сумма, руб. |
|
1 |
Бумага |
пачка |
100 |
3 |
300 |
|
2 |
Бумага для офсетной печати |
упаковка |
450 |
1 |
450 |
|
3 |
Картридж для принтера |
шт. |
800 |
1 |
800 |
|
4 |
Ручки шариковые |
шт. |
10 |
10 |
100 |
|
5 |
Диск CD-R/RW |
упаковка |
250 |
1 |
250 |
|
Итого |
1900 |
В состав основной заработной платы включаются выплаты за фактически выполненную работу в соответствии с окладами, тарифными ставками и расценками всему персоналу, принимавшему участие в разработке данного объекта. В общем виде основная заработная плата разработчиков программных изделий может быть рассчитана по формуле:
где i - наименование категории разработчиков;
n - количество категорий разработчиков;
- трудоемкость проектных работ, выполненных разработчиком i-й категории;
- часовая тарифная ставка разработчика i - категории.
В разработке программного изделия в условиях дипломного проектирования принимают участие разработчики двух категорий:
консультант (руководитель дипломного проекта);
инженер-программист (дипломник).
Часовую тарифную ставку разработчиков определим по формуле:
(руб. /час),
где - месячный оклад разработчика i-й категории, руб.
Примем месячный оклад инженера-программиста консультанта при месячном фонде времени работы . Тогда:
(руб. /час),
(руб. /час)
Таблица 3.2 Расчет основной заработной платы разработчиков АИС
№ п/п |
Наименование этапа |
Инженер-программист |
Консультант |
Всего по этапу |
|||||
T, час |
L, руб |
Сумма, руб |
T, час |
L, руб |
Сумма, руб |
||||
1 |
Предпроектный анализ задач и формирование требований пользователя |
60 |
89,30 |
5358,00 |
7,5 |
119,04 |
892,8 |
6250,80 |
|
2 |
Разработка концепции создания АИС |
50 |
4465,00 |
3 |
357,12 |
4822,12 |
|||
3 |
Разработка и согласование технического задания и создание АИС |
Подобные документы
Техническое задание на разработку автоматизированной системы и складского учета управления универсальной торговой базы. Проектирование информационной системы и выбор среды для создания программного продукта. Создание интерфейса и руководство пользователя.
дипломная работа [2,1 M], добавлен 11.07.2015Создание автоматизированной системы учета заказов и их выполнения в строительной фирме по ремонту квартир. Общие требования к информационной системе. Проектирование структуры базы данных. Построение ER-диаграммы. Реализация информационной системы.
курсовая работа [750,2 K], добавлен 24.03.2014Цель создания информационной системы. Автоматизированная информационная система "Строительное предприятие". Использование вычислительной техники и программного обеспечения для создания автоматизированной информационной системы управления на предприятии.
курсовая работа [2,5 M], добавлен 04.01.2011Детализация функций системы и требования к информационной системе. Анализ категорий пользователей. Этапы внедрения автоматизированной информационной системы на предприятии. Описание таблиц базы данных. Защита данных от несанкционированного доступа.
дипломная работа [1,0 M], добавлен 22.07.2015Выбор методологии проектирования и разработка информационной системы "Расчёт зарплаты" для предприятия ОАО РТП "Авторемонтник". Архитектурное проектирование базы данных информационной системы и разработка её интерфейса. Тестирование программного модуля.
дипломная работа [2,3 M], добавлен 25.05.2014Создание информационной системы для фирмы "Удача", которая является посредником при перепродаже недвижимости. Обоснование состава вычислительной техники и программного обеспечения для функционирования данной автоматизированной информационной системы.
курсовая работа [1,8 M], добавлен 17.02.2014Исследование системы функционирования зоомагазина "Дракоша" и схематическое описание бизнес-процессов предприятия. Генерация кода и разработка автоматизированной информационной системы магазина на языке программирования С+. Расчет диаграмм автоматизации.
курсовая работа [841,8 K], добавлен 07.08.2013Разработка автоматизированной информационной системы для учета и контроля выполнения ремонтных работ, и предоставления услуг по разработке программного обеспечения компании "МегионСофтОйл", разработка алгоритмов приложений программной системы и модулей.
дипломная работа [5,3 M], добавлен 29.06.2012Определение основных функциональных требований к модулям автоматизированной информационной системы. Разработка концептуальной модели данных. Реализация системы учета объектов интеллектуальной собственности и научно-технической продукции университета.
дипломная работа [5,2 M], добавлен 26.05.2012Предпроектное обследование ООО "ЮГАГРОМАШ". Технические и программные средства ЭИВТ предприятия. Создание логической и физической модели базы данных информационной подсистемы складского учета. Себестоимость автоматизированной информационной системы.
дипломная работа [4,8 M], добавлен 24.06.2011