Весьма привлекательной особенностью Designer/2000 является возможность генерации форм Oracle Developer/2000, проектов Visual Basic, классов C++, отчетов Oracle Reports, приложений для Oracle Web Application Server.

ERwin (Computer Associates)

ERwin разработан компанией Logic Works, которая в 1988 году была приобретена фирмой Platinum Technologies, а ее, в свою очередь, приобрела компания Computer Associates. Этот продукт в течение последних десяти лет занимает лидирующие позиции среди средств проектирования данных.

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

ERwin не ориентирован на какую-то конкретную СУБД и поддерживает более 20 типов СУБД, включая СУБД всех ведущих производителей серверов баз данных (Oracle, Sybase, Microsoft, IBM, Informix), а также все популярные форматы настольных СУБД (включая dBase, Clipper, FoxPro, Access, Paradox), кроме, возможно, самых последних версий. Дело в том, что новые версии ERwin не выпускались уже довольно давно- как минимум год не было обновлений имеющейся версии и более двух лет не выпускались новые версии этого продукта. Поэтому при использовании ERwin с последними версиями некоторых СУБД могут возникнуть проблемы (например, некоторые типы данных SQL Server 7.0 это CASE-средство поддерживает не совсем корректно). Тем не менее, ERwin остается одним из самых популярных в мире продуктов этого класса благодаря поддержке большого количества платформ, простоте интерфейса и, что немаловажно, поддержке специфических особенностей организации физической памяти наиболее популярных серверных СУБД. Например, для СУБД Oracle, Microsoft SQL Server, Sybase этот продукт позволяет изменять местоположение и параметры хранения индексов, почти для всех популярных серверных СУБД создавать кластеризованные индексы и для многих из них - указывать характеристики табличных пространств и сегментов отката.

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

ERwin поддерживает обмен моделями с репозитарием Designer/2000 и Microsoft Repository, а также генерацию клиентских приложений для Visual Basic и Power Builder.

Помимо однопользовательской работы ERwin может выступать в роли клиентского приложения для другого CASE-средства - Model Mart, которое позволяет организовать коллективную разработку моделей данных, предоставляя для этой цели разделяемый репозитарий, хранящийся в одной из серверных СУБД.

Недавно компанией Computer Associates был выпущен новый продукт- ERwin Examiner, представляющий собой инструмент проверки баз данных и DDL-скриптов с целью выявления ошибок проектирования данных, сказывающихся на целостности данных и производительности сервера, таких, например, как ошибки нормализации, противоречивые ключи и т.д. В результате проверки ERwin Examiner предлагает способы устранения найденных ошибок, генерируя соответствующие DDL-скрипты.

Power Designer (Sybase)

Power Designer (бывший S-Designor, принадлежавший компании Power Soft) представляет собой инструмент, в состав которого входят средство создания концептуальных (то есть логических) моделей, средство создания физических моделей и средство объектно-ориентированного моделирования, используемое при генерации клиентских приложений. Средство создания физических моделей представляет собой отдельный продукт - Power Designer Physical Architect. В состав продукта Power Designer Data Architect входят средства создания концептуальных и физических моделей, в состав Power Designer Developer - средства объектно-ориентированного моделирования и создания физических моделей, а в состав Power Designer Object Architect - все три средства.

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

Помимо серверных СУБД производства Sybase (Adaptive Serve rEnterprise 12.0, Sybase SQL Anywhere) Power Designer Data Architect способен работать с любыми ODBC-источниками. Как и ERwin, он поддерживает генерацию триггеров серверных СУБД, осуществляющих стандартную обработку событий, связанных с нарушениями ссылочной целостности.

Power Designer Developer и Power Designer Object Architect могут генерировать код клиентских приложений для Power Builder, а также классы Java и компоненты Java Beans. Возможно и обратное проектирование диаграмм классов из исходных текстов Java, байт-кодов и архивов Java. Поддерживается также генерация кода Web-приложений и объектов для Sybase Enterprise Application Server на основе физической модели.

