37295

Проект информационной системы Автоматизированная информационная система предприятия по изготовлению корпусной мебели «АИС Корпусная мебель»

Курсовая

Информатика, кибернетика и программирование

Описание потоков данных и бизнес процессов. Описание потоков данных и бизнес процессов. Функциональный блок Изготовление частей изделия получает в качестве входных данных согласованный проект в управлении участвуют характеристики материалов методики изготовления ГОСТы по изготовлению мебели а также согласованный проект. В качестве выходных данных выступают части изделия готовые к сборке Рисунок 1.

Русский

2013-09-24

2.91 MB

315 чел.

Содержание

ВВЕДЕНИЕ 4

1 Предпроектный анализ объекта автоматизации 5

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

1.2 Функции и организационная структура 6

1.3 Описание потоков данных и бизнес процессов 7

1.4 Обзор и анализ существующих проектных решений, выявление их достоинств и недостатков 19

1.5 Обоснование необходимости разработки информационной системы 20

2 СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ ИС 22

2.1 Разработка концепции, архитектуры построения и платформы реализации ИС 22

2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем 25

2.3 Техническое обеспечение ИС 28

3 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ 30

3.1 Описание концептуальной модели информационной базы 30

3.2 Описание логической структуры информационной базы 32

3.3 Описание физической реализации БД 36

4 ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ИС 41

4.1 Описание структуры программного обеспечения 41

4.2 Алгоритмизация типовых информационных запросов 43

4.3 Описание пользовательского интерфейса 48

ЗАКЛЮЧЕНИЕ 55

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 56

ПРИЛОЖЕНИЕ А 58

ПРИЛОЖЕНИЕ Б 68

ВВЕДЕНИЕ

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

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

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

Ввиду указанных причин, целью создания  «АИС Корпусная мебель» является снижение экономических затрат на материалы за счет оптимизации их использования.


1 Предпроектный анализ объекта автоматизации

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

Мебельное предприятие ОАО «Корпусная мебель» - молодая, быстро развивающаяся компания по производству и продаже корпусной мебели по индивидуальным заказам, вышедшая на российский рынок в 2012 году.

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

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

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

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

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


1.2 Функции и организационная структура

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

ОАО  «Корпусная мебель» состоит из следующих отделов:

  1. директор;
  2. административный отдел;
  3. отдел производства;
  4. отдел доставки.

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

Рисунок.1.1 - Организационная модель

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

Отдел производства осуществляет разработку проекта изделие, его последующее изготовление и сборку.

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

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

1.3 Описание потоков данных и бизнес процессов

1.3.1 Моделирование бизнес-процессов.  Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Для наглядности бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов[1]. Моделирование бизнес-процессов - деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) и указание связей между ними. Требования к формируемым моделям и их соответствующее содержание определяются целями моделирования. Бизнес-моделированием также называют дисциплину и отдельный подпроцесс в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе — те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе[2].

Проанализировав деятельность мебельного цеха, и проведя пред-проектное исследование, можно выделить три основных бизнес-процесса АИС «Корпусная мебель»:

  1. Принятие заказа.
  2. Изготовление частей изделия.
  3. Расчет с заказчиком.

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

  1. контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);
  2. диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную);
  3. диаграммы дерева узлов;
  4. диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой (как правило, здесь описывается основное назначение моделируемого объекта). После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы (т.е., получения диаграммы А0) проводится декомпозиция каждого блока диаграммы А0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели[3].

Главная бизнес-функция «АИС Корпусная мебель» - изготовление мебели. Входными данными является заявка на выполнение работ. Выходными – акт о выполненных работах. В качестве управления выступают порядок обслуживания клиента, ГОСТы и ТУ по изготовлению мебели, проекты готовых решений, характеристики материалов, методики изготовления. Инструментами выполнения главной бизнес-функции служат сотрудники ОАО «КорпСбор» (бухгалтер, менеджер, курьер, рабочие, мастер-технолог), а также оборудование, необходимое для изготовления мебели. Диаграмма IDEF0 для главной бизнес-функции представлена на рисунке 1.2.

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

Функциональный блок «Принятие заказа» включает регистрацию заказа, разработку эскиза, а затем и проекта изделия, а также его согласование с заказчиком. В случае внесения заказчиком каких-либо изменений, эскиз и проект разрабатываются заново. В управлении блоком «Принятие заказа» участвуют характеристики материалов, порядок обслуживания клиентов, проекты готовых решений, ГОСТы по изготовлению мебели. На вход поступает заявка на выполнение работ, на выходе получен согласованный проект и договор. В качестве исполнителей выступают менеджер и мастер-технолог. Диаграмма декомпозиции блока «Принятие заказа» представлена на рисунке 1.4.

Функциональный блок «Изготовление частей изделия» получает в качестве входных данных согласованный проект, в управлении участвуют характеристики материалов, методики изготовления, ГОСТы по изготовлению мебели, а также согласованный проект. В качестве исполнителей выступают мастер-технолог, рабочие, станки и оборудование. В качестве выходных данных выступают части изделия, готовые к сборке


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


Рисунок 1.3 - Диаграмма декомпозиции контекстной диаграммы

Рисунок 1.4 - Диаграмма декомпозиции блока «Принятие заказа»


Блок «Изготовление частей изделия» имеет в своем составе следующие блоки: заказ и получение материалов, раскрой плиты на детали, сверление соединительных отверстий облицовывание кромочным материалом. Диаграмма декомпозиции блока «Изготовление частей изделия» представлена на рисунке 1.5. Для автоматизации процесса раскроя потребовалось уточнить, какие процессы входят в блок «Раскрой плиты на детали». Поэтому была составлена и его диаграмма декомпозиции, которая представлена на рисунке 1.6.

Функциональный блок «Расчет с заказчиком» включает доставку, сборку, оплату и закрытие заявки. На вход поступают части изделия, готовые к сборке, в качестве выходных данных выступает акт о выполненных работах. Управляют данным блоком согласованный проект, договор, порядок обслуживания клиентов. Исполнителями являются рабочие, курьер, бухгалтер-кассир и менеджер. Диаграмма декомпозиции функционального блока «Расчет с заказчиком» представлена на рисунке 1.7.

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


Рисунок 1.5 - Диаграмма декомпозиции блока «Изготовление частей изделия»

Рисунок 1.6 - Диаграмма декомпозиции блока «Раскрой плиты на детали»

Рисунок 1.7 – Диаграмма декомпозиции блока «Расчет с заказчиком»


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

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

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

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

В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое[4].

Диаграмма потоков данных для бизнес-процессов ОАО «КорпСбор» представлена на рисунке 1.8.


