Разработка автоматизированной информационной системы учета заявок на ремонт подвижного состава на примере предприятия РМ ПАТП-6 - Программирование, компьютеры и кибернетика курсовая работа

Главная

Программирование, компьютеры и кибернетика
Разработка автоматизированной информационной системы учета заявок на ремонт подвижного состава на примере предприятия РМ ПАТП-6

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


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

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

Актуальность и место решаемой задачи информационного обеспечения в предметной области
1 . Разработка требований к программному обеспечению
1.1 Анализ существующих решений по автоматизации предметной области
1.3 Выбор методологии проектирования информационной системы
1.5 Ана лиз и моделирование требований
2 . Проектирование информационной системы
2.2 Проектировани е пользовательского интерфейса
2.3.1 Ко нцептуальное проектирование БД
2.3.2 Разработка логической модели данных
2.3.3 Разра ботка физической модели данных
2.4 Обоснование выбора платформы с оздания информационной системы
3 . Реализация и аттестация информационной системы
3.2 Взаимодействие приложения с источниками данных (технология доступа к данным, sq l-запросы, хранимые процедуры)
3.4 Мет одика развертывания приложения
4 . Управление информационным проектом
4.1 Выбор жизненного цикла разработки ПО
4.2 Определение цели и области действия программного проекта
4.3 Создание структуры пооперационного перечня работ
4.5 Оценка размера и возможности повторного использования ПО
4.6 Оценка длительн ости и стоимости разработки ПО
4.8 Оценка эконо мической эффективности проекта
Ростовское Муниципальное пассажирское автотранспортное предприятие №6 является филиалом Муниципального унитарного предприятия «Ростовпассажиртранс» и выполняет часть его производственных функций. Основным направлением деятельности филиала являются перевозка пассажиров.
Исходными данными для решения задач текущего и перспективного планирования работы городского пассажирского транспорта являются материалы комплексного обследования подвижного состава всех видов транспорта, а также пассажирских потоков.
Анализ материалов обследования в пределах сложившейся маршрутной схемы позволяет обеспечить более полное представление о количестве исправного транспорта на потоке. Обследование дает возможность произвести расчет количества неисправностей на единицу транспорта за день, месяц, год, а также узнать точное количество сходов и выходов единиц транспорта, на основании данных полученных в результате обследования.
Кроме того, данные обследования содержат сведения, необходимые для разработки комплексной транспортной схемы и могут быть использованы при решении ряда планово - экономических и инженерных задач в области перспектив транспортного и городского строительства.
- выявление типов, а соответственно причин сходов единицы транспорта по участкам трассы как по одному маршруту, так и по всем маршрутам;
- подсчет количества сходов в будние, выходные дни, а также расчет среднемесячного количества затрат на восстановление всех функций транспорта;
- выявление данных о сотрудниках осуществляющих перевозки пассажиров;
- подсчет количества по группировкам причин сходов за день, месяц, год как по одной единице транспорта, так и по всем.
Обследование осуществляется следующим образом: на территории въезда в автопарк находится механик, который регистрирует время вошедших и вышедших единиц подвижного состава на каждый день, по каждому индивидуальному гаражному номеру, занеся данные в специальные бланки, на которых указано плановое время отправления и прибытия машины, гаражный номер, данные о водителе и т.д. В случае если транспорт выезжает позже планового времени из автопарка или въезжает в него также позднее времени по графику, формируется заявка на данную единицу состава с указанием типа и причины неисправности, а также номером и датой заявки. Собранные за день обследования материалы в дальнейшем обрабатываются вычислительным центром предприятия.
Информация о количестве сошедших с маршрута автомашин, необходима для передачи данных в соответствующие государственные органы с целью возмещения затрат на ремонт.
Полученные данные о количестве сходов, времени поездки, количестве рейсов заносятся в базу данных. Это дает возможность получить следующие данные:
- общее количество сходов за день, месяц, год по видам транспорта и по каждому маршруту;
- основные эксплуатационные показатели работы маршрутов;
- наиболее часто встречаемые неисправности каждой единицы транспорта по каждому гаражному номеру и в целом по транспортной сети и т.д.
Целью данной курсовой работы является разработка информационной системы, учета сходов подвижного состава городского автотранспорта на примере предприятия РМПАТП-6.
Задачами курсовой работы являются, создание программного обеспечения (ПО), которое автоматизировала процесс учета сходов городского автотранспорта на примере предприятия РМПАТП-6. Для создания данной программы необходимо выполнить следующие задачи:
- выполнение сбора, спецификации и аттестации требований;
- выполнение проектирования базы данных;
- выполнение проектирования программного продукта;
- разработать информационную систему (ИС);
- тестирование блока формирование отчета;
- выполнить развёртывание программного продукта (ПП);
- обучить пользователей работе с программным продуктом.
1. Разработка требований к программному обеспечению
Анализируя существующие решения по автоматизации предметной области в организации, выявлен тот факт, что в организации не существует подобной системы учета сходов подвижного состава, как и не существует в СУБД FoxPro, которую используют в РМПАТП-6 для работы со справочниками, входными и выходными документами.
На данный момент не существует подобных систем для решения поставленных задач по автоматизации.
В настоящее время информационная система предприятия, реализована в среде FoxPro, функционирующей под оболочкой DOS, с помощью которой ведется обработка данных. Учет сходов автотранспорта в данный момент на предприятии не автоматизирован.
Основными недостатками данной системы (FoxPro) предприятия являются:
- отсутствие удобочитаемости и правильности оформления отчетов по сходам;
- расчеты производятся с использованием устаревшего программного обеспечения (FoxPro);
- процесс работы с данной информационной системой является трудоемким, что в свою очередь обеспечивает превышение трудозатрат.
Для устранения недостатков в информационной системе предприятия было предложено разработать новую информационную систему. Новая система будет основана на использовании базы данных MS Access, обращение к базе данных будет осуществляться с использованием SQL - запросов, в дальнейшем предполагается переход на SQL-server c использованием интерфейса MS Access. Использование новой информационной системы облегчит процесс работы, создания отчетов. Интерфейс системы будет обновлен для работы под семейства операционных систем Win32 (Windows XP и т. п.). Также, новая информационная система должна обеспечить больший уровень защиты, т.к. данная система не на должном уровне обеспечивает защищённость данных.
Одна из задач предприятия - это вести учет сходов подвижного состава. Поэтому для решения этой проблемы необходимо автоматизировать процесс обработки результатов обследования транспортного потока предприятия, что приведет к сокращению времени на формирование необходимых документов и отчетов.
Анализ предметной области, является одним из важнейших этапов проекта, определяющим организацию работ на РМПАТП-6, целью которого является выявление, классификация и формализация информации обо всех аспектах предметной области, влияющих на конечный результат.
Ростовское Муниципальное пассажирское автотранспортное предприятие №6 (РМ ПАТП-6) является филиалом Муниципального унитарного предприятия «Муниципальная Транспортная Компания «Ростовпассжиртранс» (МУП «МТК «Ростовпассажиртранс») и выполняет часть его производственных функций.
Организационная структура компании изображена в соответствии с рисунком 1.
Рис.1 - Организационная структура предприятия РМ ПТАП№6
Основными направлениями деятельности филиала являются:
- оказание услуг по обеспечению бесперебойного движения электрического и автомобильного транспорта, улучшение транспортного обслуживания пассажиров;
- рациональное использование трудовых и материальных ресурсов;
- содержание и текущий ремонт подвижного состава, зданий, сооружений, механизмов находящихся на балансе;
- организация всех видов деятельности, необходимых для нормальной деятельности как МТК в целом, так и филиала в частности, не запрещенных законодательством РФ и Уставом МТК;
- поддержание в технически исправном состоянии подвижного состава, оборудования, согласно техническим правилам.
Работа служб нацелена на планирование, учет, контроль, анализ перевозок.
Важнейшим фактором формирования передвижений в городе является структура единой транспортной сети. Эта структура определяется видами используемого в городе транспорта и может быть охарактеризована составляющими ее транспортными сетями. Различают в основном три вида городского транспорта: пассажирский, грузовой и специальный. Пассажирский транспорт составляют муниципальный транспорт, коммерческий и личный индивидуального пользования.
В состав предприятия входят следующие отделы:
· Общее руководство (директор, зам.директора по перевозкам, главный инженер);
· Производственно-техническая служба (ПТС);
· Отдел технического контроля (ОТК);
· Производственно-технический отдел (ПТО);
· Материально-техническое снабжение (МТС);
· Отдел бухгалтерского учета и отчетности (ОБУ и О);
· Планово-экономический отдел (ПЭО);
· Отдел информатики и вычислительной техники
Анализируя существующие решения по автоматизации предметной области в организации, выявлен тот факт, что на данный момент в организации не существует подобной системы учета сходов подвижного состава, как и не существует в системной оболочке FoxPro, которую используют для работы со справочниками, входными и выходными документами в РМПАТП-6.
Содержание и форма представления результатов формирования требований к АИС определяются потребностями последующих этапов жизненного цикла ее создания, которые, в свою очередь, зависят от внешних условий проекта, а также от предполагаемых к применению методологий, технологий и инструментов. Однако различия в современных методах не касаются некоторых общих положений.
Должен быть разработан комплекс моделей предметной области, подлежащей автоматизации (т. е. моделей «как надо»). Этот комплекс моделей представляет собой совокупность диаграмм, выполненных в какой-либо нотации; структурированных спецификаций, описывающих элементы модели (например, процессы и структуры данных при использовании методов структурного подхода), а также перечень нормативных и операционных документов предметной области, являющихся первоисточником информации, представленной в диаграммах и спецификациях.
Степень подробности результатов должна быть достаточной для выполнения следующего этапа работ (как правило, общесистемное проектирование) в соответствии с выбранным подходом. Кроме того, степень подробности моделей должна быть достаточной для планирования всего проекта.
Классическая схема анализа изображена на рисунке 1.1.
Рисунок 1.1 - Классическая схема анализа предметной области
Функциональной модель «как есть» позволяет собрать и представить в формализованном виде информацию о существующем состоянии предметной области, после чего должно последовать переосмысление состава и технологии бизнес-процессов с учетом разработки комплексной АИС, что приводит к построению модели «как надо». Когда функциональная модель «как надо» построена и все структуры данных собраны, производится построение концептуальной модели данных.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0. В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной, функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая функциональная ориентация является принципиальной т.к. функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Основу методологии IDEF0 составляет графический язык описания бизнес процессов. Модель IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ новых бизнес-процессов и степени изменения существующей структуры организации деятельности. Анализ недостатков начинают с построения модели AS-IS (как есть), т.е. модели существующей организации работы. Модель AS-IS может строиться на основе изучения документации (положений о предприятии, должностных инструкций, приказов, отчетов и т.п.), анкетирования и опроса или других источников. Полученная модель AS-IS служит для выявления неуправляемых работ, работ необеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности организации.
Процессы, протекающие в организации можно представить в виде диаграмм IDEF0 (рисунок 1.2).
Рисунок 1.2 - Процесс деятельности организации
Управлением транспорта Ростова-на-Дону и рядом других городских организаций постоянно решаются вопросы обслуживания населения города.
Весь круг вопросов рассматривается в рамках пяти основных последовательно решаемых задач:
- организация транспортной системы;
- планирование пассажирских перевозок и работы подвижного состава;
- управление движением пассажирского транспорта;
- расчет производственной программы технического обслуживания парка машин;
- учет работы подвижного и водительского состава.
Состоит в составлении рациональных маршрутных схем обслуживания населения.
Планирование пассажирских перевозок и работы подвижного состава
Единым документом, планом, отражающим, с одной стороны потребности в пассажирских перевозках и с другой стороны эксплуатационные возможности РМПАТП-6, являются маршрутные расписания движения.
Управление движением пассажирского транспорта
Работа маршрутизированных видов пассажирского транспорта на улицах города подчиняется правилам дорожного движения, контролируется и управляется сотрудниками автоинспекции, находящимися в контакте с диспетчерской службой, службой безопасности движения РМПАТП. Отсюда задачи диспетчерской службы:
- организация выпуска машин из парка на маршрут и приемки их с линии;
- постоянная регистрация количества и качества выполнения рейсов каждой подвижной единицей, работающей на линии;
- оперативная организация работы аварийных средств - линейная техпомощь подвижному составу;
- оперативная организация изменения режима движения в случае неблагоприятных погодных условий, обслуживание спортивных и культурно массовых мероприятий.
Расчет производственной программы технического обслуживания парка машин
Для расчета производственной программы технического обслуживания исходными данными служат:
- производственная программа эксплуатации парка автомобилей;
- принимаемая прогрессивная система и методы технического обслуживания и ремонта подвижного состава;
- установление нормы пробега подвижного состава до проведения отдельных видов технического обслуживания, ремонтов, а так же нормативы трудоемкости работ, применительно к условиям эксплуатации.
Учет работы подвижного и водительского состава
Для решения задач учета применяются персональные компьютеры. На них составляются диспетчерские наряды, учет внутрисменных, целодневных простоев, учет работы водителя на линии, участие в ремонте.
Структурированное программирование было основной концепцией с первых дней разработки программного обеспечения. Стандартные блоки кода создавались для типичных операций, а затем копировались в другие приложения. Это сокращало сроки разработки новых программ, но затрудняло внесение изменений, поскольку необходимо было редактировать все вставленные стандартные блоки /18/. На основе структурированного программирования сформировалась концепция объектно-ориентированного программирования.
С помощью объектно-ориентированного подхода создаются блоки кода, или объекты. Объекты могут использоваться в разных приложениях. Для изменения объекта достаточно выполнить редактирование.
По сути, все современные приложения являются объектно-ориентированными, а некоторые языки программирования предполагают использование объектно-ориентированных структур. Объектно-ориентированный подход представляет собой другой метод просмотра приложений. Все приложения делятся на небольшие элементы кода - объекты, относительно независимые друг от друга.
В структурированном программировании требуется больше усилий для создания законченных приложений.
При объектно-ориентированном подходе особое внимание уделяется как информации, так и поведению, что позволяет создавать гибкие системы, допускающие изменение их поведения или содержащейся в них информации.
В соответствии с традиционным подходом основное внимание должно уделяться информации, с которой работает система. В зависимости от того, какая информация нужна пользователям, проектируются базы данных для хранения этой информации, создаются экраны для ее вывода и встраивается возможность распечатки отчетов. Иначе говоря, прежде всего, необходимо сфокусировать внимание на самой информации, а к поведению системы можно обратиться позже. Такой подход называется ориентированным на данные.
Структурный подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй», иерархическая декомпозиция и другие, по отношению к проектированию сложной программной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем. Понятие «правильная» по отношению к декомпозиции означает следующее:
- количество связей между отдельными подсистемами должно быть минимальным;
- связность отдельных частей внутри каждой подсистемы должна быть максимальной.
Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки:
- каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
- каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
Итак, сущность структурного подхода к разработке ПО заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх», от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.
Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов:
- принцип иерархического упорядочения - принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
В структурном подходе в основном две группы средств, описывающих функциональную структуру системы и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди них являются:
DFD (Data Flow Diagrams) - диаграммы потоков данных;
SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы;
ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».
На стадии проектирования DFD используются для описания структуры проектируемой системы/16/.
Перечисленные модели в совокупности дают полное описание ПО независимо от того, является ли система существующей или вновь разрабатываемой.
Для проектирования разрабатываемой системы был выбран структурный подход.
Перед началом разработки ИС необходимо определить состав документов. На этапе сбора требований подготавливается подборка существующих в организации документов (входных, выходных) на основании которых разрабатывается ИС, для этого были выполнены следующие шаги /1, 18, 33/:
- собраны образцы бланков существующих в организации нормативно-справочных документов (НСИ);
- собраны образцы бланков существующих в организации входных документов;
- собраны образцы бланков существующих в организации выходных документов;
- собраны образцы заполнения существующих в организации (НСИ);
- собраны образцы заполнения существующих в организации входных документов;
- собраны образцы заполнения существующих в организации выходных документов.
Заполненные образцы бланков нормативно-справочных документов (НСИ) и выходные документы (приложение Д, рисунки Д.1-Д.13).
Самое главное в любой рабочей деятельности - это «Сбор требований» т.к. если разработчик будет знать то, что от него хотят чтобы он сделал, то и конечный результат будет удовлетворять обеих сторон. Максимально упрощенный и удобный процесс работы, сопровожденный минимизацией временных трудозатрат и наличие продуктивного результата, повысит работоспособность и результативность.
Этап анализа и моделирования требований начинается с метода анализа оптимальной организации работ - стандарт IDEF0 - (TO BE). Диаграмма IDEF0 - (TO BE) строится на основе диаграммы IDEF0 - (AS IS) /3, 4, 10/ . Контекстная диаграмма IDEF0 - (TO BE) представлена на рисунке 1.4.
Рисунок 1.4 - Контекстная диаграмма IDEF0 процесса деятельности Организации
Детализация процессов (TO-BE) представлена в приложении А, на рисунках А.1-А.9.
На рисунке 1.5 представлена диаграмма первого уровня декомпозиции процесса деятельности организации (IDEF0). Она используется для детализации бизнес-процессов деятельности организации /21, 24/.
Рисунок 1.5- Диаграмма первого уровня декомпозиции процесса деятельности организации (IDEF0)
До начала разработки информационной системы необходимо определить состав документов. Для этого был проведен анализ, стандартизация, унификация подборки существующих в организации документов. Все документы были увязаны в единую унифицированную систему документов.
Требования к системе разбиваются на две самостоятельные группы - требования к функциям и нефункциональные требования. Основой выявления требований первой группы является модель бизнес-процессов предприятия, на базе которой, собственно, и формируется иерархия требований. К числу нефункциональных требований относятся:
- правовые и законодательные требования;
- качественные характеристики создаваемой системы, включая требования к ее практичности, надежности, производительности и возможностям поддержки;
- другие требования, например касающиеся операционных систем и сред, совместимости и проектных ограничений.
На основании выявленных требований разрабатывается техническое задание (ТЗ) на создаваемую систему и, по необходимости, частные технические задания на ее компоненты (подсистемы). ТЗ создается на основе ГОСТ 34.602-89. ТЗ на создание автоматизированной системы включает следующие основные разделы:
- характеристика объекта автоматизации;
- состав и содержание работ по созданию системы;
- порядок контроля и приемки системы;
- требования к составу и содержанию работ по подготовке предприятия к вводу системы в действие.
Раздел «Общие сведения» содержит справочную информацию, в том числе полное наименование системы, ее условное обозначение, название предприятий разработчика и заказчика (пользователя) системы и их реквизиты, перечень документов, на основании которых создается система, плановые сроки начала и окончания работы по созданию системы, сведения об источниках и порядке финансирования работ.
В разделе «Характеристика объекта автоматизации» проводятся общие сведения о предприятии согласно его уставу, перечень основных видов деятельности и бизнес-процессов.
В следующих разделах ТЗ приводятся сведения об объекте автоматизации, требования к системе в целом, также к ее функциональной и обеспечивающей части.
При формировании требований к системе в целом указывается перечень и основные характеристики подсистем, требования к взаимосвязям и совместимости созданной системы со смежными системами, требования к режиму функционирования АИС, к ее надежности и безопасности, описание стандартизации системы и ее унификации.
Аттестация требований - процесс проверки требований на достоверность, непротиворечивость, полноту и выполнимость. Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, т. к. ошибка в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения её в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечёт за собой значительные изменения в системе, после внесения, которых она должна пройти повторное тестирование.
Во время процесса аттестации должны быть выполнены различные типы проверок документации требований:
- проверка правильности требований;
Системы, предназначены для разных пользователей с различными потребностями, и поэтому набор требований будет равными для всех пользователей системы. Однако дальнейшие размышления и анализ могут привести к необходимости введения дополнительных или новых функций.
Это означает, что в требованиях не должно быть противоречащих друг другу ограничений и различных описаний одной и той же системной функции.
Должна содержать требования, которые определяют все системные функции и ограничения, налагаемые на систему.
Существует ряд методов аттестации требований:
- автоматизированный анализ непротиворечивости.
Диаграмма потоков пользовательского интерфейса используется для изучения взаимосвязей между основными элементами пользовательского интерфейса.
Прототипы позволяют решать три основные задачи: прояснение и завершение процесса формулировки требований, исследование альтернативных решений и создание конечного продукта.
Прототип показывает внешний вид экранов пользовательского интерфейса и позволяет осуществлять частичную навигацию между ними. Он позволяет пользователям исследовать поведение предполагаемой системы в тех или иных ситуациях для уточнения требований, а также выяснить, смогут ли они с помощью системы, основанной на прототипе, выполнять свою работу. Диаграмма потоков пользовательского интерфейса показана на рисунке 1.6.
Рисунок 1.6 - Диаграмма потоков пользовательского интерфейса
В данном разделе был проведен процесс анализа предметной области, собраны необходимые требования к разрабатываемой системе, осуществлено бизнес-моделирование процессов, выполнено специфицирование и аттестация требований к программному продукту, что позволило приступить к следующей стадии разработки, проектирование информационной системы.
2. Проектирование информационной системы
Одним из важнейших этапов разработки является архитектурное проектирование, которое заключается в сборе всех возможных пожеланий к работе системы, которые только могут прийти в голову пользователям и аналитикам. Позднее эти данные должны будут систематизированы и структурированы, но на данном этапе в ходе интервью с пользователями и изучения документов, аналитик должен собрать как можно больше требований к будущей системе, что не так просто, как кажется на первый взгляд. Пользователи часто сами не представляют, что они должны получить в конечном итоге.
На этапе тестирования ИС используется как локальное приложение.
На этапе эксплуатации ИС будет использоваться как многопользовательское приложение, существует несколько способов перехода системы на многопользовательский доступ.
Планируется в дальнейшем, переход работы приложений в организации на SQL, следовательно, можно перекинуть хранилища данных Access на SQL, а интерфейсы пользователя использовать в Access/12/.
Осуществить настройку Access на многопользовательский доступ, MS Access имеет такую функцию.
Архитектурное проектирование предполагает выбор архитектуры, на которой будет базироваться информационная система.
Для проектирования информационной системы применима клиент-серверная технология. Данная технология обеспечивает большую скорость вычислений, надёжность хранимых данных, легкость поддержки информационной системы.
Под клиент-серверным приложением мы будем понимать информационную систему, основанную на использовании серверов баз данных. Общее представление информационной системы в архитектуре «клиент-сервер» изображено на рисунке 2.1.
Со стороны клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс, выполняющий все вычисления, операции ввода/выводы, редактирования и сохранения данных.
На сторону SQL - сервер приходится только одна функция - это хранение введённых данных.
Рисунок 2.1 - Представление информационной системы в архитектуре «клиент-серверная»
Под сервером обычно понимают процесс, который обеспечивает функции по управлению базой данных и предоставляет необходимые ресурсы процессам-клиентам, посылающим запросы на соответствующий вид обслуживания. Задачей клиента является инициирование связи с сервером, определение вида запроса на обслуживание, получение от сервера записей из базы данных, подтверждение окончания обслуживания. Все вопросы, связанные с синхронизацией работы клиентов и управлением выделением им необходимых ресурсов при работе с базой данных, возлагаются на сервер.
Архитектура СУБД типа «клиент-сервер» дает возмож
Разработка автоматизированной информационной системы учета заявок на ремонт подвижного состава на примере предприятия РМ ПАТП-6 курсовая работа. Программирование, компьютеры и кибернетика.
Человек Становится Человеком Только Среди Людей Сочинение
Реферат: Nascar Winston Cup 99 Essay Research Paper
Контрольная работа по теме Настройка металлорежущего станка
Курсовая работа по теме Направленность, как социальное явление
Доклад по теме Світові геноциди
Эссе По Английскому Нужные Слова
Реферат по теме Конституция Японии
Курсовая работа по теме Фінансовий аналіз руху грошових коштів на підприємстві ТОВ "Автополюс"
Реферат: Социальный менеджмент как особый тип управления
Реферат Развитие Общественного Вещания В Великобритании
Реферат по теме Развитие личностных качеств руководителей как средство повышения эффективности управления педагогическим коллективом
Нравственный Выбор Сочинение Паустовский
Стилистические Фигуры Как Средства Речевой Выразительности Реферат
Реферат: «Использование информационных технологий в современном контент-анализе»
Когда Любовь Становится Испытанием Итоговое Сочинение
Реферат по теме Стратегическое управление в социальной сфере
Какие Бывают Стили Сочинения
Учебное пособие: Методи оцінки потенціалу підприємства
Итоговая Контрольная Работа По Географии 8 Ответы
Реферат Профессиональная Деятельность Педагога
Градостоительство и его влияние на преступность - Государство и право курсовая работа
Раздел совместно нажитого имущества - Государство и право курсовая работа
Геологическая работа ветра - Геология, гидрология и геодезия курсовая работа