Power Designer Data Architect может импортировать логические и физические модели ERwin.

Power Designer Data Architect может хранить свои модели данных в коллективно разделяемом репозитарии, управляемом с помощью средства Power Designer Meta Works и доступном как дополнительный модуль в составе любого из перечисленных выше продуктов.

Отметим, что Power Designer Data Architect весьма популярен на российском рынке, причем не только среди пользователей СУБД и средств разработки Sybase.

ER/Studio (Embarcadero Technologies)

ER/Studio менее известен в нашей стране, чем Erwin и Power Designer Data Architect. Однако возможности этого продукта также заслуживают внимания.

По своему назначению этот продукт сходен с ERwin- он представляет собой специализированное средство проектирования данных и не содержит в своем составе инструментов для объектно-ориентированного моделирования или моделирования бизнес-процессов. Список поддерживаемых СУБД у этого продукта достаточно широк и включает все наиболее популярные серверные и настольные СУБД. В отличие от ERwin последняя версия этого продукта корректно поддерживает новые типы данных SQL Server 7.

ER/Studio поддерживает написание макросов на SAX Basic (клон Visual Basic for Applications). Этот язык позволяет создавать макросы для выполнения однотипных операций, например добавления стандартных полей к вновь создаваемым сущностям. С помощью этого же языка можно генерировать стандартные триггеры и хранимые процедуры для вставки, удаления, изменения записей. Код на этом языке можно даже отлаживать и обращаться к свойствам сущностей для конструирования серверного кода. Однако, в отличие от ERwin, ER/Studio не позволяет добавить к каждой таблице свои шаблоны триггеров или просмотреть код конкретного триггера в процессе разработки модели - чтобы получить код одного триггера, нужно сгенерировать скрипт для всей модели.

Модели ER/Studio можно сохранить не только в виде DDL-скрипта, но и в формате XML. Можно также создать репозитарий для их хранения в любой серверной СУБД. ER/Studio может импортировать модели ERwin, но при импорте теряются связи шаблонов серверного кода с конкретными таблицами, и не все макросы ERwin корректно преобразуются в макросы SAX Basic.

ER/Studio позволяет сгенерировать Java-классы для клиентских приложений.

Отметим, что ER/Studio является COM-сервером, что позволяет использовать его в других приложениях, предоставляя им возможность просмотра и редактирования моделей данных, а также создавать другие решения на его основе.

System Architect (Popkin Software)

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

Этот продукт поддерживает СУБД практически всех ведущих производителей, включая Oracle (Oracle 8), Sybase, DB2, SQL Server, IBM (AS400, DB2), Informix, Sybase, Access, dBASE, Paradox и др.

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

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

Модели System Architect 2001, как и в случае других CASE-средств, можно сохранять в репозитарии. Однако в отличие от традиционных репозитариев, обладающих более или менее стандартной структурой хранимых данных, репозитарийSystemArchitect является настраиваемым - к сохраняемым объектам можно добавлять дополнительные свойства, определенные пользователем.

System Architect обладает встроенным Visual Basicfor Application, что позволяет создавать разнообразные решения на базе этого продукта, включая автоматическую генерацию моделей и проектной документации.

System Architect 2001 позволяет генерировать код клиентских приложений для Visua Basic, Delphi и Power Builder (на сегодняшний день это практически единственное CASE-средство, поддерживающее генерацию кода Delphi), классы C++, а также код и текстовые экранные формы COBOL.

Visible Analyst (Visible Systems Corporation)

Visible Analyst - весьма популярный продукт компании Visible Systems Corporation. Широко известны также ранее производимые этой компанией CASE-средства EasyER и Easy CASE - предшественники Visible Analyst.

Этот продукт выпускается в трех редакциях: VisibleAnalyst DB Engineer, который включает средства проектирования данных, Visible Analyst Standard, который кроме проектирования данных позволяет осуществлять структурное моделирование, и Visible Analyst Corporate, который помимо указанных выше возможностей позволяет осуществлять также объектно-ориентированное моделирование.

