Функция

S1

0,3

Составление списка возможных поставщиков

S2

0,2

Организация переписки с поставщиками

S3

0,4

Подготовка запросов в соответствии с заявкой на материал

S4

0,4

Отправка запроса

S5

0,2

Получение предложений от возможных поставщиков

S6

1,3

Согласование полученных предложений

S7

1,5

Анализ возможных вариантов

S8

1.4

Выбор наилучшего поставщика

S9

0,5

Согласование выбранного поставщика

S10

0,4

Ввод характеристик возможных поставщиков в программу

S11

1,3

Согласование поставщика, выбранного программой

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

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

f = ?n_i*S_j

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

0,5*0,3+0,5*0,2+0,5*0,4+0,5*0,4+0,5*0,2+0,7*1,3+1*1,3+0,7*1,5+1*1,5+

+0,7*1,4+1*1,4+1*0,5=6,89у.е

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

0,5*0,3+0,5*0,2+0,5*0,4+0,5*0,4+0,5*0,2+0,7*1,3+1*1,3+0,5*0,4+0,7*1,3

+ +1*1,3=5,37 у.е

После автоматизации требуемый размер оплаты функций уменьшился на 1,52 у.е, что примерно составляет 27%. Это можно считать весьма удовлетворительным результатом.

Выводы по разделу

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



3. Проектирование информационной системы отдела снабжения предприятия «Метис»

3.1 Выбор архитектуры информационной системы

По способу организации ИС имеют следующие виды;

· архитектура файл-сервер;

· архитектура клиент-сервер;

· многоуровневая система;

· на основе интернет/интранет-технологий.

Рассмотрим более подробно особенности архитектуры построения информационных приложений.

Архитектура файл-сервер не имеет сетевого разделения компонентов и использует клиентский компьютер для выполнения функций диалога и обработки данных, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную мощность к вычислительной системе. [4]

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью файл-серверной архитектуры является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными размещаются на сервере, а диалог логики, обработка логики - на клиенте. Двух уровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере.

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней;

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

· средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика и с которого логика обработки данных вызывает операции с базой данных;

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

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle,Sun, Borland и др. [4]

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

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

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

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

В таблице 3.1 приведены, на мой взгляд, наиболее актуальные параметры по которым сравниваются рассматриваемые архитектуры ИС.

Таблица 3.1

Сравнительная характеристика архитектуры ИС

Параметры сравнения	Файл-сервер	Клиент-сервер	Многоуровневая система	Интернет/интранет-технологии
Установка СУБД	На клиентском компьютере	Отдельный сервер	Несколько отдельных серверов	Несколько отдельных серверов
Объемы передаваемых данных	Малые	Большие	Очень большие	Очень большие
Применяемые на предприятии	Нет	Да	Нет	Нет
Знакомство обслуживающего персонала с представленными архитектурами	Да	Да	Нет	Нет

Проведем расчет выбора архитектуры ИС по выбранным параметрам на основании технико-экономической эффективности.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

Таблица 3.2

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Результаты сравнения сведем результаты сравнения в таблицу 3.3.

Таблица 3.3

Оценка технико-экономической эффективности

Параметры сравнения/оценка	Весовой коэффициент	Файл-сервер	Клиент-сервер	Многоуровневая система	Интернет/интранет технологии
		Ajf	kj •Ajf	Ajk	kj •Ajk	Ajm	kj •Ajm	Aji	kj •Aji
Установка СУБД	0,15	1	0,15	4	0,6	3	0,45	3	0,45
Объемы передаваемых данных	0,25	1	0,25	3	0,75	4	1	4	1
Применяемые на предприятии	0,35	0	0	4	1,4	0	0	0	0
Знакомство обслуживающего персонала с представленными архитектурами	0,25	2	0,5	3	0,75	1	0,25	1	0,25
Интегральный технико-экономический показатель, Q		Qf = 0,9	Qk = 3,5	Qm = 1,7	Qi = 1,7

Посчитаем интегральный технико-экономический показатель:

для файл-сервера Q_f:

для клиент-сервер Q_k:

для многоуровневой системы Q_m:

Для интернет/интранет-технологии Q_i:

Интегральный технико-экономический показатель между файл-серверной архитектурой и клиент-серверной равен:



Q = Q_k/ Q_f = 3,5/0,9 = 3,89

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

