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

Оглавление

• Введение
• 1. Предпроектное обследование
• 1.1 Общее описание предметной области
• 1.2 Цели и задачи дипломной работы
• 1.3 Сравнительный анализ существующих решений
• 1.4 Организационная структура отдела пограничного контроля
• 1.5 Функциональная схема наряда «Проверка документов»
• 1.6 Сценарий проверки документов на границе
• 1.7 Функционально ориентированная модель процесса проверки документов
• 2. Математическая формализация и реинжиниринг бизнес процессов
• 2.1 Анализ и выбор CASE средств
• 2.2 Математическая формализация функционально ориентированной модели
• 2.3 Реинжиниринг бизнес процесса паспортного контроля на границе
• 2.4 Математическая формализация оптимизированной функционально ориентированной модели
• 2.5 Функциональные требования к информационной системе поддержки паспортного контроля на границе
• 3. Проектирование информационной системы поддержки паспортного контроля на границе
• 3.1 Выбор архитектуры информационной системы в соответствии с выявленными функциональными требованиями
• 3.1.1 Архитектура файл-сервер
• 3.1.2 Архитектура клиент сервер
• 3.1.3 Многоуровневая архитектура
• 3.1.4 Сравнительный анализ рассмотренных архитектур
• 3.2 Схема развертывания информационной системы
• 3.3 Анализ средств проектирования баз данных
• 3.4 Проектирование информационной структуры
• 4. Реализация выбранного варианта решения
• 4.1 Выбор языка программирования
• 4.2 Выбор СУБД
• 4.2.1 Понятие БД. СУБД и приложения
• 4.2.2 Особенности СУБД Microsoft SQL Server
• 4.3 Аппаратные требования
• 5. Социальная значимость разработки
• 6. Технико-экономическое обоснование проекта
• 6.1 Расчет интегрального показателя качества
• 6.1.1 Анализ рынка
• 6.1.2 Выбор системы-аналога
• 6.1.3 Интегральный показатель качества
• 6.2 Расчет себестоимости системы
• 6.3 Подход к ценообразованию
• 6.4 Расчет трудоемкости разработки программного продукта
• 6.5 Расчет экономического эффекта от использования программы
• 6.6 Экономия от увеличения производительности труда
• 7. Безопасность и экологичность при эксплуатации информационной системы страховой компании
• 7.1 Анализ напряженности трудового процесса при эксплуатации информационной системы
• 7.1.1 Оценка показателей трудового процесса
• 7.1.2 Дерево отказов при эксплуатации системы
• 7.2 Мероприятия по улучшению условий труда при эксплуатации информационной системы
• 7.2.1 Содержание работы
• 7.2.2 Длительность сосредоточенного наблюдения
• 7.2.3 Наблюдение за экранами видеотерминалов
• 7.2.4 Степень ответственности
• 7.3 Пожаробезопасность при эксплуатации информационной системы
• 7.3.1 Пожарная безопасность
• 7.3.2 Электрическая безопасность
• 7.4 Защита окружающей и природной среды при эксплуатации информационной системы
• Заключение


Введение

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

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

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

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



1. Предпроектное обследование

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

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

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

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

- недопущению противоправного изменения прохождения Государственной границы;

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

- защите на Государственной границе иных жизненно важных интересов личности, общества и государства от внешних и внутренних угроз.

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

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

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

Пограничные войска не должны допускать необоснованных задержек лиц, транспортных средств, товаров и животных, следующих через Государственную границу Российской Федерации.

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

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

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

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

1.2 Цели и задачи дипломной работы

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

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

· Провести сравнительный анализ существующих решений;

· Построить организационную структуру, функциональную схему, сценарий и функционально-ориентированную модель рассматриваемого объекта;

· Формализовать функционально ориентированную модель с помощью системы массового обслуживания;

· Провести анализ выделенных характеристик СМО и выявить существующие проблемы предметной области;

· Провести реинжиниринг путем построения новой, оптимизированной функционально ориентированной модели;

· Формализовать новую модель с помощью СМО;

· Провести сравнительный анализ моделей и показать преимущество оптимизированной модели;

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

· Рассмотреть способы реализации спроектированной информационной системы;

· Рассмотреть социальную значимость данного проекта;