Visible Analyst поддерживает довольно широкий спектр СУБД с точки зрения генерации серверного кода, включая Oracle 7, Sybase SQL Server (System 10 и 4.x); Informix, DB2, Ingres. Последние версии многих серверных СУБД (Oracle 8, Microsoft SQL Server 6.5/7/2000, последние версии серверов Sybase) в этом списке пока отсутствуют.

Для Informix и DB2 указанный продукт позволяет генерировать DDL-скрипты, учитывающие специфические особенности организации физической памяти наиболее популярных серверных СУБД, такие как управление табличным пространством, размером экстентов, режимами блокировки данных, степенью заполнения данными (fillfactor), а также создавать кластеризованные индексы и генерировать триггеры для выполнения стандартных операций. Из этих же СУБД можно производить непосредственно обратное проектирование. Помимо этих двух СУБД обратное проектирование можно производить также из DDL-скриптов, сгенерированных для других СУБД, а также на основе кода COBOL.

Модели Visible Analyst можно сохранять в многопользовательском репозитарии, созданном в одной из серверных СУБД.

Кроме того, Visible Analyst позволяет на оcнове созданных моделей генерировать код для Visual Basic, С++ и COBOL.

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

Visio Enterprise (Microsoft)

Продукт под названием Visio, приобретенный в январе 2000 года корпорацией Microsoft вместе с его разработчиком - компанией Visio Corporation, позиционировался на рынке как одно из самых популярных средств создания схем и диаграмм. То, что один из членов семейства Microsoft Visio 2000 - Visio 2000 Enterprise - содержит в своем составе полноценное CASE-средство, было в определенной степени сюрпризом для пользователей CASE-инструментов. Однако, если вдуматься, появление своих средств проектирования данных, моделирования бизнес-процессов и объектно-ориентированного моделирования у Microsoft - шаг вполне закономерный, поскольку такие средства появляются рано или поздно у большинства производителей популярных серверных СУБД и средств разработки, каковым Microsoft является уже довольно давно.

Как и подавляющее большинство средств проектирования данных, Visio Enterprise позволяет производить прямое и обратное проектирование данных, преобразовывать логическую модель в физическую. Этим средством поддерживаются все ODBC- и OLE DB-источники данных. С его помощью можно создавать триггеры для стандартной обработки нарушений ссылочной целостности в случае, если DDL-скрипт создается для Microsoft SQL Server, и серверные ограничения, если скрипт создается для другой СУБД. Отметим, что Visio при генерации скриптов позволяет указывать параметры организации физической памяти Oracle, Informix, Microsoft SQL Server, DB2 и некоторых других СУБД.

Отметим, что помимо средств проектирования данных Visio включает средства объектно-ориентированного моделирования и генерации кода приложений Visual Basic 6, а также классов C++ и Java. Модели Visio можно сохранять в Microsoft Repository.

Visio, в отличие от специализированных средств проектирования данных, не обладает скриптовым языком, позволяющим создавать серверный код, не связанный с конкретной СУБД. При использовании этого продукта такой код нужно создавать на этапе физического проектирования в уже созданном скрипте. Однако справедливости ради заметим, что и стоимость Visio Enterprise по сравнению с ERwin или Power Designer Data Architect невысока, тем более что Visio в целом представляет собой продукт более широкого назначения, нежели другие рассмотренные выше средства проектирования данных. К тому же этот продукт является сервером автоматизации, обладает весьма обширной объектной моделью и встроенным средством разработки - Visual Basic for Applications, что позволяет, в частности, создавать на его базе разнообразные решения, в том числе и автоматизировать разработку моделей данных.

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

3.4 Проектирование информационной структуры

Как уже говорилось ранее, в информационной системе вся информация хранится в единой БД. Для моделирования логической структуры базы данных была применена методология IDEF1x. Согласно данной методологии, [14], процесс построения информационной модели состоит из следующих шагов:

· определение сущностей; определение зависимостей между сущностями;

