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

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

Введение

программа модель вычислительный магазин

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

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

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

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

1.1 Описание предметной области.

Данная система разрабатывается для работы небольшого магазина по оптовой покупке и реализации одежды. Такое предприятие имеет индивидуальный подход к реализации заказа Клиента. Предприятие должно иметь точные данные не только о клиентах, но и о своих поставщиках, постоянно обновлять закупочные цены на товары (так как они варьируются в зависимости от курса доллара США). Предприятие имеет гибкую систему ценообразования - учитываются сроки оплаты заказа и тип заказанного товара.

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

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

Предприятие имеет определенный запас товаров на складе. Очень важно при поступлении заказа отслеживать движение товара как на склад (покупка у поставщика), так и со склада (продажа заказчику). Склад постоянно обновляется новыми поступлениями, и меняется остаток.

1.2 Анализ технического задания

1.2.1 Функциональные требования к системе

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

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

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

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

Система должна вести учет поставщиков и договоров поставки.

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

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

Система должна автоматически подготавливать текст документа получения материала со склада или поступления материала на склад и вывод этого документа на бумажный носитель.

Формирование списка товаров, договоров, клиентов или поставщиков должно происходить не более чем за 15 секунд, печать документа - не более 30 секунд, формирование различного вида отчетов - не более 1 минуты.

Система должна обеспечивать хранение данных не менее чем о 1000 наименований товаров.

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

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

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

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

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

оплата, предоплата или оплата с отсрочкой,

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

дата заказа,

заказчик и его реквизиты,

сумма заказа,

аванс (если предусмотрена предоплата),

1.2.2 Количественные требования к системе

Требования к конфигурации

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

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

Требования К Количественные и показатели системы

Для облегчения разработки системы ограничим объем записей в системе 2000 строк - это повлияет на выделение необходимого объема памяти на жестком диске, где установлена система, и обеспечит требуемую скорость работы. РЕШЕНИЕ

Время реакции системы должно быть 10 секунд.

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

Этот параметр напрямую зависит от быстродействия вычислительной машины.

1.2.3 Требования к защите информации

Система устанавливается только на одном предприятии и адаптируется под него, но в связи с большой концентрацией конкурентов на рынке МОГУТ возникнуть СЛЕДУЮЩИЕ ВИДЫ опасности:

· несанкционированного доступа??%

· нарушения целостности информации.??%

· ?????

Администратор СИСТЕМЫ приложения обладает всеми необходимыми правами для изменения политики защиты, но необходимости в этом не должно возникать. Ведь в задачу разработчика входит выбор наиболее подходящей политики защиты, которая удовлетворяет требованиям и упрощает процесс администрирования. Внедренные правила системной политики позволяют контролировать, к каким именно компонентам операционной системы будет разрешен доступ разных пользователей разных уровней, какие приложения эти пользователи смогут запускать, а также какой вид будет иметь их рабочий стол. Например, менеджер по продажам имеет право работать со своими формами и таблицами, запускать запросы, просматривать таблицы других пользователей (кладовщика и бухгалтера), но формы и таблицы менеджера могут быть запрещены даже для чтения для кладовщика.

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

Целостность данных подразумевает связь одних и тех же записей из разных таблиц, то есть в системе должно производиться каскадное обновление данных, каскадное изменение. Это требование выполняется программой, в которой разрабатывается система. РЕШЕНИЕ

Надежность

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

создания резервных копий файлов,

периодического сжатия файлов,

защиты файлов средствами шифрования,

введения и изменения пароля для открытия файла,

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

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

Резервное копирование подразумевает создание копий таких файлов, журнал заказов, журнал отчетов, данные по документообороту и необходимых баз данных. Копии этих файлов должны храниться на рабочем месте администратора на жестком диске, а так же создавать копии особо критичных данных на переносных носителях. РЕШЕНИЕ

1.2.4 Требования по совместимости

Удобство

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

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

Реализация

Особых требований к ресурсам система не предъявляет, так как на компьютере должен быть установлен стандартный пакет Microsoft Office 2003. ДЛЯ ПРОЕКТА Для разработки системы будет использоваться программное приложение Access 2003 поэтому используется тот интерфейс, который предлагает приложение, а также разработанные в нем формы.

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

Требования к совместимости

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

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

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

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

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