· Провести технико-экономическое обоснование проекта;

· Рассмотреть вопросы, связанные с безопасностью и экологичностью проекта.

1.3 Сравнительный анализ существующих решений

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

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

На российском рынке CRM-системы представлены как зарубежными, так и отечественными производителями. Причем в секторе среднего и малого бизнеса последние занимают далеко не худшие позиции за счет меньшей стоимости лицензий при сравнимой полезной функциональности. Достаточно хорошо внедряются такие системы, как "Terrasoft", "1С:Предприятие 8.0", "Winpeak".

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

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

Проведём сравнительный анализ рассмотренных информационных систем (Таблица 1.1). В качестве критериев будут выступать функциональных возможность данных систем.

«+» - данный функционал присутствует в системе.

«-» - данный функционал отсутствует в системе.



Таблица 1.1

Сравнительный анализ параметров

Программный продукт Критерии оценки	Microsoft Business Solutions CRM	1С:УПП	WinPeak CRM
Ведение списка контактов	+	+	+
Ведение клиентской базы	+	+	+
Сегментация клиентов	+	+	+
Разграничение прав доступа	-	+	-
Формирование базы знаний	+	-	+
Использование встроенной отчётности	+	+	+
Аналитика и выявление прибыльных клиентов	+	+	+
Распределение заказов по персоналу компании	+	+	+
Возможность настройки системы	+	+	+
Организация бумажного архива	-	-	-

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

1.4 Организационная структура отдела пограничного контроля

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

Рис. 1.1 Отдел пограничного контроля

Из выше представленной организационной структуры видно, что у отдела пограничного контроля пограничного управления в подчинении находятся автомобильный пункт пропуска, железнодорожный пункт пропуска, морской пункт пропуска. Все эти пункты пропуска в свою очередь делятся на пункты пропуска 1, 2 и 3 категории. Пункт пропуска каждой из категорий, как правило, состоит из 3 отделений пограничного контроля. В нашем случае мы будем заниматься рассмотрением работы 2ОПК. 2 ОПК организует следующие виды нарядов: Проверка документов (ПД). Досмотр транспортных средств (ДТС), Сопровождение Транспортных Средств (СТС), Наблюдение за Транспортными средствами (НТС). Мы рассматриваем проверку документов. Этим нарядом занимается следующий штат сотрудников: Начальник смены, у которого в подчинении находятся часовые у шлагбаума (ЧШ) и контроллер. Далее построим функциональную схему данного наряда.

1.5 Функциональная схема наряда «Проверка документов»

Рис. 1.2 Функциональная схема наряда «Проверка документов»

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

На приведенном рисунке:

· ЧШ1 - часовой у шлагбаума 1;

· ЧШ2 - часовой у шлагбаума 2;

· НС - начальник смены.

Далее рассмотрим сценарий проверки документов.

1.6 Сценарий проверки документов на границе

Рис. 1.3 Сценарий проверки документов на границе

На рис.1.3 t- время, затрачиваемое на выполнение функции, в минутах. Соответственно:

t₁ = 0,167 мин.

t₂ = 0,333 мин.

t₃ = 0,333 мин.

t₄ = 0,167 мин.

t₅ = 1 мин.

t₆ = 0,25 мин.

t_{7 1} = 0,5 мин.

t_{7 2} = 3 мин.

t_{7 3} = 3 мин.

t_{7 4} = 4 мин.

t_{7 5} = 3 мин.

t_{7 6} = 1 мин.

t_{7 7} = 2 мин.

t₈ = 0,5 мин.

t₉ = 0,5 мин.

t_{10 1} = 0,5 мин.

t_{10 2} = 3,5 мин.

t₁₁ = 0,5 мин.

t₁₂ = 0,5 мин.

t₁₃ = 0,5 мин.

t₁₄ = 0,25 мин.

t₁₅ = 23 мин.

t₁₆ = 0,5 мин.

t₁₇ = 0,5 мин.

Из данного сценария (рис. 1.3) видно, что сначала лицо пересекающее границу (далее ЛПГ) взаимодействует с ЧШ1 посредством предъявления паспорта. Это необходимо для того, чтобы часовой удостоверил личность (сличение фотокарточки с ЛПГ). В дальнейшем он возвращает документ и пропускает ЛПГ к контроллеру на детальную проверку документов.