· задание первичных и альтернативных ключей;

· определение атрибутов сущностей;

· приведение модели к требуемому уровню нормальной формы;

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

· задание триггеров, процедур и ограничений;

· генерация базы данных.

Диаграмма сущность-связь, описывающая БД в терминах IDEF1.x, строится из трех основных блоков - сущностей, атрибутов и связей. Если рассматривать диаграмму как графическое представление правил предметной области, то сущности и атрибуты являются существительными, а связи - глаголами. Логическая структура базы показана на рис. 3.4.

Рис. 3.4 Логическая модель данных

Структура базы данных состоит из следующих сущностей:

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

o Идентификатор - уникальный идентификатор, который присваивается человеку при попытке пересечения границы;

o ФИО - фамилия, имя и отчество лица пересекающего границу;

o Пол - пол ЛПГ;

o Возраст;

o Гражданство;

o Дополнительная информация о ЛПГ.

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

o Идентификационный номер документа;

o Идентификатор ЛПГ - атрибут для связи с сущностью «Лицо пересекающее границу»;

o Тип;

o Дата выдачи;

o Срок действия;

o Фото;

o Дополнительная информация.

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

o Личный номер;

o ФИО;

o Звание;

o Логин в системе;

o Пароль в системе;

o Возраст;

o Идентификатор ЛПГ - атрибут для связи с сущностью «Лицо пересекающее границу».

· Транспортное средство. Сущность, которая характеризует транспортное средство, на котором ЛПГ пытается осуществить пересечение границы. Содержит всю необходимую информацию о транспортном средстве в следующих атрибутах:

o Номерной знак;

o Государство;

o Марка;

o Модель;

o Цвет;

o Особые отметки.

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

Рис. 3.5 Физическая модель данных

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

автоматизированный информационный пограничный документ



4. Реализация выбранного варианта решения

Реализация включает в себя финальный этап разработки информационной системы. На нем выбирается язык программирования и СУБД.

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

4.1 Выбор языка программирования

Основное достоинство языка программирования Delphi состоит в объектно-ориентированном представлении. Так же существенно изменился принцип компиляции программ.

Delphi - это комбинация нескольких важнейших технологий:

- высокопроизводительный компилятор в машинный код;

- объектно-ориентированная модель компонент;

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

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

Основной упор модели в Delphi делается на то, чтобы максимально производительно использовать код. Это позволяет очень быстро разрабатывать приложения, так как уже существуют заранее подготовленные объекты. А так же вы можете создавать свои собственные объекты, без каких-либо ограничений. Язык Delphi -- строго типизированный объектно-ориентированный язык, в основе которого лежит хорошо знакомый программистам Object Pascal.

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

Среди пользователей самой популярной операционной системой является Windows. И для разработчика несомненно очень важно, чтобы писать программы именно для этой оболочки. До недавнего времени практически все программы для этого пакета операционных систем писались на Borland С++, который в своё время мог освоить только пользователь с большим опытом программирования и требовал серьёзных знаний в теории.

Бурное развитие информационных технологий требовало качественной и быстрой разработке программного обеспечения. Именно для таких разработок проявил себя Borland Delphi и Microsoft Visual Basic. В основе систем быстрой разработки (RAD-систем, Rapid Application Development -- среда быстрой разработки приложений) лежит технология визуального проектирования и событийного программирования, и вам не надо будет думать над программным кодом и реализацией стандартных задач, все, что вам требуется - это подключить определённый модуль (в зависимости от задачи) и правильно построить интерфейс программы.

Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в архитектуре “клиент-сервер”. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода (хотя это возможно).

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

4.2 Выбор СУБД

Важным шагом в проектировании БД является выбор СУБД. От выбора СУБД зависит качество работы пользователя с данными.

4.2.1 Понятие БД. СУБД и приложения

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

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

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

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

4.2.2 Особенности СУБД Microsoft SQL Server

Важнейшие характеристики СУБД Microsoft SQL Server- это:

1. Простота администрирования;

