Организационно-экономическое обоснование разработки Интернет-магазина

Автор: Пользователь скрыл имя, 16 Мая 2012 в 12:26, курсовая работа

Описание работы

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

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

 определить понятие и функции электронного магазина, а также основную технологию приобретения товаров в Интернет-магазине и комплекс управления виртуальным предприятием;

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

 получить из ER-диаграммы реляционную схему базы данных.

Содержание

ВВЕДЕНИЕ

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1. Понятие и функции электронного магазина

1.2. Основная технология приобретения товаров в электронном магазине

1.3. Управление электронным магазином

ГЛАВА 2. РАЗРАБОТКА МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ ЭЛЕКТРО-ННОГО МАГАЗИНА

2.1. Описание сущностей и установление ключевых полей

2.2. Установление связей между сущностями

2.3. Нормализация отношений

ГЛАВА 3. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ…21



3.1. Организационно-экономическая характеристика разработки интернет-магазина компании «ДонАгроСнаб»……………………………………….......21



3.2. Планирование разработки системы………………………………….......21



3.3 Стоимостная оценка проекта………………………………………...........24



3.4 Определение цены разработанной подсистемы…………………………31



3.5 Анализ целесообразности разработки……………………………………32



ЗАКЛЮЧЕНИЕ 34

ЛИТЕРАТУРА 35

Работа содержит 1 файл

Организационно-экономическое обоснование разработки Интернет-магазина.doc

— 245.50 Кб (Скачать)

Отношение находится в первой нормальной форме если[12]:

      в отношении нет одинаковых кортежей;

      кортежи не упорядочены;

      атрибуты не упорядочены и различаются по наименованию;

      все значения атрибутов атомарны.

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

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

Отношения модели предметной области электронного магазина отвечают требованиям первой нормальной формы поскольку:

      отношения не содержат одинаковых кортежей;

      в таблицах отношения столбцы могут идти в различном порядке;

      каждый атрибут имеет уникальное имя;

      порядок атрибутов не имеет значения;

      атрибуты не содержат более одного значения. Атрибут Адрес сущности Клиент является атомарным понятием, и его деление на составные части не имеет смысла, так как только внесет в ER-диаграмму лишнюю громоздкость.

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и каждый не ключевой атрибут функционально полно зависит от составного ключа. Пусть X и Y – два атрибута некоторого отношения. Говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X соответствует не более одного значения атрибута Y [6].

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

Таким образом, отношения модели предметной области электронного магазина находятся во второй нормальной форме.

Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый не ключевой атрибут не транзитивно зависит от первичного ключ. Пусть X, Y, Z – атрибуты отношения и X зависит от Y, а Y зависит от Z, но обратное соответствие отсутствует. Тогда говорят, что Z транзитивно зависит от X [6].

Отношения модели предметной области электронного магазина находятся в третьей нормальной форме, и дальнейшая нормализация не требуется.

 

 

 



33

 

ГЛАВА 3 ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ. РАЗРАБОТКА ИНТЕРНЕТ-МАГАЗИНА КОМПАНИИ «ДОНАГРОСНАБ»

 

3.1 Организационно-экономическая характеристика разработки интернет-магазина компании «ДонАгроСнаб»

Информационно система по поддержке взаимоотношений с клиентами направлена для ведения эффективной деятельности компании «ДонАгроСнаб».

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

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

После анализа аналогов на соответствие предъявляемым требованиям к системе, было принято решение о разработке системы своими силами.

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

 

3.2 Планирование разработки системы

Календарный план определяет общую трудоемкость и длительность разработки проекта.

Ожидаемая трудоёмкость выполнения работ определяется по  формуле:

 

,                            (1)

где

tmin - минимальная продолжительность выполнения отдельной работы с точки зрения разработчика;

tн.в. - наиболее вероятная продолжительность выполнения отдельной работы с точки зрения разработчика;

tmax - максимальная продолжительность выполнения отдельной работы с точки зрения разработчика.

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

 

Таблица 4.1 - Трудоемкость проектных работ

Наименование работ

Оценка трудоемкости, дней

tmin

tнв

tmax

tож

1. Разработка и утверждение технического задания

1

3

5

3

2. Анализ предметной области и изучение информационных потоков компании

6

7

8

7

3. Анализ прототипа проектируемой системы (разработанной структуры баз данных)

3

7

10

6,8

4. Анализ аналогов проектируемой системы

4

5

7

5,2

5. Разработка сценария диалога пользователей

5

8

9

7,7


 

Продолжение таблицы 4.1

Наименование работ

Оценка трудоемкости, дней

tmin

tнв

tmax

tож

6. Проектирование общей архитектуры приложения

5

8

13

8,3

7. Модификация структуры имеющейся базы данных

1

3

5

3

8. Разработка и программная реализация приложений

7

10

13

10

9. Консультации с заказчиком

2

3

5

3,2

10. Разработка и программная реализация модуля настраиваемой обработки документов

7

10

12

9,8

11. Общее проектирование функциональных подсистем

4

5

6

5

12. Программная реализация функциональных подсистем

10

18

25

17,8

13. Отладка и тестирование

10

15

18

14,7

14. Подготовка инструкции пользователя

1

3

5

3


 

 

Продолжение таблицы 4.1

Наименование работ

Оценка трудоемкости, дней

tmin

tнв

tmax

tож

15. Оформление технической и эксплуатационной документации

15

16

19

16,3

Общая трудоемкость и длительность разработки темы

120,8


 

Календарный план определяет длительность разработки проекта, равную 120,8 дня.

 

3.3 Стоимостная оценка проекта

Стоимостная оценка проекта Спр включает в себя следующие составляющие:

Спр=Стр+Сисп эвм+Сп,                            (2)

где

Стр - оценка труда разработчика темы, руб;

Сисп эвм - затраты связанные с использованием ЭВМ, руб;

Сп - прочие затраты, руб.

 

,                            (3)

где

Оi - оклад разработчика i-ой категории в месяц;

Крд – количество рабочих дней в месяце -22;

К – число категорий;

Тпр – период проектирования подсистемы, Тпр=120,8 дней;

Пд - процент дополнительной заработной платы (10  %);

Пс.н - процент единого социального налога, включая отчисления по травматизму (26,2 %), по данным предприятия;

Пн – процент накладных расходов (50 %) по данным предприятия;

Ni – численность работников i– ой категории;

Оценка труда разработчика информационной системы рассчитывается по формуле (3), исходя из месячного должностного оклада инженера-программиста компании ООО «ДонАгроСнаб», составляющего 15000 руб./месяц.

Стр=(15000/22)*120,8*[(1+10/100)*(1+(26,2/100))+0,5]=318,2*120,8*(1,1*1,262+0,5)= 72 579,7 руб.

 

Стоимостная оценка использования ЭВМ при проектировании:

Сисп. эвм=Кч*Тисп. эвм *Смч,                            (4)

где

Кч – количество часов в рабочем дне;

Тисп.эвм – время разработки ПО;

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

                            (5)

где

Сэкспл - суммарные эксплуатационные затраты за год работ ЭВМ.

Тд - действительный фонд времени работы ЭВМ, ч.

 

При расчёте Сэкспл используются следующие показатели:

Сэкспл=Собсл+Сэн+Сам+Спом+ Срем+ Смат,                            (6)

где

Собсл – затраты на оплату труда обслуживающего персонала ЭВМ, руб./год.

Сэн – затраты на электроэнергию, руб./год.

Сам – амортизационные отчисления, руб./год.

Спом – затраты на содержание помещения где находится ЭВМ разработчика, руб./год;

Срем – затраты на ремонт, руб./год.

Информация о работе Организационно-экономическое обоснование разработки Интернет-магазина