По прибытии ЛПГ к контроллеру ЛПГ предоставляет все необходимые документы (например, российская вкладная виза, виза, паспорт, свидетельство о рождении ребенка, доверенность…). В свою очередь, контроллер сперва сличает фотографии на документах с ЛПГ с целью удостовериться, что на фотокарточках изображено именно то лицо, которое предъявляет документ. Затем проверяет, не состоит ли ЛПГ на каком-либо учете лиц, которым запрещен въезд/выезд за пределы РФ, а так же не имеется ли в отношении этого лица оперативного задания или ориентировки. Следом определяет вид документов и соответствие их установленному образцу. Затем проверяет визуально и с помощью технических средств, не проводилась ли замена фотокарточек в документах и не имеется ли других подделок. Проверяет правильность заполнения документов и наличие всех необходимых отметок. Потом должен убедиться все ли лица, вписанные в документ, следуют через границу. Следом проверить соответствуют ли сведения, указанные в визе данным документа. Если же контроллер где-то выявил нарушение, то он дает запрос начальнику смены: «не подтверждение факта пересечения границы». Начальник смены тогда отдает приказ о задержании ЛПГ до выяснения обстоятельств. Дает приказ ЧШ2 не выпускать данное ЛПГ. Если все документы в порядке, то контролер дает начальнику смены запрос: «подтверждение факта пересечения границы». Начальник смены тогда дает разрешение на выезд и сообщает это как контроллеру, так и ЧШ2. Получив такую информацию от НС, контроллер должен поставить все необходимые отметки. Занести информацию в БД. Затем изъять необходимые документы и вернуть оставшиеся.

После проверки документов ЛПГ следует к ЧШ2. Тот свою очередь пропускает лицо через границу.

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

1.7 Функционально ориентированная модель процесса проверки документов

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

Рис. 1.4 Функционально ориентированная модель процесса проверки документов



На рисунке 1.4 t - время, затрачиваемое на выполнение функции (в минутах). Соответственно:

t₁ = 0,167 мин.; t₂ = 0,333 мин.; t₃ = 0,333 мин.; t₄ = 0,167 мин.

t₅ = 1 мин.; t₆ = 0,25 мин.; t_{7 1} = 0,5 мин.; t_{7 2} = 3 мин.; t_{7 3} = 3 мин.

t_{7 4} = 4 мин.

t_{7 5} = 3 мин.

t_{7 6} = 1 мин.

t_{7 7} = 2 мин.

t₈ = 0,5 мин.

t₉ = 0,5 мин.

t_{10 1} = 0,5 мин.

t_{10 2} = 3,5 мин.

t₁₁ = 0,5 мин.

t₁₂ = 0,5 мин.

t₁₃ = 0,5 мин.

t₁₄ = 0,25 мин.

t₁₅ = 23 мин.

t₁₆ = 0,5 мин.

t₁₇ = 0,5 мин.

Список необходимых документов предъявляемых для проверки:

1) Гражданский паспорт, дипломатический паспорт, служебный паспорт, общегражданский заграничный паспорт

2) Удостоверение личности

3) Свидетельство на возвращение в РФ

4) Удостоверение лица без гражданства

5) Вкладная российская виза

6) Въездной/выездной талон вкладной визы, свидетельства о приглашении, именной список (эти документы подлежат изъятию)

В данной ФОМ отображены функции и время, затрачиваемое на их выполнение.

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



2. Математическая формализация и реинжиниринг бизнес процессов

2.1 Анализ и выбор CASEсредств

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

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

На следующем этапе выберем несколько CASE-средств, среди которых будет производиться выбор. В данной работе в процессе анализа будут представлены следующие CASE-средства: Borland Together, MSVisio 2007, Rational Rose. Все эти продукты поддерживают нотацию UML 2.0.

Достоинством MSVisio 2007является тот факт, что данный продукт распространяется как надстройка к MSOffice 2007. Размер дистрибутива у данного продукта не очень большой, что позволяет скачать его с сайта разработчика без каких-либо серьезных затрат.

