Автоматизация системного учета заказов в предприятии ООО "Меркатор".

Содержание
Введение
Глава 1. Анализ и выбор метода решения задачи автоматизации системы учета заказов на предприятии ООО «Меркатор»
1.1. Анализ существующей на предприятии системы учета заказов
1.2. Принципы построения инфологических моделей
1.3. Инфологическая модель задачи автоматизации заказов
1.4. Анализ ключей сущностей проектируемой базы данных
1.5. Выбор методики и технических средств реализации базы данных
Глава 2. Разработка базы данных по учету заказов на ООО «Меркатор» с использованием пакета Microsoft Access
2.1. Процедура проектирования реляционной базы данных
2.2. Разработка и нормализация системы таблиц базы данных
2.3. Разработка форм для обработки информации в базе данных
2.4. Разработка механизма оформления заказов в базе дынных
2.5. Разработка средств анализа в базе данных ООО «Меркатор»
2.6. Разработка системы отчетов базы данных
Глава 3. Оценка надежности и экономической эффективности системы учета заказов на ООО «Меркатор»
3.1. Выбор метода оценки надежности базы данных ООО «Меркатор»
3.2. Расчет надежности системы учета заказов на ООО «Меркатор»
3.3. Оценка экономической эффективности внедрения системы учета заказов на ООО «Меркатор»
4. Контрольный пример решения задачи «Автоматизация системы учета заказов на ООО «Меркатор» г. Ростова-на-Дону»
Заключение
Список использованной литературы