2. Возможность подключения к Web;

3. Быстродействие и функциональные возможности механизма сервера СУБД;

4. Наличие средств удаленного доступа.

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

В принципе, данная СУБД представляет собой современную полнофункциональную базу данных, которая идеально подходит для малых и средних организаций. Необходимо заметить, что SQL Server уступает другим СУБД по двум важным показателям: программируемость и средства работы. При разработке клиентских БД приложений на основе языков Java, HTML часто возникает проблема недостаточности программных средств SQL Server и пользоваться этой СУБД будет труднее, если перечисленные языки необходимы. SQL Server функционирует только в среде Windows. Поэтому использование SQL Server целесообразно, по нашему мнению, только если для доступа к содержимому БД используется исключительно стандарт ODBC, в противном случае лучше использовать другие СУБД.

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

Т.к. разрабатываемая информационная система предназначена для небольшой компании с малым количеством сотрудником, то применение СУБД Microsoft SQL Server будет оптимальным.



4.3 Аппаратные требования

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

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

- процессор Pentium 75;

- память 32 Мб;

- VGA совместимый видеоадаптер;

- сетевой адаптер;

- клавиатура;

- манипулятор “Мышь”

- модуль беспроводной локальной сети «Wi-Fi».

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

- процессор Pentium (Celeron) 400;

- память 64 Мб;

- VGA совместимый видеоадаптер;

- сетевой адаптер;

- накопитель на Жестком Магнитном Диске 2 Гб.



5. Социальная значимость разработки

На сегодняшний день поездка за границу не является чем-то необычным. Каждый из нас, приложив усилия, может попасть в какую-нибудь зарубежную страну. Исторически так сложилось, что наш славный город находится в нескольких десятках километров от границы с Украиной. Поэтому многие из нас бывают там достаточно часто. И какая же первая мысль приходит к тем людям, которые собираются покинуть пределы нашего государства? Конечно, это мысль - сколько времени придется потратить в ожидании прохождения паспортного контроля. Эти утомительные и изматывающие очереди, мы теряем столько драгоценных минут.… Неужели никак нельзя сократить времяпрепровождения на границе? Конечно можно! Ведь мы живем в веке информационных технологий, а автоматизированное управление достигает своего пика.

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

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

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



6. Технико-экономическое обоснование проекта

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

6.1 Расчет интегрального показателя качества

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

6.1.1 Анализ рынка

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

6.1.2 Выбор системы-аналога

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

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

Для сравнения с разработанной системой, мы выбрали наиболее подходящую по функциональности и общим характеристикам систему. Это система "Контроль+". Именно ее мы будем рассматривать при составлении базы сравнения и вычисления интегрального показателя качества.

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

Таблица 6.1

Сопоставление технико-экономических критериев

Критерий	Весовой коэффиц., qi	Оценка модели, А1i	qi·A1i	Оценка аналога, А2i	qi·A2i
Учет попыток пересечения	0,3	10	3,0	10	3,0
Поддержка обновления информации	0,3	10	3,0	7	2,1
Разграничение доступа	0,1	6	0,6	6	0,6
Совместимость	0,2	8	1,6	6	1,2
Использование СУБД	0,2	8	1,6	8	1,6
ИТОГО:	1,0		9,8		8,5

6.1.3 Интегральный показатель качества

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

Он будет равен:

для разрабатываемой системы:

И₁ = ? A_1iq_i = 9,8

для аналога:

И₂ = ? A_2iq_i = 8,5,

где A_1i и A_2i соответствующая характеристика проекта и аналога;q_i - весовые коэффициенты.

Относительная технико-экономическая эффективность разработанного продукта:

K_и = И₁ / И₂ = 1,153.

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

6.2 Расчет себестоимости системы

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

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

, (6.1)

где Т_о - ожидаемая длительность работ;

Т_min и Т_max - наименьшая и наибольшая, по мнению эксперта, длительность работ.

Все расчеты сведены в таблице 6.2.

Таблица 6.2