Недостатком в данном CASE-средстве является тот факт, что оно поддерживает не все диаграммы нотации UML 2.0. Еще один минус - это отсутствие технической поддержки пользователей. Но! Большим плюсом является тот факт, что имеется возможность использовать не стандартные графические примитивы.

CASE-средство Rational Rose является коммерческой разработкой компании IBM. Последняя 2007 версия данного продукта поддерживает нотацию UML 2.0 в полном объеме. При инсталляции пакета разработчику предоставляется множество утилит и сопутствующих продуктов, облегчающих разработку систем. Также в пакете присутствует возможность генерации исходного кода приложения на основе моделей. Среди достоинств еще можно выделить очень красивый интуитивно понятный и эргономичный интерфейс продукта.

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

CASE-средство Borland Together поставляется в комплекте с пакетом Borland Developer Studio. Данный пакет ориентирован на разработку приложений на языках Delphi, C++ и Java. Встроенное CASE-средство в данный пакет позволяет создавать модели и генерировать исходный код из диаграммы классов. Данный пакет изначально ориентирован на написание исходного кода приложения, его компиляцию и отладку. Функции разработки моделей в данном пакете являются дополнительными.

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

В идеальном случае для создания моделей и проведения моделирования предметной области необходимо использовать CASE-средство от компании IBM - Rational Rose7.0. Но ввиду высокой стоимости и недоступности данного средства, в данной работе будет использовано CASE-средство MSVisio 2007. Оно в данном случае удовлетворяет всем требованиям и является доступным.

CASE-средство BPwin поддерживающее методологии IDEF0, DFD, IDEF3 и CASE-средство Erwin поддерживающее методологию IDEF1x, являются безальтернативными в плане выбора. Проводить сравнение между средствами, поддерживающими нотацию UML 2.0 и методологии IDEF0, DFD, IDEF3 и IDEF1x считаю нецелесообразным, так как данные средства нацелены на решение различного круга задач, причем средства с поддержкой UML 2.0 способны решать задачи, решаемые средствами BPwin и ERwin.



Таблица 2.1

Анализ CASE средств

	MS Visio 2007	Rational Rose 7.0	Borland Together
Поддержка UML 2.0 и выше	+	+	+
Генерация кода программы	+	+	+
Работа в комплексе	-	+	+
Поддержка	-	+	+
Экспертная оценка	Удовлетворительно	Отлично	Хорошо
Размер дистрибутива	350 Мбайт	8 400 Мбайт	4 500 Мбайт
Аппаратные требования	512 Мб оперативной памяти, 400 Мб свободного места на HDD.	Минимум 1 Гб оперативной памяти, от 1200 Мб свободного места на HDD.	Минимум 1 Гб оперативной памяти (рекомендуется больший объем), 700 Мб свободного места HDD
Стоимость	Бесплатно, при условии покупки MsOffice	> 130 000 рублей	>55 000 рублей

Проведя анализ достоинств и недостатков, представленных CASE-средств, можно сделать выбор какое средство необходимо использовать в данном случае. Я склоняюсь к использованию для создания модели работы объекта исследования и модели разрабатываемой системы CASE-средства MSVisio 2007, так как оно удовлетворяет требованиям по использованию нотации UML 2.0 в создаваемых моделях.

2.2 Математическая формализация функционально ориентированной модели

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

Выбор обуславливается в первую очередь тем, что наблюдается:

1. Входной поток поступающих требований или заявок на обслуживание

2. Дисциплина очереди

3. Механизм обслуживания

Все эти 3 составляющие являются основными компонентами СМО любого вида.

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

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

В нашем случае ОПК имеет один канал обслуживания. В связи с намерением ЛПГ пересечь границу, то независимо, от того, занят ли канал или нет, ЛПГ становится в очередь и ждет столько времени, сколько понадобится, т.е. пребывая в очереди, ЛПГ может ждать неограниченно долго. Это говорит о том, что система без отказов. Исходя из этого, имеем одноканальную СМО с неограниченным временем ожидания и неограниченной длиной очереди. 2ОПК представляет собой СМО с одним каналом обслуживания. Поток автомобилей с ЛПГ, прибывающих на границу имеет интенсивность л=9 (9 машин в час). Процесс проверки документов продолжается в среднем 25 минут = 0.417 часа. Так как каждая заявка рано или поздно будет обслужена, то вероятность отказа Р_отк= 0

