ВВЕДЕНИЕ
ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1Технико-экономическая характеристика предметной области
1.1.1 Характеристика предприятия
1.1.2 Краткая характеристика подразделения или видов его деятельности
1.2 Экономическая сущность задачи
1.3 Обоснование необходимости и цели использования вычислительной техники для решения задачи
1.4 Постановка задачи
1.4.1 Цель и назначение автоматизированного варианта решения задачи
1.4.2 Общая характеристика организации решения задачи на ЭВМ
1.4.3 Формализация расчетов
1.5 Анализ существующих разработок и обоснование выбора технологии проектирования
1.6 Обоснование проектных решений по видам обеспечения
1.6.1 по техническому обеспечению (ТО)
1.6.2 по информационному обеспечению (ИО)
1.6.3 по программному обеспечению (ПО)
1.6.4 по технологическому обеспечению
ГЛАВА 2. Проектирование АРМ
2.1 Информационное обеспечение задачи (комплекса задач, АРМ)
2.1.1. Концептуальная модель и ее описание
2.1.2 Используемые классификаторы и системы кодирования
2.1.3 Характеристика нормативно-справочной и входной оперативной информации
2.1.4 Характеристика результатной информации
2.2 Программное обеспечение задачи (комплекса задач, АРМ)
2.2.1 Общие положения (дерево функций и сценарий диалога)
ГЛАВА 3. РЕАЛИЗАЦИЯ АРМ
3.1 Реализация базы данных АРМ
3.2 Реализация интерфейса АРМ
3.3 Обоснование экономической эффективности проекта
3.3.1 Расчет показателей экономической эффективности проекта
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
ВВЕДЕНИЕ
Сбор, хранение, поиск, переработка, преобразование, распространение и использование информации в различных сферах деятельности приобретают решающее значение для успеха и конкурентной борьбе. В современный информационный век дня предпринимателей ключевое значение имеет не просто разработка принципиально нового изделия, а создание такого продукта или услуги, которые положили бы начало формированию нового направления в производстве, нового рынка. Только в этом случае предприятие (организация) может рассчитывать на приемлемый уровень издержек производства и снижение степени риска при выходе сначала на национальный, а затем на мировой рынок. Предпринимательское дело среди других направлений на конкурентном рынке выделяется с помощью средств информационной индивидуализации бизнеса.
Общество, осознавая важность знания, обеспечивает возможность его приобретения и использования для всех своих членов. Это делается на основе воспитания, обучения и образования, развития культуры и науки. Поскольку данные области имеют внерыночную природу, то решение проблем в них обеспечивается государственным плановым механизмом выделения ресурсов, а не стихией рынка.
Современный бизнес основывается на основательной информационной поддержке со стороны государства, которое строит информационную инфраструктуру бизнеса в виде традиционной и автоматизированной информационных систем. Государство законодательно объявило информационные ресурсы России национальным достоянием, подлежащим защите наряду с другими ресурсами. Организационно информационные ресурсы функционируют в составе Государственной системы научно-технической информации (ГСНТИ) и Государственной автоматизированной системы научно-технической информации (ГАСНТИ). В составе информационных ресурсов концентрируются значительные потоки отечественной и зарубежной информации, которая в обработанном и удобном видах доступна бизнесу.
Образовательный и научный потенциал общества - единственная реальная возможность для генерации актуальных и коммерчески значимых знаний. Если общество не развивает образование и науку, то у членов общества нет ни возможности, ни стимулов генерировать новые знания и эффективно заниматься предпринимательством и бизнесом.
Целью данного дипломного проекта является разработка автоматизированного рабочего места экономиста - снабженца строительной фирмы для учета договорных операций. Главная задача создания АРМ - ведение планового и оперативного учета хозяйственной деятельности предприятия для выработки управленческих решений и получение оперативно-плановой информации для бухгалтерских отчетов. Для решения поставленной задачи в дипломном проекте необходимо:
1. Исследовать предметную область решаемой задачи.
2. Охарактеризовать строительную фирму.
3. Дать краткую характеристику подразделений предприятия и их деятельности.
4. Определить экономическую сущность задачи.
5. Провести обоснование необходимости и цели использование вычислительной техники для решения задачи.
6. Определить цель и назначение автоматизированного варианта решения задачи.
7. Дать общую характеристику организации решения задачи на ЭВМ.
8. Провести обоснование выбора технологии проектирования.
9. Провести обоснование проектных решений.
10. Представить информационное обеспечение АРМ.
11. Представить программное обеспечение АРМ.
12. Представить технологическое обеспечение решаемой задачи.
13. Обосновать экономическую эффективность проекта.
В результате работы в дипломном проекте проводится проектирование информационной системы учета договоров строительной фирмы с помощью информационных технологий и дана оценка эффективности проектируемой ЭИС с экономической точки зрения.
В первой главе представлен анализ предметной области: изучены функции менеджера – снабженца строительной фирмы, определены возможности реализации и существующего на балансе фирмы вычислительной техники.
Во второй главе отображен процесс проектирования АРМ: созданы все необходимые модели БД и разработан сценарий интерфейса.
В третьей главе описана реализация АРМ.
ГЛАВА 1. АНАЛИ
З ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Технико-экономическая характеристика предметной области
1.1.1 Характеристика предприятия
Строительная фирма ООО «Калуга Строй Водоканал», является предприятием малого бизнеса. Организационно-правовая форма – открытое акционерное общество. Организовано с целью получения прибыли. Основной вид деятельности - строительство, ремонт и обслуживание объектов различного социально-хозяйственного назначения.
Строительная фирма ООО «Калуга Строй Водоканал», предоставляет следующие услуги:
1. Строительство объектов 1 и 2 категории сложности.
2. Отделочные работы фасадов и внутренних помещений.
3. Земляные работы.
4. Фундаментные работы
5. Прокладка наружных инженерных сетей, канализации и водопровода.
6. Кровельные работы.
7. Монтаж металлоконструкций.
8. Электротехнические работы до 1000 КВт.
9. Строительство, ремонт и содержание автомобильных дорог.
10. Оптовая торговля материалами, имеющие отношение к строительной индустрии.
11. Автоперевозки в пределах Российской Федерации.
12. Оказание ремонтно-строительных услуг населению.
13. Услуги генерального подрядчика.
В структуру предприятия входят следующие подразделения рис.1.
Рис.1.Структурная схема ООО «Калуга Строй Водоканал»
1.1.2 Краткая характеристика подразделения или видов его деятельности
Во главе предприятия находится генеральный директор, которому непосредственно подчиняются
1. Бухгалтерия.
2. Сметно-договорной отдел (который на самом деле входит в состав отдела снабжения, так как функции выполняет один человек).
3. Главный инженер.
4. Планово-экономический отдел.
5. Отдел снабжения.
6. Начальники участков.
7. Юрист-консул.
Одной из важнейших экономических задач предприятия является задача учета договоров (функции снабжения), которая решается несколькими подразделениями предприятия. В работе над данной задачей задействован отдел снабжения, а также следующие подразделения:
1. Бухгалтерия.
2. Сметно-договорной отдел.
3. Планово-экономический отдел.
Данные подразделения обеспечивают контроль подготовки и исполнения договоров, маршрутизацию и отслеживание состояние договоров, проводят учет документов, связанных с договорными отношениями, ведет подготовку проектно-сметной документации, учет материалов, готовят акты выполненных работ, приходные накладные, готовят документы оплаты по договору. Подготовку и согласование договора проводит юрист-консул предприятия. Бухгалтерия должна производит своевременные платежи по договору или отслеживать их получение от контрагентов, готовить по факту выполнения работ соответствующие акты, формировать проводки по документам или расходам будущих периодов. Генеральный директор решает вопросы, касающиеся совокупности обязательств предприятия или обязательств перед ним, хода реального выполнения работ по договору, ответственных за выполнения его этапов – ведет управленческий учет.
Рис.2.Схема реализации задач по учету договоров.
На рис.2 представлена схема реализации задач по учету договоров на предприятии ООО «Калуга Строй Водоканал», так как именно договорная система определяет работу отдела снабжения. И даже снабжение заказ и отгрузка материалов и услуг также оформляется в договорной системе.
1.2 Экономическая сущность задачи
Задача снабженца включает в себя все аспекты работы учреждения с хозяйственными договорами. После подписания договора для задач бухгалтерского учета ключевым становится понятие «обязательства», которые могут быть «товарными» или «денежными». Задача снабжения поддерживает все возможные схемы обязательств – бартер, взаимные зачеты, передача обязательств третьим лицам и т.д. На основании обязательств формируются планируемые платежи по договору. На основании платежных документов исполняются платежные обязательства, появляется или корректируется кредитно-дебиторская задолженность, формируются проводки по счетам, товарные документы «закрывают» товарные обязательства. Набор решения бухгалтерских задач позволяет экономисту – снабженцу получать информацию, которая анализируется и позволяет руководству принимать правильные управленческие решения, что приводит к рентабельной работе предприятия. Поэтому разрабатываемая информационная система для АРМ является экономической информационной системой.
1.3 Обоснование необходимости и цели использования вычислительной техники для решения задачи
В строительной фирме ООО «Калуга Строй Водоканал» традиционно используется программное обеспечение MicrosoftOffice и имеет следующие характеристики:
- вся информация находится в текстовых файлах формата Word, таблицах Excel или бумажных носителях;
- отсутствует система защиты от несанкционированного доступа;
- отсутствуют программные механизмы разграничения доступа к информации;
- сбор аналитической информации производится путем анализа информации, хранящейся на бумажных носителях;
- информационные технологии применяются, в основном, для хранения личных данных сотрудников, списков групп строителей и создания аттестационных ведомостей.
Все вышеперечисленные недостатки позволяют сделать вывод о необходимости автоматизации труда экономиста - снабженца. Целью использования вычислительной техники является устранение всех вышеперечисленных недостатков, а так же автоматизация обработки и анализа первичной и промежуточной информации и представление итоговой информации в виде отчетов. Работа экономиста – снабженца планово-экономического отдела – это процесс, происходящий во времени, который можно разделить на последовательные этапы:
- подготовительный этап;
- этап оформления договоров;
- этап формирования справочной информации;
- этап учета договоров;
- этап контроля и выполнения подписанных договоров
- этап создания отчетности.
На каждом этапе происходят информационные процессы, которые сведены в таблицу 1.
Таблица 1. Информационные процессы этапов.
| Этап | Информационные процессы |
| Подготовительный этап | прием сведений о заказчике; определение услуг педоставляемых заказчику |
| Этап оформления документов | Подготовка проектно-сметной документации; оформление договора согласование и подписание договора |
| Этап формирования справочной информации | формирование справочной информации по заказчикам; формирование справочной информации по поставщикам материалов формирование справочной информации по подрядчикам; |
| Этап учета договоров | регистрация договоров с поставщиками, регистрация проектно-сметной документации; регистрация договоров с заказчиками, регистрация проектно-сметной документации; регистрация договоров с подрядчиками, регистрация проектно-сметной документации; |
| Этап контроля и выполнения подписанных договоров | контроль сроков исполнения договорных обязательств; контроль за исполнением платежей по договорам получение аналитической информации по договорным обязательствам |
| Этап создания отчетности. | получение плановой отчетности; получение оперативной отчетности для бухгалтерских операций |
1.4 Постановка задачи
Разработать автоматизированное рабочее место экономиста-снабженца планово-экономического отдела строительной фирмы ООО «Калуга Строй Водоканал». Предусмотреть выполнение следующих функций:
1. Создать базу данных для хранения справочной информации по учету производственно-хозяйственных договоров.
2. Обеспечить автоматизированный ввод информации посредствам экранных форм.
3. Реализовать основные функции экономиста -снабженца планово-экономического отдела строительной фирмы:
- формирование справочной информации,
- ведение учета договоров,
- учет проектно-сметной документации,
- учет выполнения договорных обязательств,
4. Реализовать автоматизированный способ получения оперативной и плановой отчетности.
5. Организовать систему анализа данных.
6. Организовать автоматизированную систему отчетности.
Проектируемая система относится к системам учетно-аналитического типа, работающая в диалоговом режиме.
1.4.1 Цель и назначение автоматизированного варианта решения задачи
Автоматизация управленческой деятельности предполагает формирование электронной системы организации. Билл Гейтс, определяет электронную «нервную систему» любой организации как среду, автоматизирующую исполнение заранее намеченных действий и событий, планирование и учет, позволяющую своевременно реагировать на незапланированные события и изменения ситуации и дающую, таким образом, огромные преимущества в конкуренции и возможность эффективно работать.[4]
Основными целями разработки АРМ могут служить:
- сокращение времени обработки входной информации и получения результатных показателей;
- повышение степени достоверности выходной информации;
- снижение трудоемкости и количества ошибок при решении задачи.
В программе должны быть реализованы следующие функции:
- максимальная автоматизация ввода показателей из первичных документов;
- хранение форм первичных документов;
- хранение и выдача нормативно-справочной информации по запросу пользователя;
- обеспечение целостности хранимой информации.
Выполнение перечисленных функций осуществлено следующим образом:
1. автоматизация ввода, контроля, загрузки данных первичной информации в базу данных с использованием экранных форм:
-окно просмотра и изменения в списках заказчиков;
-окно создания общего списка подрядчиков;
-окно создания общего списка поставщиков материалов;
-окно формирования договоров;
-формирования информации по проектно-сметной документации;
2. ведение условно-постоянной информации, хранящейся в таблицах базы данных:
-редактирование справочных и учетно-оперативных данных;
-добавление учетных записей;
-удалении учетных записей;
3. выдача справочной информации:
- информация по заказчикам
- информация по подрядчикам
4. отчеты на запросы пользователей:
-формирование итоговой отчетности по заказчикам, по подрядчикам, по поставщикам;
-формирование оперативных отчетов для бухгалтерии.
1.4.2 Общая характеристика организации решения задачи на ЭВМ
Информационное обследование профессиональной деятельности является творческим процессом и не имеет жесткого алгоритма поведения. Изучение требований и функций пользователя системы проведено по принципу «от потребностей практики», [3] что позволило не изменять алгоритм работы экономиста, но в достаточной мере автоматизировать и упростить его работу.
Для автоматизации учета в системе предусматривается система формирование справочной информации, которая позволит сформировать справочники:
1. Справочник по заказчикам.
2. Справочник по подрядчикам.
3. Справочник по поставщикам материалов.
4. Справочник по отделу заключения договоров.
Информация в справочники вводится с помощью экранных форм, разработанных для удобства ввода.
Для проведения оперативного учета в разрабатываемом АРМ предусмотрена система запросов, которая реализует следующие функции:
1. Запрос по менеджерам, ведущим договоры.
2. Запрос по подрядчикам.
3. Запрос для анализа данных.
4. Запрос по договорам, заказчикам и сметам.
5. Запрос по количеству договоров, заключенных с подрядчиками.
6. Запрос по менеджерам.
Для получения отчетов используется система создания отчетной документации.
1. Отчет по заказчика, договорам, сметам.
2. Отчет по отделу заключения договоров.
3. Отчет по подрядчикам
4. Отчет по поставщикам материалов.
5. Аналитический отчет по количеству заключенных договоров.
1.4.3 Формализация расчетов
Всю информацию, содержащуюся в базе данных можно разделить на входную, промежуточную и выходную. Входная информация представлена в виде справочников, сгруппированных в таблице 2.
Таблица 2. Справочники входной информации.
| №п/п | Наименование справочника, хранящего входную информацию | Свойства справочника |
| Заказчики | Идентификатор заказчика Наименование Адрес Телефон Индекс ИНН/КПП |
|
| Подрядчик | Идентификатор подрядчика Наименование Адрес Индекс ИНН/КПП |
|
| Поставщики материалов | Идентификатор поставщика Наименование Адрес Индекс ИНН/КПП |
|
| Отдел заключения договоров | Идентификатор отдела ФИО Возраст Домашний телефон |
Промежуточная информация представляет собой процесс регистрации информационных процессов, проходящих во времени, которые перечислены в п.1.3. (таблице 2). Промежуточная информация сведена в таблицу 3 для наглядности понимания.
Таблица 3. Промежуточные функции системы.
| №п/п | Номер этапа | Наименование функции системы | Номер использованного справочника |
| 3 | Формирование справочников | 1-4 | |
| 3-4 | Добавление/удаление учетных записей в справочники | 1-4 | |
| 5 | Учет договоров | 1-4 | |
| 2-5 | Учет проектно-сметной документации | 3 | |
| 4 | Запрос по менеджерам, ведущим договоры. | 3 | |
| 4-6 | Запрос по подрядчикам. | 2 | |
| 4-6 | Запрос для анализа данных. | 2, 4 | |
| 4-6 | Запрос по договорам, заказчикам и сметам | 2, 4 | |
| 6 | Запрос по договорам, заказчикам и сметам | 1, 2, 4 | |
| 6 | Запрос по количеству договоров, заключенных с подрядчиками | 1, 2, 4 | |
| 6 | Запрос по менеджерам | 2, 4 |
В результате обработки полученная в итоге выходная информация представлена в виде отчетов (таблица 4).
Таблица 4. Выходная информация системы.
| №п/п | Номер этапа | Наименование функции системы | Номер использованного справочника | |
| 6 | Отчет по заказчика, договорам, сметам | 2, 4 | ||
| 6 | Отчет по отделу заключения договоров | 1, 2, 4 | ||
| 6 | Отчет по подрядчикам | 1, 2, 4 | ||
| 6 | Отчет по поставщикам материалов | 2, 4 | ||
| 6 | Аналитический отчет по количеству заключенных договоров | 2, 4 | ||
Последовательность обработки входной информации, необходимой для формирования итоговой выходной информации представлена в виде схемы, которая показывает алгоритм обработки информации.
1.5 Анализ существующих разработок и обоснование выбора технологии проектирования
В настоящее время существует достаточно большой набор программных разработок, в состав которых входит подсистема учета договоров. Фирма «1С». Сегодня это бесспорный лидер по известности и тиражу продаж. Прежде всего фирма известна благодаря своему продукту под названием «1С: Бухгалтерия». Существуют базовая и профессиональная разновидности этой программы, а также их различные модификации, предназначенные для использования в локальном и сетевом вариантах.
Фирма «1С» предлагает не только программные средства для автоматизации бухгалтерского учета, но и набор других программных продуктов, таких, как «1С: Электронная почта», «1С: Торговля», «1С: Документооборот», «1С: АФС», «1С: Электронный справочник бухгалтера». Данная фирма выпускает программный продукт для ведения учета договоров, входящий в модуль «1С: Документооборот». Наиболее интересной разработкой является модуль «Учет хозяйственной деятельности» входящий систему комплексной автоматизации банков и предприятий, разработанной фирмой R-styleSoftlab. Подсистема «Учет договоров» предназначена для автоматизации всех аспектов работы кредитного учреждения с хозяйственными договорами. Модуль обеспечивает ввод и хранение, контроль подготовки и исполнения, маршрутизацию и отслеживание состояния таких договоров. Также программа выполняет учет документов, связанных с договорными отношениями, на основании которых осуществляются бухгалтерские операции, — Актов выполненных работ, Приходных накладных, документов оплаты по договору и т.п.
С помощью подсистемы одновременно автоматизируется работа многих служб, у которых разные задачи и разные технологии. Так, в период подготовки и согласования договор является объектом учета для юридической службы. После его подписания хранение информации о нем становится задачей юристов, секретарей или службы делопроизводства — в зависимости от распределения обязанностей в учреждении. Бухгалтерия должна производить своевременные платежи по договору или отслеживать их получение от контрагентов, готовить по факту выполнения работ соответствующие акты, формировать проводки по документам или расходам будущих периодов. У руководства компании тоже могут возникнуть вопросы (касающиеся, скажем, совокупности обязательств предприятия или обязательств перед ним, хода реального выполнения работ по договору, ответственных за выполнение конкретных его этапов) — для этого система включает элементы управленческого учета. Приложение «Учет договоров» полностью автоматизирует процесс договорных отношений (операции по учету, движению, контролю договоров) для предприятий различных форм собственности и видов хозяйственной деятельности, объединив их подразделения вокруг базисного элемента хозяйственных взаимоотношений — договора.
Возможности подсистемы.
В подсистеме «Учет договоров» предусмотрена следующая функциональность:
- ввод и хранение как общей информации по договорам, так и специфических сведений по договорам определенного вида;
- ввод и хранение текста договора, его приложений, дополнительных соглашений и их разных редакций;
- ввод и хранение информации о структуре договора, его субъектах и предмете договора, об обязательствах по договору и их погашениях;
- ввод, хранение и анализ информации об этапах подготовки договора, мониторинг состояния подготовки договора, автоматическое изменение состояния договора при выполнении очередного этапа;
- ввод, хранение и анализ расчетно-денежных, товарно-денежных и товарно-распорядительных документов по договору;
- ввод и хранение информации о схемах бухгалтерского учета по договору (счета, правила формирования проводок);
- мониторинг состояния исполнения договора и автоматическое изменение состояния договора при обработке или подготовке сопутствующих документов;
- ввод условий и проведение расчета экономических санкций по договорам;
- группировка договоров по разным признакам (группам, категориям, центрам затрат и т.д.);
- хранение шаблонов договоров и сопутствующих документов для быстрого ввода однотипных договоров;
- сбор и хранение информации о потребностях подразделений предприятия, объединение полученных заявок и мониторинг их выполнения;
- разделение доступа к информации по договорам среди ответственных исполнителей;
- проведение анализа цен на основе ранее заключенных договоров.
Технологические особенности подсистемы
Схема работы подсистемы «Учет договоров» максимально приближена к привычным, сложившимся в кредитном учреждении технологиям работы с договорами и позволяет снять существенную часть рутинного бремени с банковских работников на каждом из этапов работы с этими документами, что в конечном итоге обеспечивает для банка значительную экономию ресурсов. Перед началом эксплуатации пользователю рекомендуется определить набор наиболее часто используемых типов договоров, которые значительно упростят ввод однотипных документов. Здесь можно указать большую часть их параметров, которые будут автоматически устанавливаться при формировании шаблона договора. Это особенно удобно при обработке повторяющихся договоров или этапов договора, когда они отличаются только датой начала исполнения. Тип договора может содержать сведения о маршруте прохождения договора по подразделениям организации и сотрудникам, которые работают с ним в процессе подготовки и исполнения. Естественно, все установленные по умолчанию параметры договора могут быть откорректированы в период его подготовки. Эти особенности подсистемы обеспечивают максимальную общность, которая подразумевает ведение договоров различного вида, с одной стороны, и простоту ввода самого договора без необходимости указания большого количества ненужных или общепринятых параметров, с другой. Необходимо отметить, что подсистема «Учет договоров» предоставляет пользователю эффективные средства по настройке всех этапов договора «с нуля», без использования заранее подготовленных типов договора. Работу над договором существенно облегчает использование различных справочников, которые можно классифицировать на внутренние, специфические только для приложения «Учет договоров» (например, «Роли участников договора», «Состояния договоров»), и внешние, которые унифицированы для других подсистем комплекса «Учет хозяйственной деятельности банка» («Товары и услуги», «Подразделения», «Сотрудники», «Контрагенты»).
Согласование и подписание договоров
Текст договора обычно формулируется постепенно. Сначала ответственный исполнитель выбирает требуемый шаблон, корректирует его параметры и вводит дополнительную информацию. Затем текст согласуется в соответствии с назначенным маршрутом, который представляет собой список сотрудников банка, чья подпись необходима для утверждения договора в целом. В маршруте также закладывается информация о сроках визирования документа каждым сотрудником, об отказе визировать текст договора, приложения, спецификаций и т.д. При этом для отдельных этапов можно назначать собственные маршруты согласования, что позволяет вести работу над договором параллельно. Когда договор одобрен всеми сотрудниками, указанными в маршруте, он «подписывается в целом», то есть формируется параметр «Дата подписания».
Контроль и выполнение подписанных договоров
После того как договор подписан, на первый план выходят задачи управленческого (контроль обязательств, сроков исполнения и др.) и бухгалтерского учета. Для обеих этих задач ключевым является понятие «обязательство». Гражданский кодекс РФ констатирует, что договор есть всегда набор встречных обязательств нескольких сторон. При этом обязательства могут быть как «товарные» (поставка каких-либо товаров или оказание услуг в определенные сроки и на определенных условиях), так и «денежные» (осуществление оплаты). Приложение «Учет договоров» поддерживает все возможные схемы обязательств — бартер, взаимные зачеты, передача обязательств третьим лицам и т.д. Обязательство содержит информацию о том, к какому из участников договора оно относится, а также сведения о сумме, дате начала действия обязательства. На основании обязательств формируются планируемые платежи по договору — платежный календарь, определяющий, кто из участников договора, когда, кому, сколько и в какой валюте должен платить. Планируемый платеж может производиться по договору в целом, по его этапу, списку этапов, части этапа или по более сложной схеме (предположим, 50 % — по факту закрытия работ на одном этапе и тем же платежом 50 % — предоплата по следующему этапу). Вся эта информация позволяет не просто отслеживать кредиторскую и дебиторскую задолженность по контрагентам, но и получать необходимую аналитику по обязательствам — по датам, договорам, этапам договора, товарным позициям и иным параметрам. Кроме того, когда в организации назначен сотрудник, ответственный за приемку и контроль работ по этапам, примененную в системе схему документооборота очень удобно использовать не только при заключении договора, но и для контроля его выполнения. С этой целью в маршруте договора или этапа вводятся элементы, относящиеся к процессу исполнения. Руководство может в любой момент получить сведения о том, какие договоры или этапы закреплены за определенным сотрудником, какие из них просрочены (т.е. работы не были закрыты вовремя), и иную управленческую информацию. Подсистема «Учет договоров» позволяет вести учет документов, которые подтверждают выполнение установленных в договоре обязательств. Существуют два вида таких документов — «товарные» (Приходные накладные, Акты выполненных работ) и «платежные». Эти документы можно вводить независимо друг от друга, что особенно удобно в том случае, когда с системой работает много людей, а сотрудники, закрывающие Акты выполненных работ или осуществляющие оплату, к самим договорам доступа не имеют. Позже система «привязывает» эти платежи или акты к соответствующим договорам. На основании платежных документов исполняются платежные обязательства, появляется или корректируется кредиторско-дебиторская задолженность, формируются проводки по счетам. Товарные документы «закрывают» товарные обязательства.
Удобство пользовательского интерфейса
Приложение «Учет договоров» поддерживает Windows-интерфейс, что обеспечивает широкие возможности по настройке модуля. Пользователь может самостоятельно решать, какие данные выводить на экран и в каком порядке, менять шрифт и фон, производить различные операции над столбцами — определять их ширину и цвет, скрывать и отображать, менять местами. Все это позволяет создавать наиболее удобные экранные формы.
Несмотря на перечисленные достоинства программных разработок ведущих Российских фирм, необходимо отметить, сто строительные организации имеют свои специфические особенности по учетной деятельности. В связи с этим проще провести разработку интересующего АРМ, так как она будет более дешевой, более приспособленной под конкретный круг решаемых задач, менее дорогой. Специализированная разработка, в рамках данной дипломной работы, также не будет обладать огромной избыточностью.
1.6 Обоснование проектных решений по видам обеспечения
1.6.1 по техническому обеспечению (ТО)
Общую структуру информационной системы можно рассматривать как совокупность обеспечивающих подсистем. Техническое обеспечение – это комплекс технических средств, предназначенных для работы информационной системы АРМ. К настоящему времени сложились две основные формы организации технического обеспечения: централизованная и частично или полностью децентрализованная.[4]
Перспективным подходом в настоящее время считается частично децентрализованный подход, применяя как персональные компьютеры, так и большие электронно-вычислительные машины с использованием распределенных сетей. Разрабатываемая информационная система учета хозяйственных операций будет входить в состав автоматизированного рабочего места экономиста - снабженца по учету договоров строительной фирмы. Под АРМ понимается совокупность инструментальных средств конечного пользователя, включающая техническое и организационно-методическое обеспечение задач его профессиональной деятельности на основе персональной ЭВМ, установленной на его рабочем месте, работающей как автономно, так и в составе вычислительной сети. В настоящее время существует множество программных продуктов, обеспечивающих информационные технологии автоматизации офиса. К ним относятся текстовые процессоры, табличные процессоры, системы управления базами данных, электронная почта, электронный календарь, компьютерные конференции, видеотекст, а также специализированные программы управленческой деятельности: ведение документов, контроль исполнения приказов и т. д.
Изучив предметную область и техническое оснащение представительства, а так же перспективные планы на будущее, был сделан вывод – применение сетевой технологии в данном случае требует существенные финансовые вложения. Существующее техническое оснащение: персональный компьютер класса не ниже PentiumI, принтер марки Canon 100 и отсутствие компьютерных сетей позволяет сделать вывод, что наиболее приемлемой является децентрализованная форма организации технического обеспечения.
1.6.2 По информационному обеспечению (ИО)
В предыдущем пункте дано определение АРМ и сделан выбор по его техническому обеспечению. Но не менее важное место занимает и информационное обеспечение. К информационному обеспечению разрабатываемой системы относятся: входные и выходные документы. Входные документы представляют собой набор справочных сведений, которые заносятся в локальную базу данных посредством специально разработанных форм. Так же к входным документам относится информация о добавлении и изменении свойства номера формы (добавление номера свойства номера) Входной информацией для разрабатываемой системы будет являться информация, получаемая посредством выходных форм.
Работа с информацией происходит посредством экранных форм. Форма – это важнейший визуальный компонент. Формы представляют собой видимые окна WINDOWS и являются основной частью практически любого приложения. В форме размещаются визуальные компоненты образующие интерфейсную часть и системные (не визуальные) компоненты Посредством форм происходит диалог между оператором и АРМ.
При разработке экранных форм использовались разные инструментальные средства, позволяющие ускорить ввод данных, а именно:
- Кнопки.
Для организации более дружественного интерфейса мы снабдили кнопки поясняющими надписями и изображениями, отражающими характер их действия;
- Выпадающие списки
.Этот компонент позволяет отображать значения выпадающего списка, что очень удобно, так как экономит площадь окна приложения, и предоставляет пользователю выбор из имеющихся значений.
- Окна редактирования -
для ввода однострочных текстов;
- Календари.
Этот компонент очень эффективен в применении за счет малого места, занимаемого им на форме. При этом он позволяют вводить дату из выпадающего календаря (по виду напоминают выпадающие списки) и обеспечивает безошибочный с точки зрения синтаксиса ввод дат;
- Таблицы.
Позволяют представлять информацию в удобном, структурированном виде;
- Многостраничные панели
.Позволяют экономить пространство окна на одном и том же месте страницы различного содержания.
Классификатор - это документ, с помощью которого осуществляется формализованное описание экономической информации в АРМ, содержащей наименования объектов, наименование классификационных группировок и их кодовые обозначения. [3]
1.6.3 По программному обеспечению (ПО)
Программное обеспечение – совокупность программ для реализации целей и задач информационной системы АРМ, а также нормального функционирования комплекса технических средств. В состав программного обеспечения входят общесистемные и специальные программные продукты. К общесистемному программному обеспечению относятся комплексы программ, ориентированных на пользователей и предназначенных для типовых задач обработки информации.[4]. Основой любого автоматизированного рабочего места является организация данных, которые подвергаются обработке. В связи с этим необходимо обосновать выбор системы управления базами данных. Наиболее широко используемая для работы под управлением ОС Windows,- СУБД Access.
Access — это система управления базами данных
(СУБД). Под системой управления
понимается комплекс программ, который позволяет не только хранить большие массивы данных в определенном формате, но и обрабатывать их, представляя в удобном для пользователей виде. Access дает возможность также автоматизировать часто выполняемые операции (например, расчет заработной платы, учет материальных ценностей и т.п.). С помощью Access можно не только разрабатывать удобные формы ввода и просмотра данных, но и составлять сложные отчеты.
Access является приложением Windows, а поскольку и Windows и Access разработаны одной фирмой (Microsoft), они очень хорошо взаимодействуют друг с другом. СУБД Access работает под управлением Windows; таким образом, все преимущества Windows доступны в Access, например, вы можете вырезать, копировать и вставлять данные из любого приложения Windows в приложение Access и наоборот.
Access — это реляционная СУБД. Это означает, что с ее помощью можно работать одновременно с несколькими таблицами базы данных. Применение реляционной СУБД помогает упростить структуру данных и таким образом облегчить выполнение работы. Таблицу Access можно связать с данными, хранящимися на другом компьютере или на сервере, а также использовать таблицу, созданную в СУБД Paradox или Dbase. Данные Access очень просто комбинировать с данными Excel.
В СУБД Access предусмотрено много дополнительных сервисных возможностей. Мастера
помогут вам создать таблицы, формы или отчеты из имеющихся заготовок, сделав за вас основную черновую работу. Выражения
используются в Access, например, для проверки допустимости введенного значения. Макросы
позволяют автоматизировать многие процессы без программирования, тогда как встроенный в Accessязык
VBA
(VisualBasicforApplications) — специально разработанный компанией Microsoft диалект языка Basic для использования в приложениях MicrosoftOffice — дает возможность опытному пользователю программировать сложные процедуры обработки данных. Просматривая свою форму или отчет, вы сможете представить, как они будут выглядеть в распечатанном виде. И наконец, используя такие возможности языка программирования С,
как функции и обращения к WindowsAPI (ApplicationProgrammingInterface — интерфейс прикладных программ Windows), можно написать подпрограмму для взаимодействия Access с другими приложениями — источниками данных.
В MicrosoftAccess добавлено множество новых средств, разработанных для облегчения работы в Интернет и создания приложений для Web. Для доступа к сети Интернет и использования преимуществ новых средств необходимы средства просмотра Web, например MicrosoftInternetExplorer, а также модем. Пользователь имеет возможность непосредственно подключаться к узлам MicrosoftWeb из программ Office (в том числе и из Access) с помощью команды Microsoftна Web из пункта меню. При этом можно, например, получить доступ к техническим ресурсам и загрузить общедоступные программы, не прерывая работу с Access.
Система Access содержит набор инструментов для управления базами данных, включающий конструкторы таблиц, форм, запросов и отчетов. Кроме того, Access можно рассматривать и как среду для разработки приложений. Используя макросы для автоматизации задач, вы можете создавать такие же мощные, ориентированные на пользователя приложения, как и приложения, созданные с помощью "полноценных" языков программирования, дополнять их кнопками, меню и диалоговыми окнами.
Справочная система фирмы Microsoft является лучшей среди аналогичных программ как для новичков, так и для опытных пользователей. Access дает возможность использовать контекстно-зависимую справку, для получения которой достаточно нажать правую клавишу мыши. Какие бы вы ни испытывали затруднения при работе с системой, вам поможет появляющаяся на экране справка по интересующей вас теме. Помимо этого справочная система Access имеет удобные и простые в использовании содержание, предметный указатель, систему поиска, журнал хронологии и закладки. В локализованной версии Access компания Microsoft добавила новое средство — Помощник.
Помощник отвечает на вопросы, выдает советы и справки об особенностях используемой программы
Достоинства Access в простоте приобретения, в простоте использования в простоте обслуживания.
Для реализации интерфейса используем Delphi, так как это требование в первую очередь было продиктовано желанием и возможностями заказчика.
Несмотря на то, что есть более прогрессивные ВЗСП, но решение остановится на том, что заказчик имеет на балансе именно это сертифицированное программное обеспечение, но и дальнейшая автоматизация ООО «Калуга Строй Водоканал» будет проводится программистом этой фирмы и его знания также ограничено этими средствами. Этот выбор также обусловлен дальнейшим ведением АРМ.
1.6.4 По технологическому обеспечению
В реальных условиях проектирование – это поиск способа, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений. В настоящее время широкое распространение получила RAD-методология – методология быстрой разработки приложений. Данная методология охватывает все этапы жизненного цикла современных информационных систем.[4]
RAD-технология позволяет при разработке и создании информационной системы применять спиральную модель жизненного цикла информационной системы, т.е. использовать прототипы. Возможность согласования прототипов системы с непосредственным будущим пользователем системы позволяет не терять общей картины проектируемой системы, контролировать требования заказчика и оперативно вносить необходимые корректировки функциональных возможностей системы. Визуальные инструменты RAD позволяют создавать современные пользовательские интерфейсы с минимальным написанием кодов программ.
Программные средства RAD-разработки делятся на универсальные и специализированные. Специализированные средства разработки ориентированы только на создание приложений баз данных и, как правило, привязаны к вполне определенным системам управления баз данных (PowerBuilder фирмы Sybase, VisualFoxPro фирмы Microsoft).[5] Среди универсальных систем визуального программирования наибольшее распространение получили: BorlandDelphi, BorlandC++, VisualBasic, с помощью которых можно разработать приложения практически любого типа, причем программы, разработанные такими средствами в состоянии взаимодействовать практически с любой системой управления базами данных. Возможности таких систем при разработке пользовательского интерфейса слились с созданием прототипов системы. При активном участии пользователя системы, способного корректировать как результаты расчетов, так и собственные требования к системе, сроки изготовления программы сокращаются. Наследованное универсальными системами событийного программирования предполагает описание различных событий различных объектов, установленных на форме-контейнере элементов управления. С помощью событийного программирования можно как обрабатывать информацию, хранящуюся в базе данных, так и создавать, редактировать, модифицировать, удалять объекты баз данных.[5] Как и любая технология, методология RAD имеет ряд своих недостатков и ограничений. Но при разработке относительно небольших систем, разрабатываемых под конкретную организацию, она достаточно эффективна.
ГЛАВА 2. ПРОЕКТ
ИРОВАНИЕ АРМ
2.1 Информационное обеспечение задачи (комплекса задач, АРМ)
2.1.1 Концептуальная модель и ее описание
На этапе анализа необходимо подробное исследование как будущих функциональных возможностей разрабатываемой системы, так и информации, необходимой для их выполнения. Поэтому особое внимание было уделено как полноте информации, так и поиску противоречивой, дублирующей или неиспользуемой информации. Каждая сущность имеет неограниченное количество атрибутов, но, проанализировав требования к системе и осуществив детализацию хранилищ данных, будущую модель можно представить в виде связанных между собой отношениями сущностей. Проведя анализ предметной области путем изучения вышеперечисленной информации, были выявлены следующие внешние сущности:
- Заказчик, лицо желающее получить строительные услуги;
- Подрядчик, лицо предоставляющее строительные услуги;
- Поставщик материалов, лицо, обязующееся поставлять материалы на строительство.
- Договор, документ, регламентирующий отношения между подрядчиком, заказчиком и поставщиком материалов.
- Смета, документ, определяющий стоимость работ по договору.
Накопителями данных являются:
- информация о заказчиках;
- информация о подрядчиках;
- информация о поставщиках материалов;
- информация о договорах;
- информация о проектно-сметной документации
Информационная система разбита на четыре логические подсистемы:
- система формирования и редактирования исходных данных;
- система запросов;
- система формирование отчетов;
- система анализа данных.
Рис. 3. Концептуальная модель
На основе проведения анализа предметной области, концептуальной модели, информационных потоков предприятия можно построить схему потоков данных, где определены основные потоки:
1,4,5 – формирование справочника заказчики;
4,2,6 – формирование справочника поставщики;
3,4,7 – формирование справочника подрядчики;
4,11,9 – формирование данных по договору с заказчиками
Рис.4. Схема потоков данных
12,4,9 – формирование данных по договору с подрядчиками
4,13,9 – формирование данных по договору с поставщиками
4,10 – формирование справочника ответственное лицо
4,11,12,9 – формирование учетных данных по договору с заказчиками
4,12,14,9 - формирование учетных данных по договору с подрядчиками
4,14,13,9 - формирование учетных данных по договору с поставщиками
17,15 – формирование запрос а по менеджерам
16,18,15 -
18,19,20,15 – формирование запроса по суммам договоров подрядчиков
21,19,18,15 – формирование запроса по заказчикам, договорам, сметам;
22,23,24,15 – формирование отчета по заказчикам, договорам, сметем;
25,26 – аналитический отчет
27,28 - отчет по подрядчикам
29,27 - отчет по поставщикам материалов
26,27 - отчет по отелу договоров
Полученная модель данных графически представлена инфологической моделью рис 5.
Рис.5. Инфологическая модель данных
Датологическая модель (рис.6) строится на основе разработанной инфологической модели и наиболее приемлемой для дальнейшей разработки является реляционная модель данных, где вся информация хранится в виде связанных таблиц, что дает возможность более эффективно хранить информацию, сохраняя целостность данных. Между таблицами устанавливаются отношения «один-ко-многим». Это самый распространенный вид отношений в реляционной базе данных.
2.1.2 Используемые классификаторы и системы кодирования
В таблицах базы данных использованы ключевые поля типа счетчик для удобства поиска и формирования необходимых связей между таблицами. Система классификации разрабатываемой ИС представлена в таблице 5.
Рис.6.Датологическая модель
Таблица 5. Система классификации.
Наименование классификатора |
Значность кода | Система кодировани | Система классификации | Вид классификатора |
| Код_Сметы_Зак | 16 | Серийный № | Отсутствует | Локальный |
| Код_Дог_Пос | 16 | Серийный № | Отсутствует | Локальный |
| Код_Дог_Подр | 16 | Серийный № | Отсутствует | Локальный |
| Код_Дог_Постав | 16 | Серийный № | Отсутствует | Локальный |
| Код_Заказчика | 16 | Серийный № | Отсутствует | Локальный |
| Код_Поставщика | 16 | Серийный № | Отсутствует | Локальный |
| Код_Подрядчика | 16 | Серийный № | Отсутствует | Локальный |
| Код_Отд_Догов | 16 | Серийный № | Отсутствует | Локальный |
| Код_Смета_Пост | 16 | Серийный № | Отсутствует | Локальный |
| Код_Смета_Заказ | 16 | Серийный № | Отсутствует | Локальный |
| Код_Смета_Подр | 16 | Серийный № | Отсутствует | Локальный |
| ИНН/КПП | 10 | Комбинир. | Многоаспект | Общероссийс |
| Номер договора | 16 | Серийный № | Отсутствует | Локальный |
| Номер сметы | 16 | Серийный № | Отсутствует | Локальный |
2.1.3 Характеристика нормативно-справочной и входной оперативной информации
Входными данными являются данные для формирования справочной
информации:
1. Данные о заказчике
2. Данные о подрядчике
3. Данные об отделе договоров
4. Данные о поставщ
Информация хранится в таблицах:
1. Таблица заказчики
2. Таблица подрядчики
3. Таблица поставщики
4. Таблица отдел договоров.
Входная информация обновляется в процессе работы программы, могут произойти какие-либо корректировки, которые нельзя предусмотреть, такие как расторжение договора, увольнение работника ведущего договор и т.д.
2.1.4 Характеристика результатной информации
Перечни промежуточных функций и выходных документов представлен в таблицах.
Информация, которая формируется в процессе обработки входных данных, хранится в таблицах:
1. Договор_Заказчик
2. Договор_Подрядчик
3. Договор_Поставщик
4. Смета_Заказчик
5. Смета_Подрядчик
6. Смета_Поставщик
Описание функций, формирующих промежуточную информацию сведены в таблицу 6.
Таблица 6. Функции.
| № п/п | Номер функции | Название использованных таблиц | Название экранных форм |
Заказчик Подрядчик Поставщик |
Формирование окна Договоры, заключенные отделом. | ||
Смета_Заказчик |
Формирование экранной формы Смета_Заказчик | ||
| Смета_Подрядчик | Формирование экранной формы Смета_Подрядчик | ||
| Смета_Поставщик | Формирование экранной формы Смета_Поставщик | ||
Заказчики Договор_Заказчики Смета_Закзчики |
Формирование отчета Заказчики, договора, сметы | ||
| Отдел заключения договоров | Формирование отчета Отдел заключения договоров | ||
Подрядчики Смета_Подрядчики |
Формирование отчета Подрядчики | ||
Поставщики Смета_Поставщики |
Формирование отчета Поставщики материалов |
Структуры таблиц, хранящих информацию из вновь образующих документов, сведены в таблицы 7-16.
Таблица 7. Структура справочника Заказчики.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код заказчика | Счетчик | — | — | Код заказчика |
| Наименование | Текстовый | — | — | Полное название заказчика |
| Адрес | Текстовый | — | — | Адрес заказчика |
| Телефон | Текстовый | — | — | Телефон |
| Индекс | Текстовый | — | — | Почтовый индекс |
| ИНН/КПП | Текстовый | — | — | Индивидуальный идентификатор |
Таблица 8. Структура справочника Подрядчики.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код подрядчика | Счетчик | — | — | Код подрядчика |
| Наименование | Текстовый | — | — | Полное название заказчика |
| Адрес | Текстовый | — | — | Адрес подрядчика |
| Индекс | Текстовый | — | — | Почтовый индекс |
| ИНН/КПП | Текстовый | — | — | Индивидуальный идентификатор |
Таблица 9. Структура справочника Поставщики.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код поставщика | Счетчик | — | — | Код поставщика |
| Наименование | Текстовый | — | — | Полное название поставщика |
| Адрес | Текстовый | — | — | Адрес подрядчика |
| Индекс | Текстовый | — | — | Почтовый индекс |
| ИНН/КПП | Текстовый | — | — | Индивидуальный идентификатор |
Таблица 10. Структура справочника Отдел договоров.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код отдела | Счетчик | — | — | Код ведущего специалиста |
| ФИО | Текстовый | — | — | ФИО специалиста |
| Возраст | Текстовый | — | — | Адрес специалиста |
| Телефон | Текстовый | — | — | телефон |
Таблица 11. Структура таблицы Договор_Заказчик.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код договор_заказчик | Счетчик | — | — | Код договора с заказчиком |
| № договора | Текстовый | — | — | Номер договора |
| Код заказчика | Числовой | — | — | Код заказчика |
| Код отв. отдел | Числовой | — | — | Код специалиста, ведущего договор |
| Сумма | Денежный | — | — | Сумма на которую заключен договор |
Таблица 12. Структура таблицы Договор_Подрядчик.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код договор_Подрядчик | Счетчик | — | — | Код договора с подрядчиком |
| № договора | Текстовый | — | — | Номер договора |
| Код подрядчика | Числовой | — | — | Код подрядчика |
| Код отв. отдел | Числовой | — | — | Код специалиста, ведущего договор |
| Сумма | Денежный | — | — | Сумма на которую заключен договор |
Таблица 13. Структура таблицы Договор_Поставщик.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код договор_Поставщик | Счетчик | — | — | Код договора с поставщиком |
| № договора | Текстовый | — | — | Номер договора |
| Код поставщика | Числовой | — | — | Код поставщика |
| Код отв. отдел | Числовой | — | — | Код специалиста, ведущего договор |
| Сумма | Денежный | — | — | Сумма на которую заключен договор |
Таблица 14. Структура таблицы Смета_Заказчик.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код Смета_Заказчик | Счетчик | — | — | Код сметы |
| № сметы | Тестовый | — | — | Номер сметы |
| № договора | Числовой | Номер договора с заказчиком | ||
| Название | Тестовый | — | — | Название сметы |
| Описание | Тестовый | — | — | Описание, дополнительные сведение |
| Стоимость | Тестовый | — | — | Сумма сметы |
Таблица 15. Структура таблицы Смета_Подрядчик.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код Смета_Подрядчик | Счетчик | — | — | Код сметы |
| № сметы | Тестовый | — | — | Номер сметы |
| № договора | Числовой | Номер договора с подрядчиком | ||
| Название | Тестовый | — | — | Название сметы |
| Описание | Тестовый | — | — | Описание, дополнительные сведение |
| Стоимость | Тестовый | — | — | Сумма сметы |
Таблица 16. Структура таблицы Смета_Поставщик.
| Поле | Тип | Значение | Ограничение | Комментарий |
| Код Смета_Поставщик | Счетчик | — | — | Код сметы |
| № сметы | Тестовый | — | — | Номер сметы |
| № договора | Числовой | Номер договора с поставщиком | ||
| Название | Тестовый | — | — | Название сметы |
| Описание | Тестовый | — | — | Описание, дополнительные сведение |
| Стоимость | Тестовый | — | — | Сумма сметы |
2.2 Программное обеспечение задачи (комплекса задач, АРМ)
2.2.1 Общие положения (дерево функций и сценарий диалога)
Диалог – это процесс обмена информацией между пользователем и программной системой, осуществляемый через интерактивный терминал и по определенным правилам [12]. Общение компьютера и пользователя при работе с информационной системой осуществлено в диалоговом режиме, управляемого программой.
Пользовательский интерфейс построен по технологии WIMP (окна, пиктограммы, мышь, всплывающие и выпадающие меню). Использованы основные элементы графического интерфейса: окна приложения, окна диалога, окна контекстного меню, иерархическое меню, компоненты ввода-вывода, пиктограммы панели инструментов, программные пиктограммы и т.д. Элементы графического интерфейса реализуют как служебные, так и основные функции программы.
Список функций, реализованный в программе, представлен в таблице 17.
Таблица 17. Функции программы.
№ п/п |
Служебные функции | Название окна приложения |
| Ввод исходных данных | Окно формирования справочных данных | |
| Формирование учетных данных | Окно формирование учетных данных | |
| Выбор типа операций экономистом | Меню системы | |
| Изменение, удаление, добавление записей в справочниках | Окно формирования справочных данных | |
| Изменение, удаление, добавление записей учетной информации | Окно формирование учетных данных | |
| Получение данных по запросам | Окно главной формы | |
| Получение отчетной информации | Окно подменю отчеты |
Сценарий диалога представлен в виде структурной схемы, где в виде дерева выявлены действия пользователя при работе с конкретной формой и предоставленные функциональные возможности панели инструментов. Каждая форма имеет иерархическое меню, которое дублирует все возможности пользователя при работе с конкретной формой.
Рис.7. Структура главного меню приложения
ГЛАВА 3. РЕАЛИЗАЦИЯ АРМ
3.1 Реализация базы данных АРМ
Реализацию АРМ менеджера – снабженца начали с реализации базы данных в Access. Формирование таблиц осуществляем по спроектированным схемам.
Реализуем выделенные в проектной части сущности:
После реализации таблиц реализуем схему данных (см. рис. 5) по информационной модели.
3.2 Реализация интерфейса АРМ.
После реализации ядра АРМ, т.е. базы данных приступили к реализации интерфейса. Интерфейс реализуем в ВЗС Delphi.
Пользовательский интерфейс обеспечивает просмотр и редактирование данных, а также управление данными и приложением в целом. Бизнес-логика приложения представляет собой набор реализованных в программе алгоритмов обработки данных. Между приложением и собственно базой данных находится специальное программное обеспечение (ПО), связывающее программу и источник данных и управляющее процессом обмена данными. Это ПО может быть реализовано самыми разнообразными способами, в зависимости от объема базы данных, решаемых системой задач, числа пользователей, способами соединения приложения и базы данных. Промежуточное ПО может быть реализовано как окружение приложения, без которого оно вообще не будет работать, как набор драйверов и динамических библиотек, к которым обращается приложение, может быть интегрировано в само приложение. Наконец, это может быть отдельный удаленный сервер, обслуживающий тысячи приложений. Источник данных представляет собой хранилище данных (саму базу данных) и СУБД, управляющую данными, обеспечивающую целостность и непротиворечивость данных.
В Delphi реализовано достаточно большое число разнообразных технологий доступа к данным. Но последовательность операций при конструировании приложений баз данных остается почти одинаковой. И в работе используются по сути одни и те же компоненты, доработанные для применения с той или иной технологией доступа к данным.
В Репозитории Delphi отсутствует отдельный шаблон для приложения баз данных. Поэтому, как и любое другое приложение Delphi, приложение баз данных начинается с обычной формы. Безусловно, это оправданный подход, т. к. приложение баз данных имеет пользовательский интерфейс. И этот интерфейс создается с использованием стандартных и специализированных визуальных компонентов на обычных формах.
Визуальные компоненты отображения данных расположены на странице Data Controls Палитры компонентов. В большинстве они представляют собой модификации стандартных элементов управления, приспособленных для работы с набором данных. Приложение может содержать произвольное число форм и использовать любой интерфейс (MDI или SDI). Обычно одна форма отвечает за выполнение группы однородных операций, объединенных общим назначением.
В основе любого приложения баз данных лежат наборы данных, которые представляют собой группы записей (их удобно представить в виде таблиц в памяти), переданных из базы данных в приложение для просмотра и редактирования, а также анализа. Каждый набор данных инкапсулирован в специальном компоненте доступа к данным. В VCL Delphi реализован набор базовых классов, поддерживающих функциональность наборов данных, и практически идентичные по составу наборы дочерних компонентов для технологий доступа к данным. Их общий предок — класс TDataSet.
Для обеспечения связи набора данных с визуальными компонентами отображения данных используется специальный компонент TDataSource. Его роль заключается в управлении потоками данных между набором данных и связанными с ним компонентами отображения данных. Этот компонент обеспечивает передачу данных в визуальные компоненты и возврат результатов редактирования в набор данных, отвечает за изменение состояния визуальных компонентов при изменении состояния набора данных, передает сигналы управления от пользователя (визуальных компонентов) в набор данных. Компонент TDataSource расположен на странице Data Access Палитры компонентов.
Таким образом, базовый механизм доступа к данным создается триадой компонентов:
– компоненты, инкапсулирующие набор данных (потомки класса TDataSet);
– компоненты TDataSource;
– визуальные компоненты отображения данных.
В приложении с источником данных или промежуточным программным обеспечением взаимодействует компонент доступа к данным, который инкапсулирует набор данных и обращается к функциям соответствующей технологии доступа к данным для выполнения различных операций. Компонент доступа к данным представляет собой "образ" таблицы базы данных в приложении. Общее число таких компонентов в приложении не ограничено.
С каждым компонентом доступа к данным может быть связан как минимум один компонент TDataSource. В его обязанности входит соединение набора данных с визуальными компонентами отображения данных. Компонент TDataSource обеспечивает передачу в эти компоненты текущих значений полей из набора данных и возврат в него сделанных изменений. Еще одна функция компонента TDataSource заключается в синхронизации поведения компонентов отображения данных с состоянием набора данных. Например, если набор данных не активен, то компонент TDataSource обеспечивает удаление данных из компонентов отображения данных и их перевод в неактивное состояние. Или, если набор данных работает в режиме "только для чтения", то компонент TDataSource обязан передать в компоненты отображения данных запрещение на изменение данных.
С одним компонентом TDataSource могут быть связаны несколько визуальных компонентов отображения данных. Эти компоненты представляют собой модифицированные элементы управления, которые предназначены для показа информации из наборов данных.
При открытии набора данных компонент обеспечивает передачу в набор данных записей из требуемой таблицы БД, которая уже реализована в ACCESS. Курсор набора данных устанавливается на первую запись. Компонент TDataSource организует передачу в компоненты отображения данных значений необходимых полей из текущей записи. При перемещении по записям набора данных текущие значения полей в компонентах отображения данных автоматически обновляются. Для размещения компонентов доступа к данным в приложении баз данных используем специальную "форму" — модуль данных (класс TDataModule). Модуль данных не имеет ничего общего с обычной формой приложения, ведь его непосредственным предком является класс TComponent. В модуле данных можно размещать только невизуальные компоненты. Модуль данных доступен разработчику, как и любой другой модуль проекта, на этапе разработки. Пользователь приложения не может увидеть модуль данных во время выполнения. Для создания модуля данных воспользуемся Репозиторием объектов или главным меню Delphi. Значок модуля данных Data Module расположен на странице New. Класс TDataModule происходит непосредственно от класса TComponent. У него почти полностью отсутствуют свойства и методы-обработчики событий, ведь от платформы для других невизуальных компонентов почти ничего не требуется, хотя потомки модуля данных, работающие в распределенных приложениях, выполняют весьма важную работу. Для создания структуры (модели, диаграммы) данных, с которой работает приложение, воспользовались возможностями, предоставляемыми страницей Diagram Редактора кода. Любой элемент из иерархического дерева компонентов модуля данных можно перенести на страницу диаграммы и задать связи между ними.
При помощи управляющих кнопок задали между элементами диаграммы отношения синхронного просмотра и главный/подчиненный. При этом производится автоматическая настройка свойств соответствующих компонентов. Для обращения компонентов доступа к данным, расположенным в модуле данных, из других модулей проекта включили имя модуля в секцию uses:
Преимуществом размещения компонентов доступа к данным в модуле данных является то, что изменение значения любого свойства проявится сразу же во всех обычных модулях, к которым подключен этот модуль данных. Кроме этого, все обработчики событий этих компонентов, т. е. вся логика работы с данными приложения, собраны в одном месте, что тоже весьма удобно.
Компонент доступа к данным является основой приложения баз данных. На основе выбранной таблицы БД он создает набор данных и позволяет эффективно управлять им. В процессе работы такой компонент тесно взаимодействует с функциями соответствующей технологии доступа к данным. Обычно доступ к функциональности технологии доступа к данным осуществляется через совокупность интерфейсов. Все компоненты доступа к данным являются невизуальными.
При открытии формы выполняется метод обработчик FormShow. В нем набор данных открывается при помощи метода Open.
Для представления данных из одного единственного поля связанного набора данныхиспользуем свойство DataField, которое определяет поле связанного набора данных, отображаемое в компоненте TDataSource.
Особое значение для приложений баз данных играет компонент TOBGrid, который представляет данные в виде таблицы. В столбцах таблицы размещаются поля набора данных, а в строках — записи. Для этого компонента не имеет смысла определять конкретное поле, но можно задать настраиваемый набор колонок, а для каждой из них определить поле набора данных. Таким образом, для каждого визуального компонента отображения данных необходимо выполнить следующие операции:
1. Связать компонент отображения данных и компонент TDataSource. Для этого используем свойство Datasource, которое должно указывать на экземпляр требуемого компонента TDataSource. Один компонент отображения данных можно связать только с одним компонентом TDataSource. Необходимый компонент можно выбрать в списке свойств в Инспекторе объектов.
2. Задать поле данных. Для этого используем свойство DataField типа TFields. В нем необходимо указать имя поля связанного набора данных. После задания свойства Datasource поле можно выбрать из списка. Этот этап применяется только для компонентов, отображающих единственное поле.
Также используем компонент TDBNavigator. Он предназначен для перемещения по записям набора данных.
В качестве инструментов доступа в приложениях Delphi применили технологию Microsoft ActiveX Data Objects (ADO), которая основана на возможностях СОМ, а именно интерфейсов OLE DB.
Технология ADO завоевала популярность у разработчиков, благодаря универсальности — базовый' набор интерфейсов OLE DB имеется в каждой современной операционной системе Microsoft. Поэтому для обеспечения доступа приложения к данным достаточно лишь правильно указать провайдер соединения ADO и затем переносить программу на любой компьютер, где имеется требуемая база данных и, конечно, установленная ADO. В Палитре компонентов Delphi есть страница ADO, содержащая набор компонентов, позволяющих создавать полноценные приложения БД, обращающиеся к данным через ADO. OLE DB представляет собой набор специализированных объектов СОМ, инкапсулирующих стандартные функции обработки данных, и специализированные функции конкретных источников данных и интерфейсов, обеспечивающих передачу данных между объектами. Согласно терминологии ADO, любой источник данных (база данных, электронная таблица, файл) называется хранилищем данных, с которым при помощи провайдера данных взаимодействует приложение. Минимальный набор компонентов приложения может включать объект соединения, объект набора данных, объект процессора запросов. В результате приложение обращается не прямо к источнику данных, а к объекту OLE DB, который "умеет" представить данные (например, из файла электронной почты) в виде таблицы БД или результата выполнения запроса SQL. Такая архитектура позволяет сделать набор объектов и интерфейсов открытым и расширяемым. Набор объектов и соответствующий провайдер может быть создан для любого хранилища данных без внесения изменений в исходную структуру ADO. При этом существенно расширяется само понятие данных — ведь можно разработать набор объектов и интерфейсов и для нетрадиционных табличных данных. Например, это могут быть графические данные геоинформационных систем, древовидные структуры из системных реестров, данные CASE-инструментов и т. д. Так как технология ADO основана на стандартных интерфейсах СОМ, которые являются системным механизмом Windows, это сокращает общий объем работающего программного кода и позволяет распространять приложения БД без вспомогательных программ и библиотек.
Спецификация OLE DB различает следующие типы объектов, которые мы использовали:
– Перечислитель (Enumerator) выполняет поиск источников данных или других перечислителей. Используется для обеспечения функционирования провайдеров ADO.
– Объект-источник данных (Data Source Object) представляет хранилище данных.
– Сессия (Session) объединяет совокупность объектов, обращающихся к одному хранилищу данных.
– Транзакция (Trasaction) инкапсулирует механизм выполнения транзакции.
– Команда (Command) содержит текст команды и обеспечивает ее выполнение. Командой может быть запрос SQL, обращение к таблице БД и т. д.
– Набор рядов (Rowset) представляет собой совокупность строк данных, являющихся результатом выполнения команды ADO.
– Объект-ошибка (Error) содержит информацию об исключительной ситуации.
После реализации основных функций АРМ приступили к реализации следующих отчетов:
В
место старого генератора отчетов в состав Delphi 7 включен продукт Rave Reports 5.0 от фирмы Nevrona. Схема создания и внедрения отчетов в приложения Delphi практически не изменилась. В Rave Reports имеются и глобальный класс отчета, и классы полос, и компоненты преобразования данных. Существенным нововведением можно считать только визуальную среду создания отчетов, что облегчает создание отчетов и делает работу эффективнее. Генератор отчетов Rave Reports является основным средством создания отчетов и его компоненты устанавливаются в Палитре компонентов по умолчанию на странице Rave. Они делятся на следующие функциональные группы:
– Компонент отчета TRvproject, с точки зрения приложения, и есть отчет.
– Компонент управления отчетом TRvSystem обеспечивает работу приложения с отчетом. Взаимодействуя с компонентом отчета, с одной стороны, и сервером отчета Rave Reports, с другой, этот компонент обеспечивает просмотр и печать отчетов.
– Компоненты соединения с источниками данных предназначены для подключения различных источников данных к отчетам.
3.3 Обоснование экономической эффективности проекта
3.3.1. Расчет показателей экономической эффективности проекта
Любой проект автоматизации решения экономической задачи должен быть обоснован расчетом ожидаемой эффективности от его внедрения. Автоматизированное решение направлено на достижение таких целей, как сокращение сроков и затрат на получение и обработку информации, повышение качества результатной информации, что улучшает точность и оперативность принимаемых на основе этой информации решений и т.д.
Таким образом, экономическая эффективность проекта
(формула 3.1.1.) складывается из двух составляющих: косвенного эффекта и прямого эффекта.
Э = Эк
+ Эп
, где Э - экономическая эффективность проекта; (3.1.1.)
Косвенный эффект
характеризуется, в основном, улучшением качественных характеристик, таких как улучшение качества обслуживания клиентов, уменьшение числа рекламаций и т.д. Перечисленные показатели достаточно сложно формализовать, что затрудняет выявление доли косвенного эффекта от автоматизированной обработки данных в общей эффективности, получение которой связано с комплексом мер по улучшению деятельности предприятия. Прямой эффект
легче рассчитать, чем косвенный, так как он отражает сокращение трудовых (формулы 3.1.2.-3.1.4) и стоимостных (формулы 3.1.5-3.1.7) затрат на обработку данных, которые позволяют расчетным путем определить его величину. В связи с вышесказанным, при выявлении экономической эффективности автоматизации работы с клиентами будет рассчитываться прямой эффект (формула 3.1.8). На рассматриваемом предприятии при существующем технологическом процессе операции регистрации клиентов осуществлялись с применением книг регистрации.
Проектируемый вариант разрабатывался с целью автоматизации процесса формирования отчетности. Поэтому, за основу расчета прямого эффекта целесообразно взять сопоставление операций существующего (базового) и внедряемого (проектируемого) вариантов, то есть анализ затрат, необходимых для выполнения всех операций технологического процесса. Прежде чем перейти к рассмотрению порядка расчета прямого эффекта, определим формулы, по которым будут рассчитываться трудовые и стоимостные показатели, характеризующие этот эффект.
К трудовым показателям относятся:
- Абсолютное снижение трудовых затрат
∆T = T0
– T1
, где (3.1.2)
∆T – абсолютное снижение трудовых затрат
T0
– трудовые затраты на обработку информации по базовому варианту
T1
- трудовые затраты на обработку информации по проектируемому варианту
- коэффициент относительного снижения трудовых затрат
KT
= ∆T/T0
, где (3.1.3)
KT
- коэффициент относительного снижения трудовых затрат
∆T - абсолютное снижение трудовых затрат
T0
- трудовые затраты на обработку информации по базовому варианту
- индекс снижения трудовых затрат или повышения производительности труда
ΥT
= T0
/ T1
, где (3.1.4)
ΥT
- индекс снижения трудовых затрат или повышения производительности труда
T0
- трудовые затраты на обработку информации по базовому варианту
T1
- трудовые затраты на обработку информации по проектируемому варианту
К стоимостным показателям относятся:
- абсолютное снижение стоимости затрат
ΔC = C0
– C1
, ΔC - абсолютное снижение стоимостных затрат (3.1.5)
С0
- стоимостные затраты на обработку информации по базовому варианту
С1
- стоимостные затраты на обработку информации по проектируемому варианту
o коэффициент относительного снижения стоимостных затрат
Kc
= ΔC/C0
, где (3.1.6)
Kc
- коэффициент относительного снижения стоимостных затрат
ΔC - абсолютное снижение стоимостных затрат
С0
- стоимостные затраты на обработку информации по базовому варианту
o индекс снижения стоимости затрат
ΥT
= T0
/ T1
, где (3.1.7)
ΥT
- индекс снижения стоимостных затрат
T0
- стоимостные затраты на обработку информации по базовому варианту
T1
- стоимостные затраты на обработку информации по проектируемому варианту
Теперь рассмотрим порядок расчета прямого коэффициента (годовой экономии).
ЭП
= (С0
+ ЕН
* К0
) – (С1
+ ЕН
* К1
), где (3.1.8)
ЭП
– прямой эффект
С0
– текущие стоимостные затраты а базовом эффекте
ЕН
– нормативный коэффициент эффективности капитальных вложений, ниже которого они уже будут нецелесообразны (=0,15)
К0
– капитальные вложения в базовом варианте
С1
– текущие стоимостные затраты проектируемом варианте
К1
– капитальные вложения в проектируемом варианте
В нашем случае при базовом варианте технологии использовались ЭВМ, также были осуществлены затраты на разработку имеющейся в данный момент программы, так что капитальные вложения базового варианта будут отличны от нуля. Капитальные затраты i варианта рассчитываются по формуле 3.1.9
Кi
= Ci
_проектирования
+ Ci
_программирования
+ Ci
_отладки
+ Ci
_внедрения
+ Ci
_покупкиТОиПО
,
где
Кi
– капитальные затраты i-го варианта
Ci
_проектирования
– стоимость проектирования i-го варианта
Ci
_программирования
– стоимость программирования i-го варианта
Ci
_отладки
– стоимость отладки i-го варианта
Ci
_внедрения
– стоимость внедрения i-го варианта
Ci
_покупкиТОиПО
– стоимость технического и программного обеспечения i-го варианта
Стоимость проектирования рассчитывается по формуле 3.1.10
Спроектирования
= Тпроектирования_1
* Смаш. час
+ Тпроектирования_2
* З/Плоператора
* Кчеловек
* (1 + Кнр
), где
Спроектирования
– стоимость проектирования (3.1.10)
Тпроектирования_1
– время использования ЭВМ при проектировании в часах
Смаш. час
– стоимость одного машинного часа
Тпроектирования_2
– время проектирования в месяцах
З/Плоператора
– месячная зарплата оператора
Кчеловек
– количество человек
Кнр
– коэффициент накладных расходов (=0,65)
Стоимость программирования рассчитывается по формуле 3.1.11
Спрограммирования
= Тпрограммирования_1
* Смаш. час
+ Тпрограммирования_2
* З/Плоператора
* Кчеловек
* (1 + Кнр
),
где
Спрограммирования
– стоимость программирования (3.1.11)
Тпрограммирования_1
– время использования ЭВМ при программировании в часах
Смаш. час
– стоимость одного машинного часа
Тпрограммирования_2
– время программирования в месяцах
З/Плоператора
– месячная зарплата оператора
Кчеловек
– количество человек
Кнр
– коэффициент накладных расходов (=0,65)
Стоимость отладки рассчитывается по формуле 3.1.12
Сотладки
= Тотладки_1
* Смаш. час
+ Тотладки_2
* З/Плоператора
* Кчеловек
* (1 + Кнр
), где
Сотладки
– стоимость отладки (3.1.12)
Тотладки_1
– время использования ЭВМ при отладке в часах
Смаш. час
– стоимость одного машинного часа
Тотладке_2
– время отладки в месяцах
З/Плоператора
– месячная зарплата оператора
Кчеловек
– количество человек
Кнр
– коэффициент накладных расходов (=0,65)
Стоимость внедрения рассчитывается по формуле 3.1.13
Свнедрения
= Твнедрения_1
* Смаш. час
+ Твнедрения_2
* З/Плоператора
* Кчеловек
* (1 + Кнр
),
где
Свнедрения
– стоимость внедрения (3.1.13)
Твнедрения_1
– время использования ЭВМ при внедрении в часах
Смаш. час
– стоимость одного машинного часа
Твнедрения_2
– время внедрения в месяцах
З/Плоператора
– месячная зарплата оператора
Кчеловек
– количество человек
Кнр
– коэффициент накладных расходов (=0,65)
Экономическая эффективность капитальных вложений определяется расчетным коэффициентом капитальных вложений (формула 3.1.14), выявляющим целесообразность этих вложений во внедряемый проект, и сроком окупаемости капитальных вложений (формула 3.1.15).
Ер
= 1/Ток
, где (3.1.14)
Ер
– расчетный коэффициент эффективности
Ток
– срок окупаемости затрат на внедрение проекта машинной обработки информации
Желательно, чтобы данный показатель был больше нормативного Ен
Ток
= (К1
– К0
)/ΔС, где (3.1.15)
Ток
– срок окупаемости затрат на внедрение проекта машинной обработки информации
К1
– капитальные вложения в проектируемый вариант
К0
– капитальные вложения в базовый вариант
ΔС – абсолютное снижение стоимостных затрат
Расчетный срок окупаемости должен быть меньше нормативного:
Тн
= 1/Ен
, где (3.1.16)
Тн
– нормативный срок окупаемости проекта
Ен
– нормативный коэффициент эффективности капитальных вложений
Расчет всех перечисленных выше показателей представлен в пункте 3.3.2 дипломного проекта.
| № п/g | Наименование операций технологического процесса решения комплекса задач | Оборудование | Ед. изм. | Объем работы в год | Норма выработки | Трудоем-кость | Средне-часовая зарплата оператора | Часовая норам амортизации | Часоавая стоимость накладных расходов | Стоимость работы оборудова-ния | Стоимостные затраты |
| 1 | Прием сведений о закзчиках | вручную | операция | 15000 | 40 | 375 | 50 | 1,3 | 1,5 | 52,8 | 19800 |
| 2 | Прием сведений о подрядчиках | вручную | операция | 10000 | 40 | 250,00 | 50 | 1,3 | 1,5 | 52,8 | 13200 |
| 4 | Прием сведений о поставщиках | вручную | операция | 20000 | 40 | 500 | 50 | 1,3 | 1,5 | 52,8 | 26400 |
| 6 | Прием сведений о персонале | вручную | операция | 15000 | 40 | 375 | 50 | 1,3 | 1,5 | 52,8 | 19800 |
| 7 | Формирование учетных данных по договорам | вручную | операция | 10000 | 30 | 333,33 | 50 | 1,3 | 1,5 | 52,8 | 17600 |
| 8 | Формирование учетных данных по проектно-сметной документации | вручную,ЭВМ | операция | 10000 | 30 | 333,33 | 80 | 1,3 | 1,5 | 82,8 | 27600 |
| 9 | Поиск записей | вручную | операция | 25000 | 30 | 833,33 | 60 | 1,3 | 1,5 | 62,8 | 52333,33 |
| 10 | Сортировка записей | операция | 15000 | 30 | 500 | 0 | 1,3 | 1,5 | 2,8 | 1400 | |
| 11 | Редактирование записей | вручную | документ | 7000 | 50 | 140 | 60 | 1,3 | 1,5 | 62,8 | 8792 |
| 12 | Отчет по заказчикам,сметам,договорам | вручную,ЭВМ | документ | 3000 | 50 | 60 | 60 | 1,3 | 1,5 | 62,8 | 3768 |
| 13 | Отчет по договорам | вручную,ЭВМ | документ | 3000 | 50 | 60 | 60 | 1,3 | 1,5 | 62,8 | 3768 |
| 14 | Отчет по объектам недвижимости | вручную,ЭВМ | документ | 3000 | 50 | 60 | 60 | 1,3 | 1,5 | 62,8 | 3768 |
| 15 | Анализ данных по договорам | вручную,ЭВМ | документ | 1000 | 50 | 20 | 60 | 1,3 | 1,5 | 62,8 | 1256 |
| 137000 | 530 | 3840 | 690 | 16,9 | 19,5 | 663,6 | 198229,3333 |
| № п/g | Наименование операций технологического процесса решения комплекса задач | Оборудование | Ед. изм. | Объем работы в год | Норма выработки | Трудоем-кость | Средне-часовая зарплата оператора | Часовая норам амортизации | Часоавая стоимость накладных расходов | Стоимость работы оборудова-ния | Стоимостные затраты |
| 1 | Прием сведений о закзчиках | вручную, ЭВМ | операция | 15000 | 80,00 | 187,50 | 30,00 | 1,50 | 1,20 | 32,70 | 6131,25 |
| 2 | Прием сведений о подрядчиках | вручную, ЭВМ | операция | 10000 | 80,00 | 125,00 | 30,00 | 1,50 | 1,20 | 32,70 | 4087,50 |
| 4 | Прием сведений о поставщиках | вручную, ЭВМ | операция | 20000 | 80,00 | 250,00 | 30,00 | 1,50 | 1,20 | 32,70 | 8175,00 |
| 6 | Прием сведений о персонале | вручную, ЭВМ | операция | 15000 | 80,00 | 187,50 | 30,00 | 1,50 | 1,20 | 32,70 | 6131,25 |
| 7 | Формирование учетных данных по договорам | вручную, ЭВМ | операция | 10000 | 50,00 | 200,00 | 30,00 | 1,50 | 1,20 | 32,70 | 6540,00 |
| 8 | Формирование учетных данных по проектно-сметной документации | вручную,ЭВМ | операция | 10000 | 50,00 | 200,00 | 60,00 | 1,50 | 1,20 | 62,70 | 12540,00 |
| 9 | Поиск записей | ЭВМ | операция | 25000 | 50,00 | 500,00 | 20,00 | 1,50 | 1,20 | 22,70 | 11350,00 |
| 10 | Сортировка записей | ЭВМ | операция | 15000 | 100,00 | 150,00 | 20,00 | 1,50 | 1,20 | 0,00 | 0,00 |
| 11 | Редактирование записей | ЭВМ | документ | 7000 | 100,00 | 70,00 | 40,00 | 1,50 | 1,80 | 43,30 | 3031,00 |
| 12 | Отчет по заказчикам,сметам,договорам | ЭВМ | документ | 3000 | 60,00 | 50,00 | 30,00 | 1,50 | 1,80 | 33,30 | 1665,00 |
| 13 | Отчет по договорам | ЭВМ | документ | 3000 | 60,00 | 50,00 | 30,00 | 1,50 | 1,80 | 33,30 | 1665,00 |
| 14 | Отчет по объектам недвижимости | ЭВМ | документ | 3000 | 60,00 | 50,00 | 30,00 | 1,50 | 1,80 | 33,30 | 1665,00 |
| 15 | Анализ данных по договорам | ЭВМ | документ | 1000 | 60,00 | 10,00 | 20,00 | 1,50 | 1,80 | 23,30 | 233,00 |
| 137000 | 910 | 2020 | 400,00 | 19,5 | 18,6 | 392,1 | 62981,00 |
Показатели эффективности от внедрения проекта
| Показатель | Затраты | Абсолютное изменение затрат | Коэффициент изменения затрат | Индекс измене-ния затрат |
|
| Базовый вариант | Проектный вариант | ||||
| Трудоемкость | Т0
|
Т1
|
ΔТ = Т0
– Т1 |
КТ
=ΔТ/Т0 *100% |
YТ
=Т0 /Т1 |
| 3840 | 2020 | 1820 | 47,4% | 1,9 | |
| Стоимость | С0
|
С1
|
ΔС = С0
– С1 |
КТ
=ΔС/С0 *100% |
YС
=С0 /С1 |
| 198229,33 | 135248,33 | 62981 | 31,72% | 1,47 | |
Рис.8. Диаграмма стоимостных затрат
Рис.9. Диаграмма трудовых затрат
Расчет экономической эффективности показывает, что целесообразно внедрять спроектированную информационную систему.
ЗАКЛЮЧЕНИЕ
В результате выполнения дипломного проекта было разработано автоматизированное рабочее место экономиста – снабженца по учету договоров строительной фирмы. Разработанная система относится к системам учетного типа и имеет некоторые признаки аналитической системы. Данная разработка улучшает качество обработки информации, автоматизирует процессы ввода данных, вывода результатов. В процессе разработки информационной системы АРМ были получены следующие результаты:
- проведен анализ предметной области решаемой задачи, в результате которого определены потоки входной, выходной, плановой и оперативно-учетной информации;
- изучена структура предприятия, связь его подразделений между собой, изучены потоки информации, передаваемые от одного подразделения к другому;
- определена цель и назначение автоматизированного варианта решения задачи – снижение себестоимости и трудовых затрат. Это позволит повысить эффективность обслуживания клиентов и составления отчетности по учитываемым операциям;
- проведен анализ существующих разработок и обоснован выбор технологии проектирования; в проекте использовалась методология структурного проектирования;
- проведено обоснование проектных решений по видам обеспечения, в результате которых для реализации проекта была выбрана операционная система WindowsNT, СУБД Access, определена конфигурация компьютера, выбран диалоговый режим работы системы;
- на основе анализа предметной области была построена схема потоков данных, определяющая функции системы АРМ, создана информационная модель системы – разработана концептуальная модель, инфологическая модель, датологическая модель проектируемой СУБД.
- дана характеристика нормативно-справочной, входной оперативной информации и результатной информации;
- разработан сценарий диалога;
- организован сбор, передача, обработка и выдача информации посредством экранных форм, печатных отчетов, запросов;
- произведен расчет экономической эффективности разработанного проекта, результаты расчета представлены таблицами и диаграммами.
В результате произведенных проектных мероприятий в данной работе разработана информационная система, лежащая в основе автоматизированного рабочего места экономиста – снабженца строительной фирмы. Спроектированная ИС относится к информационным системам учетного типа. Эффективность внедрения разработанного проекта подтверждена экономическими расчетами, а практическая ценность подтверждена актом о внедрении.
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
1. В.В. Годин, И.К. Корнеев «Информационное обеспечение управленческой деятельности». Мск. Изд. «Высшая школа», 2001 г.
2. Иванова Г.С.Технология программирования: Учебник для вузов. – 2-е изд., стереотип. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2003. – 320 с: ил. (Сер. Информатика в техническом университете.)
3. В.Н. Петров «Информационные системы» – 688л. Изд. Питер, 2002г.
4. Мшиенин А.И. Теория экономических информационных систем: Учеб. пособие. — М.: Финансы и статистика, 2002.
5. Семенов М.И. и др. Автоматизированные информационные технологии в экономике: Учебник / М.И. Семенов, И.Т. Трубилин, В.М. Лойко, Т.П. Барановская; Под общей ред. И.Т. Трубилина. — М.: Финансы и статистика, 2001.
6. Автоматизация управления предприятием / В.В. Баронов, Г.Н.Калянов, Ю.Н. Попов и др. - М.: Инфра-М, 2000.
7. Алан Р. Саймон. Стратегические технологии баз данных: менеджмент на 2000 год / Пер. с англ и предисл. М.Р. Когаловского. - М.: Финансы и статистика, 1999
8. Вендров A.M. Проектирование программного обеспечения экономических информационных систем: Учебник. - М.: Финансы и статистика, 2000.
9. Дейт К. Дж. Введение в системы баз данных. - 6-е изд. - М., СПб., Киев, Изд. дом Вильяме, 2000.
10. Ефимова О.Л. Технология проектирования и внедрения информационных систем - интегрированная технология ARIS // Реинжиниринг бизнес-процессов предприятий на основе современных информационных технологий: Сб. научных трудов 3-й Российской научно-практической конференции. - М.: МЭСИ, 1999. - С. 215 - 218.
11. Липаев В.В. Системное проектирование сложных программных средств для информационных систем. - М.: Синтег, 1999.
12. http://www.davecentral.com
13. http://www.screenshot.com
14. http://ic.krasu.ru/new/events.php3?parad-20025
15. http://www.elrussia.ru/files/36827/КИС_ВУЗа.html
16. http://rrc.karelia.ru/site/Resources/iias/
17. http://www.tts.esoo.ru/~ospp/IL/econom/il31.doc