1 Анализ предметной области и постановка задачи

1.1 Анализ работы малого предприятия

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

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

Вся деятельность предприятий базируется на Законах Украины «О предпринимательской деятельности в Украине» [6], «О налогообложении», «О законе на добавленную стоимость» и т.д. Вот почему и разрабатываемая система должна учитывать особенности национального законодательства. Сфера деятельности малого предприятия – мебельный бизнес: изготовление и продажа мебели различного назначения.

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

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

Перечисления осуществляет банк, на основе платежного поручения,оформляя необходимые документы. В платежном поручении ставится отметка банка (наименование, число, МФО).После предоплаты и оформления сопроводительных документов товарпоставляется предприятию.

Прием товара на склад осуществляется кладовщиком, на основе сопроводительных документов: товарной накладной, счета-фактуры, установочных ярлыков, описи; сопроводительных документов удоставеряющих качество. Составляется приходная накладная или Акт о приемке кладовщиком. Заполняется карточка – формуляр о товаре, в которой указаны следующие атрибуты: наименование товара, код товара, производитель, сорт (категория), единица измерения. Имеется разлинеянная область подсчета товара: дата, количество, которая отражает реально полученное количество товара на склад, а в журнале регистрации прихода товара указывается реальное количество товара находящееся на складе. Атрибуты: № прих. накладной, дата, номер товарной накладной, от кого (имя организации). Кладовщик является материально ответственным лицом.

Затем приходной ордер,счет-фактура передаются в бугалтерию для оприходывания товара в стоимостной категории. Так же прилагается выписка “Информация о платеже”, подтверждение о проплате поставщику.

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

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

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

Фирма-заказчик перечисляет деньги со свого расчетного счета на расчетный счет предприятия. Основанием служит платежное поручение. Перечисление осуществляет банк. Заказчику выдается уведомление об оплате.

Оплата товара может осуществляться через кассу предприятия, “наличными”, если сумма товара не превышает 3000 грн.Бухгалтерией выписывается приходный кассовый ордер, форма № КО1. На основании накладнойна товар (ТТН), счета-фактуры,кладовщик отпускает товар. При этом составляется расходная накладная, которая фиксируется в журнале отгрузки товарной продукции.

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

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

Коммерческий директор работает с электоронными таблицами Microsoft Excel, помечая для себя заметки о дальнейшей деятельности предприятия на основе составленной документации. Все эти операции разрознены.

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

Предполагается, что автоматизация позволит:

• - сократить временные и трудовые затраты:

• при закупке материалов и фурнитуры;

• при продаже готовой мебели;

• при выписке документов;

• поднять производительность труда;

• принимать правильные решения за счет получения оперативных данных;

• достичь высокого уровня обслуживания.

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

• операции с товарной продукцией: прием/отгрузка со склада, учет;

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

• операции с заказниками: принятие и регистрация заказов, выписка платежного требования, обсуждение с заказчиком о предмете поставки, выписка документов на отгрузку;

• операции с поставщиками: заключить договор на поставку товара, оплата по платежному поручению за товар( перечисление денег на счет поставщика ), оформление документацию на отгрузку товара.

1.2 Выбор логической и концептуальной моделей данных

Поскольку предполагается, что программный продукт должен будет обрабатывать и хранить большой объем данных, то целесообразно хранить эту информацию определенным образом в БД. Задача БД заключается в хранении всех данных для некоторой организации в одном месте, учитывая и заведомо исключать их избыточность [5]. В хорошо спроектированной базе данных исключается избыточность данных, вероятность сохранения противоречивых данных сводится к минимуму. Тогда разрабатываемый программный продукт можно отнести к классу систем управления базами данных (СУБД). Любая СУБД основывается на определенной модели данных.

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

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

Реляционная модель базы данных была первоначально разработана доктором Коддом в начале 1970-х годов [4]. В основе реляционной модели лежит математическое понятие теоретико-множественного отношения [4], которое представляет собой подмножество декартова произведения списка доменов. Домен - это просто множество значений. Например, множество целых чисел есть домен. Декартовым произведением доменов D1,D2,..,Dk (обозначается как D1D2..Dk) называется множество всех кортежей (v1,v2,..,vk) длины k, таких, что v1 принадлежит D1, v2 принадлежит D2 и т.д. Например, если k=2, D1={0.1} и D2={a, b, c}, то D1D2 есть {(0,a), (0,b), (0,c), (1,a), (1,b), (1,c)} [3]. Отношением называется некоторое подмножество декартова произведения одного или более доменов. Поскольку речь идет о базах данных, нет смысла обсуждать бесконечные отношения. Поэтому мы будем предполагать, если не оговорено противное, что отношение является конечным. Например, {(0,a), (0,c), (1,b)} есть отношение, подмножество определенного выше D1D2. Другим примером отношения может служить пустое множество. Элементы отношения называются кортежами. Удобно представлять отношение как таблицу, где каждая строка есть кортеж и каждый столбец соответствует одному компоненту. Столбцы называются при этом атрибутами, и им обычно присваиваются имена. Список имен атрибутов отношения называется схемой отношения. Если отношение называется REL и его схема имеет атрибуты A1,A2,..,Ak, то такую схему чаще всего будем записывать как REL(A1,A2,..,Ak). Совокупность схем отношений, используемых для представления информации, называется схемой (реляционной) базы данных, а текущие значения соответствующих отношений - (реляционной) базой данных. Понятие ключа отношения имеет, по существу тот же смысл, что и понятие ключа в контексте файлов или наборов объектов. Предполагается, что отношение не должно иметь двух кортежей, в которых совпадают все атрибуты ключа. Отношения в реляционных моделях данных, связываются друг с другом связями следующих видов: "один к одному", "один ко многим" и "многие ко многим". Правильное проектирование реляционной модели подразумевает использование сжатой информации, которой достаточно для создания и полной структуры базы данных. Такая информация представляет собой концептуальную модель, применение такой модели позволяет определить необходимые данные для хранения в базе данных, свести число хранимых отношений к минимуму, нормализовать отношения для упрощения решения проблем, связанных с обновлением и удалением данных. Метод декомпозиции отношений основан на 4-х нормальных формах отношений и вполне пригоден при условии небольшого количества задействованных атрибутов. На практике применяются в основном только первые 3 нормальные формы [7].

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

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

Для выбора концептуальной модели данных рассмотрим три их разновидности:

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

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

Модель "сущность-связь" описывает в терминах сущность, связь, значение. Сущность - понятие, которое может быть идентифицировано. Связь - соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграмма. Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность - это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя и более сущностями типа "многие ко многим" или подобные им.ER-диаграмма–этографическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей - ромбом. Связи могут быть трех типов: "1 к 1", "1 к n", "n кn", данные типы связей присущи реляционной модели, как и сущности, которым в реляционной модели соответствуют таблицы. В связи с тем, что модель "сущность-связь" наиболее близка по принципам организации к реляционной модели и реализация последней на основе первой наиболее удобно, то в качестве концептуальной модели выбрана модель "сущность-связь".

1.3 Методологии и технологии проектирования

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

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

Совокупное название автоматизации действий программной инженерии – CASE: компьютеризированная программная инженерия. Пакет программного обеспечения, который автоматизирует только одно действие, называется средством CASE, а выбор средств, которые используются соответствующим способом называются средой программной инженерии [7].

Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС.

Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла (ЖЦ).

Рассмотрим технологию проектирования как совокупность трех составляющих:

• пошаговой процедуры, определяющей последовательность технологических операций проектирования в нотации IDEF0 (рис. 1.1);

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

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

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

Рисунок 1.1 - Представление технологической операции проектирования

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

• технология должна поддерживать полный ЖЦ ПО;

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

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

• технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек);

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

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

• технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), ОС, языков и систем программирования);

• технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

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

Рисунок 1.2 - Физическая ДПД между поставщиком и предприятием

Декомпозиция (иногда называется пошаговым упрощением) – это такой подход к проблеме, когда проблема разделяется на несколько субпроблем. Это делает систему более понятной (рис. 1.3).

Рисунок 1.3 - Декомпозиция физическойДПД между поставщиком и предприятием

1.5Постановка задачи

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

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

Главными задачами, которые необходимо решить для автоматизации мебельного производства являются:

• изучение процессов, происходящих при движении товарной продукции и финансов на малом предприятии.

• составление технического задания на разработку ПП автоматизированной системы поддержки принятия решений по учетутоварана малом предприятии.

• выбор реализации модели данных.

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

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

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

• обеспечение безопасности жизнедеятельности (БЖД) пользователей компьютерной техники в вычислительном центре при разработке ПП.

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

Основными задачами программного продукта (ПП) являются:

Создание серверной части ПП содержащей БД, которая хранит информацию: о товарах; о поставщиках; о заказчиках; о банках; о договорах; о финансах.

Создание клиентской части для управления БД, основные функции которой:

• добавление данных в БД;

• изменение данных в БД;

• удаление данных в БД;

• реализация запросов;

• формирование отчетов.

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

ПП должен содержать информацию:

• о товарах;

• о поставщиках;

• о заказах;

• о накладных

• о заказчиках;

• о договорах;

• о движении товара на складе;

• о движении финансов.

ПП должен производить изменения в базе данных:

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

• изменять информацию о товарах, о фирмах, о поставке и продажи, об оплате;

• удалять информацию о товарах, о фирмах, о поставке и продажи, об оплате;

• реализовывать запросы: об остатке товара на складе, при приеме товара на склад, при отгрузке товара со склада;

• формировать отчеты по счетам, накладным, движения товара, движения денежных средств.

Проектируемый программный продукт должен использоваться в ОС Windows ХР. Для нормальной работы ПП необходим компьютер с такими минимальными параметрами:

• процессор 2000MГц (сервер), 1000МГц (клиент);

• оперативная память (ОП) – 1024 MБ(сервер); 512MБ(клиент);

• 20 ГБ свобного дискового пространства;

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

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

Для обеспечения надежной работы системы должно быть реализовано:

- обеспечение целостности данных;

- обеспечение контроля корректности входных данным;

- обеспечение защиты данных от несанкционированного доступа;

- восстановление системы после аварийного завершения операции над данными.

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