Рис. 2.1 Одноканальная СМО с ожиданием

Сведем характеристики одноканальной СМО и представим их в виде таблицы.

Таблица 2.2

Обозначение	Физический смысл	Формула для вычисления	Результат	Размерность
л	Интенсивность поступления потока ЛПГ	Исходные данные	9	Автомобилей с ЛПГ/час
м	Интенсивность обслуживания	м=	2,398	Автомобилей с ЛПГ /час
tобс	Время обслуживания одной заявки	Исходные данные	0,417	Часы
Ротк	Вероятность отказа обслуживания ЛПГ	Исходные данные	0
с	Количество обслуженных заявок в единицу времени	с=	3,753	Автомобилей с ЛПГ
q	Относительная пропускная способность	q = 1 - Pотк	1	Автомобилей с ЛПГ
А	Абсолютная пропускная способность - среднее число заявок, которое может обслужить система в единицу времени	A = л*q	9	Автомобилей с ЛПГ
r	Среднее число заявок в очереди	r = с2/(1 - с), при с<1 и r = с2/(с - 1), при с>1	5,116	Автомобилей с ЛПГ
k	Среднее число заявок в системе	k = r + с	8,869	Автомобилей с ЛПГ
tож	Среднее время ожидания в очереди	tож = с/м*( с - 1) = с2/л*( с - 1)	0,568	Часы
tсмо	Среднее время пребывания заявки в СМО (включая время ожидания и время обслуживания)	tсмо = tож+ tобс	0,985	Часы



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

Вывод: на основе полученной модели СМО провести реинжиниринг таким образом, чтобы достичь времени ожидания ЛПГ обслуживания не более 25 минут, времени нахождения ЛПГ в системе не более 40 минут. Количество ЛПГ в очереди не должно превышать 5.

2.3 Реинжиниринг бизнес процесса паспортного контроля на границе

Если внимательно посмотреть на функции контроллера, то следует сделать вывод о том, что именно на его работу затрачивается длительный интервал времени. Чтобы снизить этот промежуток времени, можно воспользоваться сокращением его функций. Другими словами, предоставить определенный набор действий компьютеру, т.е. ввести частичную автоматизацию. Смысл вышеизложенного состоит в том, чтобы паспорт (как гражданина РФ, так и заграничный) содержал штрих-код. Таким образом, когда контроллер воспользуется системой считывания штрих-кода, у него на мониторе, во-первых, отразится вся необходимая информация о данном лице, и, во-вторых, т.к. уже будет открыто окно данного ЛПГ, то контролеру нужно будет совершить всего лишь несколько кликов, чтобы дополнить БД нужной информацией (вместо того, чтобы полностью заносить информацию о ЛПГ, как ранее). Следовательно, такие функции как проверка на разрешение въезда/выезда, определение вида документа и соответствия образцу, фиксация всех необходимых отметок, занесение информации в БД будут выполняться уже автоматически. А значит, это значительно сократит время ожидания на обслуживание. К тому же, это существенно облегчит работу контроллера. Еще важным моментом является то, что через одного контроллера проходит весь поток транспортных средств, т.е. и грузовые машины, и легковые, и автобусы с пассажирами. Другими словами, такая разнородность потока влияет на производительность контроллера, снижается концентрация и соответственно качество работы.

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

Для того чтобы этого избежать, следует организовать работу 3 каналов обслуживания: легковые автомобили, грузовые и автобусы с пассажирами. Такое нововведение также позволит сократить очередь и уменьшить время пребывания ЛПГ в системе.

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

На рисунке 2.2 t - время, затрачиваемое на выполнение функции (в минутах). Соответственно:

t₁ = 0,167 мин.

t₂ = 0,333 мин.

t₃ = 0,333 мин.

t₄ = 0,167 мин.

t₅ = 1 мин.

t₆ = 0,25 мин.

t_{7 1} = 0,5 мин.

t_{7 2} = 4 мин.

t_{7 3} = 1,5 мин.

t_{7 4} = 3 мин.

t_{7 5} = 1 мин.

t_{7 6} = 2 мин.

t₈ = 0,5 мин.

t₉ = 0,5 мин.

t₁₀ = 0,5мин.