Интегральный технико-экономический показатель между клиент-серверной архитектурой и многоуровневой системой равен:

Q = Q_k/ Q_m = 3,5/1,7 = 2,06

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

Интегральный технико-экономический показатель между клиент-серверной архитектурой и интернет/интранет технологии равен:

Q = Q_k/ Q_m = 3,5/1,7 = 2,06

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

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

3.2 Разработка структуры БД

3.2.1 Нотация IDEF1xсущности и их атрибуты

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

· она имеет имя и описание;

· она представляет класс, а не единичный экземпляр абстракции;

· ее конкретные представители (экземпляры) могут быть уникально идентифицированы;

· она содержит логическую группировку атрибутов, представляющих информацию, интересную с точки зрения корпорации. [4]

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

Понятие атрибута. Типы атрибутов

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

Ключевые атрибуты

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

Атрибуты первичного ключа

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

Хороший первичный ключ будет обладать следующими признаками:

· значение гарантирует уникальность для каждого из экземпляров;

· значение не имеет скрытого смысла;

· область определения значений будет оставаться постоянной с течением времени;

· значения существуют для каждого из экземпляров сущности.

Внешние ключи

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

Неключевые атрибуты

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

3.2.2 Связи между сущностями

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

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

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

3.2.3 Описание процесса проектирования

Построение модели данных для модуля выбора поставщика в рассматриваемом коммерческом предприятии начнем с построения логического уровня модели представляющую собой абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Логическая модель данных является универсальной и ни как не связанна с конкретной реализацией СУБД.

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

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

· Характеристики товаров;

· Характеристики поставщиков.

Согласно всему вышеизложенному существует возможность перечислить сущности предметной области:

· Город;

· Поставщик;

· Товар.

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

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

Для сущности Поставщик атрибутами являются (ID_Поставщика, Название города, Наименование, Качество поставляемых материалов, Сроки поставки груза, Стоимость материалов, Опыт сотрудничества с поставщиками, Надежность), первичным ключом будет атрибут (ID_Поставщика). Ключом для связи с другими сущностями является атрибут (Название города).

Для сущности Товар атрибутами являются (ID_Товара, Название города, ID_Поставщика, Наименование товара, Вес, Цена, Количество), первичным ключом в данной сущности будет являться атрибут (ID_Товара). Для связи с внешними сущностями используется два атрибута (ID_поставщика) и (Название города).

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

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

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

Long Integer - числовая переменная целого значения.

Text - случайная текстовая переменная.

Date/time - числовая переменная десятичного значения.

Рис. 3.1 Логическая модель данных

автоматизированный информационный логистика поставщик



Рис. 3.2 Физическая модель данных

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



4. Реализация выбранного варианта решения

4.1 Обоснование выбора СУБД

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

Рассмотрим некоторые из представленных на рынке СУБД, сведённых в таблицу 4.1.

Таблица 4.1

Сравнение СУБД

Название критерия выбора	SQL Server 2000	ORACLE 10g	MySQL
Стоимость сервера (лицензия на процессор и на сам сервер)	5448$	4995$	Общедоступная
Стоимость клиента	146$	149$	Общедоступная
Максимальное число пользователей	Зависит от лицензии	Зависит от лицензии	Зависит от лицензии
Технические требования к серверу	166 Мгц 64 Мб ОЗУ 140-500 Мб на HDD	300 Мгц 128 Мб ОЗУ 1,5 Гб на HDD	100 Мгц 64 Мб ОЗУ 100 Мб на HDD
Поддерживаемые серверные ОС	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition, UNIX-подобные системы, Solaris, Mac OS и др.	Windows 2000 (SP2), Windows Server 2003, Windows NT® 4.0 (SP6a иливыше), Windows XP Red Hat Enterprise Linux, SUSE Enterprise Linux Server 9 Solaris 7, 8, 9
Уровень квалификации персонала	Высокий	Высокий	Средний
Установленная на данный момент на предприятии	нет	нет	да

На основании выбранных критериев проведем расчет технико-экномической эффективности MySQL, SQL Server 2000, ORACLE 10g.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Таблица 4.2

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Определим каждому критерию весовой коэффициент k_j, причем k_j= Результаты сравнения сведем результаты сравнения в таблицу 4.3.

