Разработка проекта информационной системы для супермаркета(Анализ деятельности супермаркета)

Содержание:

введение

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

При разработке данной автоматизированной системы в курсовой работе используются следующие программные продукты: CASE средство ERwin - для создания логической и физической модели БД и CASE средство BPwin - для проектирования структуры системы. Для программной реализации используются СУБД MS Access и среда программирования Borland Delphi 7.

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

Для достижения данной цели необходимо решить следующие задачи:

• осуществить аналитическое проектирование;
• определить назначение решаемых задач проектируемой ИС;
• определить структуру и алгоритма функционирования проектируемой ИС;
• разработать функциональную модель проектируемой ИС;
• разработать информационную модель;
• разработать прототипа ИС средствами MS Access/Delphi 7;
• оценить работоспособность и эффективность разработанного прототипа ИС;

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

Объектом исследования является информационная система для супермаркета.

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

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

1 аналитическое проектирование

1.1 Анализ деятельности супермаркета

В рамках данной курсовой работы в качестве предметной области рассматривается супермаркет.

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

Организационная структура продуктового магазина представлена на рисунке 1.1.

Директор магазина

Торгово-оперативный отдел

Вспомогательный персонал

Главный бухгалтер

Управляющий магазином

Продавцы

Уборщица

Кладовщик

Грузчики

Рисунок 1.1 – Организационная структура магазина

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

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

Каждый товар поставщик отпускает по определенной цене, указанной в прилагаемом прайс-листе.

На основании прайс-листа и государственной нормативной документации рассчитывается розничная цена товара для покупателей (клиентов). Товары с установленной на них розничной ценой отправляются на реализацию в торговый зал магазина.

1.1.1 Функциональное моделирование предметной области

Наиболее удобным языком моделирования процессов является методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования), предложенная более 30 лет назад Дугласом Россом и опробована на практике в период с 1969 по 1973 г. SADT – это способ функционального моделирования разработан на базе методологии структурного анализа систем, в основе которой лежала идея декомпозиции основных процессов деятельности на составляющие.

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

В основе методологии SADT лежат два основных принципа:

• 1. SA-блоки, на основе которых создается иерархическая многоуровневая модульная система, каждый уровень которой представляет собой законченную систему (блок), поддерживаемую и контролируемую системой (блоком), находящейся над ней.
  2. Декомпозиция. Использование этой концепции позволяет разделить каждый блок, понимаемый как единое целое, на свои составляющие, описываемые на более детальной диаграмме. Процесс декомпозиции проводится до достижения нужного уровня подробности описания. Диаграмма ограничивается 3-6 блоками для того, чтобы детализация осуществлялась постепенно. Вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта.

Применение SADT методологии основано на формализованном процессе создания системы, при разбиении его на следующие фазы:

• анализ – определение того, что система будет делать;
• проектирование – определение подсистем и их взаимодействие;
• реализация – разработка подсистем по отдельности;
• объединение – соединение подсистем в единое целое;
• тестирование – проверка работы системы;
• установка – введение системы в действие;
• функционирование – использование системы.

Обычно SADT-методология применяется на ранних этапах жизненного цикла информационной системы.

Для моделирования предметной области выбрано CASE-средство BPWin.

BPWin поддерживает три методологии структурного анализа и моделирования систем – IDEF0, IDEF3 и DFD. В процессе создания модели бизнес-процесса на любой ветви можно переключиться на любую из методологий и создать смешанную модель.

BPwin - это незаменимый инструмент менеджеров и бизнес-аналитиков, а начиная с версии 1.8, в которую включена поддержка диаграмм потоков данных и методики IDEF3 (BPwin Professional), становится в руках системных аналитиков и разработчиков и мощным средством моделирования процессов при создании корпоративных информационных систем.

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

BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании. Встроенный механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) - это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа.