t₁₁ = 0,5 мин.

t₁₂ = 0,5 мин.

t₁₃ = 0,5 мин.

t₁₄ = 0,25 мин.

t₁₅ = 14,5 мин.

t₁₆ = 0,5 мин.

t₁₇ = 0,5 мин.

2.4 Математическая формализация оптимизированной функционально ориентированной модели

Для того, чтобы формализовать оптимизированную ФОМ, теперь будем рассматривать 2ОПК, которое представляет собой СМО с 3 каналами обслуживания. Поток автомобилей с ЛПГ, прибывающих на границу имеет интенсивность л=9 (9 машин в час). Процесс проверки документов продолжается в среднем 15,5 минут = 0.258 часа. Так как каждая заявка рано или поздно будет обслужена, то вероятность отказа Р_отк= 0

Рис. 2.3 3-канальная СМО с ожиданием

Сведем характеристики 3-канальной СМО и представим их в виде таблицы.



Таблица 2.3

Обозначение	Физический смысл	Формула для вычисления	Результат	Размерность
л	Интенсивность поступления потока ЛПГ	Исходные данные	9	Автомобилей с ЛПГ/час
м	Интенсивность обслуживания	м=	3,876	Автомобилей с ЛПГ /час
tобс	Время обслуживания одной заявки	Исходные данные	0,258	Часы
Ротк	Вероятность отказа обслуживания ЛПГ	Исходные данные	0
с	Количество обслуженных заявок в единицу времени n каналами	с=	2,322	Автомобилей с ЛПГ
ч	Количество обслуженных заявок в единицу времени одним каналом	ч =	0,774	Автомобилей с ЛПГ
n	Количество каналов	Исходные данные	3	шт.
Р0	Вероятность простоя системы	P0=	0,101
t0	Время простоя системы, возникающее с вероятностью Р0	Р0*Т	0,101	часы
T	Период	Исходные данные	1	часы
q	Относительная пропускная способность	q = 1 - Pотк	1	Автомобилей с ЛПГ
А	Абсолютная пропускная способность - среднее число заявок, которое может обслужить система в единицу времени	A = л*q	9	Автомобилей с ЛПГ
z	Среднее число занятых каналов	z = A/м	2,322	шт.
r	Среднее число заявок в очереди	r =	3,197	Автомобилей с ЛПГ
k	Среднее число заявок в системе	k = r + z	5,519	Автомобилей с ЛПГ
tож	Среднее время ожидания в очереди	tож =	0,355	Часы
tсмо	Среднее время пребывания заявки в СМО (включая время ожидания и время обслуживания)	tсмо = tож+ tобс	0,613	Часы

Произведем сравнительный анализ одноканальной и 3-канальной СМО и представим его в виде таблицы.

Таблица 2.4

Обозначение	Физический смысл	Результат СМО с одним каналом	Результат СМО с тремя каналами
л	Интенсивность поступления ЛПГ	9	9
tобс	Время обслуживания одной заявки	0,417	0,258
r	Среднее число заявок в очереди	5,116	3,197
k	Среднее число заявок в системе	8,869	5,119
tож	Среднее время ожидания в очереди	0,568	0,355
tсмо	Среднее время пребывания заявки в СМО (включая время ожидания и время обслуживания)	0,985	0,613

Анализируя полученные результаты, видим что среднее время ожидания ЛПГ обслуживания составляет приблизительно 21 минута, среднее время пребывания ЛПГ в системе равно приблизительно 37 минут, а количество ЛПГ в очереди свелось к 4. Таким образом, делаем вывод, что проведенный реинжиниринг помог достичь поставленной цели, т.е. построение оптимальной модели позволяет уменьшить время обслуживания ЛПГ и тем самым сократить время пребывания ЛПГ в зоне контроля, сократить очередь.

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



2.5 Функциональные требования к информационной системе поддержки паспортного контроля на границе

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

1. Единое централизованное хранилище всей информации включая:

· справочники сотрудников;

· справочники лиц пересекающих границу;

· справочники лиц, которым запрещено пересечение границы;

· справочники разыскиваемых транспортных средств;

· справочник возможных документов;

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

· Проверка на разрешения въезда/выезда;

· Определение вида документа;