Посчитаем интегральный технико-экономический показатель:

Для SQL Server 2000Q_s:

,

Для ORACLE 10gQ_d:



И для MySQL:

Таблица 4.3

Оценка технико-экономической эффективности

Параметры сравнения/оценка	Весовой коэффициент	MySQL	SQL Server 2000	ORACLE 10g
Стоимость сервера	0,15	4	0,6	1	0,1	1	0,2
Стоимость клиента	0,10	4	0,40	3	0,30	3	0,3
Максимальное число пользователей	0,10	3	0,3	3	0,3	3	0,3
Технические требования к серверу	0,15	3	0,45	2	0,3	1	0,15
Поддерживаемые серверные ОС	0,05	3	0,15	4	0,2	3	0,15
Уровень квалификации персонала	0,20	4	0,8	2	0,4	1	0,2
Установленная на данный момент на предприятии	0,25	4	1,00	2	0,5	2	0,5
Интегральный технико-экономический показатель, Q		Qa= 3,7	Qs = 2,1	Qo = 1,8

Интегральный технико-экономический показатель между MySQL и SQL Server 2000, равен:

Q = Q_a/ Q_s = 3,7/2,1 = 1,76



Между MySQL и ORACLE 10g,равен:

Q = Q_a/ Q_o = 3,7/1,8 = 2,06

На основании проведенных расчетов можно сделать следующий вывод: интегральный технико-экономический показатель больше 1, что говорит в пользу MySQL и о целесообразности выбора данного СУБД.

MySQL:является решением для малых и средних приложений. Входит в LAMP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, благодаря хорошей системе безопасности этого пакета, стабильной работе, высокому быстродействию и хорошей интеграции с соответствующими средствами программирования. В дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. [5] Разработчики MySQL всегда считали стабильность предметом особой важности.

4.2 Выбор среды разработки

Выбор средства разработки приложений был основан на сравнении с C++Builder 2007, Borland Delphi 2007 и C#(MSVisual Studio 2007) (Таблица 4.3).

Новая версия продукта C++Builder 2007, ведущей интегрированной среды для быстрой разработки приложений на С++, сочетает поддержку операционной системы Windows Vista API и технологий Web 2.0 с самыми последними стандартами: значительно выросшей производительностью, интегрированными функциями проверки и множеством сочетаний клавиш, позволяющих экономить время и значительно упрощать выполнение типовых задач. [6]

C++Builder 2007 кардинально улучшает разработку на C++ для Windows, предоставляя полностью интегрированную среду для быстрой разработки приложений (RAD) на C++ под Windows, которая поддерживает Windows Vista™ и AJAX.C++ Builder 2007 продолжает традиции быстрой разработки и в то же время реализует новые технологии: поддержка Vista включает темы приложений и VCL-компоненты для поддержки Aero и VistaDesktop, а также новые диалоги работы с файлами и задачами.

Среди новых функций C++ Builder 2007: улучшенная совместимость со стандартами ANSI C++, Dinkumware и Boost; значительно ускорена работа интегрированной среды, в том числе время сборки проекта внутри среды -- так же быстро или даже быстрее, чем сборка с применением утилит командной строки.

Borland Delphi 2007 - эффективная среда разработки приложений для Microsoft Windows. BorlandDelphi2007 предоставляет исключительный "коэффициент повышения производительности", позволяя устранить утомительный труд и максимально увеличить производительность при помощи революционной среды разработки корпоративных приложений, библиотеки многократно используемых визуальных компонентов и полностью интегрированного пакета инструментов моделирования и управления жизненным циклом проектов (ALM). [7]

C#(MS Visual Studio 2007) - являясь последним из широко распространенных языков программирования, впитал в себя весь имеющийся опыт и вобрал лучшие стороны существующих языков программирования, при этом являясь специально созданным для работы в NET. Сама архитектура NET продиктовала ему объектно-ориентированную направленность.

Свой синтаксис C# во многом унаследовал от C++ и Java. Но вместе с тем он является во многом новаторским - атрибуты, делегаты и события, прекрасно вписанные в общую идеологию языка, прочно заняли место в сердцах NET - разработчиков. Их введение позволило применять принципиально новые приемы программирования.

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

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

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

Таблица 4.4

Сравнение языков программирования