BPwin может генерировать отчеты непосредственно в формате MS Excel и Word для последующей обработки и использования в других приложениях. Связь с ERwin (моделирование данных в стандарте IDEF1X) позволяет сократить время проектирования и разработки сложных информационных систем. Для системных аналитиков тесная интеграция BРwin с инструментом проектирования баз данных открывает уникальные возможности по созданию комплексных систем, в которых ERwin служит для описания информационных объектов системы, в то время как BPwin отражает функциональные особенности предметной области.

1.1.2 Деятельность магазина в нотации IDEF0

Подмножеством методологии структурного анализа и проектирования SADT является методология функционального моделирования IDEF0.

Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм.

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

Модель может содержать четыре типа диаграмм:

• контекстную диаграмму;
• диаграммы декомпозиции;
• диаграммы дерева узлов;
• диаграммы только для экспозиции (FEO).

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

• 1. Левая сторона предназначена для входа. Вход – материал или информация, которые используются или преобразуются для получения результата (выхода).
  2. Правая сторона предназначена для выхода. Выход – результат выполнения функции.
  3. Верхняя сторона используется для управления. Управление – условия, правила, стратегии, стандарты, которые влияют на выполнение функции.
  4. Нижняя сторона – для механизмов. Механизм – ресурсы, с помощью которых выполняется работа.^[1]

Управляющая информация входит в блок сверху в то время, как входная информация, которая подвергается обработке, показаны с левой стороны блока, а результаты (выход) - справа. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей снизу. Пример функционального блока представлен на рисунке 1.2.

Рисунок 1.2 – Функциональный блок в методологии IDEF0

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

Рисунок 1.3 – Контекстная диаграмма

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

Входы (слева):

1. Данные о товаре.
2. Заявки на поставку товара.
3. Заявки клиентов на обслуживание.
4. Прайс-лист.

Выходы (справа):

1. Прибыль.
2. Удовлетворение потребности клиента.
3. Отчетность.

Механизмы и управление (сверху):

1. Действующее законодательство.
2. Должностные инструкции.
3. Нормативные акты.

Ресурсы (снизу):

1. Персонал.
2. Оборудование.
3. Вычислительная техника.

Основную работу «Деятельность продуктового магазина» можно разбить на три более мелкие работы:

• • закупка товара у поставщиков;
  • хранение;
  • реализация продукции;

На рисунке 1.4 представлена диаграмма декомпозиции «Как есть».

Рисунок 1.4 – Диаграмма декомпозиции процесса «Деятельность продуктового магазина» As is”

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

Входной информацией для работы «Хранение товара» являются данные о товаре.

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

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

Работу «Реализация продукции» можно разбить на пять более мелкие работы:

• • установка розничных цен на товар;
  • запись о поставке в журнале;
  • продажа продукции клиентам;
  • учет продаж;
  • формирование отчетов.

На рисунке 1.5 представлена диаграмма декомпозиции «Как есть» работы «Реализация продукции».

Рисунок 1.5 – Диаграмма декомпозиции работы «Реализация продукции» “As is”

1.1.3 Модель DFD

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

• функции обработки информации (работы);
• документы, объекты, сотрудников, которые участвуют в обработке информации;
• внешние ссылки, которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
• таблицы для хранения документов (хранилище данных).

При построении диаграмм можно выделить элементы графической нотации (таблица 1.1).

Таблица 1.1 - Элементы графической нотации DFD

Наименование	Вид
Поток данных
Процесс
Накопитель данных
Внешняя сущность

DFD – диаграмма работы «Деятельность продуктового магазина» представлена на рисунке 1.6.

Рисунок 1.6 – DFD-диаграмма работы «Деятельность продуктового магазина» «Как есть»

Дальнейшая детализация процесса представлена на рисунке 1.7.

Рисунок 1.7 – Детализированная DFD-диаграмма работы «Деятельность продуктового магазина» «Как есть»

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

1.1.4 Модель IDEF3

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.

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

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

     Модель, выполненная в IDEF3, может содержать следующие элементы:

1. Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0. 
2. Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей: 

• Связь предшествования (Precedence) – показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией. 
• Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией. 
• Поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками. 

1. Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса, могущие возникнуть во время его выполнения. Различают два типа перекрестков: 

• Перекресток слияния (Fan-in Junction) – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса. 
• Перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно. 

1. Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы. 

На рисунке 1.8 представлена IDEF3-модель деятельности продуктового магазина.

Рисунок 1.8 – IDEF3-модель деятельности продуктового магазина «Как есть»

1.1.5 Концептуальная модель

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

В данном курсовом проекте для разработки концептуальной модели использовалось CASE-средство ERwin.

ERwin - средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных.

На рисунке 1.9 представлена концептуальная модель (ER-диаграмма) информационной системы продуктового магазина «Как есть», реализованная в ERwin.

Рисунок 1.9 – Концептуальная модель «Как есть»

1.2 Требования к качеству и оперативности (эффективности) деятельности магазина

Для эффективной работы продуктового магазина необходимо осуществление следующих требований:

1. Анализ потребностей целевой аудитории - формирование ассортимента, который хорошо покупается, эффективное управление закупками и складом.
2. Оперативный анализ поставок и продаж.
3. Анализ и оценка работы персонала – контроль, минимизация злоупотреблений со стороны сотрудников.
4. Эффективное управление финансами, взаиморасчетами с контрагентами.
5. Привлечение новых покупателей – маркетинговые мероприятия, способствующие повышению уровня продаж.
6. Составление отчетных документов для анализа деятельности и принятия необходимых управленческих решений.

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

1.3 Оценка соответствия деятельности магазина к предъявляемым требованиям по эффективности

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

Анализ проблем деятельности продуктового магазина представлен в таблице 1.2.

Таблица 1.2 – Проблемы и затраты связанные с ними

N	Проблема	Время t(существующее) в неделю	Затраты, руб.
1	Учет поставок и продаж	7 часов	1050
2	Формирование отчетных документов	3 часа	450
3	Поиск информации о товаре, поставщиках и тд.	2 часа	300
Итого:		12 часов	1800

Таким образом, отсутствие автоматизации некоторых процессов продуктового магазина приводит к затрате времени 12 часов в неделю и к финансовой потере в размере 1800 руб. в неделю.

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

1.4 Анализ существующих подходов к автоматизации деятельности магазина

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

Рассмотрим наиболее популярные из них:

1. «1С Управление торговлей 8»

Прикладное решение «1С Предприятие 8. Управление торговлей» в комплексе решает задачи оперативного учета в управлении, анализа и планирования торговых операций и их обеспечения; автоматизирует торговые, финансовые и складские контуры управления; обеспечивает современный уровень управления торговым предприятием. Помогает реализовавать торговые схемы и учет склада. Управление предприятием, автоматизируемое программой «1С:Управление торговлей 8», может быть представлено в виде следующей схемы.

1С УТ автоматизирует следующие направления хозяйственной деятельности:

• управление продажами (включая оптовую, розничную и комиссионную торговлю);
• управление поставками;
• планирование продаж и закупок;
• управление складскими запасами;
• управление заказами покупателей;
• управление отношениями с клиентами;
• анализ товарооборота предприятия;
• анализ цен и управление ценовой политикой;
• мониторинг и анализ эффективности торговой деятельности.

Цена базовой версии - 5680 руб.

Техподдержка – 1000 руб.

2. ERP-решения

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

Комплексные информационные системы управления (ERP) являются базовым механизмом управления ресурсами современного предприятия. Они позволяют связать все бизнес-процессы, информацию и внешние отношения предприятия в единую систему. ERP-система поддерживает все функции менеджмента – от определения целей до контроля исполнения.

Цена 50000 руб.

Цена за доп. рабочее место – 8000 руб.

Техподдержка – 9000 руб.

1.5 Постановка задачи на курсовое проектирование

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