· Фиксация всех необходимых отметок;

· Занесение информации в центральное хранилище данных.



3. Проектирование информационной системы поддержки паспортного контроля на границе

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

3.1.1 Архитектура файл-сервер

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

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

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

3.1.2 Архитектура клиент сервер

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере (см. рис. 3.1).

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

Рис. 3.1 Классический вариант клиент-серверной информационной системы

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

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

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

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

3.1.3 Многоуровневая архитектура

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней (см. рис. 3.2)

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

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

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

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.

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

Рис. 3.2 Классический вариант многоуровневой информационной системы

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

С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду UNIX, однако прикладные серверы можно строить на базе Microsoft Windows NT с использованием вызова удаленных процедур для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети.

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

3.1.4 Сравнительный анализ рассмотренных архитектур

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

3.2 Схема развертывания информационной системы

Учитывая выбранную архитектуру схему развертывания можно изобразить, как показано на рисунке 3.3.

Страница:

•  1 
•  2 
•  3 

дипломная работа "Информационная система паспортного контроля на границе" скачать

Подобные документы

• Информационная система обслуживания клиентов паспортного стола

  Функциональная схема отдела контроля по соблюдению правил проживания, временного пребывания иностранных граждан и лиц без гражданства. Математическая формализация и реинжиниринг бизнес-процессов. Выбор архитектуры информационной системы паспортного стола.
  
  дипломная работа [2,3 M], добавлен 20.07.2014
  

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

  Требования к системе проектирования информационной системы финансового контроля. Информационное, программное и техническое обеспечение автоматизированной системы. Алгоритмы и модели работы базы данных, созданной в среде разработки Borland Delphi 7.0.
  
  дипломная работа [1,2 M], добавлен 25.10.2013
  

• Автоматизированная информационная система контроля и учета товарных и денежных средств на примере ООО "Волжанка"

  Проектирование автоматизированной информационной системы контроля и учета товарных и денежных средств для магазина розничной торговли. Составление базы данных в среде СУБД MySQL. Расчет затрат на проектирование и эксплуатацию разработанной системы.
  
  дипломная работа [4,3 M], добавлен 13.12.2013
  

• Разработка автоматизированной информационной системы для медработников "Заказы на лекарства"

  Выбор, обоснование и особенности работы СУБД. Характеристика языков программирования. Разработка структурной и функциональной модели информационной системы аптеки. Проектирование программной среды АИС и ее интерфейса. Построение модели базы данных.
  
  курсовая работа [442,3 K], добавлен 21.04.2012
  

• Создание автоматизированной информационной системы зоомагазина "Дракоша"

  Исследование системы функционирования зоомагазина "Дракоша" и схематическое описание бизнес-процессов предприятия. Генерация кода и разработка автоматизированной информационной системы магазина на языке программирования С+. Расчет диаграмм автоматизации.
  
  курсовая работа [841,8 K], добавлен 07.08.2013
  

• Проектирование автоматизированной информационной системы в гостиничном бизнесе

  Анализ возможностей методологии и инструментальных средств проектирования информационной системы "Гостиница". Создание модели процессов, ее дополнение организационными диаграммами. Поиск и исправление ошибок с помощью Erwin Examiner. Связь с СУБД Acces.
  
  курсовая работа [6,5 M], добавлен 17.06.2011
  

• Бизнес-проект разработки и внедрения автоматизированной информационной системы для музея

  Проблемы внедрения информационной системы. Процесс разработки и внедрения автоматизированной информационной системы на примере музея "Галерея изящных искусств". Рекомендации по устранению основных рисков или снижению степени их влияния на проект.
  
  курсовая работа [3,0 M], добавлен 07.05.2015
  

• Автоматизированная система контроля знаний по дисциплине "История мира"

  Методы разработки автоматизированных систем. Характеристика языка программирования Delphi и операционной системы Windows. Разработка автоматизированной системы контроля знаний на примере дисциплины "История мира". Этапы разработки программного продукта.
  
  курсовая работа [3,8 M], добавлен 18.05.2014
  

• Проектирование и создание автоматизированной информационной системы "Поликлиника"

  Анализ существующих систем управления базами данных и выбор оптимальной. Создание автоматизированной информационной системы "Поликлиника", определение сущностей и взаимосвязей, описание физической модели, проектирование интерфейса, алгоритм программы.
  
  курсовая работа [3,1 M], добавлен 21.11.2009
  