Критерии сравнения	C++Builder 2007	Borland Delphi 2007	C#(MS Visual Studio 2007)
Степень соответствия назначения языка и целей разработки	Ориентирован на разработку систем любой степени сложности	Ориентирован на разработку систем любой степени сложности	Ориентирован на разработку систем любой степени сложности
Использование международных стандартов	Полностью стандартизирован	Имеет собственный стандарт	Полностью стандартизирован
Поддерживаемые СУБД	MS SQL Server 2000/2005, My SQL, Oracle, Sybase, Interbase 2007, SQL Anywhere, DB2, Informix	Inter Base 7.5, Oracle, IBM DB2, Microfost SQL Server 2000/2005, Informix, SQL Anywhere, MySQL, Sybase	Inter Base 7.5, Oracle, IBM DB2, Microfost SQL Server 2000/2005, Informix, SQL Anywhere, MySQL, Sybase
Поддерживаемые ОС	Windows Vista/ Server 2003/ XP Professional/ 2000 Professional / 2000 Server	Microsoft Windows 2000/ XP Professional (SP2 иливыше)/ Vista Professional/ Microsoft Windows Server 2003.	MS Windows OC
Квалификация разработчиков	Высокая	Высокая	Высокая
Стоимость продукта	900 у.е.	900 у.е.	900 у.е.

Проведем расчет выбора средств реализации по выбранным параметрам на основании технико-экономической эффективности.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

Таблица 4.5

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Результаты сравнения сведем результаты сравнения в таблицу 4.5.

Посчитаем интегральный технико-экономический показатель:

для C++Builder 2007Q_c:

Для Borland Delphi 2007Q_b:



Для C#(MS Visual Studio 2007) Q_#:

Интегральный технико-экономический показатель между C#(MS Visual Studio 2007) иC++Builder 2007 равен:

Q = Q_#/ Q_c = 3,6/2,75 = 1,31

т.к. технико-экономический показатель больше 1 выбор в сторону C#(MS Visual Studio 2007).

Таблица 4.6

Оценка технико-экономической эффективности

Параметры сравнения/оценка	Весовой коэфф.	C++Builder 2007	Borland Delphi 2007	C# (MS Visual Studio 2007)
		Ajk	kj •Ajk	Ajm	kj •Ajm	Aji	kj •Aji
Степень соответствия назначения языка и целей разработки	0,25	3	0,75	2	0,5	4	1
Использование международных стандартов	0,10	2	0,2	2	0,2	3	0,3
Поддерживаемые СУБД	0,20	2	0,4	2	0,4	3	0,6
Поддерживаемые ОС	0,15	2	0,3	3	0,45	4	0,6
Квалификация разработчиков	0,2	4	0,8	4	0,8	4	0,8
Стоимость продукта	0,1	3	0,3	3	0,3	3	0,3
Интегральный технико-экономический показатель, Q		Qc = 2,75	Qb = 2,65	Q# = 3,6

Интегральный технико-экономический показатель между C#(MS Visual Studio 2007) и Borland Delphi 2007равен:

Q = Q_#/ Q_b = 3,6/2,65 = 1,36



т.к. технико-экономический показатель больше 1 выбор в сторону C#(MS Visual Studio 2007).

Вывод - для разработки ИС будем использовать C#(MS Visual Studio 2007) т.к. по сравнению с C++Builder 2007 и Borland Delphi 2007 с использованием технико-экономического показателя, C#(MS Visual Studio 2007) наиболее подходит мне по критериям оценки.

4.3 Графический интерфейс пользователя модуля выбора поставщика

Рис. 4.1 Графический интерфейс

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



5. Социальная значимость разработки

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

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

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

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



6. Технико-экономическое обоснование проекта

6.1 Расчет затрат на проектирование

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

Для расчета затрат на этапе проектирования необходимо определить продолжительность каждой работы начиная с составления технического задания и заканчивая оформлением документации. [8] Продолжительность работ определяется либо по нормативам (с использованием справочников), либо расчетом с помощью экспертных оценок по формуле (определение среднего времени продолжительности работ на каждом из этапов).

Расчеты длительности всех работ на этапе проектирования сведены в таблицу 6.1.

Таблица 6.1

Длительность всех работ на этапе проектирования

Наименование работ	Длительность работ (дней)	Расход машинного времени
	tmin	tmax	t0	tM