В качестве инструментальных средств разработки будут использоваться некоторые CASE - средства: ERWin, BPWin и программа для построения базы данных Microsoft Access, язык программирования VBA, для защиты информации используется способ идентификации и аутентификации пользователя, а также разграничение прав доступа.

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

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

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

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

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

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

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

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

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

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

Ниже приведена одна из диаграмм ГДЕ ДИАГРАММА?? - «Выдача купленного товара Заказчику со слада фирмы».

Основной исполнитель: кладовщик.

Заинтересованные лица и их требования:

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

- Заказчик. Хочет быстро и в полном объеме получить товары н оформить данную операцию с минимальными затратами. Кроме этого хочет получить накладную на товар.

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

Предусловия: кладовщик идентифицирован и аутентифицирован.

Результаты (постусловия): данные о выдаче товара сохранены в системе.

Данные программы складского учета обновлены. Накладная сгенерирована и распечатана. Основной успешный сценарий:

1. Заказчик, получивший предварительно подтверждение о поступлении товара, приходит на склад.

2. Кладовщик открывает новый бланк накладной.

3. Кладовщик вводит код товара.

4. Система по коду товара записывает наименование товара, его описание, изготовителя, цену и общую стоимость покупки. Цена вычисляется на основе набора правил (например, у разных типов товара начисляется различный процент НДС). Кладовщик повторяет пп. 3-4 для каждого наименования товара.

5. Система подсчитывает общую стоимость покупки, включая налог.

6. Система регистрирует операцию, отправляет сведения программе складского учета (для обновления данных).

7. Система распечатывает накладную.

8. Заказчик оплачивает товар, получает накладную, товар и уходит.

Расширения (или альтернативные потоки).

*а. При каждом выходе системы из строя.

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

2. Система восстанавливает предыдущее состояние.

За. Неправильный код товара.

1. Система сигнализирует об ошибке, отменяет ввод неверного кода.

2. Система просит повторить ввод кода товара.

36. Товар отсутствует на складе.

1. Система сообщает, что данного кода нет в базе.

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

3. Система просит повторить ввод кода товара.

7а. Принтер не распечатывает накладную.

1. Система сообщает об отсутствии драйвера данной марки принтера.

2. Кладовщик закрывает форму накладной с уже введенными данными.

3. Специалист устанавливает драйвер и перезапускает систему.

4. Кладовщик входит в свою программу и открывает сохраненную форму накладной.

5. Принтер распечатывает накладную.

Специальные требования:

- Отклик службы авторизации в 90% случаев приходит в течение 30 секунд,

- Возможность локализации (представления на разных языках) отображаемого текста,

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

Открытые вопросы:

- Изучить законодательство по налогообложению.

- Изучить подробнее вопрос восстановления удаленных служб.

- Как лучше и надежнее связываться с удаленными клиентам}

(поставщиками). Оставить ли различные виды оплаты или ввести только безналичный расчет.

Остальные прецеденты:

* Открытие заказа.

* Расчет цен.

* Оформление бланка заказа.

* Запрос поставщику.

* Оформление товара на складе.

* Транспортировка товара заказчику.

* Оплата товара заказчиком.

* Передача товара на склад заказчика.

* Идентификация менеджера в программе.

* Регистрация заказчика.

* Оформление договора.

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

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

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

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

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

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

После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания. Далее анализом созданных диаграмм достигается соответствие модели реальным процессам на любом и каждом уровне модели. В данной модели содержится три уровня декомпозиции. Нулевой уровень - это разбиение контекстной диаграммы на три работы, а последующая декомпозиция модели - это более подробное описание каждого блока контекстной модели. Например, блок «Принятие заказа» разбивается на 3 блока, «Покупка товара» - на 4 блока, «Исполнение заказа» - на 5 блоков.

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

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

2. Разработка модели данных

Разработка способов доступа к информационной системе

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

Наиболее распространенным средством моделирования данных являются диаграммы «сущность - связь» (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных.

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

Менеджер по продажам: его основная задача - получить заказ и сделать все для скорейшего его выполнения. Ему необходима информация о том, какой тип товара (одежда, белье, головные уборы и т.п.) нужен заказчику, цены поставщиков, накрутка его фирмы, НДС на товар и т.д.

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

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

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

Таким образом, можно выделить следующие сущности:

Сотрудник (сведения о сотрудниках),

Поставщик (сведения о поставщиках),

Заказчик (сведения о заказчиках),

Товары (сведения о товаре, его изготовителе, цене и др.),

Типы (перечень типов товаров),

Заказ (сведения о том, какие товары входят в заказ, кто оформил его, куда поступит заказ, на какую он сумму и дату выполнения заказа).

Каждая сущность должна обладать некоторыми свойствами:

Имеет уникальное имя (к одному и тому же имени должна применяться одна и та же интерпретация),

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

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

Последним шагом моделирования является идентификация атрибутов.

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

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

ИНН_Сотрудника - уникальный идентификатор

Фамилия

Имя

Отчество

ДолжностьРаботника - атрибуты сущности

ДатаРождения

АдресРаботника

ДомашнийТелефон

Далее определяются все атрибуты и уникальные идентификаторы для других сущностей и все данные обрабатываются с помощью программы ERWin. На рисунках 10-11 приложения показана полученная модель данных на логическом и физическом уровнях.

3. Расчеты и оценки

3.1 Оценка требуемых ресурсов вычислительных средств

В основе системы лежит база данных, и вся работы системы связана с ней, т.е. система выполняет обработку запросов, работу с таблицами (ввод, удаление и редактирование записей), кроме этого она взаимодействует с другими специализированными программами, которые используются в работе предприятия. Поэтому для оценки требуемых вычислительных средств использовалась готовая база данных, а именно база данных «Борей». Эта БД входит в состав пакета Microsoft Access, содержит достаточно большой объем записей, большое количество запросов, форм, таблиц.

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

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

Pentium II (с ОЗУ 64 МБ) - 20 с для 1000 записей в таблице, Pentium II (с ОЗУ 120 МБ) - 5 с для 1000 записей в таблице, Athlon 700 (с ОЗУ 64 МБ) - 7 с для 1000 записей в таблице. Данные 2 и 3 удовлетворяют требованиям, т.к. время выполнения запроса не должно превышать 15 с.

Выбираемый объем жесткого диска зависит от объема, занимаемого базой данных и другими рабочими программами и операционной системой. Получим, что на ПК установлено только Microsoft Access 2000 и Microsoft Office 2000, и объем записей составляет 2000, то минимум требуемого объема памяти составляет 3 Гбайта, все остальные параметры ПК выбираются в соответствии с функциями, выполняемыми на рабочем месте.

Рабочее место администратора

Обязанность администратора - следить за правильной работой системы, делать резервные копии, контролировать безопасность. Поэтому рабочее место администратора должно быть оснащено более мощным ПК, чем на других местах. Также ПК администратора является сервером сети, которая будет объединять все рабочие места. Исходя из всех этих требований, можно сказать, что ПК администратора должен обладать более мощным процессором, большим ОЗУ и большим объемом жесткого диска, так как на нем кроме всех рабочих программ, системы и базы данных, будут храниться необходимые резервные копии. По этой причине ПК должен иметь встроенный CD-RW привод.

Рабочее место менеджера, бухгалтера, кладовщика

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

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

Ниже приведен следующий состав технических средств для рабочих мест:

Администратор
Процессор	1,8 GHz
ОЗУ	256 Mb
HDD	40 Gb
ОС	Windows Server 2000

Менеджер (бухгалтер, кладовщик)
Процессор	1,2 GHz
ОЗУ	128Mb
HDD	20Gb
ОС	Windows 2000
Принтер	Любой лазерный, работающий с форматом А-3

3.2 Оценка загрузки вычислительных средств

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

Для тестирования также можно использовать БД «Борей», пока не разработана до конца наша система. Результаты получили следующие:

Время реакции системы на маломощном компьютере - 5 сек. При полной загрузке - 9 сек.

Количество записей	Время реакции
1000	5 сек
2000	10 сек

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

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

Заключение

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

К проектируемой системе предъявляются следующие функциональные требования:

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

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

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

Система должна вести учет поставщиков и договоров поставки.

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

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

Система должна автоматически подготавливать текст документа получения материала со склада или поступления материала на склад и вывод этого документа на бумажный носитель.

Литература

1. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. «СУБД», 1995, №3.

2. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. М., Центр Информационных Технологий, 1996

3. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М., «Лори», 1996.

4. Создание информационной системы предприятия. «Computer Direct», 1996, N2.

Размещено на Allbest.ru