Информационная система должна отвечать следующим требованиям:

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

Система должна содержать базу данных:

• товаров;
• видов товаров;
• поставщиков;
• поставок;
• сотрудников;
• продаж.

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

Разрабатываемая ИС должна реализовывать поиск в базе данных сведений о:

• товарах;
• поставщиках;
• поставок товара;
• сотрудниках магазина;
• продажах.

Выводы: в результате аналитического проектирования построена модель информационной системы продуктового магазина в нотациях idef0,dfd, idef3, а также построена концептуальная модель посредством CASE-средства ERwin. Анализ модели показал, что отсутствие автоматизации бизнес-процессов супермаркета приводит к потерям времени из-за выполнения некоторых задач вручную. Эта потеря времени может быть выражена в финансовых потерях: магазин теряет 1800 руб. в неделю. Таким образом, необходима разработка специализированной информационной системы для автоматизации учета поставок и продаж.

2 проектная часть

2.1 Определение назначения и решаемых задач проектируемой ИС

Информационная система разрабатывается для продуктового магазина. Основными ее функциями являются:

1. Учет справочной информации (ИС должна содержать справочники «Товары», «Поставщики», «Группы товаров», «Единицы измерения», «Сотрудники», «Должности», «Производители»).
2. Учет поставок и продаж (ИС должна предоставлять возможность добавления, редактирования и удаления сведений о поставках и продажах).
3. Формирование отчетности (Возможность формирования отчета о продажах и списка товаров).
4. Оперативный доступ к информации. (Должна обеспечивать оперативный доступ к информации и возможность поиска и сортировки).

2.2 Определение структуры и алгоритма функционирования проектируемой ИС

Структура функционирования ИС представлена на рисунке 2.1.

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

Запуск ИС

1. Главное меню

2. Продажи

3. Поступление товара

Главное окно

1.1.1 Новая запись

1.1.2 Удалить запись

1.1.3 Печать отчета о продажах

1.1.4 Выход

1.1 Файл

2 Продажи

3 Поступление товара

1.2.1 Товары

1.2.2 Группы товаров

1.2.3 Ед. измерения

1.2.4 Сотрудники

1.2.5 Должности

1.2.6 Поставщики

1.2.7 Должности

1.2 Справочники

1 Просмотр

2 Добавление

3 Редактирование

1.2.* Справочники

1.1 Файл

1.2 Справочники

1 Главное меню

2.1 Просмотр продаж

2.2 Добавление записи

2.3 Редактирование

2.4 Сортировка

3.1 Просмотр

3.2 Добавление

3.3 Редактирование

Рисунок 2.1 - Структура функционирования ИС

Алгоритм - это определенная последовательность логических действий для решения поставленной задачи.

На рисунке 2.2 представлен алгоритм функционирования ИС.

Удалить?

Выбор действия

Ввод данных

Конец

Удалить?

Ввод данных

Вывод отчета

Выбор действия

Начало

19

26

25

Удаление записи

17

21

20

Редактирование

Добавление новой записи

Удаление записи

18

10

24

23

Сохранение изменений

22

35

Выйти

27

Нет

Да

Сохранение изменений

Удаление записи

Сохранение изменений

Редактирование

Выйти из ИС

Перейти к справочникам

Перейти к поступления

Печать отчета

Добавление новой записи

Удаление записи

Вывод на главной форме информации о продажах

9

Нет

Да

Сохранение изменений

15

16

13

14

12

11

Выбор справочника

8

7

6

5

4

3

1

2

Рисунок 2.2 – Алгоритм функционирования ИС

2.3 Разработка функциональных моделей проектируемой ИС

2.3.1 Модель idef0 (“Как будет”)

Диаграмма «to be» в нотации idef0 процесса «Реализация продукции» представлена на рисунке 2.3.

Рисунок 2.3 – Диаграмма процесса «Реализация продукции» to be

Как видно из диаграммы процесс «Реализация продукции» состоит из пяти более мелких процессов:

1. Учет товаров.
2. Запись о поставке в ИС.
3. Продажа продукции.
4. Учет продаж.
5. Формирование отчетов.

По сравнению с моделью «as is» вместо процесса «Установка розничных цен на товар» осуществляется «Учет товаров», так как теперь вся информация о товаре хранится в информационной системе и у каждого товара указывается его розничная стоимость. При необходимости продавец может изменить стоимость товара, добавить новый товар в базу или удалить его. Далее осуществляется процесс «Запись о поставке в ИС». Если до внедрения ИС запись о поставке осуществлялась в ручную в журнал поставок, то теперь запись о поставках осуществляется в ИС на основе накладных, которые поступают продавцу со склада вместе с товаром. «Учет продаж» осуществляется посредством ИС, кроме того появляется возможность автоматизированного формирования отчетов о продажах.

2.3.2 Модель dfd (“Как будет”)

Dfd-диаграмма «to be» представлена на рисунке 2.4.

Рисунок 2.4 - Dfd-диаграмма «to be»

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

2.3.3 Модель idef3 (“Как будет”)

Dfd-диаграмма «to be» представлена на рисунке 2.5.

Рисунок 2.5 – idef3-диаграмма «to be»

2.4 Разработка информационной модели

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

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

Самой популярной моделью концептуального проектирования является модель «сущность-связь» (ER-модель), она относится к семантическим моделям.

Основными элементами модели являются сущности, связи между ними и их свойства (атрибуты).

Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели.

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

Атрибут – характеристика (параметр) некоторой сущности.

Домен – множество значений (область определения атрибутов).

У сущностей выделяются ключевые атрибуты – ключ сущности – это один или более атрибутов, уникально определяющих данную сущность.

Между сущностями могут быть уставлены связи – бинарные ассоциации, показывающие, каким образом сущности относятся или взаимодействуют между собой.^[2]

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

• 1. «Товар». Атрибуты: Код товара, Наименование, Единица измерения, Группа товаров, Производитель, Стоимость, Остаток.
  2. «Поставщик». Атрибуты: Код, Наименование, Адрес.
  3. «Производитель». Атрибуты: Код, Наименование, Адрес.
  4. «Поставка». Атрибуты: Номер накладной, Дата поставки, Код товара, Количество, Поставщик, Сотрудник.
  5. «Продажа». Атрибуты: Дата продажи, Код товара, Количество, Сотрудник.
  6. «Сотрудник». Атрибуты: Код, ФИО, Должность.

На рисунке 2.6 представлена логическая схема БД, на рисунке 2.7 представлена физическая схема БД, реализованные в ERwin.

Рисунок 2.6 – Логическая схема БД

Рисунок 2.7 – Физическая схема БД

2.5 Интерфейсное решение проектируемой ИС

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

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

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

• набор задач пользователя, которые он решает при помощи системы;
• используемая системой метафора (например, рабочий стол в MS Windows);
• визуальный (и не только) дизайн экранов программы;
• средства отображения информации, отображаемая информация и форматы;
• устройства и технологии ввода данных;
• диалоги, взаимодействие и транзакции между пользователем и компьютером;
• обратная связь с пользователем;
• поддержка принятия решений в конкретной предметной области;
• порядок использования программы и документация на нее.

В дизайне пользовательского интерфейса можно условно выделить декоративную и активную составляющие. К первой относятся элементы, отвечающие за эстетическую привлекательность программного изделия. Активные элементы подразделяются на операционные и информационные образы моделей вычислений и управляющие средства пользовательского интерфейса, посредством которых пользователь управляет программой. К примеру, в создаваемом программном продукте активной составляющей является элемент изменения размеров таблицы. Управляющие средства различных классов программных изделий могут значительно различаться. Классы интерфейса являются слишком широкими понятиями. Классы, задаваемые базовыми интерактивными средствами, целесообразно разбить на подклассы, например, в пределах графического класса различаются подклассы: двухмерные и трехмерные интерфейсы. По этой классификации широко распространенный интерфейс WIMP относится к первому из указанных подклассов. В основе управляющих средств пользовательского интерфейса лежит тот или иной интерфейсный язык. При этом роль синтаксиса играют используемые графические образы и их динамические свойства. Сегодня развиваются такие новые классы интерфейсов, как SILK (речевой), биометрический (мимический) и семантический (общественный). В основе управляющих средств пользовательского интерфейса лежит тот или иной интерфейсный язык. При этом роль синтаксиса играют используемые графические образы и их динамические свойства. Дизайн конкретных реализаций интерфейса может включать композицию, различных типов управляющих средств, информационные образы предметной области и декоративные элементы.^[3]

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

Область главного меню

Область учета продаж

Область навигации по записям

Кнопка «Поступления»

Область сортировки

Рисунок 2.8 – Структура главной формы ИС

Все другие окна программы будут иметь вид представленный на рисунке 2.9.

Область вывода информации

Область кнопок управления

Рисунок 2.9 – Структура окон ИС

2.6 Разработка прототипа ИС средствами MS Access/Delphi 7.0

Для программной реализации информационной системы выбраны СУБД MS Access и среда программирования Borland Delphi 7.

Выбор системы управления базами данных (СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке программного обеспечения.

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

Чтобы выбрать СУБД, вначале необходимо определиться с целью её использования. Если нужно создать «настольную» базу данных, то для этого идеально подходит Microsoft Access, так как она создавалась для этих целей.

Microsoft Access – это приложение, предназначенное для создания и редактирования баз данных. Данная СУБД входит в состав пакета офисных программ Microsoft Offiсe.

СУБД Access (фирма Microsoft) имеет высокие скоростные характеристики. Она входит в состав чрезвычайно популярного в нашей стране и за рубежом пакета прикладных программ Microsoft Office. Набор команд и функций, которые предлагаются разработчикам программных продуктов в среде Microsoft Access, по гибкости и мощи отвечает большинству современных требований к представлению и обработке данных. В Microsoft Access поддерживаются разнообразные многоуровневые и всплывающие меню, работа с окнами и мышью, в ней реализованы функции низкоуровневого доступа к файлам, настройки принтера, управление цветами, представления данных в виде электронных таблиц. Система обладает средствами быстрой генерации экранов, меню и отчетов, поддерживает язык управления запросами SQL, имеет встроенный язык Visual Basic for Applications (VBA), хорошо работает в сети. СУБД Access позволяет использовать другие компоненты пакета Microsoft Office, такие как текстовый процессор Word for Windows, электронные таблицы Excel.

Microsoft Access включает в себя средства, которые существенно упрощают разработку БД. К таким средствам относятся:

1. Модули форм, отчетов и процедуры обработки событий.

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

3. Модель событий, похожая на используемую в языке Microsoft Visual Basic. Она позволяет приложениям реагировать на возникновение различных событий, например, перемещение мыши, нажатие клавиши на клавиатуре или истечение определенного промежутка времени.

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

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

6. Улучшенные средства отладки. Помимо пошагового выполнения программ на языке VBA и установки точек прерывания, можно вывести на экран список всех активных процедур.

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

8. Процедура обработки ошибок. Помимо традиционных способов обработки ошибок возможно использование процедуры обработки события Error для перехвата ошибок при выполнении программ и макросов.

9. Программы-надстройки. С помощью VBA можно создавать программы-надстройки, например, нестандартные мастера и построители.

10. Программная поддержка механизма OLE. С помощью механизма OLE можно обрабатывать объекты из других приложений.

В СУБД Microsoft Access процесс создания реляционной БД включает создание схемы данных. Схема данных наглядно отображает таблицы и связи между ними, а также обеспечивает использование связей при обработке данных и целостность БД. Схема данных представляет неразрывную связь немашинного проектирования БД с этапом её создания.^[4]

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

Анализ задачи показывает, что для реализации требуемых функций подходят различные языки программирования (Visual C++, C++ Builder, Delphi и др.). Все они обладают достаточно эффективными средствами для реализации поставленных задач. Для реализации программы оптимальной загрузки производственных мощностей был использован язык программирования Delphi.

Delphi – одна из самых мощных систем, позволяющих на самом современном уровне создавать как отдельные прикладные программы Windows, так и разветвленные комплексы, предназначенные для работы в корпоративных сетях и Интернет. Это мощная система визуального объектно-ориентированного программирования, позволяющая решать множество задач, в частности:

• создавать законченные приложения для Windows самой различной направленности, от вычислительных и логических, до графических и мультимедиа;
• быстро создавать профессионально выглядящий оконный интерфейс для любых приложений, написанных на любом языке; интерфейс удовлетворяет всем требованиям Windows и автоматически настраивается на ту систему, которая установлена на компьютере пользователя, поскольку использует многие функции, процедуры, библиотеки Windows;
• создавать мощные системы работы с локальными и удаленными базами данных любых типов; при этом имеются средства автономной отладки приложений с последующим выходом в сеть;
• создавать приложения, которые управляют другими приложениями, в частности, такими программами Microsoft Office, как Word, Excel и др.
• создавать приложения различных классов для работы в Интернет;
• создавать профессиональные программные установки для приложений Windows, учитывающие всю специфику и все требования Windows.^[5]

На рисунке 2.10 представлена главная форма, реализованная в Delphi 7.

Рисунок 2.10 – Главная форма

На данной форме используются следующие компоненты:

• меню MainMenu1, при помощи данного компонента происходит переключение между формами в программе;
• компонент DBGrid, предназначен для отображения информации из таблиц базы данных;
• кнопка BitBtn, пиктографическая кнопка служит для выдачи команд на выполнение определенных функциональных действий;
• компонент RadioGroup, используется для отображения радиокнопок на панели.

На рисунке 2.11 представлена форма «Поступление товара».

Рисунок 2.11 - Форма «Поступление товара»

На данной форме используются следующие компоненты:

• компонент DBGrid, предназначен для отображения информации из таблиц базы данных;
• компонент DBNavigator, обеспечивает перемещение указателя текущей записи, активизацию режима редактирования, добавление и удаление записей. Компонент представляет собой совокупность командных кнопок.

Все остальные окна программы организованы аналогично.

Главное меню программы содержит два пункта: Файл и Справочники. Вид главного меню c пунктами и подпунктами представлен на рисунке 2.12.

Рисунок 2.12 – Главное меню, реализованное в Delphi

ЗАКЛЮЧЕНИЕ

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

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

Решены следующие задачи:

• осуществлено аналитическое проектирование;
• определено назначение решаемых задач проектируемой ИС;
• определена структура и алгоритм функционирования проектируемой ИС;
• разработана функциональную модель проектируемой ИС;
• разработана информационная модель;
• разработать прототипа ИС средствами MS Access/Delphi 7;
• оценена работоспособность и эффективность разработанного прототипа ИС;

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

Список использованных источников

1. Агальцов В.П. Базы данных. – 2-е изд., перераб. – М.: Форум, 2013 – 349 с.: ил., табл.
2. Баканов М.В., Романова В.В., Крюкова Т.П. Базы данных. Системы управления базами данных: учебное пособие / М.В. Баканов, В.В. Романова, Т.П. Крюкова; Кемеровский технологический институт пищевой промышленности. - Кемерово, 2010. – 166 с.
3. Баранчинков А.И. Алгоритмы и модели ограничения доступа к записям баз данных. – М.: Горячая линия – Телеком, 2011. – 181 с.: ил.
4. Бураков П.В., Петров В.Ю. Введение в системы баз данных: Учебное пособ. - Изд-во: СПбГУ ИТМО, 2012. – 129 с.
5. Войниканис Е.А. Базы данных как объект правового регулирования: учебное пособие для вузов. – М.: СТАТУС, 2011. – 172 с.
6. Гурвиц Г.А. Microsoft Access 2010. Разработка приложений на реальном примере. – СПб.: БХВ-Петербург, 2011. – 496 с.
7. Диго С.М. Базы данных. Проектирование и создание. Учебно-методический комплекс. М.: ЕАОИ, 2013. – 171 с.
8. Елиферов В.Г., Репин В.В. «Бизнес-процессы: Регламентация и управление: Учебник». – М.:ИНФРА-М, 2014. – 319с. – (учебники программы МВА).
9. Епанешников А., Епанешников В. Практика создания приложений в ACCESS 2013 Диалог-МИФИ, 2014.
10. Корчагин, С. В. Разработка программных комплексов. [Текст]: учеб. пособие для вузов – М.: "БХВ-Петербург", 2011 – 500с. 2000 – экз. - ISBN 2-4582-12457-5 (в пер.).
11. Клюшин, Д.А. Полный курс Delphi7. [Текст] : уч. пособие для вузов / Т.Р. Бешелев, Г.А. Гурвич; под общ. ред. Д. А. Архангельский. − М.: «Горячая Линия – Телеком», 2011 - 382 с.; 25 см. – Библиогр.: с. 325-363. - Предм. указ.: с.368-377. − 30000 экз. – ISBN 5-3894-673-3.
12. Крылов, Е.В., Острейковский, В.А., Типикин, Н.Г. Техника разработки программ. В 2-х книгах Гриф УМО ВУЗов России [Текст]: − СПб.: Изд-во: Высшая школа, 2012. – 469 с., 3000 экз. – ISBN: 978-5-06-005525-2.
13. Тидвелл, Д. Разработка пользовательских интерфейсов [Текст]. – М.: Издательство «Питер», 2014. – 416.- 2500 экз.- ISBN 978-5-91180-073-4.
14. Федотова Д.Э., Семёнов Ю.Д., Чижик К.Н. CASE-технологии: [Текст]: учебное пособие. – 1-е изд. – М.: «Горячая линия – Телеком», 2015. – 160 с.: ил.; 24 см. – Предм. указ.: с. 153–158. – 3000 экз. – ISBN 5-93507-121-X (мягкая обложка)
15. Хомоненко А.Д., Гофман В.Э. Работа с базами данных в Delphi [Текст]: учебное пособие. – 3-е издание., перераб. и доп. – СПб.: БХВ-Петербург, 2015 – 640с.: ил. ISBN 5-94157-361-8.

1. Федотова Д.Э., Семёнов Ю.Д., Чижик К.Н. CASE-технологии: [Текст]: учебное пособие. – 1-е изд. – М.: «Горячая линия – Телеком», 2015. – 160 с.: ил.; 24 см. – Предм. указ.: с. 153–158. ↑

2. Баканов М.В., Романова В.В., Крюкова Т.П. Базы данных. Системы управления базами данных: учебное пособие / М.В. Баканов, В.В. Романова, Т.П. Крюкова; Кемеровский технологический институт пищевой промышленности. - Кемерово, 2010. – 166 с. ↑

3. Тидвелл, Д. Разработка пользовательских интерфейсов [Текст]. – М.: Издательство «Питер», 2014. – 416.- 2500 экз.- ISBN 978-5-91180-073-4. ↑

4. Епанешников А., Епанешников В. Практика создания приложений в ACCESS 2013 Диалог-МИФИ, 2014. ↑

5. Клюшин, Д.А. Полный курс Delphi7. [Текст] : уч. пособие для вузов / Т.Р. Бешелев, Г.А. Гурвич; под общ. ред. Д. А. Архангельский. − М.: «Горячая Линия – Телеком», 2011 - 382 с.; 25 см. – Библиогр.: с. 325-363. - Предм. указ.: с.368-377. − 30000 экз. – ISBN 5-3894-673-3. ↑