• Разработка объектно-ориентированной модели информационной подсистемы "Деканат: экзаменационная сессия"

  Разработка объектно-ориентированной модели информационной подсистемы учета студентов университета во время экзаменационной сессии с помощью программы Rational Rose 2000, с использованием языка UML. Порядок генерации программного кода на языке С++.
  
  курсовая работа [689,9 K], добавлен 21.06.2011
  

• Разработка Web–ориентированной информационной системы IT-предприятия

  Требования к структуре и функционированию информационной системы. Входная и выходная информация подсистемы управления проектами. Описание "TheSystem", предназначенной для обеспечения процесса учета кадров, контроля работы сотрудников предприятия.
  
  дипломная работа [3,1 M], добавлен 07.03.2012
  

• Разработка автоматизированной информационной системы "Библиотека ВУЗа"

  Разработка автоматизированной информационной системы для эффективного и быстрого обслуживания пользователей библиотеки ВУЗа. Среда разработки: MS Access. Язык программирования - VBA. Расчет технико-экономической выгоды внедрения данной технологии.
  
  дипломная работа [304,7 K], добавлен 19.03.2010
  

• Создание автоматизированной информационной системы (АИС) для учета деятельности авторемонтного предприятия

  Обоснование необходимости совершенствования информационной системы (ИС) ООО "Мехсервис". Анализ системы учета деятельности авторемонтного предприятия. Разработка концепции построения автоматизированной ИС. Описание продукта информационной технологии.
  
  дипломная работа [2,7 M], добавлен 22.05.2012
  

• Информационная система учета и контроля успеваемости и посещаемости студентов ЮТИ ТПУ

  Проблема повышения оперативности учета и контроля посещаемости и успеваемости студентов ЮТИ ТПУ. Разработка информационной системы, требования к ней. Информационное обеспечение задачи, автоматизация предметной области. Описание интерфейса системы.
  
  дипломная работа [2,6 M], добавлен 17.07.2012
  

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

  Создание автоматизированной информационной системы для ОАО "Сибирь". Построение функциональной модели, описывающей существующую организацию работы на основе анализа деятельности предприятия. Смешанная модель в стандартах IDEF0, DFD, IDEF3 и IDEF1X.
  
  курсовая работа [2,4 M], добавлен 17.09.2010
  

• Разработка информационной системы ведения проектов строительной компании ООО "Стройтек"

  Описание структуры управления компании. Структура программно-аппаратных средств. Анализ технического задания. Расчет обобщенного критерия эффективности информационной системы ведения проектов строительной компании. Выбор языка программирования и СУБД.
  
  дипломная работа [2,1 M], добавлен 29.06.2013
  

• Моделирование и формализация

  Основные понятия: модель, моделирование, виды моделей. Пути и способы изучения темы "Моделирование и формализация" в курсе информатики в 8 классе. Создание табличной информационной модели. Понятие информационной модели, системы и структуры системы.
  
  методичка [1,8 M], добавлен 30.05.2013
  

• Информационная система "Data-центр"

  Разработка информационной системы "Библиотека Дорам" в архитектуре клиент - сервер; управление реляционными базами данных (СУБД) Microsoft SQL Server. Визуальная среда программирования и технические средства. Разработка структурированного приложения.
  
  курсовая работа [3,2 M], добавлен 12.01.2010
  

• Разработка объектно-ориентированной модели информационной подсистемы для приемной комиссии университета

  Этапы разработки объектно-ориентированной модели информационной подсистемы приемной комиссии для учета абитуриентов. Создание диаграмм для моделирования процесса обмена сообщениями между объектами. Порядок генерации программного кода на языке С++.
  
  курсовая работа [429,3 K], добавлен 29.06.2011
  

• Автоматизированная информационная система библиотеки высшего учебного заведения

  Особенности создания автоматизированной информационной системы для системного администратора библиотеки. Функции ввода и обновления данных и печати документов. Технологическая последовательность выполнения процедур системы, инструкция пользователя.
  
  курсовая работа [430,0 K], добавлен 12.03.2013
  

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