Определение продолжительности работ

Наименование работ	Длительность работ (дней)
	tmin	tmax	t0
Разработка ТЗ	5	9	6,6
Анализ ТЗ	4	6	4,8
Поиск и изучение источников*	12	16	13,6
Разработка алгоритма	14	20	16,4
Разработка программы*	20	34	25,6
Тестирование и отладка программы*	20	25	22,0
Оформление сопроводительной документации*	7	14	9,8
Машинное время	59	89	71,0
Итого:	82	124	98,8

Ленточный график работ представлен на рисунке 6.1.

Рисунок 6.1 - Ленточный график



Всего было затрачено 99 дней (из них с использованием ЭВМ-71 день). Себестоимость разработанной системы рассчитаем по формуле (6.2):

К = Z_п + М_п + Н_р, (6.2)

где Z_п - заработная плата проектировщика на всем этапе проектирования;

М_п - затраты на использование ЭВМ на этапе проектирования;

Н_р - накладные расходы.

Одним из основных видов затрат на этапе проектирования является заработная плата проектировщика, которая рассчитывается по формуле (6.3):

Z_п = Z_дТ_п (1 + а_с /100) (1 + а_п /100), (6.3)

где Z_д - дневная заработная плата разработчика на этапе проектирования;

а_с - единый социальный налог (ЕСН);

а_п - процент премий.

Z_д = 110 руб.,

Т_п= 99 дней,

_с = 26%,

_п = 20%,

Z_п = 110 99 (1 + 26/100)(1 + 20/100) = 16466 (руб.).

Формула (6.4) для расчетов затрат на использование ЭВМ на этапе проектирования имеет вид:

М_п= С_м ·t_м, (6.4)

где С_М - стоимость 1 часа машинного времени; t_М - необходимое для решения задачи машинное время (час).

С_М= 15 руб.,

t_М = t_Р t,

где t_Р - время, требуемое на разработку программы;

t - количество часов работы с ПП в день.

t_М = 71 4 = 284 ч,

М_П = 15 · 352 = 4260 руб.

Накладные расходы составляют 10% от заработной платы персонала, занятого эксплуатацией программы, и вычисляются по формуле (6.5):

Н_П = (Z_П · 10) / 100, (6.5)

Н_П = (16466 · 10) / 100 = 1647 руб.

Таким образом, получим себестоимость системы по формуле (6.6):

С = Z_п + М_п + Н_п, (6.6)

С= 16466 + 4260 + 1647 =22373 руб.

Цена разработанной системы вычисляется по следующей формуле (6.7):

Ц = С + П, (6.7)

где П - прибыль разработчика.

Прибыль составляет 5% от себестоимости системы.

Таким образом, цена разработанной системы равна:

Ц = С + 0,05 · С,

Ц = 22373 + 0,05 · 22373 = 23492 руб.



6.3 Подход к ценообразованию

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

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

Для рынка олигополии характерно:

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

- производство как однородной, так и диверсифицированной продукции;

- высокая монопольная (рыночная) власть отдельной фирмы (больше, чем на конкурентном рынке, но меньше, чем при чистой монополии).

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

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

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

6.4 Расчет трудоемкости разработки программного продукта

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

Обозначим G - трудоемкость разработки ПП (чел-мес), Т - длительность разработки ПП, месяц.

G и Т определяются по формулам (6.8) и (6.9)

, (6.8)

, (6.9)

где n - количество тысяч строк ИТП.

ИТП, в нашем случае составляет 2100 строк, т.е. n= 2,1. Исходя из этого, определим G и Т:

,



6.5 Расчет экономического эффекта от использования программы

Критерием эффективности создания и внедрения новых методов является ожидаемый экономический эффект. Он определяется по формуле (6.10):

Э = Э_г - К_п · Е_н, (6.10)

гдеЭ_г - годовая экономия; К_п - капитальные затраты покупателя; Е_н - нормативный коэффициент (Е_н = 0,3).

