РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ АНАЛИЗА ПОСТАВЩИКОВ НА ПРИМЕРЕ КОМПАНИИ ООО "ФОРМУЛА ДОСТАВКИ".

ВВЕДЕНИЕ
1.АНАЛИЗ ЗАДАЧ РАЗРАБОТКИ СИСТЕМЫ ВЫБОРА ПОСТАВЩИКОВ КОМПАНИИ ООО «ФОРМУЛА ДОСТАВКИ»
1.1 Технико-экономический анализ предприятия ООО «Формула доставки»
1.2 АВС-анализ поставщиков предприятия
1.3 Экономический анализ на основе XYZ-анализа
1.4 Управленческие решения, предлагаемые на основе девятикратной
матрицы
1.5 Анализ информационных процессов предприятия
1.6. Выбор средств реализации информационной системы
1.7. Разработка технико-экономического описания и технического задания
2.ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ВЫБОРА ПОСТАВЩИКА
2.1 Разработанные структуры для хранения данных
2.2 Формы приложения
3.РЕАЛИЗАЦИЯ СИСТЕМЫ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
4.ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ПРОЕКТА
4.1 Выбор и обоснование методики расчёта экономической эффективности
4.2 Расчёт показателей экономической эффективности проекта
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ АНАЛИЗА ПОСТАВЩИКОВ
НА ПРИМЕРЕ КОМПАНИИ ООО "ФОРМУЛА ДОСТАВКИ".

Функции автоматизированной системы могут быть достигнуты, за счет использования вычислительной техники и программных средств. Учитывая, что поиск информации, сведений и документов учета в деятельности специалистов отдела снабжения составляют порядка 30% рабочего времени, то внедрение автоматизированной системы учета позволит существенно высвободить квалифицированных специалистов, может привести к экономии фонда заработанной платы, уменьшения штата сотрудников, однако могут привести к и введению в штат сотрудников отдела штатной единицы оператора, в обязанности которого будет входить ввод сведений о протекающих бизнес процессах.
Необходимо отметить, что внедрение разрабатываемой системы, позволит снизить, а в идеале, полностью исключить ошибки заказа, покупки и учета материальных ресурсов, что в свою очередь может привести как к экономическому выигрышу предприятия, связанных исключением издержек, связанными с судебными разбирательствами в случае несвоевременной поставки товарно-материальных ценностей.
Таким образом, внедрение автоматизированной системы учета приведет к значительному экономическому эффекту, сокращению штата сотрудников на 1/3, экономии фонда заработанной платы, повышению производительности труда.
Разрабатываемая программная система должна соответствовать следующим требованием
программное обеспечение, реализующее работу «Информационной системы анализа поставщиков на примере компании ООО "Формула доставки" может быть представлено в виде приложения Access 2003.
Программное обеспечение, реализующее работу «Информационной системы анализа поставщиков на примере компании ООО "Формула доставки" должно обеспечивать выполнение следующих внутренних функций:
программа должна обладать удобным интерфейсом;
оператору должна быть предоставлена возможность руководить ходом поиска информации в базе данных;
тестирование и испытание программного обеспечения должны проводиться в соответствии с отработанными методиками;
разрабатываемое программное обеспечение должно быть надежным и устойчиво выполнять свои функции;
разрабатываемое программное обеспечение должно быть безопасным в использовании;
документация на программное обеспечение должна быть выполнена в соответствии с нормативными документами;
разработчик должен совершать сопровождение разработанной программной системы.
К разрабатываемому программному обеспечению сформулированы следующее требования по производительности: время реакции системы на запрос пользователя не более 1 с.
Разрабатываемая «Информационная система анализа поставщиков на примере компании ООО "Формула доставки" должна обеспечить устойчивое функционирование в среде следующих операционных систем:
Windows ХР/7.
Модуль программной системы должен быть приложением Access 2003 (файлом mdb). Программная система должна оперировать с всеми возможными именами файлов и каталогов Windows.
Тестирование разработанного программного обеспечения должно проводиться по стратегиям «белого» и «черного» ящиков. Количество тестов должно быть избыточным для покрытия всего дерева решений.
Тестирование должно проводиться для каждой операционной системы, в которой предусмотрено функционирование программы.
Испытания программного обеспечения должны проводиться на первом этапе с подсистемами разработанной программы, а затем с программной системой полностью.
По результатам испытаний составляется отчет и акт проведения испытаний.
В состав комиссии по испытаниям разрабатываемого программного обеспечения должны входить представитель разработчика и заказчика. Возможно привлечение для работы в комиссии по испытаниям независимых экспертов, имеющих опыт в тестировании подобных программных систем (по желанию заказчика).
При разработке программного обеспечения разработчику необходимо выполнить следующую сопроводительную документацию на программное обеспечение:
- описанием программы в соответствии с ГОСТ 19.402-78 (в подразделе "Описание логической структуры" должны быть указаны быть алгоритм работы словесно или в виде блок-схемы по ГОСТ 19.002‑80, 19.003-80, 19.005-85);
методика испытаний в соответствии с ГОСТ 19.301-79;
- описание применения (ГОСТ 19.502-78) может быть выполнено в виде руководства системного программиста (ГОСТ 19.503-79), руководства программиста (ГОСТ 19.504-79) или руководство оператора (ГОСТ 19.505-79).
Разрабатываемое программное обеспечение должно удовлетворять требованиям мобильности т.е. способности работать в различных операционных системах, на различных компьютерах и носителях без изменения самого программного обеспечения.
Разрабатываемое программное обеспечение должно быть корректным, эффективным, гибким, защищенным, достоверным и простым в применении.
Временной интервал между отказами программного обеспечения должен составлять не менее 1000 часов непрерывной работы. Минимальный объем данных, которые могут быть потеряны должен соответствовать объему данных, с которыми в данный момент работает программа и составлять не более 2 МБ.
При возникновении ошибки ввода вывода программа должна выводить сообщение на экран компьютера.
Разработчик должен совершать сопровождение, разработанного программного обеспечения. Обновление программного обеспечение должно выполняться при выявлении ошибок функционирования, но не реже одного раза в год.
Программное обеспечение должно применяться в нормальных физических и погодных условиях, а также в условиях допустимых для функционирования ЭВМ.
В целях обеспечения безопасности рекомендуется не использовать в качестве файлов базы данных других файлов (файлов не базы данных).
2. ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ВЫБОРА ПОСТАВЩИКА
2.1 Разработанные структуры для хранения данных
Информационное обеспечение - это создание информационных условий функционирования системы, обеспечение необходимой информацией, включение в систему средств поиска, получения, хранения, накопления, передачи, обработки информации (10).
Проектные решения представляют собой набор документов, с помощью которых происходит процесс автоматизации. Данный раздел описывает эти документы:
Требования заказчика – документ, который описывает основные требования и пожелания заказчика по тому, как в конечном итоге должен выглядеть готовый продукт
Анализ исследования – данный документ содержит информацию о проведенных исследованиях в рамках поставленной задачи. Для выявления более оптимального и эффективного выполнения поставленной задачи.
Техническое задание - документ, содержащий основные технические требования, предъявляемые к будущему продукту, а так же исходные данные для разработки.
Отчет – данный документ представляет собой полный отчет о проделанной работе над поставленной задачей.
Тестирование – документ, содержащий в себе результаты тестирования, а так же описывающий обнаруженные недостатки в системе с целью их устранения.
Устранение ошибок – этот документ содержит в себе выявленные ошибки на стадии внедрения и действия по их устранению.
Внедрение- документ, содержащий в себе данные о том каким образом внедрить систему.
Руководство пользователя - содержит в себе руководство по настройке системы, возможных ошибках и действий по их устранению.
На основании данных документов происходит обоснование проектных решений оп информационному обеспечению.
Информационное обеспечение включает в себя внутримашинное и внемашинное информационное обеспечение.
Внемашинное информационное обеспечение включает различные документы на бумажных носителях.
Внутримашинное информационное обеспечение включает информационную базу на машинном носителе и средства ее ведения. Данное обеспечение должно реализоваться в режиме реального масштаба времени, где изменения в данных, произведенные одним пользователем, сразу должны становиться доступными другим пользователям системы.
Инфологическая модель предметной области – это формализованное описание предметной области, выполненное безотносительно к используемым в дальнейшем программным и техническим средствам. Инфологическая модель должная быть динамической и позволять легкую корректировку. К основным требованиям, предъявляемым к инфологической модели, можно отнести следующие:
- модель должна содержать всю необходимую и достаточную информацию для последующего проектирования базы данных;
- должна быть понятна лицами, принимающими участие в создании и использовании.
При разработке логической модели БД, прежде всего, необходимо решить, какая модель данных наиболее подходит для отображения конкретной концептуальной модели предметной области. Для решения поставленной задачи наиболее органично подходит реляционная модель данных.
В реляционной модели данных объекты и взаимосвязи между ними представляются с помощью таблиц. Взаимосвязи также рассматриваются в качестве объектов. Каждая таблица представляет один объект и состоит из строк и столбцов. В реляционной БД каждая таблица должна иметь первичный ключ (ключевой элемент) – поле или комбинацию полей, которые единственным образом идентифицируют каждую строку в таблице. Благодаря своей простоте и естественности представления реляционная модель данных получила наибольшее распространение в СУБД для персональных компьютеров.
На стадии разработки концептуальной модели из предметной области выделяются отдельные сущности. Отображение концептуальной модели на реляционную модель производится относительно просто. Каждый объект концептуальной модели отображается в одно отношение, которое отражает представление пользователя в удобном для него табличном формате. Простота отображения достигается использованием реляционного подхода еще на стадии создания концептуальной модели.
Среди множества целей, которые необходимо достигнуть в процессе проектирования представляются наиболее важными следующие:
возможность хранения всех необходимых данных в БД;
исключение избыточности данных;
сведения числа хранимых в БД отношений к минимуму;
нормализация отношений для упрощения решения проблем, связанных с обновлением и удалением данных.
Первым этапом в процессе проектирования БД является определение всех атрибутов, которые будут впоследствии помещены в БД. После чего определяется, сколько отношений необходимо и какие атрибуты включать в какие отношения.
Исключение избыточных данных заключается в удалении повторяющейся информации в данных, что способствует повышению производительности, уменьшению размера БД.
Необходимость сведение отношений к минимуму обуславливается тем, что разбиение одного отношения на два (или более отношений) желательно с точки зрения исключения определенных проблем, например, повышается гибкость модели на случай дальнейшей ее модификации, но это усложняет модель, снижает производительность системы.
Нормализация отношений представляет собой разбиение одного отношения на два или более в соответствии со специальной методикой разбиения.
Для того, чтобы отношение считалось нормализованным, каждое из его полей должно быть неделимым и не должно содержать никаких повторяющихся групп. Поле считается нормализованным, если оно содержит только один элемент данных. Повторяющаяся группа – это поле, которое повторяется внутри определения записи с целью хранения нескольких значений для атрибутов.
Отношение находится в первой нормальной форме, если все кортеже не повторяются. Если некоторые кортежи повторяются, то атрибуты с повторяющимися значениями выделяются в отдельное отношение или устанавливают новый атрибут, который станет первичным ключом для данного отношения.
Отношение находится во второй нормальной форме, если все не ключевые атрибуты зависят от первичного ключа. Если есть зависимость каких-нибудь не ключевых атрибутов от части ключа, то следует выделить эти атрибуты в отдельные отношения ту часть первичного ключа, от которой зависят данные атрибуты, и установить связь от нового отношения к старому.
Отношение находится в третьей нормальной форме, если отсутствует взаимосвязь между не ключевыми атрибутами. Выделение в одно отношение атрибутов с одной и той же зависимостью от ключевого атрибута, использование атрибутов, определяющих зависимость, в качестве первичного ключа нового отношения и установки связи от нового отношения к старому.
Четвертая нормальная форма запрещает хранить независимые атрибуты в одном и том же отношении, когда между этими атрибутами существует связь вида «многие ко многим».
Рассмотренные выше нормальные формы относятся к методу декомпозиции на основе функциональных зависимостей, который является пригодным при условии небольшого числа задействованных атрибутов. В данном случае число атрибутов существенно усложняют применение этого метода. Поэтому применим метод «сущность-связь» (entity-relation), который отличается от метода декомпозиции тем, что функциональные зависимости привлекаются не на начальном, а на конечном этапе проектирования.
Сущность – некоторый объект, имеющий экземпляры, отличающиеся друг от друга и допускающие однозначную идентификацию.
Связь – соединение между двумя или более сущностями.
Атрибут – это свойство сущности. Если атрибут или набор атрибутов используется для идентификации экземпляра сущности, то называется ключом сущности. Важной характеристикой связи между двумя (и более) сущностями является степень связи: «один к одному», «один ко многим», «многие ко многим». Экземпляры сущности, участвующие в связи, делятся на класс принадлежности: обязательные или необязательные. После построения диаграмм ER-типа, из них получают отношения, анализируя степень связи между сущностями. Логическая модель проектируемой базы данных представлена.
Каждый элемент сущности обладает конкретными значениями атрибутов, причем не существует двух разных элементов с одинаковыми значениями. В процессе анализа предметной области были выделены следующие сущности:
Для выполнения задания проекта, в среде MS Access был создан файл базы данных, содержащий таблицу данных содержащую информацию о поставщиках предприятия.
Структура разработанной таблицы представлена на рис. 2.1. Разработанная таблица содержит информацию, названии компании и объеме поставок на предприятия ООО «Формула доставки» в течении одного года по месяцам.
В соответствии с заданием в разработанную таблицу были введены данные, содержащие информацию о численных значениях (рис.2.2). Таим образом в таблицу были введены данные о пяти предприятиях, которые являются поставщиками для рассматриваемой компании
Рис.2.1 Структура разработанной таблицы
Рис.2.2 Ввод исходных данных в разработанную таблицу базы данных
2.2 Формы приложения
Для обеспечения выполнения функций по выбору и отображению оптимальных поставщиков было разработано приложение базы данных Access, содержащее 10 разработанных формы. Внешний вид разработанных форм представлен на рис.2.3- 2.12.
Рисунок 2.3 – Внешний вид главной формы приложения
На рис.2.3 представлена главная форма приложения, которая является кнопочной и предназначена для управления вычислительным процессом, с ее помощью организован диалог пользователя с информационной системой, а так же происходит выбор и активизация соответствующих форм приложения. Форма дает возможность пользователю осуществить ввод исходных данных, просмотреть статистику предприятия, а так же перейти на форму, предназначенную для анализа поставщиков.
Для ввода данных о предприятии используется форма представленная на рис. 2.4. Ввод осуществляется путем заполнения соответствующих полей в форме.
На рис.2.5 представлена форма с помощью, которой можно провести просмотр статистики каждого поставщика.
Рисунок 2.4 – Ввод данных о поставщиках
Рисунок 2.5 – Просмотр статистики поставщиков
С помощью формы представленной на рис. 2.6 пользователю предоставляется возможность
Рисунок 2.6 – Просмотр статистики поставщиков нарастающим итогом
При активизации пункта главного меню «Анализ поставщиков» приложение загружает форму «Выбор поставщиков», внешний вид которой представлен на рис.2.7 С помощью этой формы можно активизировать различные методы анализа поставщиков:
- ABC – анализ;
- XYZ – анализ;
- метод Паретто.
Все результирующие виды анализа имеют собственные формы, представленные на рис.2.8-2.12
Рисунок 2.7 – Внешний вид формы «Выбор поставщиков»
Рисунок 2.8 – Внешний вид формы результатов ABC – анализа
Рисунок 2.9 – Внешний вид формы на основе данных ABC-анализа
Рисунок 2.10 – Внешний вид главной формы XYZ – анализа
Рисунок 2.11 – Внешний вид формы содержащей информацию о стабильных и надежных поставщиках
Рисунок 2.11 – Внешний вид формы содержащей информацию о недостаточно стабильных и надежных поставщиках
3. РЕАЛИЗАЦИЯ СИСТЕМЫ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
Для реализации функций, возлагаемых на разрабатываемое программное обеспечение, были созданы 15 запросов к базе данных. Большинство из них имеют вспомогательные функции. Приведем некоторые из них. Запросы «Для получения статистических данных» предприятия имеет вид следующий вид:
SELECT ABC_analiz.*, ABC_analiz!Январь+ABC_analiz!Февраль+ABC_analiz!Март+ABC_analiz!Апрель+ABC_analiz!Май+ABC_analiz!Июнь+ABC_analiz!Июль+ABC_analiz!Август+ABC_analiz!Сентябрь+ABC_analiz!Октябрь+ABC_analiz!Ноябрь+ABC_analiz!Декабрь AS Выражение1, [Выражение1]/12 AS Выражение2, ([Январь]-[Выражение2])*([Январь]-[Выражение2])+([Февраль]-[Выражение2])*([Февраль]-[Выражение2])+([Март]-[Выражение2])*([Март]-[Выражение2])+([Апрель]-[Выражение2])*([Апрель]-[Выражение2])+([Май]-[Выражение2])*([Май]-[Выражение2])+([Июнь]-[Выражение2])*([Май]-[Выражение2])+([Июнь]-[Выражение2])*([Июнь]-[Выражение2])+([Июль]-[Выражение2])*([Июль]-[Выражение2])+([Август]-[Выражение2])*([Август]-[Выражение2])+([Сентябрь]-[Выражение2])*([Сентябрь]-[Выражение2])+([Октябрь]-[Выражение2])*([Октябрь]-[Выражение2])+([Ноябрь]-[Выражение2])*([Ноябрь]-[Выражение2])+([Декабрь]-[Выражение2])*([Ноябрь]-[Выражение2]) AS Выражение3, Sqr([Выражение3]/11) AS Выражение4, [Выражение4]/[Выражение2]*100 AS Выражение5, IIf([Выражение5]<10,"x",IIf([Выражение5]>25,"z","y")) AS Выражение6
FROM ABC_analiz;
Результат выполнения запроса представлен на рис.3.1
Рис. 3.1 – Результат выполнения запроса 2
Для получения данных нарастающим итогом были использованы запросы, следующего вида:
SELECT Статистика_abc.Выражение9, Статистика_abc.Выражение1, SSum1(Статистика_abc!Выражение9,Статистика_abc.Выражение8) AS Total_proc FROM Статистика_abc
ORDER BY Статистика_abc!Выражение8 DESC , Статистика_abc.Выражение9 DESC;
Указанный запрос использует разработанную функцию в среде Visual Basic:
Option Compare Database
Option Explicit
Private PrevName1 As String
Public PrevSum1 As Double
Public Function SSum1(Pole1 As String, amount As Double) As Double
If PrevName1 = Pole1 Then
SSum1 = PrevSum1 + amount
PrevSum1 = SSum1
Else
If Pole1 = 2 Then
SSum1 = PrevSum1 + amount
Else
SSum1 = amount
End If
PrevSum1 = SSum1
PrevName1 = Pole1
End If
End Function
Результат выполнения запроса представлен на рис.3.2
Рис. 3.2 – Результат выполнения запроса
Для получения данных ABC-анализа был разработан запрос текст, которого имеет вид:
SELECT Статистика_abc.id_companya, Статистика_abc.Компания, Статистика_abc.Выражение1, SSum(Статистика_abc!Выражение9,Статистика_abc.Выражение1) AS Total_ob, Статистика_abc.Выражение8, [нарастающий итог процентов].Total_proc, IIf(SSum3(Статистика_abc!Выражение9,Статистика_abc!Выражение8)<75,"A",IIf(SSum4(Статистика_abc!Выражение9,Статистика_abc!Выражение8)<95,"B","C")) AS Выражение2, SSum4(Статистика_abc!Выражение9,Статистика_abc!Выражение8) AS Выражение4, SSum5(Статистика_abc!Выражение9,Статистика_abc!Выражение8) AS Выражение5
FROM [нарастающий итог процентов] INNER JOIN Статистика_abc ON ([нарастающий итог процентов].Выражение9 = Статистика_abc.Выражение9) AND ([нарастающий итог процентов].Выражение1 = Статистика_abc.Выражение1)
ORDER BY Статистика_abc.Выражение1 DESC;
Результат выполнения запроса представлен на рис. 3.3.
Рис. 3.3 – Результат выполнения запроса

Для осуществления XYZ- анализа используется запрос
SELECT XYZанализ_статистика.Компания AS Выражение1, XYZанализ_статистика.Выражение4 AS Выражение2, XYZанализ_статистика.Выражение5 AS Выражение3, XYZанализ_статистика.Выражение6 AS Выражение4
FROM XYZанализ_статистика
ORDER BY XYZанализ_статистика.Выражение6;
Результат выполнения запроса представлен на рис.3.4
Рис. 3.4 – Результат выполнения запроса