1. Разработка ТЗ	3	5	3,8	-
2. Анализ ТЗ	4	6	4,8	-
3. Поиск и изучение литературы	3	5	3,8	-
4.Обзор существующих аналогов системы;	5	7	5,8	-
5. Разработка алгоритма	9	13	10,6	-
6. Разработка программы	18	24	20,4	142
7. Отладка работы программы	15	20	17	119
8.БЖ и экологичность разработки	5	7	5,8	40
9.Технико-экономическое обоснование работы	6	9	7,2	50
10. Оформление пояснительной записки	7	9	7,8	54
Итого:	75	105	87	405

t_o = (3t_min +2t_max)/5, (6.1)

где t_о - ожидаемая длительность работ;

t_min, t_max - наименьшая и наибольшая по мнению эксперта длительность работ.

Для определения продолжительности этапа проектирования Т_П по данным табл.6.1 построим график организации работ во времени.

Размещено на http://www.allbest.ru/

Рис. 6.1 - Ленточный график

Так как некоторые процессы можно проводить параллельно, общая продолжительность работ уменьшается. По графику видно, что общее время проектирования Т_П=77 дней.

Капитальные затраты на этапе проектирования К_п рассчитываются по формуле:

K_П = Z_П + M_П + Н_П, (6.2)

где Z_П - заработная плата проектировщика задачи на всем этапе проектирования;

M_П - затраты на использование ЭВМ на этапе проектирования;

Н_П - накладные расходы на этапе проектирования.

Одним из основных видов затрат на этапе проектирования является заработная плата проектировщика, которая рассчитывается по формуле:

(6.3)

где Z_д - дневная заработная плата разработчика задачи на этапе проектирования;

А_с - процент отчислений на социальное страхование (26%);

А_п - процент премий (35%).

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

Z_д= ОК / Д_р, (6.4)

где: ОК - оклад разработчика (7000 руб.);

Д_р - среднее число рабочих дней (21 дней);

Получим,

Z_д = 7000/21 = 333 руб.

Отсюда,

Z_П = 333 * 77 * (1 + 0,26)•(1 + 0,35) = 43 615 руб.

Стоимость одного часа машинного времени примем С = 10 руб, тогда затраты на использовании ЭВМ равны:

М_П = С • Z_д, (6,5)

М_П = 10 * 333 = 3330 руб.

Накладные расходы составляют 80% от заработной платы персонала, занятого эксплуатацией программы, и вычисляются по формуле:

Н_П = (Z_П * 80) / 100, (6,6)

То есть Н_П = (43615 * 80)/100 = 34 892 руб.

Таким образом, капитальные затраты на этапе проектирования продукта составят:

К_П = Z_П + М_П + Н_П, (6,7)

К_П = 43 615 + 3330 + 34 892 = 81 837 руб.

6.2 Состав эксплуатационных расходов

В эксплуатационные расходы входят:

содержание персонала, занятого работой с программой;

расходы на функционирование программы;

накладные расходы;

прочие расходы.

Расходы на содержание персонала

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

(6,8)

где n_i - численность персонала i - вида;

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

а_c - процент отчислений на социальное страхование, пенсионный фонд и фонд стабилизации (обычно a_c = 26,6%);

а_п - средний процент премий за год.

До внедрения программы: n₁ = 5, z₁ = 84 000 руб., а₁= 15%. Следовательно:

Z₁ = 5 * 84 000 * (1 + 0,266) * (1 + 0,15) = 611 478 руб.

После внедрения программы: n₂ = 3, z₂ = 84 000 руб., а₂= 15%. Значит:

Z₂ = 3 * 84 000 * (1 + 0,266) * (1 + 0,15) = 366 886 руб.

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

Расходы на функционирование программы

Расходы на функционирование системы заключаются в затратах на машинное время. Формула для расчетов имеет вид:

М = С * t, (6,9)

где C - стоимость 1-го часа машинного времени;

t - необходимое для решения задачи машинное время (в часах).

При условии, что до внедрения программы компьютеры не использовались, М₁= 0. Если стоимость одного часа работы составляет 10 рублей, а программа работает 2016 часов в год, то М₂= 10 * 2016 = 20 160 руб. после внедрения программы.

Накладные расходы

Накладные расходы составляют 80 % от основной зарплаты персонала, занятого эксплуатацией программы. Т.о., накладные расходы составляют в год:

до использования программы: 611 478 * 80/100 = 489 182 руб.

после внедрения программы: 366 886 * 80/100 = 293 509 руб.

Прочие расходы

Прочие расходы составляют 2% от суммы всех эксплуатационных расходов.

До внедрения программы: (611 478 + 489 182) * 2/100 = 22 013 руб.

После внедрения программы: (366 886 + 293 509 + 20 160) * 2/ 100 = 13 611 руб.

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

Р₁ = 611 478 + 489 182 + 22 013 = 1 122 673 руб.

Р₂ = 366 886 + 293 509 + 20 160 + 13 611 = 694 166 руб.



6.3 Расчет экономии от увеличения производительности труда пользователя

Страница:

•  1 
•  2 
•  3 

дипломная работа "Информационная система отдела снабжения предприятия "Метис"" скачать

Подобные документы

• Модель информационной системы отдела снабжения предприятия ООО "Бисквит"

  Описание отдела снабжения предприятия ООО "Бисквит". Функциональная схема и сценарии процесса пополнения сырьевых запасов, определения норм закупки сырья. Оптимизация и реинжиниринг бизнес-процессов. Проектирование информационной системы, ее параметры.
  
  дипломная работа [1,9 M], добавлен 11.12.2012
  

• Разработка программного обеспечения для задач снабжения

  Разработка стратегии и выбор способа автоматизации задачи снабжения для предприятия. Построение функциональной модели бизнес-процессов предметной области. Создание программного средства "1С: Конфигурация ОМТС" для оптимального решения задач снабжения.
  
  дипломная работа [7,2 M], добавлен 12.04.2012
  

• Информационная система регистратуры гостиницы "Бастион"

  Сравнительный анализ гостиничных информационных систем. Анализ и выбор CASE-средств для моделирования бизнес-процессов. Визуальная и математическая модели предметной области, выбор архитектуры и платформы информационной системы, построение базы данных.
  
  дипломная работа [1,4 M], добавлен 20.07.2014
  

• Разработка функциональной модели "Документооборот предприятия"

  Роль инструментальных средств проектирования в создании информационной системы. Преимущества CASE-средств разработки Bpwin и Erwin, системы поиска, исправления ошибок модели данных Model Validator. Разработка модели процессов документооборота предприятия.
  
  контрольная работа [2,2 M], добавлен 24.06.2012
  

• Создание информационной системы для хранения, анализа и обработки информации, применяемой для организации отдела снабжения

  Обоснование необходимости применения вычислительной техники и телекоммуникационного оборудования для решения задач. Проектирование информационной системы отдела снабжения. Физическая модель данных с указанием типов основных атрибутов, нормализация таблиц.
  
  дипломная работа [1,6 M], добавлен 19.02.2017
  

• Анализ деятельности торгового предприятия "ИнТорг" с точки зрения организации отдела закупок

  Проектирование информационной системы отдела закупок торгового предприятия. Основные функции отдела логистики. Определение наиболее загруженной функции с помощью программного пакета MatLab. Обзор существующих решений по автоматизации выбора поставщика.
  
  дипломная работа [2,2 M], добавлен 20.07.2014
  

• Информационная система компании "Радуга-ТВ". Отдел продаж

  Анализ принципа работы отдела продаж на примере "Радуга-ТВ". Математическое моделирование работы с клиентами отдела продаж. Выбор архитектуры информационной системы, средств ее проектирования. Выбор системы управления базой данных, программные требования.
  
  дипломная работа [1,7 M], добавлен 20.07.2014
  

• Автоматизация комплекса задач менеджера отдела продаж торговой организации

  Анализ деятельности компании в целом и отдела продаж в частности. Описание состояния информационной системы предприятия. Декомпозиция бизнес-процессов, протекающих в отделе продаж. Проектирование информационной системы, ее программное обеспечение.
  
  дипломная работа [2,4 M], добавлен 29.08.2014
  

• Проектирование системы информационной безопасности

  Анализ инфраструктуры ООО магазин "Стиль". Создание системы информационной безопасности отдела бухгалтерии предприятия на основе ее предпроектного обследования. Разработка концепции, политики информационной безопасности и выбор решений по ее обеспечению.
  
  курсовая работа [2,2 M], добавлен 17.09.2010
  