Годовая экономия Э_г складывается из экономии эксплуатационных расходов и экономии в связи с повышением производительности труда пользователя. Таким образом, получаем формулу (6.11):

Э_г = (Р₁ + Р₂) + Р_п, (6.11)

гдеР₁ и Р₂ - соответственно эксплуатационные расходы до и после внедрения; Р_п - экономия от повышения производительности труда пользователя.

Т.к. программный продукт не требует дополнительных эксплуатационных расходов, то годовая экономия Э_г равна:

Э_г = Р_п.

6.6 Экономия от увеличения производительности труда

Если пользователь при выполнении работы j-того вида после использования системы экономит Т_j часов, то повышение производительности труда Р_п (в процентах) определяется по формуле (6.12):

P_п = Т_j / (t_j- T_j) · 100, (6.12)

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

Т_j иt_j должны быть определены в среднем за год.

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

Р_п = (1,83 / (2 - 1,83))*100% = 1076%

До использования программы годовая оплата пользователя составляла:

5000*12 = 60000 руб.

После использования программы:

(5000 / 10,76) · 12 = 5576 руб.

Таким образом, экономия от повышения производительности труда пользователя равна:

Р_п = 60000 - 5576 = 54424 руб.

Годовая экономия равна:

Э_г= Р_п = 54424 руб.

Так как капитальные затраты покупателя равны:

К_п = С + П,

К_П= 22373 + 0,05 · 22373 = 23492 руб.

Отсюда получаем, что ожидаемый экономический эффект равен:

Э = Э_г - Е_н·К_п

Э = 54424 - 0,3 ·23492 = 47346 руб.

В результате получим таблицу 6.3.

Таблица 6.3

Показатели экономической эффективности разработки

Показатель	Цена, руб.
Себестоимость	22373
Цена с учетом прибыли	23492
Экономический эффект	47346



7. Безопасность и экологичность при эксплуатации информационной системы страховой компании

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

7.1 Анализ напряженности трудового процесса при эксплуатации информационной системы

Оценку напряженность трудового процесса для оператора проведем в соответствии с руководством P2.2.2006-05 «Гигиенические критерии оценки и классификация условий труда по показателям вредности и опасности факторов производственной среды, тяжести и напряженности трудового процесса» [11].

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

7.1.1 Оценка показателей трудового процесса

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

1. Нагрузки интеллектуального характера

1.1 "Содержание работы" - наиболее сложная по содержанию работа, требующая той или иной степени эвристической (творческой) деятельности. Оценка 3.2;

1.2 "Восприятие сигналов (информации) и их оценка" - по данному фактору трудового процесса осуществляется восприятие сигналов (информации) с последующей коррекцией действий и выполняемых операций. Оценка 2.0;

1.3 "Распределение функций по степени сложности задания". Любая трудовая деятельность характеризуется распределением функций между работниками. Соответственно, чем больше возложено функций на работника, тем выше напряженность его труда. Оценка 2.0;

1.4 "Характер выполняемой работы". Наибольшая напряженность характеризуется работой в условиях дефицита времени и информации. При этом отмечается высокая ответственность за конечный результат работы. Оценка 3.2;

2. Сенсорные нагрузки.

2.1 "Длительность сосредоточенного наблюдения (в % от времени смены)" - чем больше процент времени отводится в течение смены на сосредоточенное наблюдение, тем выше напряженность. Общее время рабочей смены принимается за 100%. Оценка 3.1;

2.2 "Плотность сигналов (световых, звуковых) и сообщений в среднем за 1 ч работы" - количество воспринимаемых и передаваемых сигналов (сообщений, распоряжений) позволяет оценивать занятость, специфику деятельности работника. Оценка 1.0;

2.3 "Число производственных объектов одновременного наблюдения" - указывает, что с увеличением числа объектов одновременного наблюдения возрастает напряженность труда (до5). Оценка 1.0;