Будем предполагать, что значение функции частоты отказов Z(t) пропорционально числу ошибок, оставшихся в ПС после израсходованного на тестирование времени (:
, (3.2)
где С — некоторая константа; t — время работы ПС без отказа.
Тогда, если время работы ПС без отказа 1 отсчитывается от точки t = 0, а ( остается фиксированным, функция надежности, или вероятность безотказной работы на интервале времени от 0 до t, равна:
; (3.3)
. (3.4)
Из величин, входящих в формулы (3.3) и (3.4), не известны начальное значение ошибок в ПС (ЕT) и коэффициент пропорциональности - С. В процессе тестирования собирается информация о времени и количестве ошибок на каждом прогоне, т.е. общее время тестирования( складывается из времени каждого прогона:
. (3.5)
Предполагая, что интенсивность появления ошибок постоянна и равна (, можно вычислить ее как число ошибок в единицу времени:
, (3.6)
где Аi — количество ошибок на i-м прогоне.
. (3.7)
Имея данные для двух различных моментов тестирования (a и (b, которые выбираются произвольно с учетом требования, чтобы (c((b)<( c((A) можно сопоставить уравнения (3.4) и (3.7) при:
, (3.8)
. (3.9)
Вычисляя отношения (8) и (9), получим:
. (3.10)
Подставив полученную оценку параметров ET, в выражение (3.8), получим оценку для второго неизвестного параметра:
. (3.11)
Получив неизвестные Е( и С, можно рассчитать надежность программы по формуле (3.3).
Модель Lа Раdula является модификацией модели Шумана и ориентирован на использованием в системах, в которых уровень влияния ошибки в одном из модулей на другие модули программного комплекса минимален. По этой модели выполнение последовательности тестов производится в т этапов. Каждый этап заканчивается внесением изменений (исправлений) в программную систему. Возрастающая функция надежности базируется на числе ошибок, обнаруженных в ходе каждого тестового прогона. Надежность системы в течение i-го этапа:
, i = 1,2,3,…, (3.17)
где А—параметр роста; при i ( (.
Эти неизвестные вычисляются путем решения следующих уравнений:
, (3.18)
, (3.19)
где Si. — число тестов; mi, — число отказов во время i-го этапа; т — число этапов; i=1,2, ...,т. Определяемый по этой модели показатель есть надежность системы на i-м этапе:
, i = m+1, m+2 … (3.20)
Преимущество модели заключается в том, что она является прогнозной и, основываясь на данных, полученных в ходе тестирования, дает возможность предсказать вероятность безотказной работы программы на последующих этапах ее выполнения. Как легко видеть, модель Шумана для системы учета заказов ООО «Меркатор» является избыточной, а модель La Padula в полной мере отражает особенности функционирования программного комплекса. Поэтому именно эту модель целесообразно использовать для оценки уровня надежности системы учета заказов ООО «Меркатор».
3.2. Расчет надежности системы учета заказов на ООО «Меркатор»
Для применения метода La Padula, являющегося модификацией метода Шумана, прежде всего необходимо описать саму процедуру тестирования разработанного программного комплекса. Как уже отмечалось выше, нас не будут на этом этапе интересовать возможности заполнения исходных таблиц в базе данных и связанные с этим фактические ошибки. Содержательной частью разработанного программного комплекса является взаимосвязанная система запросов, макросов, пользовательских форм и отчетов – и именно эта среда должна быть подвергнута тестированию и именно здесь следует обнаруживать и устранять ошибки.
Работа пользователя с системой учета заказов начинается с открытия стартовой формы базы данных и в дельнейшем пользователь двигается от задачи к задаче с помощью управляющих кнопок на рабочих формах системы. Опишем графически систему навигации в базе дынных по учету заказов ООО «Меркатор»:
Рисунок 3.1. - Система навигации в базе учета заказов ООО «Меркатор»
Будем считать единичным тестом системы проход по всем возможным маршрутам в описанной системе навигации. Это означает, что будут открыты все формы, выполнены все возможные предлагаемые действия (такие, как редактирование данных, ввод новых данных, удаление записей), сформированы все возможные отчеты. При формировании записей и отчетов будут использоваться единичные данные, т.е. отчет будет формироваться на каждом шаге тестирования только один раз на основе случайным образом вводимых данных (начальная дата, конечная, фамилия и т.п.). При обнаружении на шаге тестирования ошибок перед следующим тестированием ошибки исправляются.
Для определения надежности системы учета заказов на ООО «Меркатор» было реализовано десять шагов тестирования (десять этапов), при этом было выявлено и устранено 48 ошибок различного типа. На каждом этапе тестирования выполнялось по 24 тестовых задания (это соответствует общему возможному количеству шагов в системе навигации). По типам ошибки распределились следующим образом:
Таблица 3.1. - Ошибки программы по категориям и частоты их появления
Тип ошибки
Количество ошибок Частота появления ошибки
Ошибки вычислений 5 0,10 Логические ошибки 11 0,23 Ошибки ввода-вывода 8 0,17 Ошибки манипулирования данными 9 0,19 Ошибки сопряжения 8 0,17 Ошибки определения данных 4 0,08 Ошибки в БД 3 0,06 ВСЕГО 48 1  Таким образом, в основном при разработке программного комплекса были допущены логические ошибки (в основном, неверная организация запросов), а также существенную долю ошибок составили некорректности при организации ввода и вывода данных (17%, в основном из-за неверного указания формата вводимых данных), ошибки сопряжения (опять же в основном при организации сложных запросов) и ошибки манипулирования данными в работе макросов.
По этапам тестирования обнаруженные ошибки распределились следующим образом:
1-ый этап: 9 ошибок
2-ой этап: 9 ошибок
3-ий этап: 8 ошибок
4-ый этап: 9 ошибок
5-ой этап: 6 ошибок
6-ий этап: 3 ошибок
7-ый этап: 2 ошибок
8-ой этап: 1 ошибок
9-ий этап: 1 ошибок
10-ый этап: 0 ошибок
Как отмечалось выше, для количественной оценки надежности был выбран метод La Padula, так как он позволяет вычислить прогнозное значение надежности. Для расчета надежности с помощью математического пакета MathCAD был реализован алгоритм Процедура обработки объявления (Processing). Количественный расчет имеет следующий вид:
Si - число тестов на этапе; mi - число отказов на i-ом этапе;
m - число этапов; Rf - предельное значение надежности;
A - параметр роста; R(i)=Rf-A/i - надежность на i-ом этапе.
m:=10;
;
А: =1
Given
Rf=0.9846
A=0.485

Были получены следующие расчетные контрольные значения:
Шаг тестирования i 1 5 10 20 50 100 надежность 0,461 0,849 0,8975 0,92175 0,9363 0,94115
График надежности представлен на рисунке 3.2.
Рисунок 3.2. - График надежности
Из графика видно, что в процессе проведенных тестов прогнозируемое значение надежности приближается к 1. Отметим, что, начав тесты после исправления найденных ошибок, мы, пользуясь данным алгоритмом, получим для Rf значение, еще более близкое к единице. Поэтому можно считать, что разработанный программный комплекс обеспечивает высокую (близкую к 1) надежность хранения и обработки данных, программные сбои в его работе следует считать маловероятными.
3.3. Оценка экономической эффективности внедрения системы учета заказов на ООО «Меркатор»
В завершение работы дадим оценку экономической эффективности внедрения на ООО «Меркатор» единой системы учета заказов. При этом эффект от применения новых информационных технологий может быть как прямым, поддающимся прямому счету, так и косвенным, не поддающимся прямому счету и выявляемому опосредствовано.
При внедрении на ООО «Меркатор» единой системы учета заказов система документооборота предприятия претерпела существенные изменения. Основными из них являются следующие:
-- документооборот на предприятии теперь осуществляется на единой информационной базе, доступной всем заинтересованным лицам. Информация в базе данных является унифицированной, она оформляется единообразно для всех структурных подразделений фирмы.
-- значительно возросла скорость документооборота. Как отмечалось в первой главе, обработка запросов (формирование заказа, выписка счета, обновление списка товарных позиций и т.п.) до внедрения единой системы учета заказов могла занимать до нескольких суток. Теперь любой запрос выполняется в течение нескольких минут.
-- снизились затраты живого труда менеджеров и бухгалтерских работников на организацию документооборота – большинство запросов и отчетов выполняются простым введением исходных данных запроса и нажатием кнопки. Отпала необходимость в рутинной работе по набору различного рода документов, в переводе данных из одного электронного формата в другой.
-- руководство фирмы получило возможность формирования аналитических данных различного типа в режиме реального времени, без отвлечения сотрудников ООО для решения этих задач.
-- определены ответственные лица, несущие персональную ответственность за своевременность ввода и достоверность информационных записей в базе данных.
Можно констатировать, что внедрение единой электронной системы учета на ООО «Меркатор» качественно изменило систему документооборота, сделало её более гибкой, оперативной и точной. Однако дать количественную экономическую оценку многим из этих факторов затруднительно. Поэтому выделим те факторы использования новой системы учета заказов, которые имеют явный количественный способ оценки. Фактически таких факторов три – возросшая скорость документооборота, снижение количества фактических ошибок и неточностей при оформлении документации и снижение затрат живого труда сотрудников.
Рассмотрим сначала такой фактор, как снижение затрат живого труда. Будем предполагать, что количество поступающих заявок и заказов на фирме является постоянным, не зависящим от используемой системы организации документооборота. Для обслуживания поступающих заявок сотрудники фирмы должны выполнить определенное количество элементарных действий. В соответствии с описанной в Главе 1 схемой работы ООО «Меркатор» к таким элементарным действиям относятся:
-- принятие и оформление поступившего заказа
-- согласование заказа (проверка наличия товаров на складе, проверка возможности заказа товаров у поставщиков)
-- оформление товаров на склад
-- оформление (при необходимости) заказа на продукцию у поставщиков
-- выставление счета покупателям
-- контроль оплаты выставленных счетов
До внедрения единой системы учета заказов данные действия выполнялись каждым подразделением самостоятельно, на основе данных, предоставляемых другими службами фирмы. Поэтому данные действия включали в себя довольно много рутинной ручной работы по вводу текстов и численных данных, выполнению арифметических операций и т.п. Единая система учета заказов позволяет заинтересованным пользователям совершать все вышеперечисленные элементарные действия просто путем выполнения запроса в базе данных – база данных ООО «Меркатор» как раз и разрабатывалась с целью унификации и автоматизации этих действий. Наблюдения за работой сотрудников и снимки рабочего времени позволяют сравнить затраты времени на совершение элементарных запросов до и после внедрения электронной системы учета заказов.
Таблица 3.2. - Затраты времени на формирование документации
Запрос Кол-во в месяц Время на обработку в отчетном году, мин Время на обработку после внедрения БД, мин Экономия живого труда за год, час принятие и оформление поступившего заказа 1860 12 6 2232 согласование заказа 870 15 10 870 оформление товаров на склад 66 10 6 53 оформление заказа на продукцию у поставщиков 48 25 10 144 выставление счета покупателям 1620 8 2 1944 контроль оплаты выставленных счетов 1620 6 2 1296 ИТОГО за год 73008 11982 5443,2 6539 Таким образом, внедрение единой системы учета заказов на ООО «Меркатор» позволяет сократить затраты живого труда за год на 6539 час. С учетом общей численности сотрудников, выполняющих работы по обслуживанию и контролю заказов (сотрудники отдела продаж, менеджеры склада и сотрудники бухгалтерии), в 18 человек, общий фонд рабочего их времени составляет (средняя продолжительность рабочего дня принимается 7,8 часа, среднее количество рабочих дней в году 264) 18*7,8*264=37065 часов в год. Следовательно, экономия живого труда составит 17,64%. После внедрения компьютерной системы учета заказов сотрудники смогут меньше времени тратить на рутинные операции оформления и обработки документации, более эффективно заниматься своими непосредственными обязанностями: ведением переговоров с клиентами и поставщиками, аналитической работе и др. При необходимости также возможно сокращение численности работников и их перепрофилирование.
По данным бухгалтерии, совокупная заработная плата сотрудников отдела продаж, бухгалтерии и складских работников за отчетный 2007 год составила 2678,4 тыс. руб. Следовательно, экономия в денежном выражении за счет сокращения затрат живого труда при внедрении системы учета заказов на ООО «Меркатор» в плановом году составит 472,4 тыс. руб.
Для получения аналитических данных администрацией предприятия в отчетном году было сформировано сотрудниками бухгалтерии и администрации ООО 24 аналитических документа разного уровня сложности. При выполнении работ по формированию этих документов сотрудник бухгалтерии или администрации отвлекался полностью на 1 день. Следовательно, затраты живого труда на данный вид работ составляют 24 рабочих дня – фактически один человек-месяц. После внедрения системы учета административные работники могут формировать требуемые отчеты самостоятельно, в рабочем режиме. Время на их формирование можно считать незначительным. Экономия живого труда составит в денежном выражении 12,5 руб. Важно также отметить. Что теперь данные отчеты можно формировать хоть ежедневно, по мере обновления информации в базе данных, что может значительно повысить уровень аналитической работы администрации фирмы.
Количественная оценка возможна также и для такого фактора, как сокращение времени обслуживания клиентов. Из предыдущих данных видно, что происходит сокращение времени на совершение элементарных запросов сотрудниками. Однако важно подчеркнуть, что в отчетном году наблюдался значительный временной разрыв (до нескольких суток) между возникновением потребности в результатах запроса и его фактическим составлением, поскольку был затруднен обмен данными между различными структурными подразделениями фирмы.
На первый взгляд, нет прямой связи между оперативностью выполнения запросов и финансовыми показателями работы фирмы. Однако наблюдения за прохождением заказов показывают прямую зависимость между скоростью оформления и согласования заказа и выставления счета клиенту и процентом оплаченных счетов. Зачастую клиент при недостаточно быстро оформленном заказе просто «уходит», отказываясь от покупки. Особенно это касается новых клиентов, впервые обращающихся на фирму. Как следствие, возможны потери многих перспективных деловых контактов.
Приведем наблюдения бухгалтерии, характеризующие зависимость между скоростью выставления счета (выставление счета подразумевает уже оформленный и согласованный заказ) и процентом оплаченных счетов. Бухгалтерия проводила выборочный анализ, всего было обработано более 2000 поступивших на фирму заявок. Такое количество обработанных данных гарантирует высокий уровень достоверности.
Таблица 3.3. - Процент оплаченных счетов и время их выставления
Время выставления счета после поступления заявки Процент выставленных счетов Процент оплаченных счетов До 6 часов 30 90 От 6 до 12 часов 20 85 От 12 часов до суток 25 85 От суток до трех 15 70 Свыше трех суток 10 50 Всего за отчетный год поступило 22320 запросов, из которых было впоследствии поставлено и оплачено 14560 заказов на общую сумму 24,4 млн.руб. 7760 заявок не дошло до стадии оплаты и выполнения. Средняя стоимость одного выполненного заказа составляет 1675 руб. После внедрения автоматизированной системы учета следует ожидать, что от поступления запроса до оформления счета должно пройти не более 12 часов. Будем считать для определенности, что 50% счетов будут выставляться в период до 6 часов, а остальные – в период до 12 часов. Это означает, при сохранении текущей динамики поступления заявок, что в плановом году будет выставлено клиентам 11160 счетов в период до 6 часов и 11160 счетов в период от 6 до 12 часов. Соответственно, будет оплачено 10044 счета и 9486 счетов – всего 19530 счетов. Неоплаченными останутся 2790 счетов – вместо 7760 счетов в отчетном году. Следовательно, фирма отгрузит клиентам дополнительно товаров на сумму (7760-2790)*1675=8324,75 тыс. руб. При сложившемся уровне торговой наценки в 10% фирма получит от дополнительно реализованных товаров балансовую прибыль в размере 756,8 тыс. руб.
Итак, в результате внедрения базы данных по учету заказов ООО «Меркатор» получит 756,8 тыс. руб. балансовой прибыли за счет увеличения товарооборота и добьется экономии живого труда сотрудников в размере 472,4 тыс. руб. Совокупный экономический эффект Эс составит 1229,2 тыс. руб.в плановом году. Косвенные эффекты внедрения системы учета, не получившие количественной оценки, в данном расчете не учитываются.
Затраты на создание и поддержку базы данных по учету заказов на ООО «Меркатор» складываются из следующих статей:
-- затраты К1 на проектирование, разработку и отладку программного обеспечения базы данных составляют 3 человек-месяца, что составляет в денежном выражении 60 тыс. руб. при средней зарплате программиста 20 тыс. в месяц. (с учетом социальных начислений)
-- затраты К2 на формирование информационной базы данных составляют 3 человеко-месяца, что составит 45 тыс. руб. при средней зарплате оператора 15 тыс. руб. в месяц (с учетом социальных начислений)
-- затраты К3 на поддержание работоспособности сети базы данных определяются необходимостью введения штатной должности системного администратора. Заработная плата за год составит 120 тыс. руб. (с учетом социальных начислений).
-- ожидаемые затраты К4 по текущему технологическому обслуживанию локальной вычислительной сети, связанные с увеличением рабочей нагрузки на оборудование. Будем предполагать, что интенсивность использования компьютерной техники возрастет в два раза и в том же отношении возрастут текущие технологические расходы, в отчетном 2007 г. составлявшие 240 тыс. руб. Следовательно, можно считать, что К4 = 240 тыс. руб.
Затраты К3 и К4 относятся к категории текущих и при осуществлении дальнейших расчетов должны вычитаться из рассчитанного выше совокупного экономического эффекта.
Других вложений в реализацию проекта не требуется, поскольку ООО «Меркатор» в полной мере обеспечено компьютерами, соединенными в скоростную локальную сеть. Таким образом, совокупные затраты на проект в плановом году составят 225 тыс. руб.
Срок окупаемости (Ток) капитальных вложений на создание базы данных определяется как:
Ток = Кабд / (Эс –К3 –К4) = К1+К2/Эс =105/ (1229,2-120-240)= 0,12 года,
что составляет полтора месяца.
Для оценки целесообразности внедрения информационного проекта следует задаться уровнем граничного значения Егр для коэффициента эффективности капитальных вложений. При сроке службы разработанного программного продукта (в связи с моральным устареванием) этот коэффициент равен 0,33.
Внедрение базы данных будет эффективно, поскольку расчетный коэффициент эффективности капитальных вложений (Ер) будет больше выбранного его граничного значения (Егр):
Ер = (Эс –К3 –К4) / Кабд = 1 / Ток =7,7 ( Егр =0,33.
Следовательно, мероприятие по внедрению базы данных учета заказов на ООО «Меркатор» следует признать экономически целесообразным и эффективным.
4. Контрольный пример решения задачи «Автоматизация системы учета заказов на ООО «Меркатор» г. Ростова-на-Дону»
Теперь проведем решение группы задач средствами разработанной в работе системы учета заказов на ООО «Меркатор». На момент решения контрольного примера таблица Сотрудники содержала исчерпывающие о сотрудниках предприятия, всего 22 записи, таблица Товары содержала данные о 77 товарных позициях, таблица Поставщики содержала данные о 29 фирмах – поставщиках продукции, таблица Клиенты содержала 91 запись об основных покупателях товаров фирмы, а таблица Заказы содержала 830 записей о заказах, осуществленных в период между февралем 2005 г. и маем 2007 года. Фактически на момент решения контрольного примера база данных содержала 4% всех записей о заказах за данный период.
Требуется получить на основании уже внесенных в базу данных записей исчерпывающие данные по следующим позициям:
Общую сумму продаж за 2006 год
Количество продаж и их общий объем за 1-ый квартал 2006 г.
Количество и объем продаж с 10.02.2007 по 30.04.2007 г.
Количество и объем продаж с 10.02.2007 по 30.04.2007 г., выполненных менеджером Ясеневой М.А.
Вывести все сделки за истекший 2007 год, сумма каждой из которых превышает 75000 руб.
Вывести телефоны клиентов, начинающихся на букву П.
Полный объем данных по поставленным тестовым заданиям в удобной для обозрения форме может быть получена только в форме отчетов, пригодных для вывода на принтер. Для того, чтобы получить необходимые отчеты, выполним следующую последовательность действий:
- откроем программный комплекс db_Меркатор.mdb
- войдем в базу данных ООО «Меркатор»
- выберем функцию «Печать отчетов»
После указанных действий будет открыта форма Отчеты о продажах. Она имеет вид:
Рисунок 4.1. Форма для обработки контрольных заданий
Чтобы получить общую сумму продаж за 2006 год, откроем для просмотра отчет Суммы продаж по годам. В результате полученный отчет занимает одну страницу и имеет вид, представленный в Приложении Б на рисунке Б.1.
Мы видим, что в 2006 году было совершено 412 продаж на общую сумму 6230463,98 руб.
Для того, чтобы с помощью разработанного программного комплекса дать ответ о количестве продаж и их общем объеме за 1-ый квартал 2006 г., мы также можем воспользоваться тем же отчетом: легко видеть, что в заданном периоде было совершено 95 продаж на сумму 1345726,25 руб.
Тот же результат может быть получен с помощью построения отчета Суммы продаж по кварталам. Соответствующий отчет вынесен в Приложение Б в качестве рисунка Б.2.
Установим теперь количество и объем продаж с 10.02.2007 по 30.04.2007 г. Для решения этой задачи сформируем отчет Продажи по сотрудникам. При выборе этого отчета программа предложит ввести начальную и конечную даты анализа. Итоговый отчет займет 8 листов, на нём будут представлены объемы продаж по сотрудникам за указанный временной интервал. Итоговые данные выводятся в конце отчета. В нашем случае общий объем продаж составит 2971370,4 руб.
Этот же отчет позволяет получить данные о продажах по отдельным сотрудникам. В частности, для менеджера Ясеневой М.А. сведения выводятся также на 8 странице отчета. Мы видим, что за период с 10.02.2007 по 30.04.2007 г. менеджером Ясеневой М.А. было выполнено 13 заказов (их номера: 10889, 10893, 10905, 10942, 10951, 10953, 10963, 10970,10978, 11016, 11017, 11022, 11058) на общую сумму 337706,1 руб., что является для менеджера оптимальным результатом.
Итоги продаж по объему за истекший 2007 год получим, выбрав отчет Итоги продаж по объему за 2007 год. Предварительно в запросе Сумма продаж погодам установим значение фильтра 75000, что позволит отсечь все заказы с меньшими суммами. Скриншот отчета имеет вид, представленный на рисунке Б.4 Приложения Б.
Мы видим, что общая сумма заказов, имеющих стоимость свыше 75000 руб., составила всего 963295,85руб., таких заказов за 2007 год было размещено восемь.
Наконец, решим последний контрольный пример - Вывести телефоны клиентов, начинающихся на букву П. Для этого откроем форму Телефоны Клиентов и выберем вкладку с буквой П. Получим данные, выведенные в виде формы, по 6 организациям – клиентам. Соответствующий скриншот вынесен в качестве рисунка Б.5 Приложения Б.
Заключение
Использование баз данных и информационных систем становится неотъемлемой составляющей деловой деятельности современного человека и функционирования преуспевающих организаций. В связи с этим большую актуальность приобретает освоение принципа построения и эффективного применения соответствующих технологий и программных продуктов.
Цель информационной системы - обработка данных об объектах реального мира. Создавая базу данных, разработчик стремится упорядочить информацию по различным признакам и быстро извлекать выборку с произвольным сочетанием признаков. Это возможно сделать, если данные надлежащим образом структурированы. Обязательными атрибутами современной базы данных являются тщательно проработанные инфологическая и датологическая модели рабочей среды.
В ходе выполнения данной дипломной работы были решены следующие задачи:
-- проведен анализ системы документооборота на ООО «Меркатор»;
-- построена инфологическая модель процесса учета и контроля заказов;
-- разработана даталогическая модель системы учета заказов на предприятии с использованием средств Microsoft Access;
-- выполнена программно завершенная разработка программного комплекса учета и контроля заказов средств Microsoft Access, включающая полный набор форм и отчетов, необходимых для организации эффективной работы сотрудников ООО «Меркатор»;
-- проведен анализ надежности созданного программного продукта;
-- поведена оценка экономической эффективности мероприятий по внедрению на фирме разработанного программного комплекса.
Анализ надежности, проведенный с использованием динамического метода анализа La Padula, показал, что ожидаемая на момент завершения отладочных работ надежность комплекса составляет 0,9846, а при увеличении количества шагов тестирования-отладки надежность асимптотически приближается к 1. Учитывая высокую, приближающуюся к абсолютной, надежность лежащей в основе разработки среды программирования баз данных Microsoft Access, следует признать, что разработанный программный комплекс является в целом надежным, вероятность возникновения сбоев и ошибок в работе является допустимо малой величиной.
Проведенный в работе анализ экономической эффективности показал, что внедрение разработанного программного комплекса в эксплуатацию является экономически обоснованным и целесообразным. Срок окупаемости проекта невелик, всего чуть более полутора месяцев, а совокупный экономический эффект с учетом дополнительных текущих затрат на обслуживание системы в плановом году должен составить 869,2 тыс. руб.
При выполнении тестовых заданий были получены корректные результаты расчетов с использованием базы данных, содержащих сведения о 830 заказах за 2005-07 гг. (т.е. при обработке 4% заказов фирмы за отчетный период).
Таким образом, поставленные перед дипломным проектом задачи выполнены полностью, а цель дипломного проектирования достигнута.
Следующим этапом автоматизации работ на ООО «Меркатор» должно стать проектирование и разработка системы учета выполнения заказов. Эта база данных должна интегрировать сведения, предоставляемые бухгалтерией ООО и службой доставки заказов, а также данные о вносимых в заказы корректировках и дополнениях. Такая база данных должна стать естественным дополнением для системы учета заказов. Ввиду различного функционального назначения, система контроля выполнения заказов на фирме должна сначала быть разработана независимо от системы учета заказов, а впоследствии обе системы следует интегрировать в единую систему автоматизации работы предприятия.
Список использованной литературы
1. ГОСТ 2.105-95. Единая система конструкторской документации. Общие требования.- Взамен ГОСТ 2.105-79, ГОСТ 2.906-71. Введ. 1.07.96.-М.: ИПК Издательство стандартов, 1996.-36с.
2. ГОСТ 19.791-90 (ИСО 5807-85). Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.- Взамен ГОСТ 19.002-80, ГОСТ 19.003-80. Введ. 1.01.92.- М.: ИПК Издательство стандартов, 1991.-26с.
3. Автоматизированные системы обработки учетно-аналитической информации: Учебник В.С. Рожнов, В.Б. Либерман, Э.А. Умнова и др./ под ред. проф. В.С. Рожнова. - М.: Финансы и статистика, 2002.-252с.
4. Антипов Д. В., Соколов А. В. Базы данных. Москва,Игфра-М, 2002.
5. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 2003. – 320 с.
6. Балабанов И.Т. Основы финансового менеджмента: Учеб. пособие.-М.: Финансы и статистика, 2002 - 340 с.
7. Благодатских В.А. Экономика, разработка и использование программного обеспечения ЭВМ: Учебник.-М.: Финансы и статистика, 1999. – 288с.
8. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1999. – 351 с.
9. Вейскас Д. Эффективная работа с Access. СПб., BHV, 2004г, 320 с.
10. Гласс Р. Руководство по надежному программированию: Пер. с англ. –М.: Финансы и статистика, 2002. - 280 с.
11. Григоренко Г.П., Данелян Т.Я. Системы автоматизированной обработки экономической информации (САОЭИ): Учебное пособие/Моск. эконом. - стат. ин-т. - М.,1996-126с.
12. Гурвиц Г. А. Разработка приложения в среде клиент-сервер, ДВГУПС 2005, 204 с.
13. Джексон Г. Проектирование реляционных баз данных. - М.: Мир, 2001, 440 с.
14. Дуванов А. А. «Конструирование баз данных». СПб, BHV, 2003г.
15. Иванцов И.А., Тестирование и диагностика локальных сетей, Сети и системы связи, 2(44), 2004
16. Информационные системы в экономике: Учебник/Под ред. проф. В.В. Дика. - М. Финансы и статистика,2003 - 180 с..
17. Карминский А.М., Нестеров П.В. Информатика в современном бизнесе.- М.: Финансы и статистика, 2002- 228 с..
18. Кириллов В.В. Структурированный язык запросов (SQL). – СПб.: ИТМО, 2004. – 80 с.
19. Котляров В.П. Основы тестирования программного обеспечения. Интернет-университет информационных технологий – Изд-во INTUIT.ru, 2006 г
20. Куницына Л.Е. Информационные технологии и системы в экономике: Методический комплекс.- Ростов-на-Дону: РГЭА, 1998.-175с
21. Липаев В.В., – Отладка сложных программ – М.: Энергоатомиздат, 2003
22. Липаев В.В., Штрик А.А., – Технология сборочного программирования – М.: Радио и связь, 2002, - 148 с.
23. Мамаев Е. В. «Microsoft SQL Server 2000», СПБ.: Питер 2001, 1280 с.
24. Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 2004. – 196 с.
25. Мейер М. Теория реляционных баз данных. – М.: Мир, 1997. – 608 с.
26. Мишенин А.Н. Теория экономических информационных систем. - М.: Финансы и статистика, 2002 - 248 с..
27. Паутов А.Ю. Документация SQL. - С-Пб: Питер, 2004. - 107 с.
28. Проектирование экономических информационных систем: Учебник / Е.А. Петров, Г.М. Смирнов, А.А. Сорокин, Ю.Ф. Тельнов. - М.: Финансы и статистика, 2006 - 286 с..
29. Симонович С.В. Язык структурированных запросов SQL, СПб «Питер», 2005.
30. Тассел Д. Ван. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Изд-во МГУ, 2005
31. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 2005. Кн. 1. – 287 с.: Кн. 2. – 320 с.
32. Фролов А.В., Фролов Г.В. Локальные сети персональных компьютеров. – М.: «ДИАЛОГ - МИФИ», 2003 - 280 с.
33. Шуленин А.В., Microsoft SQL Server и активный Internet. Материалы Форума "Информационные Технологии'05". - М.: Издательство МГУ, 2005. - 239 с
34. Шуленин В.В. OLAP-технологии разработки баз данных. - М.: Диалог-МИФИ, 2003 . - 140 с.
35. Шураков В.В. Надежность программного обеспечения систем обработки данных. –М.: Статистика, 2001, - 215 с.

Приложение А. Описание сущностей (таблиц) и атрибутов базы данных ООО «Меркатор»
Таблица А.1. Описание сущностей (таблиц) и атрибутов базы данных ООО «Меркатор»
Имя таблицы Имя поля Ключ Тип ключа Описание Размер Индексированное поле Обязательное поле Условие на значение Поставщики КодПоставщика * Счетчик Номер, однозначно определяющий поставщика. Длинное целое Да (Совпадения не допускаются) Название Текстовый 40 Да (Допускаются совпадения) да Адрес Текстовый 60 Нет нет Город Текстовый 15 Нет нет Область Текстовый 15 Нет нет Индекс Текстовый 10 Да (Допускаются совпадения) нет Страна Текстовый 20 Нет нет Телефон Текстовый Телефон с кодом страны или региона 24 Нет нет Факс Текстовый Телефон с кодом страны или региона 24 Нет нет
Продолжение Таблицы А.1.
Имя таблицы Имя поля Ключ Тип ключа Описание Размер Индексированное поле Обязательное поле Условие на значение Товары Код Товара * Счетчик Уникальное число, автоматически присваиваемое новой записи. Да (Совпадения не допускаются) Наименование Текстовый 40 Да (Допускаются совпадения) да КодПоставщика Числовой Совпадает со значением поля "КодПоставщика" в таблице "Поставщики". Длинное целое Да (Допускаются совпадения) нет ЕдиницаИзмерения Текстовый 30 Нет нет Цена Денежный - Нет нет >=0 НаСкладе Числовой Целое Нет нет >=0 ПоставкиПрекращены Логический "Да" означает, что товар больше не поставляется. - Нет нет =Нет
Продолжение Таблицы А.1.
Имя таблицы Имя поля Ключ Тип ключа Описание Размер Индексированное поле Обязательное поле Условие на значение Заказано КодЗаказа * Числовой Совпадает со значением поля "КодЗаказа" в таблице "Заказы". Длинное целое Да (Допускаются совпадения) нет КодТовара * Числовой Совпадает со значением поля "КодТовара" в таблице "Товары". Длинное целое Да (Допускаются совпадения) да Цена Денежный - Нет да >=0 Количество Числовой Целое Нет да >0 Скидка Числовой Одинарное с плавающей точкой нет да Between 0 And 1
Продолжение Таблицы А.1.
Имя таблицы Имя поля Ключ Тип ключа Описание Размер Индексированное поле Обязательное поле Условие на значение Заказы КодЗаказа * Счетчик Уникальный номер заказа Длинное целое Да (Совпадения не допускаются) КодКлиента Числовой Совпадает со значением поля "КодКлиента" в таблице "Клиенты". Длинное целое Да (Допускаются совпадения) нет КодСотрудника Числовой Совпадает со значением поля "КодСотрудника" в таблице "Сотрудники". Длинное целое Да (Допускаются совпадения) нет ДатаРазмещения Дата/время Да (Допускаются совпадения) нет НазваниеПолучателя Текстовый Название организации или ФИО получателя. 40 Нет нет АдресПолучателя Текстовый Адрес получателя (без почтового индекса). 60 Нет нет ГородПолучателя Текстовый 15 Нет нет ИндексПолучателя Текстовый 10 Да (Допускаются совпадения) нет ОбластьПолучателя Текстовый Область, республика или район получателя. 15 Нет нет СтранаПолучателя Текстовый 20 Нет нет
Продолжение Таблицы А.1.
Имя таблицы Имя поля Ключ Тип ключа Описание Размер Индексированное поле Обязательное поле Условие на значение Сотрудники КодСотрудника * Счетчик Номер, автоматически присваиваемый новому сотруднику. Длинное целое Да (Совпадения не допускаются) ФИО Текстовый 60 Да (Допускаются совпадения) да Пол Текстовый 8 Нет нет Должность Текстовый Должность сотрудника. 30 Нет нет ДатаРождения Дата/время Нет нет <Date() Адрес Текстовый 60 Нет нет Город Текстовый 15 Нет нет Индекс Текстовый 10 Да (Допускаются совпадения) нет Страна Текстовый 20 Нет нет ДомашнийТелефон Текстовый Телефонный номер, включая региональный код. 24 Нет нет МобильныйТелефон Текстовый 24 Нет нет Примечание Поле МЕМО Общие сведения о сотруднике. Нет нет
Продолжение Таблицы А.1.
Имя таблицы Имя поля Ключ Тип ключа Описание Размер Индексированное поле Обязательное поле Условие на значение Клиенты КодКлиенты * Счетчик Уникальное число, автоматически присваиваемое новой записи. Длинное целое Да (Совпадения не допускаются) нет Название Текстовый 40 Да (Допускаются совпадения) да ОбращатьсяК Текстовый 30 Нет нет Адрес Текстовый 60 Нет нет Город Текстовый 15 Да (Допускаются совпадения) нет Область Текстовый Область или республика. 15 Да (Допускаются совпадения) нет Индекс Текстовый 10 Да (Допускаются совпадения) нет Страна Текстовый 20 Нет нет Телефон Текстовый Телефон с кодом страны или региона. 24 Нет нет Факс Текстовый Телефон с кодом страны или региона. 24 Нет нет
Приложение Б. Отчеты решения контрольно