• Анализ предметной области отдела заказов малого предприятия

  Модель системы в нотации UML 2.0 по методологии IDEF1x через CASE. Информационная система улучшения работы менеджера предприятия по обслуживанию клиентов и процессов. Построение плана работ по подготовке и защиты на степень бакалавра с помощью CASE.
  
  курсовая работа [2,4 M], добавлен 13.11.2009
  

• Проектирование информационной системы "Лизинговая компания" с использованием case-технологий

  Структура лизинговой компании. Создание функциональной и информационной модели. Моделирование бизнес-процесса "Выполнить заказ клиента". Требование к техническому обеспечению и надежности системы. Состав ИБД лизинговой компании ООО "Лизинг–Трейд".
  
  курсовая работа [1,4 M], добавлен 29.06.2014
  

• Проектирование автоматизированной системы малого предприятия

  Создание автоматизированной информационной системы для ОАО "Сибирь". Построение функциональной модели, описывающей существующую организацию работы на основе анализа деятельности предприятия. Смешанная модель в стандартах IDEF0, DFD, IDEF3 и IDEF1X.
  
  курсовая работа [2,4 M], добавлен 17.09.2010
  

• Разработка автоматизированной информационной системы "Гостиница"

  Обзор принципов построения и эффективного применения систем управления базами данных, CASE-средств автоматизации проектирования. Анализ возможностей методологии и инструментальных средств. Разработка модели бизнес-процессов гостиницы в среде All Fusion.
  
  курсовая работа [3,3 M], добавлен 28.12.2012
  

• Разработка и внедрение автоматизированных систем документооборота в отделе тестирования компании ООО "Вип Ай Ти Маркет"

  Характеристика предприятия ООО "Вип Ай Ти Маркет" и его деятельности. Программная и техническая архитектура информационной системы. Выбор комплекса задач автоматизации документооборота и характеристика существующих бизнес-процессов отдела тестирования.
  
  отчет по практике [467,4 K], добавлен 14.03.2011
  

• Разработка АРМ специалиста отдела продаж и специалиста отдела снабжения

  Роль информатики в пользовательской обработке данных и проектировании автоматизированных интегрированных систем управления. Применение Microsoft Access для формирования банка данных о заказах, содержание АРМ специалистов отдела продаж и снабжения.
  
  курсовая работа [2,0 M], добавлен 08.05.2011
  

• Система планирования транспортного отдела предприятия

  Исследование предметной области. Принципы системы планирования транспортного отдела предприятия. Создание организационной модели, с помощью case средств Bp win4. Основные направления совершенствования организации работы внутризаводского транспорта.
  
  курсовая работа [961,0 K], добавлен 07.06.2016
  

• Проектирование автоматизированной информационной системы в гостиничном бизнесе

  Анализ возможностей методологии и инструментальных средств проектирования информационной системы "Гостиница". Создание модели процессов, ее дополнение организационными диаграммами. Поиск и исправление ошибок с помощью Erwin Examiner. Связь с СУБД Acces.
  
  курсовая работа [6,5 M], добавлен 17.06.2011
  

• Разработка автоматизированной информационной системы учета для расчёта заработной платы ОАО РПТ "Авторемонтник"

  Выбор методологии проектирования и разработка информационной системы "Расчёт зарплаты" для предприятия ОАО РТП "Авторемонтник". Архитектурное проектирование базы данных информационной системы и разработка её интерфейса. Тестирование программного модуля.
  
  дипломная работа [2,3 M], добавлен 25.05.2014
  

• Информационная система отдела кадров

  Анализ предметной области. Технико-экономическое обоснование разработки программного обеспечения информационной системы отдела кадров. Проектирование пользовательского интерфейса. Оптимизация параметров микроклимата помещений, оборудованных ПЭВМ.
  
  дипломная работа [6,8 M], добавлен 16.01.2015
  

• Проектирование и создание автоматизированной информационной системы "Поликлиника"

  Анализ существующих систем управления базами данных и выбор оптимальной. Создание автоматизированной информационной системы "Поликлиника", определение сущностей и взаимосвязей, описание физической модели, проектирование интерфейса, алгоритм программы.
  
  курсовая работа [3,1 M], добавлен 21.11.2009
  

Другие документы, подобные "Информационная система отдела снабжения предприятия "Метис""

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам