Скачать .docx |
Дипломная работа: Автоматизированная система управления документооборотом центральной заводской лаборатории. Подсистема регистрации и сопровождения заказов на испытания
Автоматизированная система управления документооборотом ЦЗЛ. Подсистема регистрации и сопровождения заказов на испытания.
Введение
Любая деятельность человека связана с обработкой информации. При этом наибольший успех имеет тот, кто может качественно обработать достаточно большой объем информации за приемлемое время. Естественно, что проблема создания различных средств и методов оперирования с информацией всегда привлекала внимание общества.
В настоящее время компьютерная индустрия проникает во все области нашей жизни. Компьютер становится нашим повседневным помощником. Области применения ЭВМ непрерывно расширяются, все более захватывая и такие стороны человеческой деятельности, которые, как казалось, не приемлют каких либо вычислений. Применение ЭВМ в системах обработки информации и управления, для научно-технических расчетов и моделирования стало вполне естественным.
Одна из областей применения компьютеров – это автоматизация процессов производства. В настоящее время все большее значение имеет ускоренное решение некоторых видов задач, что приводит к экономии ресурсов и времени. Автоматизированная система управления документооборотом ЦЗЛ решает именно эти две задачи.
До внедрения данного программного продукта на производстве все заказы хранились в многочисленных журналах, хранимых в разрозненном виде. Автоматизация процесса позволила упорядочить и структурировать все имеющиеся по заказам сведения. Это привело к упрощению труда оператора и значительному сокращению времени на обработку одного вида заказа.
1. Общая часть
1.1 Цель разработки
В данном дипломном проекте поставлена следующая задача: спроектировать и реализовать автоматизированную систему управления документооборотом центральной заводской лаборатории ОАО «ВМЗ». Техническое задание на проектирование необходимо разрабатывать на основании анализа текущей системы документооборота, сопровождающей процесс проведения испытаний в лабораториях ЦЗЛ.
1.1.1 Анализ использования разработки
Система предназначена для автоматизации процесса формирования и обработки заказов на испытание образцов продукции основных цехов ОАО «ВМЗ», а также записи и хранения их в электронном виде.
Объектом автоматизации является документооборот процесса подготовки, изготовления и испытания образцов продукции основных цехов ОАО «ВМЗ».
Автоматизированная система управления документооборотом ЦЗЛ ОАО «ВМЗ» (именуемая далее Система) разрабатывается для:
- формализации процесса формирования заказов на испытание образцов с единой системой нумерации;
- централизованного электронного учёта заказов на испытание образцов и результатов испытаний;
- практически полного упразднения бумажных журналов и протоколов,
- сокращения объема вводимых данных за счет исключения дублирования вводимой информации о пробах, образцах и испытаниях,
- повышения оперативности поступления заказов и формирования протоколов и сертификатов на базе единой интегрированной автоматизированной системой оперативного управления производством (ИАСОУП) ОАО «ВМЗ».
Разрабатываемый программный продукт должен строиться по клиент-серверной архитектуре.
Серверная часть системы должна быть общей с интегрированной автоматизированной системой оперативного управления производством (ИАСОУП) и использовать в качестве хранилища данных единую базу данных (БД) в системе управления базами данных (СУБД) Oracle.
Клиентские части должны иметь несложный интуитивно понятный интерфейс, облегчающий работу оператора. Кроме того, клиентские подсистемы должны строиться по открытой архитектуре для обеспечения возможности автоматического ввода данных с различных устройств электронной регистрации измерений.
1.1.2 Характеристика объекта информатизации
Существует более 10 различных форм заказов, которые различаются по цехам и по видам испытаний.
Все формы различаются как по содержанию, так и по расположению полей. Номер заказа присваивается в цехе (порядковый с начала года). Регистрация заказов может проводиться в цехе и в ЦЗЛ (номер, дата). По одному заказу изготавливается несколько образцов.
Пробы сдаются сменному мастеру участка изготовления образцов. Сменный мастер регистрирует заказ в «журнале приёма проб». Объём и виды необходимых испытаний указываются цехом в заказе. Может указываться ссылка на научно-техническую документацию, в которой указано, какие образцы и каким образом необходимо изготавливать и / или непосредственно указываются виды и количество испытаний.
После изготовления образцов на участке изготовления производится регистрация в том же «журнале приёма проб» даты и времени сдачи и ответственного лица.
Заказ (ранее доставленный на участок изготовления образцов) вместе с образцами передаётся в одну из лабораторий.
В лабораториях заказ регистрируется в «журнале приёма образцов» в лаборатории механических испытаний (ЛМИ), журнале «Сталь. Результаты испытаний (трубные цеха)» в объединенной аналитической лаборатории (ОАЛ) и в аналогичных журналах в других лабораториях. Заказ, как документ, хранится в лаборатории в течение 5 лет.
Результаты механических испытаний фиксируются в журналах. Всего существует 21 журнал по цехам и видам испытаний. В пределах одного заказа в журналах дублируются такие данные как: номер заказа, дата, время, марка стали, номер плавки, номер партии, номер трубы и т.д. Некоторые результаты получаются в результате вычислений, которые производятся на бумаге с использованием калькулятора.
Кроме журналов, результаты испытаний фиксируются в протоколе. Протокол оформляется в 2‑х экземплярах: один хранится в ЛМИ, второй – направляется в отдел технического контроля (ОТК) цеха.
В других лабораториях процесс регистрации и производится аналогичным образом. Отличия имеются в формах документов согласно специфике испытаний.
1.2 Анализ методов решения
Архитектура прикладной информационной системы четко определяет способ построения и развития приложений и компонентов системы и способ включения приложений в общую информационную систему. Если все делается правильно, то приложения в системе можно однозначно отнести к одному из трех типов информационных составляющих (или компонент) системы.
Презентационная
компонента содержит логику, которая представляет информацию во внешний мир и может вводить информацию из внешнего мира. В большинстве случаев внешним миром для
информационной системы является человек, конечный пользователь. Однако иногда в качестве такового может оказаться аппаратный комплекс, телефонная аппаратура, банкомат или другая аппаратура сопряжения. Обычно логика презентационной компоненты предназначена для генерации
системы вложенных меню, диалогов, форм, экранов и прочего, что позволяет пользователю осуществлять навигацию по различным частям приложения или по разным приложениям или вводить информацию на экране. Иногда на этом уровне приложение также позволяет осуществлять простейшие оценки правильности ввода информации и простейшие манипуляции по внешнему виду выводимой информации.
Бизнес-компонента содержит логику, которая реализует манипуляции с выбранными данными по определенным правилам, т.е. бизнес-компонента – это обработка.
Компонента доступа к данным содержит логику, которая взаимодействует либо с хранилищами данных (базы данных, иерархическая файловая система) или с каким либо типом удаленного источника данных, например, с другой прикладной системой. Функции доступа к данным обычно используются бизнес-компонентами.
1.2.1 Однозвенные приложения
Для мэйнфремов и для мини-компьютеров многопользовательские приложения обычно не разбиваются на свои фундаментальные составляющие. Все три компоненты сочетаются в исполняемой программе, которая работает на одной машине с вполне определенным файлом данных. В настоящее время таких программ почти уже не существует, и специалисты обучены писать по-новому, на совершенно других инструментах программирования.
Раньше в информационных отделах работали специалисты, писавшие файл-серверные системы для персоналок. Это означает, что все программы были сложны для понимания, и развивать которые мог только их
первоначальный автор.
1.2.2 Двухзвенные приложения
С появлением персональных компьютеров, локальных сетей, реляционных баз данных и мощных настольных приложений, компьютерная индустрия развернулась в сторону открытых систем и архитектуры клиент-сервер. Вскоре появились мощные инструменты для скоростной разработки клиент-серверных приложений.
Открытые системы создавались для того, чтобы выйти из ограниченности и закрытости персонального решения и получить доступ к внешним источникам информации. В клиент-серверной архитектуре пользователи получили доступ к реляционным данным, могут сгенерировать свои собственные отчеты и манипулировать выборками при помощи персональных электронных таблиц и инструментов анализа данных на своих персональных компьютерах. Двухзвенная клиент-серверная архитектура разделяет приложение на две части: вычисление настольным компьютером и хранение данных сервером. Теперь клиентская машина в общем случае может быть с любой операционной системой, от DOS до UNIX, серверная часть также может варьироваться от аппаратуры, возможно даже меньшей вычислительной мощности по сравнению с персональным компьютером пользователя до многопроцессорных кластеров или мэйнфреймов.
Граница между клиентом и сервером в таких системах проводится в произвольном месте и большей частью зависит от используемых инструментов. В наиболее популярных и распространенных клиент-серверных системах в качестве клиентской рабочей станции применяется Windows‑компьютер, а в качестве сервера – SQL сервер на основе Windows или UNIX. Инструментарий, при помощи которого создаются такие системы, позволяет разработчикам разрабатывать логику клиента и осуществлять простейшие запросные операции серверу. Такой тип клиент-серверной
архитектуры называют архитектурой с толстым клиентом
, поскольку большая часть приложения, включая презентационную логику, бизнес-логику и логику доступа к данным, выполняется на персональном сетевом компьютере.
Двухзвенный клиент-серверный подход предоставляет значительные преимущества по сравнению с однозвенным подходом – проектирование происходит заметно быстрее, а сервер может быть довольно простым, поскольку большая часть сложной обработки возлагается на клиента. Следствием из этого является заметное удешевление системы, особенно серверной ее части. Появляется возможность не зависеть от платформы сервера, поскольку все базы данных от одного поставщика предоставляют одинаковый интерфейс независимо от платформы сервера. А такие интерфейсы, как ODBC (Microsoft) или IDAPI (Borland-Inprise) позволяют добиться и независимости от производителя БД.
Также двухзвенный подход обладает и недостатками. Это проблемы с безопасностью данных, проблемы с надежностью и управляемостью информационной системы, чрезмерные расходы при модификации и обслуживании информационной системы. Двухзвенная архитектура работает прекрасно, если имеется только одна реляционная БД, а клиентские приложения совершают четко определенные простые действия с данными. Hо по мере возрастания сложности системы – когда количество источников данных и количество пользователей возрастает – двухзвенная клиент-серверная система очень быстро исчерпывает возможности по развитию. Без жесткого контроля по безопасности, который могла бы предоставить только централизованная система, такой контроль должен возлагаться на каждое клиентское приложение в отдельности. По мере возрастания сложности клиентского приложения увеличивается и его размер, а, следовательно, и затраты.
Одной из методик, повышающей надежность и управляемость корпоративной информационной системы, является перенос логики управления данными в хранимые процедуры на корпоративный SQL сервер. При этом логика доступа к данным отделяется от логики обработки данных. Хранимые процедуры представляют собой предкомпилированные функции SQL, работающие внутри SQL сервера. Они заметным образом повышают общую устойчивость и производительность системы.
Однако написание хранимых процедур требует довольно высокой квалификации. Кроме того, при написании хранимых процедур разработчик имеет дело со специфическим окружением конкретного SQL-сервера, его специфической архитектурой и его ограничениями.
Также двухзвенный клиент-серверный подход хорошо работает в случае, когда все корпоративные данные хранятся лишь в одном месте, в одном SQL-сервере. Но на самом деле большинство данных до сих пор находится в прежних форматах баз данных, а то и просто сохраняются в файловой системе. Существующие на сегодня RAD-инструменты (rapidapplicationdevelopment) предназначены большей частью для операций с данными, выбираемыми из реляционных таблиц, и почти не предлагают средств для интеграции данных из многих источников в единую систему.
Каждый производитель SQL-сервера поддерживает свой собственный протокол для обращения к данным, поэтому разработчику приходится каждый раз заново решать проблему установления соединения, синхронизации данных, безопасности и множество других мелких и неприятных технических проблем.
Клиентские приложения становятся все более сложными и все менее управляемыми. Это общая тенденция для двухзвенного клиент-серверного подхода.
Двухзвенная клиент-серверная архитектура – это архитектура, существенно зависящая от применяемых программных инструментов.
Возможности масштабирования и развития системы существенно ограничены. Двухзвенная архитектура позволяет весьма производительным способом использовать RAD-инструменты, однако стоимость масштабируемости, администрирования, развития такой архитектуры непомерно высока. И при всем при этом такая архитектура принципиально ограничивает доступ ко всем корпоративным данным и возможности интеграции всех систем в единое целое, поддержку одновременно и новых и прежних технологий.
Но инструменты визуальной сборки приложений дали возможность проектировать систему чрезвычайно быстро. SQL‑серверы позволяют одновременно работать большому числу пользователей. Сетевой трафик настолько мал, что сеть практически не замедляет работу большого числа конечных пользователей и передает данные с большой скоростью. Проблемы и ограничения содержатся не в программных продуктах, а в выбранной архитектуре прикладной информационной системы.
1.2.3 Трехзвенные приложения
Способ преодолеть ограничения двухзвенной архитектуры существует. Переход к трехзвенной архитектуре позволяет сохранить преимущества двухзвенного клиент-серверного подхода, и, кроме того, добиться дополнительной гибкости.
Под тремя звеньями понимаются три логические части корпоративной прикладной системы, количество компьютеров, работающих в системе, не имеет значения. Трехзвенная модель информационной системы подразумевает логическое деление прикладной системы на три звена – презентационная логика, бизнес-логика и логика доступа к данным. В самом общем случае в системе может существовать сколь угодно много компонент каждого типа. Поэтому говорят о многозвенной архитектуре. Каждая прикладная компонента системы может разделяться любым количеством прикладных систем. При разработке компоненты каждого типа может использоваться самый подходящий тип инструментального средства. Каждая компонента может быть установлена на одном или сразу на многих вычислительных машинах. Каждая компонента взаимодействует друг с другом через общий интерфейс, который скрывает детали реализации соответствующей логики. Hа инфраструктуру системы возлагаются задачи обеспечения безопасности данных, совместимости и надежной синхронизации между компонентами системы.
Эта задача решена для всех компонент системы, и не требует отдельной проработки для каждой компоненты.
1.2.3.1 Модули и объекты
Преимущества трехзвенной архитектуры заключаются не только в жизненном цикле приложения. То, что строится в результате применения многозвенного подхода – это набор клиентских и серверных модулей, которые взаимодействуют друг с другом при помощи стандартных протоколов и стандартных соглашений об интерфейсах, их можно интегрировать и сопрягать друг с другом. Каждый модуль содержит в себе один или более объектов, разделяемых между приложениями. Эти объекты могут включаться в качестве составной части в другие системы.
1.2.3.2 Балансировка загрузки и надежность системы
Динамическая распределенная инфраструктура позволяет распределенному приложению динамически реконфигурироваться для того, чтобы приспособиться к увеличившемуся количеству пользователей, изменившейся загрузке процессора или при внезапно случившемся сбое. Это может происходить абсолютно незаметно для пользователя. Именно физическое разделение системы на модули является наиболее эффективным средством для поддержки масштабируемости, надежности системы. По мере подключения дополнительных пользователей, при превышении допустимого уровня использования процессора, при исчерпании физической памяти или при наступлении какого-либо другого критерия серверный модуль может переключиться на альтернативную серверную машину или разместить нагрузку на нескольких дополнительных машинах. Модуль балансировки может быть использован для того, чтобы повысить надежность системы в целом. Это достигается автоматическим переключением на работающую серверную машину в случае возникновения какой-либо неисправности. Это означает, что распределенная инфраструктура, позволяющая приложению быть разделяемым, безопасным, надежным, масштабируемым и управляемым, является самой важной составляющей корпоративной информационной системы.
1.2.3.3 Служба каталогов
Служба каталогов организует доступ к динамическому списку ресурсов всего предприятия. Когда пользователь или клиентское приложение формирует запрос, служба каталогов обрабатывает его и сообщает клиенту, каким образом взаимодействовать с соответствующим ресурсом. Для того, чтобы объект можно было найти в системе, тот должен быть зарегистрирован, как DCOM‑объект. При этом это дает требуемую гибкость, характерную для трехзвенных систем – мы просто указываем объект, и – в соответствии с каталогом представляется тот компьютер, на котором будет исполняться код. В результате такой гибкости становится возможной и балансировка загрузки – можно предоставить тот компьютер, который в данный момент меньше всего загружен работой.
1.2.3.4 Сервис безопасности
Сервис безопасности устанавливает реестр авторизированных пользователей и групп пользователей всего предприятия и регулирует, какие ресурсы всей системы допустимо использовать для каждого пользователя. Сервис безопасности предоставляет единственный пароль для пользователя для всех доступных ресурсов предприятия. Если пользователь был аутентифицирован при входе в систему, все подсистемы воспринимают его аутентифицированным и не требуют повторного введения пароля при перемещении от подсистемы к подсистеме.
1.2.3.5 Служба управления приложениями
Служба управления приложениями предоставляет средство динамической реконфигурации приложений. Эта служба отвечает за запуск приложений на соответствующей машине и их последующий мониторинг. Если с приложением что-нибудь случилось в процессе эксплуатации, служба управления приложениями должна рестартовать приложение или произвести некую последовательность действий в зависимости от того, что было предписано при конфигурации системы.
1.2.3.6 Интерфейс приложений
Для того чтобы трехзвенная инфраструктура заработала, недостаточно создать набор распределенных приложений, которые могут запускаться и уничтожаться под управлением сервера приложений. Кроме этого, необходимо, чтобы разные слои трехзвенной архитектуры могли взаимодействовать между собой.
Как правило, ключевая идея такого взаимодействия заключается в том, что базовый программный продукт предоставляет централизованный или распределенный репозиторий интерфейсов всех модулей системы. При введении модуля в систему такой интерфейс регистрируется в репозитории-хранилище, после чего различные модули, чьи интерфейсы совместимы между собой, могут подключаться друг к другу и взаимодействовать между собой, в каком бы месте сети они не находились.
Для того чтобы разработчик мог использовать программные инструменты от различных производителей (например, Java, C++, Delphi и т.п.) для определения интерфейсов распределенных объектов применяется специальный язык определения интерфейсов IDL. Для разных стандартов (CORBA, DCOM, DCE) этот язык несколько отличается, но главный его смысл – он нужен для однозначного определения интерфейса взаимодействия модулей между собой.
1.2.3.7 Гранулированность информационной системы
За высокую гранулированность в системе приходится платить производительностью (динамическое связывание объектов требует затрат процессорного времени), а если система разбита на слишком крупные гранулы, уменьшается степень повторного использования кода, что нежелательно. CORBA, DCOM, DCE подталкивают разработчика к разбиению системы на мелкие гранулы (или объекты, что более правильный термин). Приложения серверного слоя также могут дополнительно разбиваться на гранулы-объекты, статически связываемые в период проектирования (компилирование приложения). Как правило, продукт от каждого производителя ориентирован на соответствующую архитектуру объектов (CORBA, DCOM, DCE), так Entera ориентирована на DCE, MIDAS – на DCOM, ORBIX – на CORBA.
Объектные трехзвенные архитектуры DCE, CORBA, DCOM предлагают реально действующие стандарты для построения трехзвенных приложений. Существующие серверы приложений, которые не поддерживают этих архитектур, предлагают свои внутренние механизмы для построения трехзвенной архитектуры. Перед тем, как выбрать, в какой архитектуре строить свою информационную систему, корпоративный разработчик обязан ясно представлять себе, какую цену он заплатит за соответствие архитектуре, то есть необходимо хорошо представлять себе не только плюсы соответствующей архитектуры, но и ее минусы.
1.2.3.8 Минусы трехзвенных архитектур
Трехзвенные архитектуры обладают рядом преимуществ. Это гибкость, масштабируемость, многоплатформенность, распределенность технологий, управляемость, сочетаемость технологий, безопасность данных, доступность, надежность. Но также они имеют и ряд недостатков:
– непроработанность архитектуры;
- тяжелые в реальности решения;
- несоответствие с уже имеющимися технологиями;
- неустойчивость версий стандартов, а, следовательно, потенциальная несовместимость;
- недоразвитость инструментов (неудобство, ошибки);
- неоправданная дороговизна средств (или обучения специалистов, или высокая цена администрирования).
Рассмотрим два основных вида объектных архитектур DCE и DCOM. DCE – это распределенная архитектура появившаяся раньше DCOM.
Исходная UNIX-ориентированность технологии DCE, ее некоторая громоздкость, ее ориентированность только на язык С, отсутствие системы управления приложениями – это очевидные минусы.
С другой стороны – надежность, поддержка архитектуры многими производителями, надежный сервис безопасности, масштабируемость и ориентация архитектуры для работы с тысячами пользователей, использующих сотни источников данных – это плюсы. Расширяемость DCE доказывает и то, что при помощи хорошо устроенных продуктов можно скомпенсировать недостатки архитектуры, достроив в рамках архитектуры недостающие механизмы.
DCOM – закрытая архитектура с закрытым протоколом. Может использоваться только в рамках данной реализации, соотношения между объектными сервисами обладают очевидными недостатками. Производителем DCOM является компания Microsoft.
Но недостатки архитектуры так же, как и в случае DCE, можно исправить удачно сделанными продуктами. Inprise MIDAS вносит необходимую гибкость в архитектуру, снабжая ее необходимым инструментарием и утилитами.
1.2.3.9 Тонкие и толстые клиенты
В системе, построенной на основе трехзвенной архитектуры, клиентское приложение часто называют тонким клиентом. Имеется в виду то, что клиентское приложение трехзвенной архитектуры освобождено от кода обращения к данным, и поэтому гораздо тоньше по объему.
Тонким клиентом называют также и стандартные internet‑клиенты, которые в интрасетях действительно занимаются только отображением / представлением данных, хотя и не являются объектами, соответствующими архитектурам DCE, CORBA, DCOM. Эти два типа клиентов различаются не столько по объему кода, сколько по способу их применения в течение жизни информационной системы. Трехзвенная архитектура предназначена для того, чтобы внести расширяемость и масштабируемость в информационные системы. Системы, которым нужны эти качества, никогда не бывают полностью завершены, и в течение жизненного цикла всегда подвергаются изменениям. Тонкие клиенты первого типа также подвергаются изменениям с изменениями системы и, должны время от времени заменяться новыми, более модифицированными версиями. Тонкие клиенты второго типа (ультратонкие) могут не заменяться в течение жизненного цикла системы, поэтому обслуживание интранет-системы несравненно проще трехзвенной системы, построенной без применения стандартных тонких клиентов. В принципе, никакого противоречия тут нет, и можно было бы построить ультратонкого клиента и для DCE, CORBA, DCOM.
Первоначально может показаться, что ультратонкий клиент не может быть достаточно функциональным по сравнению с просто тонким. Действительно, ультратонкий клиент не меняется в течение своей жизни, однако способен интерпретировать скрипты, получаемые с сервера.
В том случае, если при установлении соединения (или в течение рабочего сеанса, что тоже возможно) приложение серверного слоя снабжает ультратонкого клиента правилами работы с бизнес-логикой, правилами отображения и манипулирования информацией, мы имеем дело с процессом доставки кода. В предельном случае готовое клиентское приложение, хранящееся на сервере, просто инсталлируется на клиентский компьютер. И это наиболее опасная ситуация, поскольку на клиентский компьютер может быть доставлено разрушительное приложение, снабженное вирусом или «троянским конем».
Следующий шаг по ужесточению контроля – это введение на клиента интерпретатора, который контролирует опасные ситуации. Например, на клиентский компьютер подгружается только описание формы – расположение кнопок, полей ввода и других контрольных элементов, что позволяет достичь компромисса между требованиями безопасности, функциональности презентационной логики и требованиями нулевого администрирования для ультратонкого клиента.
Движение в сторону достижения максимальной безопасности в пределе останавливается на варианте, когда клиентскими рабочими станциями являются терминалы либо X‑терминалы, а вся информация между сервером и терминалами курсирует с шифрованием трафика.
Удобство реализации ультратонкого клиента с подгружаемым со стороны сервера приложений скриптом или кодом может быть как удачным, так и неудачным в зависимости от реализации.
1.3 Анализ средств программирования
На сегодняшний момент существует большое количество языков программирования с различными возможностями и функционалом. В процессе обучения был изучен язык программирования С++, поэтому было принято решение вести разработку системы на С++ или родственном ему языке. Язык C++ – это универсальный язык программирования, для которого характерны экономичность выражения, современный поток управления и
структуры данных, богатый набор операторов. Язык C++ не является ни языком «очень высокого уровня», ни «большим» языком, и не предназначается для некоторой специальной области применения, но отсутствие ограничений и общность языка делают его более удобным и эффективным для многих задач, чем языки, предположительно более мощные.
При этом возникает проблема, на какой разновидности остановится и в какой интегрированной среде разработки создавать программную часть ИС.
Проведем сравнительный анализ основных сред разработки на С++:
1.3.1 Borland C ++ Builder
BorlandC++ Builder– очень мощная интегрированная среда программирования. Вместо отдельного инструментария, оперирующего визуальными элементами управления, в C++ Builder интегрирована так называемая палитра компонент, разделенная картотечными вкладками на несколько функциональных групп. Функциональные возможности поставляемых компонент можно достаточно просто модифицировать, а также разрабатывать компоненты, обладающие совершенно новым поведением.
Система содержит библиотеку из более 100 визуальных компонент. Помимо известных элементов управления Windows (кнопки, линейки прокрутки, поля редактирования, простые и комбинированные списки и т.д.) библиотека содержит новые компоненты поддержки диалогов, обслуживания баз данных и многие другие.
Опытным C++ программистам нравится синтаксис и структура кода разрабатываемых на C++ Builder программ, хотя его графическое обрамление заметно отличается от традиционных оболочек систем разработки. C++ Builder поддерживает основные принципы объектно-ориентированного программирования – инкапсуляцию, полиморфизм и множественное наследование, а также нововведенные спецификации и ключевые слова в стандарте языка.
1.3.2 Microsoft Visual C ++
MicrosoftVisualC++ – универсальный язык программирования, задуманный так, чтобы сделать программирование более приятным для серьезного программиста. Visual C++ предоставляет гибкие и эффективные средства определения новых типов. Используя определения новых типов, точно отвечающих концепциям приложения, программист может разделять разрабатываемую программу на легко поддающиеся контролю части. Информация о типах содержится в некоторых объектах типов, определенных пользователем. Такие объекты просты и надежны в использовании в тех ситуациях, когда их тип нельзя установить на стадии компиляции. Программирование с применением таких объектов часто называют объектно-ориентированным. При правильном использовании этот метод дает более короткие, проще понимаемые и легче контролируемые программы.
Ключевым понятием C++ является класс. Классы обеспечивают скрытие данных, гарантированную инициализацию данных, неявное преобразование типов для типов, определенных пользователем, динамическое задание типа, контролируемое пользователем управление памятью и механизмы перегрузки операций. C++ предоставляет гораздо лучшие, чем в C, средства выражения модульности программы и проверки типов. C++ и его стандартные библиотеки спроектированы так, чтобы обеспечивать переносимость. Имеющаяся на текущий момент реализация языка будет идти в большинстве систем, поддерживающих C. Из C++ программ можно использовать C библиотеки, и с C++ можно использовать большую часть инструментальных средств, поддерживающих программирование на C.
1.3.3 Microsoft Visual Studio
MicrosoftVisualStudio– это уже проверенный временем программный продукт. Выделим две важнейшие его идеи:
· открытость для языков программирования;
· принципиально новый подход к построению каркаса среды – Framework. Net.
Среда разработки теперь является открытой языковой средой. Это означает, что наряду с языками программирования, включенными фирмой Microsoft в среду могут добавляться любые языки программирования, компиляторы которых создаются другими фирмами-производителями. Таких расширений среды Visual Studio сделано уже достаточно много, практически они существуют для всех известных языков – Fortran и Cobol, RPG и Component Pascal, Oberon и SmallTalk.
Открытость среды не означает полной свободы. Главное ограничение, которое можно считать и главным достоинством, состоит в том, что все языки, включаемые в среду разработки Visual Studio. Net, должны использовать единый каркас – Framework. Net. Благодаря этому достигаются многие желательные свойства:
- легкость использования компонентов, разработанных на различных языках;
- возможность разработки нескольких частей одного приложения на разных языках;
- возможность бесшовной отладки такого приложения;
- возможность написать класс на одном языке, а его потомков – на других языках.
Существенно расширился набор возможных архитектурных типов построения приложений. Помимо традиционных Windows- и консольных приложений, появилась возможность построения Web‑приложений. Большое внимание уделяется возможности создания повторно используемых компонентов – разрешается строить библиотеки классов, библиотеки элементов управления и библиотеки Web‑элементов управления. Популярным архитектурным типом являются Web‑службы, ставшие сегодня
благодаря открытому стандарту одним из основных видов повторно используемых компонентов.
Рассмотрим два типа языка Visual С, включенных в среду разработки MicrosoftVisualStudio:
1.3.3.1 Visual С++
Одним из основных достоинств языка С++ считается высокая переносимость написанных на нем программ между компьютерами с различной архитектурой, между различными операционными средами. Трансляторы языка С++ существуют практически для всех используемых в настоящее время персональных компьютеров.
С++ – язык программирования высокого уровня, обеспечивающий необычайно легкий доступ к аппаратным средствам компьютера.
Перечислим некоторые особенности языка С++:
- В языке С++ реализованы некоторые операции низкого уровня (в частности, операции над битами). Некоторые из таких операций напрямую соответствуют машинным командам.
- Базовые типы данных языка С++ отражают те же объекты, с которыми приходится иметь дело в программе на языке ассемблера, – байты, машинные слова, символы, строки.
- Язык С++ поддерживает механизм указателей на переменные и функции. Поддерживается арифметика указателей, что позволяет осуществлять непосредственный доступ и работу с адресами памяти практически так же легко, как на языке ассемблера.
Несмотря на эффективность и мощность конструкций языка С++, он относительно мал по объему. В нем отсутствуют встроенные операторы для выполнения ввода-вывода, динамического распределения памяти, управления процессами и т.п., однако в системное окружение языка С входит библиотека стандартных функций, в которой реализованы подобные действия. Вынос этих функций в библиотеку позволяет отделить особенности архитектуры конкретного компьютера и соглашений операционной системы от реализации языка, сделать программу максимально независимой от деталей реализации операционной среды. В то же время программисты могут пользоваться системными библиотечными программами, чтобы более эффективно использовать особенности конкретных операционных сред.
1.3.3.2 Visual C #
Многие разработчики хотели бы использовать современный язык, который позволял бы писать, читать и сопровождать программы с простотой Visual Basic и в то же время давал мощь и гибкость C++, обеспечивал доступ ко всем функциональным возможностям системы, взаимодействовал бы с существующими программами и легко работал с возникающими Web – стандартами.
Учитывая все подобные пожелания, Microsoft разработала новый язык – C#. В него входит много полезных особенностей – простота, объектная ориентированность, типовая защищенность, «сборка мусора», поддержка совместимости версий и многое другое. Данные возможности позволяют быстро и легко разрабатывать приложения, особенно COM – приложения и Web – сервисы. При создании C#, его авторы учитывали достижения многих
других языков программирования: C++, C, Java, Delphi, Visual Basic и т.д. При разработке C# у его авторов была возможность оставить в прошлом все неудобные и неприятные особенности (существующие, как правило, для обратной совместимости), любого из предшествующих ему языков. В результате получился действительно простой, удобный и современный язык, по мощности не уступающий С++, но существенно повышающий продуктивность разработок.
C# является хорошим выбором для быстрого конструирования различных компонентов – от высокоуровневой бизнес логики до системных приложений, использующих низкоуровневый код. Также следует отметить, что C# является и Web‑ориентированным – используя простые встроенные конструкции языка ваши компоненты могут быть легко превращены в Web‑сервисы, к которым можно будет обращаться из Internet посредством любого языка на любой операционной системе. Дополнительные возможности и преимущества перед другими языками приносит в C# использование передовых Web‑технологий, таких как: XML и SOAP. Среда разработки Web‑сервисов позволяет программисту смотреть на существующие сегодня Web‑приложения, как на родные C# объекты, что дает возможность разработчикам соотнести имеющиеся Web‑сервисы с их познаниями в объектно-ориентированном программировании.
Очень часто можно проследить такую связь – чем более язык защищен и устойчив к ошибкам, тем меньше производительность программ, написанных на нем. В C#, как в, несомненно, современном языке, существуют характерные особенности для обхода возможных ошибок. Например, там все переменные автоматически инициализируются средой и обладают типовой защищенностью, что позволяет избежать неопределенных ситуаций в случае, если программист забудет инициализировать переменную в объекте или попытается произвести недопустимое преобразование типов. Также в C# были предприняты меры для исключения ошибок при
обновлении программного обеспечения. Изменение кода, в такой ситуации, может непредсказуемо изменить суть самой программы. Чтобы помочь разработчикам бороться с этой проблемой C# включает в себя поддержку совместимости версий. В частности, если метод класса был изменен, это должно быть специально оговорено. Это позволяет обойти ошибки в коде и обеспечить гибкую совместимость версий. Также новой особенностью является поддержка интерфейсов и наследования.
Все рассмотренные выше языки программирования позволяют реализовать в полной мере все возложенные на разрабатываемую систему функции. Безусловно, при выборе языка нужно учитывать текущие тенденции в мире программирования. В настоящее время все большей популярностью пользуется С#, который к тому же в данный момент является ведущим языком по разработке открытых Web‑приложений. Именно поэтому данный программный продукт разработан на VisualC#.
1.4 Анализ платформ (операционных систем)
На сегодняшний день существует большое множество различных операционных систем. Наиболее популярными являются Windows‑системы и Unix‑системы, которые соответствуют всем международным стандартам и удовлетворяют пользователей по скорости, масштабируемости и открытости. Рассмотрим основные преимущества и недостатки этих операционных систем.
1.4.1 Linux
Linux – это современная POSIX‑совместимая и Unix‑подобная операционная система для персональных компьютеров и рабочих станций. Это многопользовательская сетевая операционная система с сетевой оконной графической системой X Window System. Операционная система Linux
поддерживает стандарты открытых систем и протоколы сети Internet и совместима с системами Unix, DOS, MS Windows. Все компоненты системы, включая исходные тексты, распространяются с лицензией на свободное копирование и установку для неограниченного числа пользователей.
Возможности, которые предоставляет операционная система Linux:
· дает возможность бесплатно и легально иметь современную ОС для использования, как на работе, так и дома;
· обладает высоким быстродействием;
· работает надежно, устойчиво, совершенно без зависаний; не подвержена вирусам;
· позволяет использовать полностью возможности современных ПК, снимая ограничения, присущие DOS и MS Windows по использованию памяти машины и ресурсов процессоров;
· эффективно управляет многозадачностью и приоритетами, фоновые задачи (длительный расчет, передача электронной почты по модему, форматирование дискеты и т.д.) не мешают интерактивной работе;
· позволяет легко интегрировать компьютер в локальные и глобальные сети, в т.ч. в Internet; работает с сетями на базе Novell и MS Windows;
· позволяет выполнять представленные в формате загрузки прикладные программы других ОС – различных версий Unix, DOS и MS Windows;
· обеспечивает использование огромного числа разнообразных программных пакетов, накопленных в мире Unix и свободно распространяемых вместе с исходными текстами;
· предоставляет богатый набор инструментальных средств для разработки прикладных программ любой степени сложности, включая системы класса клиент-сервер, объектно-ориентированные, с многооконным текстовым и / или графическим интерфейсом, пригодных для работы как в Linux, так и в других ОС;
· дает пользователю и особенно разработчику замечательную учебную базу в виде богатой документации и исходных текстов всех компонент, включая ядро самой ОС.
Linux – это полностью многозадачная многопользовательская операционная система (точно также как и другие версии UNIX). Linux достаточно хорошо совместим с рядом стандартов на уровне исходных
текстов, включая IEEE POSIX.1, System V и BSD. Linux поддерживает различные типы файловых систем для хранения данных. Реализована файловая система FAT и FAT32, позволяющая прямо обращаться к файлам MS-DOS на жестком диске. Поддерживается также файловая система ISO 9660 CD-ROM для работы с дисками CD-ROM.
Linux обеспечивает полный набор протоколов TCP/IP для сетевой работы. Поддерживается весь спектр клиентов и услуг TCP/IP, таких как FTP, telnet, NNTP и SMTP.
1.4.2 Microsoft Windows
Microsoft Windows предоставляет иной подход к средам рабочей станции и сервера и реализует новейшие концепции управления системой и
администрирования. Вот некоторые из них.
• Active Directory – расширяемая и масштабируемая служба каталогов, использующая пространство имен, основанное на стандартной Интернет-службе именования доменов (DomainNameSystem, DNS).
• IntelliMirror – средства конфигурирования, поддерживающие зеркальное отображение пользовательских данных и параметры среды, а также центральное администрирование установки и обслуживания программного обеспечения.
• Terminal Services – службы терминалов, обеспечивающие удаленный вход в систему и управление другими системами Windows.
• WindowsScriptHost– сервер сценариев Windows для автоматизации таких распространенных задач администрирования, как создание учетных записей пользователей и отчетов по журналам событий.
Хотя у Windows масса других возможностей, каждая из этих четырех оказывает большое влияние на выполнение задач администрирования. Наиболее эффективна технология Active Directory, фундаментально изменившая способы управления пользователями, группами и системами. Так что для успешной работы в Windows необходимо четко понимать структуры и процедуры Active Directory.
На крупных промышленных предприятиях чаще всего используют Unix‑системы, т. к. они более удовлетворяют потребностям и запросам пользователей. Многие задачи, решаемые в Unix, невозможно реализовать в Windows‑системах. Но в Unix‑системах присутствует один большой недостаток – они не поддерживают Batch.21, при помощи которого разрабатываемый программный продукт будет обращаться к базе данных и будет в качестве посредника между клиентской и серверной части приложения.
Поэтому в качестве платформы для данного программного обеспечения была выбрана Windows‑система, которая удовлетворяет всем поставленным требованиям для решения данной задачи.
1.5 Обзор и выбор СУБД
База данных – это набор записей и файлов, организованных специальным образом.
До появления СУБД все данные, которые содержались в компьютерной системе постоянно, хранились в виде отдельных файлов.
Поставщики СУБД предлагают программные продукты для различных вычислительных систем: от персональных компьютеров и рабочих станций
до локальных сетей, мини-компьютеров и больших ЭВМ. Рассмотрим 4 основных типа СУБД, которые занимают лидирующее положение на рынке.
1.5.1 MySQL
MySQL–представляет собой очень быстрый, многопоточный, многопользовательский и надежный сервер баз данных SQL. Сервер MySQL предназначен как для обслуживания критически важных, сильно загруженных производственных систем, так и для встраивания в программное обеспечение массового применения. MySQL – торговая марка, принадлежащая MySQL AB. Программное обеспечение MySQL распространяется в соответствие с двойной лицензией. Пользователь может использовать его либо как бесплатный продукт с открытым исходным кодом на условиях общедоступной лицензии GNU, либо приобрести стандартную коммерческую лицензию у MySQL AB.
Внутренние характеристики и переносимость:
- написан на C и C++. Протестирован на множестве различных компиляторов;
- работает на различных платформах;
- для обеспечения переносимости используется GNU Automake, Autoconf и Libtool;
- полностью многопоточный с использованием потоков ядра. Это означает, что, если такая возможность обеспечивается, можно легко организовать работу с несколькими процессорами;
- очень быстрые дисковые таблицы на основе В-деревьев со сжатием индексов;
- очень быстрая базирующаяся на потоках система распределения памяти;
- очень быстрые соединения, использующие оптимизированный метод однопроходного мультисоединения (one-sweep multi-join);
- хеш-таблицы в памяти, используемые как временные таблицы;
- SQL‑функции реализованы при помощи хорошо оптимизированной библиотеки классов, поэтому они выполняются настолько быстро, насколько это возможно. Обычно после инициализации запроса распределения памяти не происходит вообще;
- MySQL – код протестирован с использованием Purify (коммерческий детектор утечки памяти), а также Valgrind, одного из GPL‑инструментов.
1.5.2 Interbase
Interbase– высокопроизводительный, экономичный, многоплатформенный сервер баз данных. InterBase представляет собой экономичную, высокопроизводительную СУБД с обработкой транзакций, которую используют миллионы пользователей во всем мире. Сочетая легкость установки, автоматическое восстановление после аварийных отказов и минимальные требования к администрированию, InterBase является наиболее подходящим решением для встраивания в тиражируемые приложения. Обладая поддержкой многопроцессорного режима и сложной архитектурой, InterBase идеально подходит для многофункциональных бизнес приложений, обслуживающих большое количество пользователей. Графический пользовательский интерфейс IBConsole включает монитор производительности, одновременно отслеживающий состояние нескольких серверов и баз данных InterBase.
В основе InterBase находится многоуровневая архитектура управления несколькими версиями, предлагающая весомые преимущества в надежности, производительности, эффективности труда разработчиков и постоянном сопровождении. InterBase освобождает разработчиков от решения проблем совместимости и задач памятью, и наряду с этим обеспечивает немедленное восстановление после аварийных отказов.
InterBase представляет собой идеальное решение для установки в условиях отсутствия администратора баз данных или IT‑поддержки. Автоматическое восстановление после аварийных сбоев и автоматизированные процессы управления учетными записями пользователей, оперативное резервное копирование и автоматизация других задач сопровождения позволяют существенно уменьшить потребность в администрировании. Функции автоматической настройки включают оптимизацию запросов на основе затрат и автоматическую «сборку мусора». Динамическая перестройка структур индекса улучшает производительность и уменьшает потребность в администрировании.
СУБД InterBase не привязывает разработчиков к определенному языку программирования или к какой-либо платформе. InterBase обеспечивает межплатформенную совместимость систем Windows, Linux, Solaris и Java, при этом не требуется перекодирование и поддержка нескольких серверных частей СУБД.
Высокая экономичность и универсальность мощной встраиваемой СУБД Borland InterBase – это широко распространенная СУБД для потребительских приложений, используемых тысячами конечных пользователей.
1.5.3 SQL Server
SQL Server – семейство продуктов, разработанных для хранения данных в больших системах, осуществляющих обработку информации, и обслуживания коммерческих Web‑узлов. SQL Server прост и удобен в использовании, он широко применяется как в сложных системах, с которыми работают сотни пользователей, так и в малом бизнесе. Он популярен также у отдельных пользователей, которым нужен надежный и удобный сервер БД. Клиентские приложения могут работать с БД SQL Server разными способами. Например, клиентское приложение может обращаться к реляционному ядру БД с использованием языка структурированных
запросов. Клиент-серверная система управления базами данных предоставляет богатый спектр новых возможностей, которые облегчают процесс создания, внедрения и управления распределенными клиент-серверными прикладными программами. Основные возможности: встроенная поддержка приложений Internet, усовершенствованные механизмы распределенных транзакций, тиражирование в разнородных средах, расширенные распределенные средства управления и новая архитектура динамической блокировки.
MSSQL Server обеспечивает производительность, безопасность и взаимодействие с другими системами, которые так необходимы для организации работы предприятия. В то же время эта система весьма экономична и проста в управлении, что делает ее идеальным решением для компаний любого размера.
Microsoft SQL Server облегчает создание и управление прикладными программами для внутренних корпоративных сетей (так называемые «интрасети») и Internet. Новая утилита Microsoft SQL Server Web Assistant использует интерфейс, типичный для программ-мастеров, и шаг за шагом помогает администратору базы данных или Web‑мастеру помещать данные из Microsoft SQL Server в сети WWW. Таким образом можно легко создавать интерактивные Web‑узлы, основу которых составляют базы данных. При помощи утилиты Web Assistant, Microsoft SQL Server автоматически создает страницы на основе гипертекстового языка описания документов или заполняет HTML – шаблоны данными из Microsoft SQL Server, причем это может осуществляться либо каждый раз при изменении данных, либо в установленные моменты времени.
1.5.4 Oracle
Oracle– система управления базами данных нового поколения. Значительное продвижение технологии вперед, с одной стороны, можно объяснить появлением объектных расширений реляционной модели данных,
то есть совершенно нового направления для Oracle. С другой стороны, в первую очередь Oracle – это устойчивая, масштабируемая система управления реляционными базами данных, способная эффективно хранить и обрабатывать огромное количество данных в условиях многопользовательского доступа. Ядро сервера Oracle было серьезно переработано на основе опыта разработки и эксплуатации приложений для предыдущих версий, при этом был получен значительный выигрыш в производительности и надежности. С помощью технологий Oracle возможно построить информационную систему, решающую сколь угодно сложные задачи по обработке данных. Для этого в распоряжении проектировщиков и разработчиков имеются все необходимые инструментальные средства. Oracle оказалась очень удачной системой управления базами данных. На ее основе были построены системы, автоматизирующие самые различные области человеческой деятельности. В базах данных под управлением серверов Oracle было накоплено огромное количество информации. В Oracle появились новые возможности для управления большими и сверхбольшими базами данных. Кратко перечислим их.
Секционирование таблиц и индексов – таблицы и индексы могут быть разбиты на секции, с каждой из которых можно работать как с одним объектом, например, хранить различные секции на различных устройствах и управлять ими автономно.
Для оптимального доступа к данным была улучшена работа оптимизатора запросов: введен новый тип запросов – типа «звезда», появились новые подсказки оптимизатору. Теперь поддерживаются новые виды индексов – масочные двоичные индексы и индексы с реверсированным ключом.
Другим важным нововведением для Oracle стала поддержка объектных расширений. Тенденция к объектной ориентированности в настоящее время наблюдается у всех крупных производителей систем управления базами
данных. Не осталась в стороне и корпорация Oracle. Oracle поддерживает абстрактные типы данных, то есть разработчик может конструировать новые типы данных из базовых.
Начиная с версии 8.1.5.0, ядро сервера Oracle включает в себя Java‑машину. Таким образом, стало возможным разрабатывать серверную компоненту системы как на основном языке создания хранимых программ PL/SQL, так и на Java. Программы, написанные на этих языках, могут взаимодействовать между собой. Использование языка Java предоставляет возможность подключения сотен предопределенных классов. Динамический SQL в Oracle выполняется так же быстро, как и обычный статический. Появилась возможность ведения политики безопасности: принудительное блокирование учетной записи пользователя, установка срока действия пароля, блокирование учетной записи пользователя после определенного числа неудачных попыток входа в систему, программная реализация собственных алгоритмов проверки сложности пароля и т.д.
Каждая из рассмотренных выше СУБД по своим функциям подходит для разработки Автоматизированной системы регистрации заказов на испытания. Была выбрана СУБД Oracle, которая больше всего подходит для крупных предприятий по своим техническим характеристикам, к тому же данная СУБД уже давно широко применяется в ОАО «ВМЗ».
1.6 Дополнительные программные средства
Одним из важных требований построения системы является ее полная интеграция с интегрированной информационной системой оперативного управления производством, внедряемой в настоящее время в трубных цехах ВМЗ. Эта система реализуется с использованием сторонних программных продуктов MES уровня AspenOne.
Для управления информацией об объектах в системе продуктов
AspenOne используется продукт AspenBatch.21. Он представляет собой надстройку над базой данных и упрощает взаимодействие с ней со стороны клиентских приложений. Кроме того, Batch.21 выполняет функции контроля данных, их интеграцию и выборку, а также формирование отчетов по расписанию или по требованию.
Batch.21 позволяет просматривать технологические данные в периодическом контексте. Например:
• Если нужно просмотреть диаграммы нескольких ключевых технологических переменных за промежуток времени, в течение которого обрабатывался один заказ, то с помощью Batch.21 можно легко настроить такие диаграммы с помощью:
– Консоли запросов (Query Tool ) для поиска партии.
– Программы Process Explorer, перетащив идентификатор заказа из консоли запросов на диаграмму Process Explorer . Диаграмма автоматически отобразит данные за период обработки данного заказа.
• если нужно сравнить динамику изменения ключевой технологической переменной (например, вязкости металла) для нескольких заказов, наложив друг на друга профили вязкости для каждого случая, то перекрывающаяся периодическая диаграмма – отображение Process Explorer , входящее в комплекс Batch.21 , позволит сделать это;
• если нужно иметь возможность быстро создавать отчеты, описывающие эффективность производственного процесса в периодическом контексте;
• Консоль запросов (Batch Query Tool ) представляет собой удобное в эксплуатации средство генерации отчетов, позволяющее Batch.21 прозрачно выполнять сложные SQL‑запросы к реляционной базе данных или к базе данных реального времени InfoPlus.21 . Результаты запросов могут быть легко перемещены в другое приложение, например, Microsoft Excel .
Эти возможности обусловлены тем, что Batch.21 анализирует и хранит данные в периодическом контексте.
Клиентские приложения Batch.21 связываются с сервером через интерфейс приложений Batch.21 . Клиентские приложения позволяют организовать обмен периодическими данными с базой данных, настраивать базу данных, просматривать эти данные в Process Explorer и создавать отчеты в MS Excel .
Бизнес-логика системы Batch .21 сконцентрирована в сервере ППП (BCU) – программе преобразования партий (Batch Conversion Utility ) и его компонентах, которые базируются на Microsoft Transaction Server . Эти компоненты осуществляют связь с реляционной СУБД и СУБД реального времени. Сервер ППП считывает данные из БД реального времени и преобразует их, согласно своим настройкам, в данные Batch.21 . Через интерфейс приложений Batch.21 сервер ППП соединяется с сервером Batch.21 .
Данные Batch .21 хранятся в реляционной базе данных Microsoft SQL Server или Oracle . Чтобы хранить технологические данные, необходимо использовать СУБД реального времени InfoPlus .21 .
Таблица 1 – Особенности и преимущества Batch.21
Особенность | Преимущество |
Периодические данные можно легко извлечь с помощью консоли запросов. | Это позволяет генерировать сложные отчеты по периодическим процессам без необходимости дополнительного программирования. |
Временные диаграммы можно использовать для просмотра технологических данных, как периодических, так и обычных. | Пользователю нет необходимости изучать новые программные средства; быстрое переключение между графиками. |
Псевдонимы тэгов | Пользователю нет необходимости знать, какой именно аппарат задействован для какой именно партии; он освобожден от необходимости запоминать имена тэгов. |
Можно выбирать вид периодической диаграммы. | Можно сравнивать партии между собой, или сравнивать эффективность по различным параметрам для одной партии. |
Имеются графические консоли для настройки Batch.21. | Упрощается настройка потока периодических данных. |
С помощью ППП можно настраивать сбор периодических данных из базы данных реального времени. | Можно гибко настроить оптимальный баланс между текущей информацией и загрузкой системы; может накапливать данные в промежуточном хранилище. |
Рассмотрев все аспекты для разработки автоматизированной системы управления документооборотом ЦЗЛ, изучив предметную область, в которой будет применяться данная система, и, собрав необходимые сведения о том, что бы хотели видеть пользователи данного программного продукта, в итоге получили конкретный метод решения:
- Клиент-серверная архитектура системы – трехзвенная
- Использование Web-forms (тонкий клиент)
- Язык программирования – Visual C #
- СУБД – Oracle
- Операционная система – Windows
2. Специальная часть
2.1 Структура информационной системы
Web-browserWeb-browserWeb-browser
Рисунок 2 – Структура информационной системы и ее отдельных компонентов
Структура информационной системы построена по трехзвенной архитектуре «клиент – сервер».
Функционирование механизма в трехзвенной архитектуре обеспечивается при помощи трех основных компонентов:
- рабочих станций пользователей;
- серверов приложений;
- сервера базы данных.
Организация работы автоматизированной системы в трехзвенной архитектуре позволяет оптимально распределить нагрузку на аппаратное обеспечение. Удаленные пользователи обращаются к программным модулям, запущенным на сервере приложений. При этом все, кроме визуализации,
переносится на сторону сервера.
СУБД Oracle представляет собой хранилище данных, к которым обращается система Batch.21. Используется Oracle 9i.
Структура объектов (таблиц, триггеров, хранимых процедур) скрыта от разработчика, поскольку используется промежуточная система Batch.
Все компоненты системы развернуты на серверах HPProliantDL 360.
Batch.21 осуществляет выполнение запросов к базе и предоставляет два вида интерфейса:
- DCOM;
- Web‑сервисы.
Web‑сервисы используют передачу данных через XML. DCOM– технология распределенной компонентной модели.
ApplicationServer – Web‑сервер, содержащий разработанные по технологии ASP. Net приложения для решения стоящих перед нами задач.
Клиентские ПК – «тонкие» клиенты, получающие доступ к приложениям ApplicationServer через Web-browser.
2.2 Требования к информационной системе
2.2.1 Общие требования
Система должна создаваться как открытая, масштабируемая система, непосредственно связанная с процессом производства и системой контроля качества продукции.
Данная система для более тесной интеграции с процессом производства продукции должна быть реализована на единой платформе с интегрированной автоматизированной системой оперативного управления производством.
Создаваемая система не должна влиять на работоспособность ИАСОУП, а лишь получать и предоставлять данные для общего использования.
2.2.2 Требования к структуре и функционированию системы
Разрабатываемая система должна строиться по клиент-серверной архитектуре (Рисунок 3).
Серверная часть системы должна быть общей с ИАСОУП и использовать в качестве хранилища данных единую БД в СУБД Oracle.
Клиентские части должны иметь несложный интуитивно понятный интерфейс, облегчающий работу оператора. Кроме того, клиентские подсистемы должны строиться по открытой архитектуре для обеспечения возможности автоматического ввода данных с различных устройств электронной регистрации измерений.
Журналы и протоколы, формируемые системой должны содержать всю необходимую для отчетности информацию и отвечать существующим требованиям к оформлению и содержанию.
2.2.3 Требования к удобству эксплуатации
Все разработанные клиентские части должны иметь удобный для эксплуатации интерфейс, максимально облегчать ввод данных оператору. Основная часть информации должна храниться в электронном виде. Необходимые журналы и протоколы должны быть доступны через стандартный механизм Web‑доступа.
2.2.4 Т ребования к защите информации от несанкционированного доступа
В Системе должна быть предусмотрена защита от несанкционированного доступа, разрушения или изменения информации (программ, баз данных).
Должна быть предусмотрена защита от несанкционированного изменения информации по следующим путям доступа:
- человеко-машинный интерфейс;
- внешние носители (дискеты и т.п.);
- корпоративные компьютерные сети.
Должен быть предусмотрен парольный доступ для работы с Системой на основе доменной аутентификации пользователей.
Для защиты от вирусов должен проводиться периодический контроль на наличие вирусов.
2.2.5 Требования по сохранности информации и надежности функционирования
При возникновении нештатных ситуаций, таких как сбой серверной или клиентской части, информация, введенная в Систему до момента сбоя должна полностью сохраняться. В Системе должна быть предусмотрена функция резервирования информации на случай полной или частичной потери данных на стороне сервера и обеспечены соответствующие условия хранения записей, сводящие к минимуму возможность их порчи или повреждения и предотвращающие ее потерю.
2.2.6 Общие требования к функциям Системы
Все функции Системы должны выполняться с надежностью, оговоренной в п.п. 2.1. Выполнение любой из функций (основных или дополнительных) не должно приводить к останову или недопустимой задержке выполнения остальных функций Системы. Основными формами ввода информации должны быть экранные формы, соответствующие каждому виду испытаний. Основными формами представления журналов и протоколов являются сформатированные html‑документы. Формы ввода и структура выходных документов согласуются с Заказчиком в процессе выполнения проекта.
2.3 Программное обеспечение
Программное обеспечение (ПО) Системы должно представлять собой совокупность программных средств, обеспечивающих реализацию целей и задач Системы, а также функционирование комплекса технических средств Системы.
В состав ПО должно входить:
- общее программное обеспечение;
- специальное программное обеспечение.
Общее программное обеспечение представляет собой операционную систему Windows 2000 и выше с компонентами.NET Framework.
Специальное программное обеспечение должно включать интерфейсные компоненты и клиентские части Системы. Специальное ПО должно разрабатываться согласно принципам архитектуры открытых систем для обеспечения возможности расширения его функций.
2.4 Описание программного состава информационной сети ЦЗЛ
В состав информационной сети ЦЗЛ входят приложения:
- Zakaz_web;
- Proba_web;
- DWTT_web;
- Rast_web;
- Udar_web;
- Xim_web;
Zakaz_web – данное приложение используется в цехах для оформления заказа на проведение испытаний в ЦЗЛ (Рисунок 4). В нем присутствуют все виды испытаний, проводимых в ЦЗЛ, а также основные характеристики испытываемых труб: толщина стенки, диаметр, номер плавки, номер трубы, марка стали и другие.
Рисунок 4 – Заказ на испытание труб
Также в данном приложении можно осуществить поиск уже имеющегося в базе данных заказа по номеру. Для формирования заказа необходмо выбрать цех (2, 3, 4, 5) и тип заказа (1‑сварное соединение, 2‑основной металл, 3‑зарезервировано, 4‑металлография) и нажать кнопку «Задать». Система сгенерирует очередной свободный номер заказа данного типа. После этого необходимо заполнить все поля формы и нажать кнопку «Сохранить». Если все поля заполнены правильно, заказ сохраняется и внизу появится сообщение «Заказ успешно сохранен», в противном случае выведется предупреждение. Из этой формы можно посмотреть бланк заказа, нажав кнопку «Бланк заказа».
Данная форма заполняется на основании заказа, оформленного в цехе. Оператор может последовательно получить все непринятые заказы, нажимая кнопку «Получить» или может сразу ввести номер нужного заказа в поле и нажать кнопку «Загрузить». После этого заказ можно принять, нажав на кнопку «Принять». Из этой формы также можно посмотреть бланк заказа.
DWTT_web – приложение, реализующее проведение испытаний на DWTT. В данном приложении используются такие параметры для проведения испытаний, как толщина образца трубы, высота сечения, высота хрупкой составляющей, толщина хрупкой составляющей, вязкая составляющая в процентах. Форма ввода данных DWTT является самой объемной, поскольку может сразу работать с несколькими заказами (до пяти). Это реализовано в связи со спецификой испытаний. Принятые к исполнению заказы можно загрузить в форму, нажав кнопку «Получить». После проведения испытаний и занесения параметров в поля формы, необходимо нажать кнопку «Рассчитать» для расчета вычисляемых величин и далее кнопку «Сохранить».
Rast_web – приложение, реализующее проведение испытаний на растяжение труб. В данном приложении присутствует два вида растяжений: продольное и поперечное . Главными параметрами для проведения испытаний служат начальная толщина, ширина, площадь, расчетная длина образца , а также конечная расчетная длин (Рисунок 7). Чтобы получить номер нужного заказа на испытания по растяжению труб, нелюходимо нажать кнопку «Получить», либо ввести номер нужного заказа. После ввода всех параметров необходимо нажать кнопку «Рассчитать» для получения результатов по испытанию, затем кнопку «Сохранить».
Udar _ web – приложение, реализующее проведение испытаний на ударный изгиб по трубам.
Для проведения испытаний используются такие параметры, как высота, ширина, площадь, поглощающая энергия и ударная вязкость образца . Все действия, производимые в этой форме для испытаний аналогичны действиям при испытаниях на растяжение.
Xim_web – приложение, реализующее проведение испытаний стали, из которой изготовлена труба, по химическим параметрам. В данном приложении предствлены все необходимые химические реагенты, которые используют для определения прочности испытываемого образца. Испытания можно проводить как по одному виду химического реагента, так и по нескольким. Чаще всего для более точного определения качества стали испытания проводятся по всем видам реагентов.
Во всех формах предусмотрена проверка вводимых пользователем данных на правильность ввода, большая часть полей просто не позволяет ввести недопустимые символы. Данный функционал, как и расчеты в формах, выполнены в виде Java‑скриптов. Это значительно ускоряет работу с приложением.
2.5 Описание алгоритма
Данный программный продукт разработан по определенному алгоритму:
Рисунок 10 – Алгоритм действия автоматизированной системы
Рисунок 11 – Алгоритм вывода данных о заказе
Рисунок 12 – Алгоритм ввода данных о новом заказе
Рисунок 13 – Алгоритм получения номера заказа
Разработанный программный код системы регистрации и сопровождения заказов ЦЗЛ ОАО «ВМЗ» вынесен в приложение.
Из-за большого объема приведены два кода программы – это файлы DWTT_web (Приложение А) и Zakaz_web (Приложение Б). Остальной программный код по структуре аналогичен приложению DWTT_web, за исключением названий различного рода испытаний, принцип работы приложений подобен.
3. Экономика производства
В успешном завершении проекта и его эффективной эксплуатации заинтересованы все его участники, реализующие таким образом свои индивидуальные интересы, а именно:
- заказчик проекта получает проект и доходы от его использования;
- руководитель проекта и его команда получают плату по контракту, дополнительное вознаграждение по результатам работы, а также повышение профессионального рейтинга;
- органы власти получают налоги со всех участников, а также удовлетворение общественных, социальных и прочих нужд и требований на вверенной им территории.
Бизнес-планирование и мониторинг позволяют легче преодолеть помехи и препятствия, связанные с такими внешними и внутренними факторами, характерными для переходного периода в России, как:
- нестабильная экономика;
- дефицит и ограниченность средств и ресурсов;
- инфляция и возрастание стоимости проекта;
- социальные проблемы и требования;
- возрастающие требования к качеству программной продукции.
Если эти изменения не анализируются и не учитываются, то это приводит к таким негативным результатам, как:
- превышение ранее установленной стоимости, продолжительности и сроков завершения проектов;
- увеличение штрафов за нарушение обязательств;
- отставание в реализации и практическом использовании результатов научных исследований и опытно-конструкторских разработок;
- снижение эффективности и увеличение сроков окупаемости проекта.
В создавшихся условиях работа инженера подразумевает не только нахождение прогрессивных решений, но и их технико-экономическое обоснование, доказательство того, что выбранный вариант является наиболее выгодным и экономически эффективным.
3.1 Анализ основных разделов бизнес-план а
Данный раздел посвящён обоснованию эффективности разработки автоматизированной системы управления документооборотом ЦЗЛ.
При анализе целесообразности данную разработку следует рассматривать как некоммерческий продукт в том смысле, что она не предназначена для широкого тиражирования и продажи с целью получения прибыли. Это упрощение сделано для того, чтобы показать прибыльность внедрения нашего программного продукта (ПП) на бюджетных предприятиях, где ценность системы определяется сэкономленными ею средствами. Экономическая целесообразность разработки такой продукции заключается в экономии трудозатрат по сравнению с ручной обработкой и получении более достоверной информации за более короткое время.
3.2 Описание функций автоматизированной системы
Автоматизированная система предназначена для автоматизации управления документооборотом ЦЗЛ на производстве с последующим получением статистической и аналитической информации журналах. Опишем основные функции, которые способна выполнять данная система:
1) Ведение базы данных заказов с подробными данными различных свойствах заказа:
- ввод новой записи о заказе;
- редактирование записи о заказе;
- просмотр сохраненной записи о заказе;
- обслуживание баз данных журнала регистрации;
2) Получение аналитической и статистической информации:
- выдача статистической информации о количестве заказов, в общем, и по конкретным свойствам, за конкретный период времени;
- выдача статистической информации о количестве брака;
3) Получение справочной информации в печатном виде на официальных бланках:
- печать журнала регистраций за определенный период времени;
- печать справок по различным видам проведенных испытаний;
- печать аналитической и статистической отчетности;
Таким образом, функциональные возможности системы весьма значительны и смогут удовлетворить основные потребности потенциальных пользователей при учете заказов и получении необходимой информации.
3.3 Возможный рынок сбыта автоматизированной системы
Главным заказчиком разрабатываемой автоматизированной системы является ЦЗЛ ОАО «ВМЗ». Как уже было сказано ранее, разрабатываемый ПП ориентирован на применение, прежде всего, в учреждениях, где ценность системы будет определяться экономией трудозатрат по сравнению с ручной обработкой информации, а также получением более достоверной и точной информации за короткие промежутки времени.
Потребность в автоматизированной системе может возникнуть также на других промышленных предприятиях такого же профил я.
3.4 Календарный план-график работы над автоматизированной системой
Жизненным циклом программы считается весь цикл от принятия решения о проведении разработок до полного отказа конечного пользователя от применения данного ПП:
- этап работы над ПП составил 4 месяца;
- этап введения ПП – 1 месяц;
- этап зрелости: полный переход к автоматизированной системе (порядка 1 месяца);
По предварительным оценкам, замена системы произойдет не ранее 2012 года. Следовательно, минимальный срок «жизни» разрабатываемой программы составляет не менее 5 лет.
3.5 Оценка конкурентоспособности ИСУП
Успех в конкурентной борьбе в большей степени определяется тем, насколько удачно выбран тип конкурентного поведения организации и насколько умело он реализуется на практике.
Конкурентоспособность изделия – это его способность противостоять на рынке изделиям, выполняющим аналогичные функции. При этом конкуренцию составляют не только изделия той же технолого-конструктивной группы, но и любой товар, выполняющий аналогичные функции. Конкурентоспособность определяется многими факторами. Одни факторы определяют характеристики самого продукта, другие зависят от темпов технического развития товарной группы, к которой относится изделие, третьи – от рыночной конъюнктуры.
Из известных нам автоматизированных систем учета заказов, построенная на основе базы данных Access.
Проведём сравнение разработанной автоматизированной системы и системы базы данных Access по основным показателям ПП:
- функциональный набор: примерно одинаковый;
- интерфейс: у автоматизированной системы более удобный, разработанный специально для ЦЗЛ с учетом требований и пожеланий будущих пользователей;
- инструкция для пользователя: у автоматизированной системы более подробная;
- требуемые ресурсы: примерно одинаковые.
Таким образом, при равных стартовых возможностях применение разработанной автоматизированной системы кажется более предпочтительным. Это превосходство обуславливается, прежде всего, тем, что автоматизированная система разработана с учетом требований ЦЗЛ, устранены лишние детали, интерфейс более гибкий и удобный. Следовательно, можно утверждать, что автоматизированная система будет сохранять высокую конкурентоспособность до тех пор, пока не появятся новые, перспективные технологии.
3.6 К алькуляция темы
Характерной чертой проводимых работ является их теоретическая направленность. Основными источниками затрат при работе над темой как части этапа проектирования жизненного цикла целенаправленной интеллектуальной системы являются капитальные предпроизводственные затраты, которые в определенной степени могут быть учтены и минимизированы.
Калькулирование осуществляется по калькуляционным статьям расходов.
Данные по окладам работающего персонала, а также все процентные составляющие, используемые в этой части, были получены в плановом отделе ОАО «ВМЗ» (Приложение В).
Таблица 2 – Затраты на расходные материалы
№ п/п | Наименование материала | Расход, шт. |
Цена, руб./шт. | Сумма, руб. |
1 | Пакет VisualStudio с библиотеками | 1 | 8000 | 8000 |
2 | Вспомогательная литература | 3 | 70 | 210 |
3 | CD диски | 10 | 10 | 100 |
4 | Канцтовары | + | + | 200 |
Итого | 8510 |
Таблица 3 – Основная заработная плата разработчиков ПП
№ п/п | Наименование этапа | Исполнители | Трудоём-кость, чел. дн.1 | Трудоём-кость, чел. мес.2 | Оклад, руб. | Затраты по з/п, руб. |
1 | Подготовительный | Программист | 20 | 0.909 | 12000 | 10908 |
2 | Техническое задание | Специалист по ИО | 10 | 0.455 | 12000 | 5460 |
3 | Основной | Программист | 60 | 2.727 | 12000 | 32724 |
4 | Тестирование | Программист | 10 | 0.455 | 12000 | 5460 |
5 | Технический отчёт | Программист | 15 | 0.682 | 12000 | 8184 |
6 | Сдача темы |
Специалист по ИО | 5 | 0.227 | 12000 | 2724 |
Итого | 65460 |
Дополнительная заработная плата разработчиков ПП составляет 20% от основной заработной платы:
0.2 ´ 65460 = 13092 руб.
Фонд заработной платы представляет собой сумму основной и дополнительной заработной платы:
65460+13092 = 78552 руб.
Отчисления на социальные нужды составляют 26,2% от фонда оплаты труда:
0.262 ´ 78552 » 20580,62 руб.
Накладные расходы составляют 250% от величины основной заработной платы:
2.5 ´ 65460 » 163650 руб.
Прочие расходы включают расходы на машинное время (порядка 3‑ёх месяцев на разработку, отладку и тестирование ПП: 700 часов стоимостью 2 руб./час):
700 ´ 2 = 1400 руб.
Таблица 4 – Калькуляция темы
№ п/п | Наименование статей расходов | Затраты, руб. |
1 | Расходные материалы | 8510.00 |
2 | Основная заработная плата разработчиков | 65460.00 |
3 | Дополнительная заработная плата разработчиков | 13092.00 |
4 | Отчисления на социальное страхование | 20580,62 |
5 | Накладные расходы | 163650.00 |
6 | Прочие расходы | 1400.00 |
Итого затрат | Зк = 272692,62 |
3.7 Оценка экономической эффективности применения ПП
Показатель эффекта определяет все позитивные результаты, достигаемые при использовании ПП. Экономический эффект от использования ПП за расчётный период Т определяется по формуле, руб.:
ЭТ = РТ – Зк ,
где РТ – стоимостная оценка результатов применения ПП в течение
периода Т, руб.;
Зк – стоимостная оценка затрат на создание и сопровождение ПП, руб.
Стоимостная оценка результатов применения ПП за расчётный период Т определяется по формуле:
Т
PT = åPt ´at ,
где Т – расчётный период;
Рt – стоимостная оценка результатов года t расчётного периода, руб.;
at – дисконтирующая функция, которая вводится с целью приведения всех затрат и результатов к одному моменту времени.
Дисконтирующая функция имеет вид:
at = 1 / (1 + p)t ,
где p – коэффициент дисконтирования (p = Eн = 0.2, Ен – нормативный коэффициент эффективности капитальных вложений).
Таким образом,
Т
PT = åPt / 1.2t
t = 0
В данном случае ПП заменяет ручной труд, следовательно, набор полезных результатов в принципе не меняется. В качестве оценки результатов применения ПП в год берётся разница (экономия) издержек, возникающая в результате использования ПП, т.е. Pt = Эу .
Экономия от замены ручной обработки информации на автоматизированную образуется в результате снижения затрат на обработку информации и определяется по формуле, руб.:
Эу = Зр – За ,
где Зр – затраты на ручную обработку информации, руб.;
За – затраты на автоматизированную обработку информации, руб.
Затраты на ручную обработку информации определяются по формуле:
Зр = Ои ´ Ц ´ Гд / Нв ,
где Ои – объём информации, обрабатываемой вручную, Мбайт;
Ц – стоимость одного часа работы, руб./час;
Гд – коэффициент, учитывающий дополнительные затраты времени на логические операции при ручной обработке информации;
Нв – норма выработки, Мбайт/час.
В данном случае: Ои = 25 Мбайт (общий размер обрабатываемых данных, вводимых для регистрации за год с последующим подсчетом статистики),
Ц= 12000 / 22 / 8 » 68,18 руб./час,
где Гд = 2.5 (установлен экспериментально);
Нв = 0.004 Мбайт/час. Следовательно, затраты на ручную обработку информации будут равны:
Зр = 25 ´68,18 ´ 2.5 / 0.004 = 1065312,5 руб.
Затраты на автоматизированную обработку информации рассчитываются по следующей формуле:
За = ta ´ Цм + tо ´ (Цм + Цо ),
где ta – время автоматической обработки, ч.;
Цм – стоимость одного часа машинного времени, руб./час;
tо – время работы оператора, ч.;
Цо – стоимость одного часа работы оператора, руб./час.
Для данного ПП: ta = 18 ч., Цм = 2 руб., tо = 83.3 ч.,
Цо = 12000 / 22 / 8 »68,18 руб.
(Для ввода данных оператором в систему понадобится: (1000 случаев)*(5 мин. регистрации 1 случая) = 5000 мин. = 83.3 часа; Для автоматической обработки введенных данных, если получать по 10 справок в неделю (время получения одной справки 2 мин.) понадобится 1080 мин. = 18 часов в год)
Следовательно, затраты на автоматизированную обработку информации будут равны:
За = 18 ´ 2 + 83,3 ´ (2 + 68,18) = 2096.01 руб.
Таким образом, годовая экономия от внедрения ПП равна:
Эу = 1065312,5 – 5882 = 1059430,50 руб.
Экономический эффект от использования ПП за год определяется по формуле, руб.:
Эг = Эу – Ен ´ Зк.,
Эг = 1065312,5 – 0.2 ´ 272692,62 »792619,88 руб .
Эффективность разработки может быть оценена по формуле:
Эр = Эг ´ 0.2 / Зк,
Эр = 792619,88 ´ 0.2 / 272692,62 »0,58
Поскольку Эр > 0.20, наша разработка является экономически целесообразной.
Предполагается, что данный ПП без изменений и доработок будет использоваться в течение пяти лет. Тогда стоимостная оценка результатов применения ПП (экономия) за расчётный период T = 5 лет составит:
5
P5 =å1065312,5/ 1.2t =
t=0
=1065312,5+887760,42+739800,35+616500,29+513750,24+428125,2=
=4251249.00 руб.
Экономический эффект от использования ПП за расчётный период T = 5 лет составит:
ЭТ = 4251249.00 – 272692,62 = 3978556,38 руб.
Очевидно, что разработка нашей автоматизированной системы является абсолютно эффективной.
3.8 Расчёт цены ПП
Как уже отмечалось ранее, данный ПП не предназначен для выхода на открытый рынок программной продукции. Тем не менее, определение договорной цены ПП необходимо для случая появления возможности продажи автоматизированной системы.
Цена программной продукции формируется на базе экономически обоснованной (нормативной) себестоимости её производства и прибыли, руб.:
Цпп = С + Пн + Нэ ,
где С – себестоимость ПП, руб. (используем Зк );
Пн – нормативная прибыль, руб.;
Нэ – надбавка к цене, руб., если годовой экономический эффект от применения ПП составляет свыше 10 тыс. руб. (берётся в% от нормативной прибыли).
Нормативная прибыль определяется как:
Пн = Уп ´ Фзп ,
где Уп – уровень прибыли в% к фонду заработной платы разработчиков
Фзп – фонд заработной платы разработчиков ПП, руб.
Уровень прибыли рассчитывается по формуле:
Уп = Руп + Рп,
где Руп – расчётный уровень прибыли (норматив рентабельности), включаемый в цену на разработку (ориентировочно 90 ¸ 100% к Фзп );
Рп – предложения разработчиков по повышению Руп на основе анализа эффективности создаваемого ПП, его научно-технического уровня, важности и т.д.; в качестве показателей повышения Руп могут быть приняты предложения разработчиков или заказчика по повышению уровня основных требований: конкретных характеристик, ТЗ, сокращение сроков выполнения работы и др.
Примем Руп = 90%, Рп = 5% к Фзп . Тогда уровень прибыли будет равен:
Уп = 0.9 + 0.05 = 0.95
Определим нормативную прибыль:
Пн = 0.95 ´ 78552 » 74624,4 руб.
Поскольку годовой экономический эффект от применения ПП больше 10 тыс. руб., надбавку к цене за эффективность возьмём 20% от нормативной прибыли:
Нэ = 0.2 ´ 78552» 15710,4 руб.
Таким образом, договорная цена нашей ИСУП составит:
Цпп = 272692,62+ 74624,4 + 15710,4 = 363027,42 руб .
В том случае, если будет осуществляться тиражирование ПП (n копий), договорная цена каждой тиражной копии составит:
Цтк = Цпп / n = 363027,42 / n руб .
Бизнес-план – специальный инструмент менеджмента, используемый в современной рыночной экономике независимо от масштабов, сферы деятельности и формы предпринимательства. Успех и в обычной рыночной торговле, и в выходе фирмы с новым продуктом на рынок невозможен без полного и ясного представления о перспективах предпринимаемого дела, без разработки надёжных предварительных ориентиров и реального плана действий. Бизнес-план позволяет очертить круг проблем, с которыми столкнётся предприниматель при реализации своих целей в изменчивой, неопределённой, конкурентной хозяйственной среде, сформировать и обеспечить пути решения этих проблем.
Задачей создаваемой автоматизированной системы является автоматизация управления документооборотом ЦЗЛ. Поскольку приходится с каждым днем вести все более жесткий контроль качества, нагрузка на пользователей постоянно возрастает. Это вызывает необходимость расширения штата сотрудников с целью своевременного выполнения процесса регистрации и своевременной выдачи статистической отчетности. Внедрение автоматизированной системы может дать значительный эффект за счёт, прежде всего, сокращения времени, а также за счёт уменьшения необходимого числа сотрудников, занимающихся этой проблемой. Расширение сферы применения ПП на всю систему учета позволит ещё больше повысить экономический эффект от применения ПП.
Затраты на разработку , полученные методом калькуляции, составляют 272692,62 руб .
Договорная цена на ИСУП, сформированная на основе нормативной себестоимости производства ПП и прибыли, составляет 363027,42 руб .
Экономический эффект от использования данного ПП за расчётный период (5 лет) составит 3978556,38 руб. , при этом эффективность разработки – примерно 0,58 , т.е. разработчик покроет свои расходы на создание автоматизированной системы ориентировочно за год и затем начнёт получать прибыль.
Таким образом, заказчик должен утвердить затраты на создание нашей автоматизированной системы, поскольку в результате анализа установлено, что внедрение разработки оправдано и экономически целесообразно.
4. Мероприятия по технике безопасности и противопожарной технике
4.1 Техника безопасности при работе за компьютером
На местах работы пользователей и в лабораториях ЦЗЛ установлена дорогостоящая сложная и требующая осторожного и аккуратного обращения аппаратура – компьютеры (ПЭВМ), а так же другие технические средства. Поэтому необходимо: бережно обращаться с этой техникой; не входить в лабораторию в верхней одежде; войдя в лабораторию, спокойно занимать своё место.
На рабочем месте размещены составные части ПЭВМ – системный блок, клавиатура и монитор (дисплей). Во время работы лучевая трубка монитора (дисплея) работает под высоким напряжением. Неправильное обращение с клавиатурой, кабелями и мониторами может привести к тяжелым поражениям электрическим током, вызвать загорание или иной выход из строя аппаратуры. Поэтому строго запрещается:
- Трогать разъемы соединительных кабелей;
- Прикасаться к экрану и к тыльной стороне монитора, клавиатуры;
- Прикасаться к питающим проводам и устройствам заземления;
- Класть дискеты, книги тетради на монитор и клавиатуру;
- Работать во влажной одежде и влажными руками;
- Использовать в работе дискеты, не зарегистрированные в лаборатории вычислительной техники (ЛВТ).
При появлении запаха гари немедленно прекратите работу, выключите аппаратуру и сообщите об этом старшему по должности или соответствующему специалисту.
Перед началом работы:
- Убедитесь в отсутствии видимых повреждений аппаратуры и соединительных кабелей на вашем рабочем месте;
- Сядьте так, чтобы линия взора приходилась в центр экрана, что дает возможность, не наклоняясь, пользоваться клавиатурой и воспринимать передаваемую на экран монитора информацию;
- Хорошо разберитесь в особенностях применяемых в работе устройств;
- Запишите в журнал регистрации время начала и окончания работы на ПЭВМ;
Во время работы ПЭВМ лучевая трубка монитора является источником электромагнитного излучения, неблагоприятно воздействующего на зрение при работе вблизи экрана. Поэтому следует соблюдать расстояние между вашими глазами и экраном монитора равное 60–70 см., допустимое расстояние не менее 30 см.
Следите за осанкой, не допускайте искривления позвоночника.
- Во время работы:
· Строго выполняйте все указанные выше правила
· Следите за исправностью аппаратуры и немедленно прекращайте работу при появлении необычного звука или самопроизвольного выключения аппаратуры.
- Плавно нажимайте на клавиши, не допускайте резких ударов;
- Работайте на клавиатуре чистыми руками;
- Никогда не пытайтесь самостоятельно устранить неисправность в работе аппаратуры.
По окончании работы:
- Подготовьте компьютер к выключению (завершите все работающие программы.), чтобы не потерять не сохраненные данные;
- Отключите тумблер «СЕТЬ»;
- Запишите в журнале регистрации время окончания работы.
4.2 Порядок действий при возникновении нештатной ситуации
- При работе с Системой может возникнуть ряд нештатных ситуаций, непосредственно несвязанных с ее работоспособностью. Прежде всего, это потеря сетевого соединения, сбои операционной системы и выход из строя аппаратной части и т.д. Решение данной проблемы не входит в область ответственности разработчика системы. При возникновении такой проблемы необходимо обратиться в службу поддержки пользователей ОАО «ВМЗ».
- При возникновении сбоя на клиентской части системы, оператор прежде всего должен убедиться, что он не вызван сторонними причинами, частично указанными выше.
- Если сбой произошел в работе Системы, не по сторонним причинам, то необходимо связаться с системным администратором ИАСОУП.
- В любом из перечисленных случаев, когда работоспособность Системы временно нарушена, необходимо продолжать регистрацию измерений в бумажных журналах вручную. При восстановлении работоспособности занести всю накопленную в бумажных журналах информацию в Систему. Это подразумевает наличие на рабочих местах операторов бланков журналов и инструкций, а также справочников ГОСТов и ТУ в бумажной форме.
Заключение
В данном дипломном проекте проведено проектирование и разработка автоматизированной системы управления документооборотом ЦЗЛ, в частности подсистема регистрации и сопровождения заказов на испытания.
Разработанная система позволяет решать следующие задачи:
· Ввод заказов на испытания в единую ИСОУП;
· Приемка заказов работниками ЦЗЛ;
· Регистрация результатов испытаний на DWTT;
· Регистрация результатов испытаний на химический анализ;
· Регистрация результатов испытаний на растяжение;
· Регистрация результатов испытаний на ударный изгиб.
Также Система предоставляет пользователю удобный и наглядный интерфейс.
Система построена по новейшей архитектуре информационной системы – трехзвенной, что позволяет значительно облегчить работу системного администратора.
В результате внедрения Системы значительно сократился объем бумажной документации.
Разработанный продукт входит в состав MES‑системы (ManufacturingEnvironmentSystem – система управления производственной средой предприятия) ОАО «ВМЗ». Также данный программный продукт соответствует международным стандартам качества и заметно повышает рейтинг ОАО «ВМЗ».
Список используемой литературы
1. MySQL. Справочник по языку.: Пер. с англ. – М.: Издательский дом «Вильяме», 2005.
2. Стефанков Д.В. Справочник программиста и пользователя. М.: Кварта, 1993.
3. Намиот Д.Е. Основные особенности языка программирования C++. – М.: «Память», 1991.
4. Разработка Web – приложений на Microsoft Visual Basic.NET и Microsoft Visual C#.NET. Учебный курс MCAD/MCSD/Пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2003.
5. Ватсон К. С#.: Пер. с англ. – М.: Издательство «Лори», 2005.
6. Журнал «КомпьюТерра» №37–38 1998
7. Выполнение организационно-экономической части дипломных проектов: учебное пособие. – М.: МИРЭА, 1994. – 74 с.
8. Кураков Л.П., Попов В.М. и др. Сборник бизнес-планов: Современная практика и документация. Отечественный и зарубежный
9. ГОСТ 12.2.032–84 – Рабочее место при выполнении работ сидя. Общие эргономические требования.