2.4 "Размер объекта различения (при расстоянии от глаз работающего до объекта различения не более 0.5 м) при длительности сосредоточенного наблюдения (% от времени смены)". Класс напряженности труда зависит от размера рассматриваемого предмета и продолжительности времени наблюдения (т.е. от нагрузки на зрительный анализатор). Оценка 2.0;

2.5 "Работа с оптическими приборами (микроскоп, лупа и т.п.) при длительности сосредоточенного наблюдения (% от времени смены)". На основе хронометражных наблюдений определяется время (часы, минуты) работы за оптическим прибором. Оценка 1.0.

2.6 "Наблюдение за экраном видеотерминала (ч в смену)". Согласно этому показателю фиксируется время (ч, мин.) непосредственной работы пользователя ВДТ с экраном дисплея в течение всего рабочего дня при вводе данных, редактировании текста или программ, чтении буквенной, цифровой, графической информации с экрана. Оценка 3.1;

2.7 "Нагрузка на слуховой анализатор (при производственной необходимости восприятия речи или дифференцированных сигналов)". Разборчивость слов и сигналов от 100% до 90%, помехи отсутствуют. Оценка 1.0;

2.8 "Нагрузка на голосовой аппарат (суммарное количество часов, наговариваемых в неделю)". Степень напряжения голосового аппарата зависит от продолжительности речевых нагрузок. Перенапряжение голоса наблюдается при длительной, без отдыха, голосовой деятельности. Оценка 1.0;

3. Эмоциональные нагрузки

3.1 "Степень ответственности за результат собственной деятельности. Значимость ошибки" - указывает, в какой мере работник может влиять на результат собственного труда при различных уровнях сложности осуществляемой деятельности. Характерна самая высокая степень ответственности за окончательный результат работы, а допущенные ошибки могут привести возникновению опасных ситуаций для жизни людей. Оценка 3.2;

3.2 "Степень риска для собственной жизни". Исключена. Оценка 1.0;

3.3 "Степень ответственности за безопасность других лиц". Исключена. Оценка 1.0;

4. Монотонность нагрузок.

4.1 "Число элементов (приемов), необходимых для реализации простого задания или многократно повторяющихся операций" - чем меньше число выполняемых приемов, тем выше напряженность труда, обусловленная многократными нагрузками. Оценка 2.0;

4.2. "Продолжительность (с) выполнения простых производственных заданий или повторяющихся операций" - чем короче время, тем, соответственно, выше монотонность нагрузок. Оценка 2.0;

4.3 "Время активных действий (в % к продолжительности смены)". Чем меньше время выполнения активных действий и больше время наблюдения за ходом производственного процесса, тем, соответственно, выше монотонность нагрузок. Оценка 2.0;

4.4 "Монотонность производственной обстановки (время пассивного наблюдения за ходом техпроцесса в % от времени смены)" - чем больше время пассивного наблюдения за ходом технологического процесса, тем более монотонной является работа. Оценка 2.0;

5. Режим работы.

5.1 "Фактическая продолжительность рабочего дня". Колеблется от 8 - 9 ч. Оценка 2.0;

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

5.3. "Наличие регламентированных перерывов и их продолжительность". Перерывы регламентированы, недостаточной продолжительности: от 3 до 7 % рабочего времени. Введение перерывов на отдых в счет рабочего времени способствует улучшению функционального состояния организма работника и обеспечивает высокую производительность его труда. Оценка 2.0.

Так как количество оценок 3.1 или 3.2 не превышает пяти, то условия труда пользователя допустимы (2 класс).

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

7.1.2 Дерево отказов при эксплуатации системы

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

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

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

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

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

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

1. Некорректные действия оператора:

- ошибки вследствие переутомления;

- ошибки из-за нервного напряжения;

- ошибки вследствие недостаточной квалификации пользователя.

2. Программные ошибки:

- сбой операционной системы (ОС);

- ошибки проектирования;

- ошибки программ.

3. Сбой в работе сети:

- отключение системы питания;

- выход из строя системы оборудования.

4. Возникновение пожара:

- присутствие горючих материалов;

- появление искры или огня.

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

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

...