Информационная система для интернет – магазина компьютерных товаров

Автор работы: Пользователь скрыл имя, 19 Июня 2013 в 17:13, курсовая работа

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

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

Содержание работы

ВВЕДЕНИЕ 3
1 ПОДГОТОВИТЕЛЬНЫЕ РАБОТЫ 5
1.1 Анализ предметной области 5
1.2 Постановка задачи 10
1.3 Знакомство с BPwin 11
2 ПРОЕТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ 16
2.1 Разработка технического задания 16
2.2 Проектирование системы в BPwin 22
2.3 Внедрение и сопровождение системы 27
БИБЛИОГРАФИЧЕСКИЙ СПИСОК 32

Файлы: 1 файл

Курсовая.doc

— 333.50 Кб (Скачать файл)

После долгой беседы с заказчиком был составлен необходимый  минимум свойств и требований, предъявляемых к будущей системе. Система должна:

Система должна разделять пользователей, подключенных через интнрнет на группы: администратор, авторизованный пользователь и гость (неавторизованный пользователь).

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

Возможность заказа выбранного товара в режиме он – лайн авторизованными пользователями.

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

Для администраторов  возможность поиска по базе информации по покупателям.

Возможность анализа  в базе динамики изменения цен, объемов  продаж и объемов поставки.

Заказчик так  же обозначил, что база данных работает под управлением Microsoft SQL Server и используется многопоточный доступ к базе данных. Так же уточнил что необходимо обеспечение одновременной работы системы и модулям экспорта внешних данных с одной базой данных.

1.3 Знакомство с BPwin

Моделирование деловых процессов, как правило, выполняется с помощью case – средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и другие. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin.

BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).

BPwin имеет достаточно  простой и интуитивно понятный  интерфейс пользователя. При запуске  BPwin по умолчанию появляется основная  панель инструментов, палитра инструментов (вид которой зависит от выбранной диаграммы) и, в левой части, навигатор модели — Model Explorer.

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

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

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

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

Наиболее удобным языком моделирования бизнес-процессов  является IDEF0, где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

Процесс моделирования  системы в IDEF0 начинается с создания контекстной диаграммы — диаграммы наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель.

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

Цель моделирования  определяется из ответов на следующие вопросы:

    • Почему этот процесс должен быть смоделирован?
    • Что должна показывать модель?
    • Что может получить клиент?

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

IDEF0 – модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.

В закладке Status того же диалога  можно описать статус модели, время  создания и последнего редактирования. В закладке Source описываются источники информации для построения модели. Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS – IS и ТО – ВЕ.

Обычно сначала строится модель существующей организации работы — AS – IS («как есть»). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес – процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес – процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS – IS недостатки можно исправить при создании модели ТО – ВЕ («как должно быть») — модели новой организации бизнес – процессов.

Результат описания модели можно получить в отчете – Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.

Модель может содержать  четыре типа диаграмм: контекстную, диаграмму  дерева узлов, диаграммы для экспозиции, диаграммы для экспозиции.

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

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

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

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

Стрелки (Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными. В IDEF0 различают несколько типов стрелок.

Вход (Input) — информация, которая используются или преобразуются работой для получения результата.

Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая диаграмма должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань диаграммы.

Выход (Output) —информация, которая производятся в процессе работы. Каждая диаграмма должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться.

Механизм (Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и так далее. Стрелка механизма рисуется как входящая в нижнюю грань диаграммы.

Вызов (Call) — специальная стрелка, указывающая на другую диаграмму модели. Стрелка вызова рисуется как исходящая из нижней грани работы.

Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий.

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

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

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

 

2  Проетирование информационной системы

2.1 Разработка технического задания

1. Введение

1.1. Наименование программы

Интернет –  магазин компьютерных товаров.

1.2. Назначение  и область применения

Программа предназначена  для управления базой данных, содержащей следующие данные:

1.2.1. Предложения  фирм – поставщиков

1.2.2. Прейскуранты цен  на товары

1.2.3. Возможность проведения статистических анализов (изменение цен)

1.2.4. Данные по  покупателям

1.2.5. Данные по  фирмам – изготовителям

Программа предоставляет  веб – интерфейс для управления содержимым в соответствии с протоколом http.

2. Требования  к программе

2.1. Требования  к функциональным характеристикам

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

2.1.1. Разделение  пользователей, подключенных через  интернет, на группы:

2.1.1.1. Администраторы  базы данных

2.1.1.2. Авторизованные

2.1.1.3. Неавторизованные

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

2.1.3. Возможность  заказа выбранного товара в  режиме он – лайн авторизованными  пользователями. Подключение конкретной  платежной системы в условия  технического задания не входит.

2.1.4. Возможность  оплаты он – лайн или в офисе продаж компании.

2.1.5. Возможность  поиска по базе данных информации  по фирмам – производителям.

2.1.6. Для администраторов  возможность поиска по базе  информации по покупателям.

2.1.7. Для администраторов   возможность анализа в базе  динамики изменения цен, объемов продаж и объемов поставки.

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

2.2. Требования  к надежности 

2.2.1. Требования  к обеспечению надежного функционирования  программы

Надежное функционирование программы обеспечивается выполнением Заказчиком следующих организационно – технических мероприятий:

  1. Организация бесперебойного электропитания технических средств
  2. Использование лицензированного программного обеспечения
  3. Регулярное выполнение рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 года об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПК, и оргтехники, и сопровождению программных средств.
  4. Регулярное выполнение требований ГОСТ 51188-98, защита информации, испытание программных средств на наличие вирусов

2.2.2. Время восстановления  после отказа

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

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

2.2.3. Отказы из  – за некорректных действий  пользователей системы

Отказы программы  вследствие некорректных действий пользователей  при взаимодействии с программой через веб – интерфейс недопустимы.

3. Условия эксплуатации

3.1. Климатические  условия эксплуатации

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

3.2. Требования  к квалификации и численности  персонала

Информация о работе Информационная система для интернет – магазина компьютерных товаров