Рисунок 1.8 - Диаграмма потоков данных


1.4 Обзор и анализ существующих проектных решений, выявление их достоинств и недостатков

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

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

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

Плюсы:

  1. мощный спектр настроек;
  2. большой запас функциональности;
  3. автоматизация;
  4. русский интерфейс;

Минусы:

  1. программа платная;
  2. громоздкость;
  3. довольно сложна в освоении;
  4. ограничения демо-версии.

Астра-раскрой. Программа раскроя Астра Раскрой предназначена для оптимизации раскроя листовых материалов - древесностружечных плит, металла, стекла и пластиков. Программа обеспечивает ввод и хранение информации о заказах и материалах; автоматическое и интерактивное формирование карт раскроя; расчет, сохранение и учет отходов; печать карт раскроя и спецификаций[6].

Плюсы:

  1. создание заказа для раскроя.
  2. раскройка заказа.
  3. редактирование карты раскроя.
  4. печать технической документации.
  5. расчет стоимости заказа и печать счета-фактуры.

Минусы:

  1. высокая стоимость программы;
  2. громоздкий интерфейс;
  3. нерацинальное использование системных ресурсов компьютера.

1.5 Обоснование необходимости разработки информационной системы

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

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

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

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

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

- создание заказа;

- сохранение заказа;

- создание плана раскроя листа и возможность его сохранения;

- печать плана раскроя, договора, счета;

- расчет суммы заказа;

- формирование акта о выполненных работах.


2 СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ ИС

2.1 Разработка концепции, архитектуры построения и платформы реализации ИС

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

В настоящее время наиболее распространенными архитектурами являются:

  1.  файл-сервер;
  2.  клиент-сервер;
  3.  многоуровневая архитектура.

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

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

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

  1.  масштабируемость;
  2. конфигурируемость - изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;
  3. высокая безопасность;
  4. высокая надёжность;
  5. низкие требования к скорости канала (сети) между терминалами и сервером приложений;
  6. низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

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

  1. сложность разработки систем на основе многоуровневой архитектуры, т.к  очень сложно «состыковать» различные модули, особенно если они написаны разными группами. А изменение в одном модуле, как правило, вызывает лавинообразные изменения в остальных, и с этой точки зрения даже простую систему, основанную на многоуровневой архитектуре, будет сложнее выполнить в 2 раза;
  2.  высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
  3.  высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений;
  4.  высокая сложность администрирования[7].

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

Схема функционирования и построения информационной системы представлена рисунке 2.1

Рисунок 2.1 - Архитектура "клиент-сервер"

2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем

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

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

  1. информационная;
  2. техническая;
  3. программная;
  4. математическая;
  5. лингвистическая.

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

Состав обеспечивающих подсистем не зависит от выбранной предметной области и имеет:

  1. функциональную структуру;
  2. информационное обеспечение;
  3. математическое (алгоритмическое и программное) обеспечение;
  4. техническое обеспечение;
  5. организационное обеспечение,

а на стадии разработки ИС дополнительные обеспечения:

  1. правовое;
  2. лингвистическое;
  3. технологическое;
  4. методологическое;
  5. интерфейсы с внешними ИС.

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

Математическое обеспечение состоит из алгоритмического и программного.

Организационное обеспечение – это совокупность средств и методов организации производства и управления ими в условиях внедрения ИС.

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

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

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



Рисунок 2.2 - Состав функциональных и обеспечивающих подсистем


2.3 Техническое обеспечение ИС

В соответствие с пунктом 4.3.5.1 Техничесного задания (приложение А), система реализована посредством технических средств, приобретаемых Заказчиком.

В комплекс технических средств должны входить следующие элементы:

  1.  рабочие станции;
  2.  источники бесперебойного питания;
  3.  средства для построения ЛВС;
  4.  сервер БД;
  5.  принтер.

Требования к серверу:

  1.  память 8 Гб;
  2.  процессор 2.2 ГГц Intel Xeon 5500 минимум;
  3.  скорость диска SATA 8 Гбит/с;
  4.  сетевой адаптер 10 Гбит/с;
  5.  операционная система Windows Server 2008.

Требования к рабочей станции:

  1.  процессор 2 Ггц;
  2.  память 2 Гб;
  3.  жесткий диск не менее 500;
  4.  операционная система Windows 7;
  5.  сетевой адаптер 100 Мбит/с.

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

  1.  круглосуточный режим работы комплекса технических средств и оборудования;
  2.  гарантированное выполнение всего комплекса программного обеспечения в случае сбоя или выхода из строя части оборудования;
  3.  защиту данных от несанкционированного доступа;
  4.  сервера и рабочие места должны быть объединены локальной сетью.

На рисунке 2.3 представлена топология локальной вычислительной сети (ЛВС) для ОАО «КорпСбор».

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

Рисунок 2.3 - Логическая схема сети ОАО "КорпСбор"


3 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Описание концептуальной модели информационной базы

Для хранения данных в информационной системе используется реляционная база данных под управлением СУБД Oracle 11g. Концептуальная схема структуры информационной базы приведена на рисунке 3.1.

В АИС «Корпусная мебель» основными объектами являются Заказ, Детали, Материалы, Счет, Заказчик, Фурнитура, План раскроя, Акт о выполненных работах.Рассмотрим отдельно каждый из объектов.

У сущности «Заказ» есть следующие атрибуты: Номер заказа, Дата поступления, Наименование заказа, Количество комплектов, Срок выполнения, Id заказчика, Id плана.

Сущность «Детали» имеет следующие атрибуты: Id детали, Длина, Ширина, Наименование, Id заказа, Id материала, Количество.

Сущность «Материал» имеет атрибуты: Наименование, Id материала, Цена за лист, Длина, Ширина.

Сущность «Счет» имеет атрибуты: Id счета, Сумма к оплате, Id заказа.

Сущность «Заказчик» имеет атрибуты: Id заказчика, ФИО, Адрес, Телефон.

Сущность «Фурнитура» имеет атрибуты: Id фурнитуры, Наименование, Количество, Стоимость, Id заказа.

Сущность «План раскроя» имеет атрибуты: Id плана, Файл-изображение (переменная строкового типа, в которой будет храниться ссылка на изображение с планом раскроя), Наименование.

Сущность «Акт о выполненных работах» имеет атрибуты: Id плана, Дата окончания работ, ФИО исполнителя, Id заказа.

Между объектами Заказ и Детали максимальная мощность связи 1:N, т.е. одному заказу может принадлежать множество деталей.


Рисунок 3.1 - Концептуальная схема базы данных


Между объектами Детали и Материал максимальная мощность связи 1:N, т.е. на листе материала может быть множество деталей.

Между объектами Акт о выполненных работах и Заказ максимальная мощность связи 1:1, т.е. одному заказу может соответствовать 1 акт о выполнении работ.

Между объектами Заказ и Счет максимальная мощность связи 1:1, т.е. заказу может соответствовать только 1 счет.

Между объектами Заказ и План раскроя максимальная мощность связи 1:N, т.е. в заказе может быть создано несколько планов раскроя.

Между объектами Заказ и Заказчик максимальная мощность связи 1:N, т.е. у одного заказчика может быть множество заказов.

Между объектами Детали и Материал максимальная мощность связи 1:N, т.е. на листе материала может быть множество деталей.

Между объектами Фурнитура и Заказ максимальная мощность 1:N, т.е. одному заказу может соответствовать множество единиц фурнитуры.

3.2 Описание логической структуры информационной базы

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

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

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


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

  1. исключение некоторых типов избыточности;
  2. устранение некоторых аномалий обновления;
  3. разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
  4. упрощение процедуры применения необходимых ограничений целостности.

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

В создании и развитии теории нормализации принимали участие многие учёные. Однако первые три нормальные формы и концепцию функциональной зависимости предложил Э. Кодд.

Первая нормальная форма (1NF): переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов. В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ.

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

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

Нормальная форма Бойса-Кодда (BCNF): переменная отношения находится в нормальной форме Бойса-Кодда (иначе — в усиленной третьей нормальной форме) тогда и только тогда, когда каждая ее нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.

Четвёртая нормальная форма (4NF): переменная отношения находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса — Кодда и не содержит нетривиальных многозначных зависимостей.

Пятая нормальная форма (5NF): переменная отношения находится в пятой нормальной форме (иначе — в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения[10].

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

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


Рисунок 3.2 – Логическая структура информационной базы


3.3 Описание физической реализации БД

Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.[11].

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

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

В конструкторе были созданы следующие таблицы: Details, Materials, invoice, Furnitur, Zakaz, Zakazchik, Design_cutting, Akt_work_perfomed. Физическая модель АИС «Корпусная мебель» представлена на рисунке 3.3.

Описание созданных таблиц базы данных приведены в таблицах 3.1-3.7.


Рисунок 3.3 - Физическая модель


Таблица 3.1 - Описание полей таблицы Zakaz

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_zakaz

Номер заказа

Integer

PK

Date_invite

Дата заказа

Date

-

Name_zakaza

Имя заказа

Varchar2(255)

-

quantity_komplects

Количество комплектов

Integer

-

Period_execution

Срок выполнения

Date

-

Id_zakazchik

Идентификационный номер заказчика

Integer

FK

Таблица 3.2 - Описание полей таблицы Zakazchik

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_zakazchik

Идентификационный номер заказчика

Integer

PK

FIO

ФИО заказчика

Varchar2(255)

-

Adress

Адрес заказчика

Varchar2(255)

-

Telephone

Телефон

Integer

-

Таблица 3.3 - Описание полей таблицы Details

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_det

Номер детали

Integer

PK

Name

Имя детали

Varchar2(255)

-

Dlina

Длина детали

Decimal(10,2)

-

Shirina

Ширина детали

Decimal(10,2)

-

Kolvo

Количество таких деталей в проекте

Integer

-

Id_zakaz

Идентификатор заказа

Integer

FK

Id_mater

Идентификатор материала

Integer

FK

Таблица 3.4 - Описание полей таблицы Furnitur

Наименование поля БД

Описание поля

Тип данных

Примечание

id_furnit

Номер детали

Integer

PK

Name

Имя детали

Varchar2(255)

-

quantity

Количество

Integer

-

cost

Цена за штуку

Decimal(10,2)

-

Id_zakaz

Идентификатор заказа

Integer

FK

Таблица 3.5 - Описание полей таблицы Materials

Наименование поля БД

Описание поля

Тип данных

Примечание

id_mater

Номер листа

Integer

PK

Name

Имя детали

Varchar2(255)

-

Dlina

Длина

Decimal(10,2)

-

Cost_of_list

Цена за лист

Decimal(10,2)

-

Shirina

Идентификатор заказа

Decimal(10,2)

-

Таблица 3.6 - Описание полей таблицы invoice

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_schet

Идентификационный номер счета

Integer

PK

Date_invoice

Дата оплаты

Date

-

Summ_for_pay

Сумма к оплате

Decimal(10,2)

-

Summ_work

Оплата работы

Decimal(10,2)

Summ_of_materials

Затраты на материалы

Decimal(10,2)

-

Id_zakaz

Номер заказа

Integer

FK

Таблица 3.7 - Описание полей таблицы Akt_work_perfomed

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_act

Идентификационный номер счета

Integer

PK

Data_end

Дата выполнения

Date

-

FIO_worker

ФИО исполнителя

Varchar2(255)

-

Id_zakaz

Номер заказа

Integer

FK

Таблица 3.8 - Описание полей таблицы Design_cutting

Наименование поля БД

Описание поля

Тип данных

Примечание

Id_design

Идентификационный номер плана

Integer

PK

File_raskroy

Файл с планом раскроя

Blob

-

Name_design

Наименование плана

Varchar2(255)

-

Id_zakaz

Номер заказа

Integer

FK

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


Рисунок 3.4 – Пример заполнения таблиц в базе данных Oracle


4 ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ИС

4.1 Описание структуры программного обеспечения

Программа будет проектироваться по клиент-серверной архитектуре с использованием модульного принципа проектирования. В качестве сервера баз данных будет выступать СУБД Oracle 11g. Применение данной системы не требует затрат, так как используется бесплатная версия.

Oracle Database 11g помогает снизить затраты на информационные технологии и повысить качество услуг за счет консолидации в облака баз данных и готовые системы, например, Oracle Exadata и Oracle Database Appliance. Это быстрая, надежная, безопасная и легкая в управлении система, подходящая для выполнения всех задач, связанных с базами данных, в том числе с приложениями для предприятий, банками данных и анализом крупных объемов данных. Oracle Exadata — это единственная машина баз данных, которая обеспечивает высочайшую производительность как для банков данных, так и онлайн-обработки транзакций, что делает ее идеальной платформой для консолидации связанных с базами данных смешанных нагрузок в частные облачные среды.

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

Начиная с версии 10g компания Oracle позиционирует свою СУБД как платформу для GRID вычислений. Концепция GRID вычислений достаточно проста, понятна, гибка и позволяет экономить средства предприятия. Поэтому в последнее время наблюдается постепенное внедрение этой архитектуры в IT инфраструктуру. Все большую популярность приобретают многоядерные процессоры. Сейчас большинство новых серверов имеет двух – четырех ядерные процессоры и это не предел. Поэтому эра систем с тысячами процессоров уже не за горами. Нужна платформа, позволяющая эффективно реализовывать приложения на этой инфраструктуре. Oracle предлагает в качестве такой платформы GRID на основе СУБД Oracle 11g.

Для реализации клиентской части приложения будет применена среда разработки Microsoft Visual Studio 2010. Microsoft Visual Studio — линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework и Microsoft Silverlight.

Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования или инструментов для прочих аспектов процесса разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server)[12].

На рисунке 4.1 представлена структура проекта Microsoft Visual Studio 2010.

Рисунок 4.1 - Обозреватель решений проекта

Созданы следующие формы:

  1.  KorpSbor.cs – экранная форма главного окна программы;
  2.  Spravochnik.cs – экранная форма справочника материалов;
  3.  Zakaz.cs – экранная форма создания заказа;
  4.  Plan_raskroya.cs – экранная форма справочника планов раскроя;
  5.  Plan_postr.cs – экранная форма диалогового окна после построения плана раскроя.

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

4.2 Алгоритмизация типовых информационных запросов

4.2.1 Алгоритм реализации раскроя. Для построения планов раскроя использовался модифицированный метод Нелдера-Мида с использованием генетического алгоритма.

Данный метод (далее – алгоритм)  используется   для  получения  плотной   упаковки   k  прямоугольников на   шаге 2 генетического  алгоритма.  Дано  k – число  прямоугольников. Для описания взаимного  расположения  прямоугольников  на   плоскости  будем  использовать   2k -мерное  пространство. Координаты центров прямоугольников будем интерпретировать   как  точку  2k -мерного  пространства.

Для  применения  алгоритма  Нелдера- Мида  важнейшими   шагами  являются  выбор начальной  точки и  критерий  преобразования симплекса. В  алгоритме, изложенном  ниже,  предложен   новый способ выбора  начальной  точки, который   позволяет  двигаться  к  решению   не   выходя  за   пределы построенной допустимой  области  в   пространстве   размерности  2k+2.  Сложность   выбора критерия   преобразования   симплекса   связана  с  необходимостью  предотвратить преждевременную   остановку  алгоритма  из - за   попадания  симплекса   в  локальный   минимум.

Шаг 1.  Построение  правильного  симплекса   в   пространстве   размерности  2k + 2.  При   построении   симплекса   используем   свойство,  что  проекция   любой   его вершины   на   противоположную   грань  совпадает  с  центром  масс  этой   грани.

Шаг 2.  Построение  ограничений  на   расстояния   между   центрами прямоугольников (каждого   с  каждым).

Шаг 3.  Построение  ограничений  для  расстояний   между   центрами прямоугольников  и  сторонами   полосы (для  каждого   прямоугольника   со   всеми сторонами). Эти ограничения преобразуем в ограничения  пространства   2k+2, как  это  было описано  на   предыдущем  шаге.

Шаг 4. Поиск  максимальной  и  минимальной   высоты  полосы.

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

Шаг 6.  Вписываем   правильный  симплекс  в   сферу   радиуса . Увеличиваем размер допустимой  области  путем  сдвига  ограничений  на  R.

Шаг 7.  Вычисляем   целевую   функцию   для  каждой  вершины   симплекса. Целевая  функция   C – расстояние   от   вершины   до  ограничений.  По  построению точка  не   нарушает  ограничение,  если   значение   целевой  функции   отрицательно  (чем   меньше  значение   целевой  функции,  тем   оно   ближе   к  искомому решению).  Уменьшаем  размер   допустимой  области  на   величину,  равную модулю  целевой  функции,  умноженному   на   коэффициент   Q.

Шаг 8.  Сортировка  вершин  симплекса   в   зависимости  от   значения   целевой функции   от   максимальных к  минимальным   значениям.

Шаг 9.  Отражаем  i- ую  вершины   симплекса   относительно   своей противоположной   грани   и  получаем  точку I. Если  значение   целевой  функции  для  точки  I строго   отрицательно   и  разность   между   целевой  функцией  и  сдвигом   меньше  ε (чем меньше  ε,  тем   точнее   работа   алгоритма),  то   решение  найдено.

Шаг 10.  Если  значение   целевой  функции   в   точке I отрицательно   и  i- ая вершина   симплекса   не   была  получена   из   точки  I  на   предыдущем преобразовании    симлекса   и  выполнено   хотя   бы  одно  из   следующих   условий 1 или  2,  то   тогда  i-ая   вершина   симплекса   заменяется   своей  противоположной  точкой   и осуществляется   переход  на   Шаг 8.

Шаг 11.  Если  длина   ребра  симплекса   больше  ε,  то   переход  на   Шаг 7.  В противном   случае   решение   не   может   быть  найдено  и  алгоритм   завершает работу.

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

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

Шаг 2.  Выбираем  текущую   высоту  как  среднее  значение   между   минимальной  и  максимальной  высотой.

Шаг 3.  Находим   точку  внутри   допустимой  области.

Шаг 4.  Если допустимая  область  существует,  то  максимальную  высоту  делаем  текущей,  иначе  минимальную  высоту  делаем   текущей.  Если  разность   между  минимальной   и  максимальной  высотой   больше  некоторого   числа  ε,  переходим  на   Шаг 2, в   противном   случае   алгоритм   завершает  свою  работу.

Следует  также   заметить,  что  для  увеличения   скорости   работы  алгоритма можно   увеличить  допустимую  область.  Для  этого  необходимо  увеличить ширину  полосы (например,  на  1-3%),  а  ширину  прямоугольников  уменьшить  (на  1-2%).  Далее  алгоритм   уплотнения   упаковки,  используя  реальные   размеры  полосы,  прямоугольников  и  данные  о   взаимном  расположении прямоугольников,  проверяет  возможность   данной  упаковки.  Если  такая упаковка   возможна,  то   решение   найдено.  Если  увеличение   ширины  полосы  и  уменьшение  ширины  прямоугольников  приводят   к  невозможности   реализации  такой  упаковки,  то   упаковку   необходимо  проводить  с исходными   данными[13].

4.2.1 Типовые информационные запросы. Информационные запросы к базе в данной программе будут осуществляться с помощью языка структурированных запросов SQL.

SQL - универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. SQL основывается на исчислении кортежей [14].

Рассмотрим некоторые имеющие место запросы:

  1. Вывести заказ по его номеру:

select *

from Zakaz

where id_zakaz ='111'

Результат представлен на рисунке 4.2.1:

Рисунок 4.2.1 - Результат запроса поиска заказа по его номеру

  1. Вывести ФИО и адрес заказчика по дате заказа:

select zk.id_zakazchik, zk.FIO, zk.Adress

from Zakazchik zk, Zakaz z

where z.Date_invite ='25.12.2012'

AND zk.id_zakaz= z.id_zakaz

Результат представлен на рисунке 4.2.2:

Рисунок 4.2.2 - Результат запроса поиска заказчика по дате заказа

  1. Вывести детали по дате заказа:

select d.*

from Detali d,Zakaz z

where z.Date_invite ='25.12.2012'

AND d.id_zakaz= z.id_zakaz

Результат представлен на рисунке 4.2.3:

Рисунок 4.2.3 - Результат запроса поиска детали по дате заказа

Возможность выполнения таких запросов включена в пользовательский интерфейс.

4.3 Описание пользовательского интерфейса

Пользовательский интерфейс представлен в виде иерархии форм.

В начале работы пользователь видит окно, представленное на рисунке 4.3. Соответствии с техническим заданием (приложение А), в АИС «КорпСбор» существует разграничение доступа на уровне функций. Поэтому, при работе с программой пользователь должен выбрать отдел, в котором он работает и далее ввести пароль (окно ввода пароля представлено на рисунке 4.4). Работникам административного отдела доступны все функции, работникам производственного не доступно изменение заказа, справочных данных заказчика, а также счетов и актов о выполнении работ.

Рисунок 4.3 – Выбор отдела пользователя

Рисунок 4.4 - Окно ввода пароля

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

Рисунок 4.5 - Главное окно программы

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

Рисунок 4.6 - Меню "Заказ"

При нажатии на «Создать» пользователь видит форму создания заказа, представленную на рисунке 4.7.

Рисунок 4.7 - Создание нового заказа

Кнопка «Экспорт» используется, чтобы экспортировать данные о заказе в Microsoft Word для последующей их печати.

При нажатии на кнопку «Сохранить» внесенные изменения сохраняются без выхода из формы ввода, при нажатии на кнопку «ОК» происходить сохранение и выход, при нажатии на кнопку «Отмена» - выход без сохранения изменений.

Вкладки «Заказчик», «Счет» и «Акт» имеют аналогичную вкладке «Заказ» структуру.

Вкладка «Детали» используется для внесения данных по деталям для данного заказа и представлена на рисунке 4.8. Вкладка «Материалы» имеет ту же структуру.

При нажатии на кнопку «Рассчитать план раскроя» появляется окно с результатами расчета. На на рисунках 4.9-4.11 представлен план раскроя для заказа 111. Программа автоматически выполняет раскладку на листы. Вкладки соответствуют листам. Учитывается материал каждого листа.

Рисунок 4.8 - Добавление новых деталей в заказ

Рисунок 4.9 - План раскроя

Рисунок 4.10 - План раскроя. Лист 2

Рисунок 4.11 - План раскроя. Лист 3

При нажатии на кнопку «Сохранить остаток как новый лист» выполняется добавление в справочник «Материалы» нового листа с размерами, соответствующими размерами остатка. Номер новому материалу присваивается автоматически. При нажатии на кнопку «Печать» появляется диалоговое окно печати изображения плана раскроя. При нажатии на кнопку «Сохранить» план раскроя и текст с данными о раскрое экспортируется в Microsoft Word. Все созданные планы раскроя хранятся в базе данных в соответствующем справочнике.

На вкладке «Счет» производится расчет итоговой суммы заказа. Интерфейс вкладки «Счет» представлен на рисунке 4.12. Для заполнения доступны все поля, кроме поля «Итого сумма к оплате». Данное поле рассчитывается автоматически после нажатия на кнопку «Рассчитать итоговую сумму».

Рисунок 4.12 - Вкладка "Счет"

В программе реализован поиск данных. Доступ к поиску осуществляется через меню «Справочники» главного окна программы. На рисунке 4.13 представлено меню для поиска данных по заказу.

Рисунок 4.13 - Поиск заказа

При нажатии на «Поиск по номеру» появляется окно поиска заказа. Поиск данных по заказу с номером 111 представлен на рисунке 4.14.

Рисунок 5 - поиск данных по заказу с номером 111

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

Листинг программы приведен в приложении Б.


ЗАКЛЮЧЕНИЕ

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

  1. выполнен анализ предметной области;
    1. разработана функциональная схема АИС «Корпусная мебель»;
    2. разработана концепция, выбраны архитектура построения и платформа реализации системы;
  2. спроектирована концептуальная модель АИС «Корпусная мебель»;
  3. спроектирована логическая модель системы АИС «Корпусная мебель» на основе концептуальной модели;
  4. определена физическая структура сервера баз данных;
  5. разработан прототип информационной системы АИС «Корпусная мебель»;

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


СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

  1. Черемных С.В. Структурированный анализ систем IDEF-технологии/ С.В. Черемных, И.О. Семенов, В.С. Ручкин. – М: Финансы и статистика, 2003.-208 с.;
  2. Маклаков С.В. BPWin и ERWin CASE - средства разработки информационных систем / Маклаков С.В. - М: ДИАЛОГ МИФИ, 2001.-256с.;
  3. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suit / Маклаков С.В. - М. :ДиалогМИФИ, 2003. – 432с.;
  4.  Моделирование бизнес-процессов средствами BPwin // Интернет университет информационных технологий: открытый университет «ИНТУИТ» [Электронный ресурс] – URL: http://www.intuit.ru/department/se/devis/8/2.html (дата обращения 10.12.2012);
  5. Программа Раскрой v6.30.96 // Форум мебельщиков Freesoftmebel  [Электронный ресурс] –URL: http://freesm.narod.ru/raskroj-soft.htm (дата обращения 10.12.2012);
  6. Официальный сайт продукта АстраРаскрой [Электронный ресурс] – URL: http://www.astrapro.ru/astranest.asp  (дата обращения 10.12.2012);
  7. Архитектурные особенности проектирования и разработки Веб-приложений //Интернет-университт информационных технологий: открытый  университет «ИНТУИТ» [Электронный ресурс]  - URL: http://www.intuit.ru/department/internet/mwebtech/5/ (дата обращения 10.12.2012);
  8. Бойко В.В.Проектирование баз данных информационных систем / Бойко В.В., Савинков В.М.  – 2-е изд. – М.: Финансы и статистика, 1989. – 350 с.;
  9.  Дейт К. Дж. Введение в системы баз данных.: Пер. с англ. / Дейт К. Дж.  – 6-е изд. – Киев: Диалектика, 1998. – 784 с.;
  10. Черноморов Г.А. Базы данных в среде промышленных СУБД / Черноморов Г.А. - Новочеркасск : ЮРГТУ, 2006. - 884 с.;;
  11. Кузнецов С. Д. Основы баз данных / Кузнецов С. Д. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с.;
  12. Рендольф Н. Visual Studio 2010 для профессионалов / Рендольф Н., Гарднер Д., Андерсон К., Минутилло М. - Киев: Диалектика, 2011.-1184 с.;
  13. Мартишина С.А. Упаковка прямоугольников в полосу модифицированным методом Нелдера-Мида с использованием генетического алгоритма [Электронный ресурс] / С.А. Мартишина,  М.В. Храпченко - URL: http://www.ispras.ru/ru/proceedings /docs/2010/19/isp_19_2010_135.pdf  (дата обращения - 10.12.2012).
  14. Базы данных. Язык SQL для студента /В.В. Дунаев: БХВ-Петербург, 2006.- 288с.
  15. Г.А Черноморов. Базы данных в среде промышленных СУБД Новочеркасск : ЮРГТУ, 2006;


ПРИЛОЖЕНИЕ А

(обязательное)

Техническое задание на разработку ИС

  1.  Общие сведения

  1.  Полное наименование системы и ее условное обозначение

«Автоматизированная информационная система предприятия по изготовлению корпусной мебели»,  АИС «Корпусная мебель».

  1.  Шифр темы или шифр (номер) договора

    23010265.КП12.156

  1.  Наименование предприятия (объединений)  разработчика и заказчика (пользователя) системы и их реквизиты

Предприятие разработчик: ЮРГТУ(НПИ) (далее - Исполнитель) в лице Ткачевой Олеси Игоревны. Адрес: 346400, Ростовская обл., г.Новочеркасск, ул. Энгельса, 85а.

Предприятие заказчик: ОАО "КорпСбор" (далее - Заказчик) в лице генерального директора Дубового Петра Петровича. Адрес: 346400,

Ростовская область, г. Новочеркасск,  ул. Энгельса, 178.

  1.  Перечень документов, на основании которых создается система, кем и когда утверждены эти документы

Основанием для разработки системы является двухсторонний договор №12345 от 10 сентября 2012 года между заказчиком и разработчиком.

  1.  Плановые сроки начала и окончания работы по созданию системы

Разработка системы ведется в следующие сроки: дата начала - 10 сентября 2012 года, дата окончания – 28 декабря 2012 года

  1.  Сведения об источниках и порядке финансирования работ

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

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

АС «Корпусная мебель» поставляется в виде исполняемых модулей по завершению всего объема работ, технические средства приобретаются Заказчиком самостоятельно. Оформление результатов работ по созданию системы производится путем подписания акта о принятии системы Заказчиком при отсутствии претензий к Разработчику. Акт составляется в двух экземплярах. Один экземпляр находится у Заказчика, другой – у Разработчика.

  1.  Назначение и цели создания (развития) системы

2.1 Назначение системы

АС «Корпусная мебель» предназначена для автоматизации работы предприятия,  изготавливающего корпусную мебель.

2.2 Цели создания системы

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

  1.  Характеристика объектов автоматизации

3.1 Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию

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

3.2 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды

Данная система будет установлена в производственных и офисных помещениях.

  1.  Требования к системе
  2.  Требования к системе в целом

4.1.1 Требования к структуре и функционированию системы

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

АС  «Корпусная мебель» включает следующие подсистемы:

- Принятие заказа;
- Изготовление изделия;

- Расчет с заказчиком.

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

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

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

4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы:

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

4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами:

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

4.1.1.4 Требования к режимам функционирования системы:

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

4.1.1.5 Требования по диагностированию системы:

Диагностика и обновление системы производятся при необходимости.

4.1.1.6 Перспективы развития, модернизации системы:

Модернизация системы осуществляется по требованию заказчика системы.

4.1.2 Требования к численности и квалификации персонала системы

  4.1.2.1 Требования к численности персонала (пользователей) АС

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

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

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

Численность персонала может быть различной в зависимости от объема и характера работ.

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

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

Выполнение операций должно занимать не более 30 секунд.

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

Восстановление системы при ошибках в работе аппаратных средств (кроме носителей данных и программ) и ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.

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

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

4.1.5 Требования к безопасности 

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

4.1.6 Требования по эргономике и технической эстетике:

Требования  отсутствуют.

4.1.7 Требования к транспортабельности:

Требования отсутствуют.

4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.

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

Допустимые площади для размещения персонала и технических средств подсистемы должны соответствовать требованиям СанПиН 2.2.2.542-96. Реализация данных требований должна быть обеспечена Заказчиком.

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

Обслуживание системы осуществляет один сотрудник.

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

Должно быть произведено нормирование вредных и опасных факторов на основании СанПиН 2.2.2/2.4.1340-03. Помещения с рабочими местами должно иметь искусственное освещение, быть оборудование приточно-вытяжной вентиляцией. Напряжение сети должно составлять 220 В и быть стабильным, без перепадов. Шум в помещении должен быть нормирован в соответствии с СН 2.2.4/21.8-562-96.

4.1.8.3 Требования по количеству, квалификации обслуживающего персонала и режимам его работы.

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

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

Запасные изделия и приборы не требуются.

4.1.8.5 Требования к регламенту обслуживания.

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

4.1.9 Требования к защите информации от несанкционированного доступа:

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

а) идентификацию и аутентификацию пользователя;

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

4.1.10 Требования по сохранности информации при авариях

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

4.1.11 Требования к средствам защиты от внешних воздействий

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

4.1.12 Требования по патентной частоте:

Требования не предъявляются.

4.1.13 Требования по стандартизации и унификации

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

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

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

Экранные формы должны проектироваться с учетом требований унификации:

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

4.1.14 Дополнительные требования:

Требования не предъявляются.

4.2 Требования к функциям (задачам), выполняемым системой

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

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

  1.  подсистема принятия заказа,
  2.  подсистема изготовления изделия,
  3.  подсистема расчета с клиентом.

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

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

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

4.2.2 Временной регламент реализации каждой функции, задачи (или комплекса задач)

Не предъявляется.

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

Не предъявляются.

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

Не предъявляются.

4.3 Требования к видам обеспечения

4.3.1 К информационному обеспечению системы

4.3.1.1 К составу, структуре и способам организации данных в системе

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

 4.3.1.2  К информационному обмену между компонентами системы

Не предъявляются.

4.3.1.3 К информационной совместимости со смежными системами

Не предъявляются.

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

Для классификации услуг изготовления и сборки мебели необходимо использовать Общероссийский классификатор услуг населению ОК 002-93 (ОКУН). Для классификации мебели должны использоваться классификаторы «ОКП 561000 – Мебель бытовая», «ОКП 562000 – Мебель специальная», «ОКП  568000 – Составные части мебели».

 4.3.1.5 По применению систем управления базами данных

Не предъявляется.

 4.3.1.6 К структуре процесса сбора, обработки, передачи данных в системе и представлению данных.

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

 4.3.1.7 К защите данных от разрушений при авариях и сбоях в электропитании системы

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

 4.3.1.8 К контролю, хранению, обновлению и восстановлению данных

Система должна поддерживать автоматическое ежедневное резервное копирование.

 

4.3.1.9 К процедуре придания юридической силы документа, продуцируемым техническими средствами АС.

Не предъявляются.

 

4.3.2 Требования к математическому обеспечению системы.

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

4.3.3 Требования к лингвистическому обеспечению системы.

Не предъявляются.

 4.3.4 Требования к программному обеспечению системы

Система должна работать в операционных системах Windows XP/Vista/7

4.3.5 Требования к техническому обеспечению системы

4.3.5.1 К видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе.

В комплекс технических средств должны входить следующие элементы:

- рабочие станции;

- источник бесперебойного питания;

- среда передачи данных между рабочими станциями (например, витая пара UTP 5e);

- принтер.

Технические средства приобретаются Заказчиком самостоятельно.

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

Процессор Intel Pentium IV 2 ГГц  и выше, оперативная память не менее 2Гб, объем жесткого диска не менее 500 Гбайт.

 4.3.6 Требования к метрологическому обеспечению

Не предъявляются.

4.3.7 Требования к организационному обеспечению системы.

Для организационного обеспечения приводят требования:

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

Функционирование системы обеспечивает инженер-системотехник, в эксплуатации участвуют  4 сотрудника.

4.3.7.2 К организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации.

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

4.3.7.3 К защите от ошибочных действий персонала системы.

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

5 Состав и содержание работ по созданию (развитию) системы

    Состав и содержание работ по созданию системы представлены  в таблице 3.

    Таблица 3 - Состав и содержание работ по созданию  системы  

Стадии

Этапы работ

1 Формирование требований к АС

1.1 Обследование объекта и необходимости создания АС

1.2 Формирование требований заказчика к АС

1.3 Оформление отчёта о выполненной работе и заявки на раз-работку АС

2 Разработка и утверждение ТЗ

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

2.2 Утверждение технического задания на создание АС

3 Разработка концепции АС

3.1  Изучение объекта АС

3.2 Проведение необходимых научно-исследовательских работ

3.3  Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя

4 Разработка АС

4.1 Реализация алгоритма раскроя

4.2 Отладка программы на тестовых примерах

4.3 Реализация структуры данных в среде разработки

4.4 Связывание структуры данных с алгоритмом расчета

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

5Рабочая документация

  1.  Разработка рабочей документации на систему и её части

5.2 Адаптация программ

6 Ввод в действие

6.1 Подготовка объекта автоматизации к вводу АС в действие

6.2 Подготовка персонала

6.3 Комплектация АС поставляемыми программными средствами

6.4 Проведение опытной эксплуатации и приемочных испытаний

7 Сопровождение АС

7.1 Выполнение работ в соответствии с гарантийными обяза-тельствами

7.2 Послегарантийное обслуживание

  1.  Порядок контроля и приемки системы

6.1 Виды, состав, объем и методы испытаний системы и ее составных частей

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

6.2 Общие требования к приемке работ по стадиям

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

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

6.3 Статус приемочной комиссии (государственная, межведомственная, ведомственная)

Статус приемочной комиссии определяется Заказчиком до проведения испытаний.

  1.  Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

  1.  Приведение поступающей в систему информации  к виду, пригодному для обработки с помощью ЭВМ

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

  1.   Изменения, которые необходимо осуществить в объекте автоматизации

     Не требуется.

  1.  Создание условий функционирования объекта автоматизации

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

- определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации системы;

-  обеспечить присутствие пользователей на обучении работе с системой, проводимом Исполнителем;

- обеспечить соответствие помещений и рабочих мест пользователей системы в соответствии с требованиями, изложенными в настоящем ТЗ;

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

- совместно с Исполнителем подготовить план развертывания системы на технических средствах Заказчика;

- провести опытную эксплуатацию.

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

7.4 Создание необходимых для функционирования системы подразделений и служб

Не требуется.

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

Обучение персонала производят в срок с 25 декабря 2012 года по 30 декабря 2012.

  1.  Требования к документированию

    Для системы на различных стадиях создания должны быть выпущены следующие документы из числа предусмотренных в ГОСТ 34.201–89 «Информационная технология. Комплекс стандартов на автоматизированные системы»:      

  1.  Схема организационной структуры;
  2.  Схема функциональной структуры;  
  3.  Перечень входных сигналов и данных;
  4.  Перечень выходных сигналов (документов);
  5.  Пояснительная записка к техническому проекту;
  6.  Описание автоматизируемых функций;
  7.  Описание постановки задач (комплекса задач);
  8.  Описание организации информационной базы;
  9.  Описание массива информации;
  10.  Описание программного обеспечения;
  11.  Руководство пользователя.

9 Источники разработки

В качестве источников разработки используется статья С.А. Мартишина,  М.В. Храпченко «Упаковка прямоугольников в полосу модифицированным методом Нелдера-Мида с использованием генетического алгоритма» (URL: http://www.ispras.ru/ru/proceedings/docs/2010/19/isp_19_2010_135.pdf).


ПРИЛОЖЕНИЕ Б

(рекомендуемое)

Текст программы

Текст модуля KorpSbor.cs

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace КорпСбор_интерфейсСшарп

{

   public partial class KorpSbor : Form

   {

       public KorpSbor()

       {

           InitializeComponent();

       }

       private void Form1_Load(object sender, EventArgs e)

       {

       }

       private void toolStripButton1_Click(object sender, EventArgs e)

       {

       }

       private void toolStripLabel1_Click(object sender, EventArgs e)

       {

       }

       private void создатьToolStripMenuItem1_Click(object sender, EventArgs e)

       {

       }

       private void toolStripTextBox1_Click(object sender, EventArgs e)

       {

       }

       private void toolStripMenuItem1_Click(object sender, EventArgs e)

       {

       }

       private void заказToolStripMenuItem1_Click(object sender, EventArgs e)

       {

       }

       private void создатьToolStripMenuItem_Click(object sender, EventArgs e)

       {

           Zakaz f = new Zakaz();

           f.Show(); // или так

       }

       private void материалыToolStripMenuItem_Click(object sender, EventArgs e)

       {

           Spravochnik Mater = new Spravochnik();

           Mater.Show(); // или так

       }

       private void планыРаскрояToolStripMenuItem_Click(object sender, EventArgs e)

       {

           Plan_raskroya Plan = new Plan_raskroya();

           Plan.Show();

       }

       private void открытьСправочникToolStripMenuItem_Click(object sender, EventArgs e)

       {

          

       }

       private void поискПоНомеруToolStripMenuItem_Click(object sender, EventArgs e)

       {

           PoiskZakazaID Poisk_Z_ID = new PoiskZakazaID();

           Poisk_Z_ID.Show();

       }

   }

}

 

Текст модуля PlanPostr.cs

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace КорпСбор_интерфейсСшарп

{

   public partial class Plan_postr : Form

   {

       public Plan_postr()

       {

           InitializeComponent();

       }

       private void pictureBox1_Click(object sender, EventArgs e)

       {

       }

   }

}

Текст модуля Zakaz.cs

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace КорпСбор_интерфейсСшарп

{

   public partial class Zakaz : Form

   {

       public Zakaz()

       {

           InitializeComponent();

       }

       private void Form2_Load(object sender, EventArgs e)

       {

       }

       private void button1_Click(object sender, EventArgs e)

       {

       }

       private void listBox1_SelectedIndexChanged(object sender, EventArgs e)

       {

       }

       private void label1_Click(object sender, EventArgs e)

       {

       }

       private void label4_Click(object sender, EventArgs e)

       {

       }

       private void dateTimePicker2_ValueChanged(object sender, EventArgs e)

       {

       }

       private void button7_Click(object sender, EventArgs e)

       {

       }

       private void label6_Click(object sender, EventArgs e)

       {

       }

       private void button3_Click(object sender, EventArgs e)

       {

           Plan_postr Plan_post = new Plan_postr();

           Plan_post.Show();

       }

   }

}

Текст модуля Spravochnik.cs

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace КорпСбор_интерфейсСшарп

{

   public partial class Spravochnik : Form

   {

       public Spravochnik()

       {

           InitializeComponent();

       }

       private void Spravochnik_Load(object sender, EventArgs e)

       {

       }

       private void dataGridView1_CellContentClick(object sender, DataGridViewCellEventArgs e)

       {

       }

       private void bindingSource1_CurrentChanged(object sender, EventArgs e)

       {

       }

   }

}

Текст модуля PlanRaskroya.cs

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace КорпСбор_интерфейсСшарп

{

   public partial class Plan_raskroya : Form

   {

       public Plan_raskroya()

       {

           InitializeComponent();

       }

       private void Plan_raskroya_Load(object sender, EventArgs e)

       {

       }

   }

}

Текст модуля PoiskZakazaID.cs

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace КорпСбор_интерфейсСшарп

{

   public partial class PoiskZakazaID : Form

   {

       public PoiskZakazaID()

       {

           InitializeComponent();

       }

       private void PoiskZakazaID_Load(object sender, EventArgs e)

       {

       }

   }

}

Текст модуля Form1.cs

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace WindowsFormsApplication1

{

   public partial class Form1 : Form

   {

       public Form1()

       {

           InitializeComponent();

       }

       private void button1_Click(object sender, EventArgs e)

       {

           Form2 Pass = new Form2();

           Pass.Show();

       }

   }

}

Текст модуля Form2.cs

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace WindowsFormsApplication1

{

   public partial class Form2 : Form

   {

       public Form2()

       {

           InitializeComponent();

       }

       private void textBox1_TextChanged(object sender, EventArgs e)

       {

       }

   }

}


 

А также другие работы, которые могут Вас заинтересовать

38226. Борьба с коррупцией в период трансформации 43.64 KB
  Об этом говорится в исследовании Глобальный барометр коррупции Globl Corruption Brometer подготовленном Центром антикоррупционных исследований и инициатив Trnsprency Interntionl. Среди стран СНГ лидирует в рейтинге коррупции Азербайджан где к взяткам прибегают 47 граждан. Отметим что общий показатель коррупции по всем странам мира вырос за последнее время: по данным исследования сегодня один человек из четырех не понаслышке знает о том что такое взятка. Тем не менее исследование отмечает и некоторые позитивные тенденции: так в...
38229. Теория бухгалтерского учета. Понятие об учете, виды учета, их взаимосвязь 487 KB
  Понятие об учете виды учета их взаимосвязь. Предмет и объекты бухгалтерского учета. Метод бухгалтерского учета. Обобщение данных текущего бухгалтерского учета.
38230. Глобализация конкуренции и конкурентные преимущества стран 39.08 KB
  Один из основных детерминантов национального конкурентного преимущества в какойлибо отрасли это спрос на внутреннем рынке на товары или услуги предлагаемые этой отраслью. Взаимосвязанные отрасли Для многих отраслей самым главным ресурсом остается наличие связанных и вспомогательных отраслей. Стратегия структура и соперничество фирм Еще одним важным детерминантом определяющим конкурентоспособность отрасли является тот факт что фирма создается организуется и управляется в зависимости от характера конкуренции на внутреннем рынке.
38231. Маркетинг. Ответы на экзаменационные вопросы 111 KB
  Сущность и эволюция маркетинга. Изучение маркетинга позволяет сделать максимально правильный выбор целевого рынка. Самой главной целью маркетинга является: поставить производимый товар или услугу вне конкуренции. Без маркетинга работа предприятия практически невозможна.
38232. Теория маркетинга. Сбытовая политика предприятия 394.5 KB
  Рынок – совокупность существующих и потенциальных покупателей товара. Анализ маркетинговой среды: определение ёмкости рынка прогнозирование величины спроса проведение маркетинговых исследований выбор целевого сегмента и определение его профиля позиционирование товара и фирмы в целом. Разработка товарной политики: разработка новых товаров управление товарным ассортиментом разработка дизайна и качественных характеристик товара разработка упаковки и товарной марки определение комплекса дополнительных услуг. Применяется когда реальные...
38233. Организация маркетинга на предприятии, организационный механизм 62.5 KB
  Организационный механизм – маркетинговое подразделение предприятия а управленческий – разрабатываемый им план маркетинга который является составной частью бизнес-плана. Функциональная служба маркетинга включает в себя отделы где сотрудники специализируются на выполнении одной определённой функции маркетинга. Товарная служба маркетинга характеризуется те что служба состоит из отдела которая осуществляет деятельность по определённому товару группе товаров.
38234. Анализ маркетинговой среды 109.5 KB
  Видовые конкуренты – это прочие разновидности того же товара способные удовлетворить конкретное желание покупателя. Конкуренты марки – это разные марки одного и того же товара способные удовлетворить его желание. В данном случае разновидностями товара будут трех пяти и десятискоростные велосипеды. расположите по определённым характеристикам характеристики товара при его покупке.