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

Содержание Введение Актуальность и место решаемой задачи информационного обеспечения в предметной области

Цели и задачи курсовой работы

1. Разработка требований к программному обеспечению

1.1 Анализ существующих решений по автоматизации предметной области

1.2 Анализ предметной области

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

1.4 Сбор требований

1.5 Анализ и моделирование требований

1.6 Спецификация требований

1.7 Аттестация требований Выводы

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

2.1 Архитектурное проектирование

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

2.3 Проектирование баз данных

2.3.1 Концептуальное проектирование БД

2.3.2 Разработка логической модели данных

2.3.3 Разработка физической модели данных

2.4 Обоснование выбора платформы создания информационной системы

2.5 Проектирование модулей Выводы по главе

3. Реализация и аттестация информационной системы

3.1 Реализация приложения

3.2 Взаимодействие приложения с источниками данных (технология доступа к данным, sql-запросы, хранимые процедуры)

3.3 Тестирование приложения

3.4 Методика развертывания приложения

Выводы по главе

4. Управление информационным проектом

4.1 Выбор жизненного цикла разработки ПО

4.2 Определение цели и области действия программного проекта

4.3 Создание структуры пооперационного перечня работ

4.4 Идентификация задач и действий

4.5 Оценка размера и возможности повторного использования ПО

4.6 Оценка длительности и стоимости разработки ПО

4.7 Распределение ресурсов проекта

4.8 Оценка экономической эффективности проекта

Выводы по главе Заключение Список сокращений СПИСОК ИСПОЛЬЗОВАННой литературы Приложение A

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

Ростовское Муниципальное пассажирское автотранспортное предприятие № 6 является филиалом Муниципального унитарного предприятия «Ростовпассажиртранс» и выполняет часть его производственных функций. Основным направлением деятельности филиала являются перевозка пассажиров.

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

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

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

Задачей обследования является:

- выявление типов, а соответственно причин сходов единицы транспорта по участкам трассы как по одному маршруту, так и по всем маршрутам;

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

— выявление данных о сотрудниках осуществляющих перевозки пассажиров;

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

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

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

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

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

— основные эксплуатационные показатели работы маршрутов;

— наиболее часто встречаемые неисправности каждой единицы транспорта по каждому гаражному номеру и в целом по транспортной сети и т. д.

Цели и задачи курсовой работы

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

Задачами курсовой работы являются, создание программного обеспечения (ПО), которое автоматизировала процесс учета сходов городского автотранспорта на примере предприятия РМПАТП-6. Для создания данной программы необходимо выполнить следующие задачи:

— выполнение сбора, спецификации и аттестации требований;

— выполнение проектирования базы данных;

— выполнение проектирования программного продукта;

— разработать информационную систему (ИС);

— тестирование блока формирование отчета;

— выполнить развёртывание программного продукта (ПП);

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

1. Разработка требований к программному обеспечению

1.1 Анализ существующих решений по автоматизации предметной области

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

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

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

Основными недостатками данной системы (FoxPro) предприятия являются:

— отсутствие удобочитаемости и правильности оформления отчетов по сходам;

— расчеты производятся с использованием устаревшего программного обеспечения (FoxPro);

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

Для устранения недостатков в информационной системе предприятия было предложено разработать новую информационную систему. Новая система будет основана на использовании базы данных MS Access, обращение к базе данных будет осуществляться с использованием SQL — запросов, в дальнейшем предполагается переход на SQL-server c использованием интерфейса MS Access. Использование новой информационной системы облегчит процесс работы, создания отчетов. Интерфейс системы будет обновлен для работы под семейства операционных систем Win32 (Windows XP и т. п.). Также, новая информационная система должна обеспечить больший уровень защиты, т.к. данная система не на должном уровне обеспечивает защищённость данных.

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

1.2 Анализ предметной области

Анализ предметной области, является одним из важнейших этапов проекта, определяющим организацию работ на РМПАТП-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, являются маршрутные расписания движения.

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

— организация выпуска машин из парка на маршрут и приемки их с линии;

— постоянная регистрация количества и качества выполнения рейсов каждой подвижной единицей, работающей на линии;

— оперативная организация работы аварийных средств — линейная техпомощь подвижному составу;

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

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

— производственная программа эксплуатации парка автомобилей;

— принимаемая прогрессивная система и методы технического обслуживания и ремонта подвижного состава;

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

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

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

Структурированное программирование было основной концепцией с первых дней разработки программного обеспечения. Стандартные блоки кода создавались для типичных операций, а затем копировались в другие приложения. Это сокращало сроки разработки новых программ, но затрудняло внесение изменений, поскольку необходимо было редактировать все вставленные стандартные блоки /18/. На основе структурированного программирования сформировалась концепция объектно-ориентированного программирования.

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

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

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

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

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

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

— количество связей между отдельными подсистемами должно быть минимальным;

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

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

— каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

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

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

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

— принцип «разделяй и властвуй»;

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

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

DFD (Data Flow Diagrams) — диаграммы потоков данных;

SADT (Structured Analysis and Design Technique — метод структурного анализа и проектирования) — модели и соответствующие функциональные диаграммы;

ERD (Entity — Relationship Diagrams) — диаграммы «сущность-связь».

На стадии проектирования DFD используются для описания структуры проектируемой системы/16/.

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

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

1.4 Сбор требований

Перед началом разработки ИС необходимо определить состав документов. На этапе сбора требований подготавливается подборка существующих в организации документов (входных, выходных) на основании которых разрабатывается ИС, для этого были выполнены следующие шаги /1, 18, 33/:

— собраны образцы бланков существующих в организации нормативно-справочных документов (НСИ);

— собраны образцы бланков существующих в организации входных документов;

— собраны образцы бланков существующих в организации выходных документов;

— собраны образцы заполнения существующих в организации (НСИ);

— собраны образцы заполнения существующих в организации входных документов;

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

Заполненные образцы бланков нормативно-справочных документов (НСИ) и выходные документы (приложение Д, рисунки Д.1-Д.13).

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

1.5 Анализ и моделирование требований

Этап анализа и моделирования требований начинается с метода анализа оптимальной организации работ — стандарт 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)

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

1.6 Спецификация требований

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

— правовые и законодательные требования;

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

— требования по безопасности;

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

На основании выявленных требований разрабатывается техническое задание (ТЗ) на создаваемую систему и, по необходимости, частные технические задания на ее компоненты (подсистемы). ТЗ создается на основе ГОСТ 34.602−89. ТЗ на создание автоматизированной системы включает следующие основные разделы:

— общие сведения;

— назначение и цели создания ИС;

— характеристика объекта автоматизации;

— требования к системе;

— состав и содержание работ по созданию системы;

— порядок контроля и приемки системы;

— требования к составу и содержанию работ по подготовке предприятия к вводу системы в действие.

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

В разделе «Характеристика объекта автоматизации» проводятся общие сведения о предприятии согласно его уставу, перечень основных видов деятельности и бизнес-процессов.

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

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

1.7 Аттестация требований

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

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

— проверка правильности требований;

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

— проверка на непротиворечивость;

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

— проверка на полноту;

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

— проверка на выполнимость;

Существует ряд методов аттестации требований:

— обзор требований;

— прототипирование;

— генерация тестовых сценариев;

— автоматизированный анализ непротиворечивости.

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

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

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

Рисунок 1.6 — Диаграмма потоков пользовательского интерфейса

Выводы

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

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

2.1 Архитектурное проектирование

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

На этапе тестирования ИС используется как локальное приложение.

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

Планируется в дальнейшем, переход работы приложений в организации на SQL, следовательно, можно перекинуть хранилища данных Access на SQL, а интерфейсы пользователя использовать в Access/12/.

Осуществить настройку Access на многопользовательский доступ, MS Access имеет такую функцию.

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

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

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

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

На сторону SQL — сервер приходится только одна функция — это хранение введённых данных.

Рисунок 2.1 — Представление информационной системы в архитектуре «клиент-серверная»

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

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

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

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

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

При проектировании прототипов пользовательского интерфейса была использована СУБД Access.

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

В состав любой СУБД входят языки двух типов:

— язык описания данных (с его помощью описываются типы данных, их структура и связи);

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

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

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

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

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

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

Прототип пользовательского интерфейса верхнего уровня можно посмотреть ниже на рисунке 2.2.

Рисунок 2.2 — прототип пользовательского интерфейса верхнего уровня Прототип пользовательского интерфейса нижнего уровня можно посмотреть ниже на рисунке 2.3.

Рисунок 2.3 — прототип пользовательского интерфейса нижнего уровня

2.3 Проектирование баз данных

2.3.1 Концептуальное проектирование БД

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

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

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

Концептуальная модель данных представлена на рисунке 2.4.

Рисунок 2.4 — Концептуальная модель.

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

2.3.2 Разработка логической модели данных

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

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

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

Рисунок 2.5 — Логическая модель После создания полной и адекватной логической модели можно переходить к созданию физической модели базы данных.

2.3.3 Разработка физической модели данных

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

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

Рисунок 2.6 — Физическая модель На рисунке 2.7 ниже отображена схема данных БД.

Рисунок 2.7 — Схема данных

2.4 Обоснование выбора платформы создания информационной системы

В качестве операционной среды при реализации АИС будет использоваться операционная оболочка Microsoft Windows XP, так как это наиболее распространенная и приспособленная для пользователя среда, с дружественным пользовательским интерфейсом. Операционная среда Microsoft Windows XP является многозадачной, высокопроизводительной. Это интегрированная среда, которая обеспечивает эффективный обмен текстовой, графической и видеоинформацией между отдельными программами.

В качестве системы разработки будет использоваться среда MS Access 2003, SQL-server. Выбор данной среды обусловлен следующими причинами:

1. Данная среда является ведущей средой быстрой разработки приложений на рынке благодаря следующим особенностям:

— визуальная среда разработки;

— полное использование возможностей среды WINDOWS.

2. Наибольший опыт разработчика работы именно в этой среде.

3. Пожелание заказчика (в перспективе возможна доработка этого приложения силами других разработчиков).

Минимальными требования, предъявляемые MS Access 2003 к ПК — это Intel-совместимая платформа ПК, процессор от Intel Pentium 3 и выше, ОЗУ 256 MB, OS MS XP.

Исполняемый файл БД «АТП.mdb» во время работы может менять свой размер даже в том случае, если данные не изменялись. Это обусловлено внутренней организацией и логикой работы MS Access. Увеличение размера файла может быть вызвано тем, что СУБД может создавать временные объекты (таблицы, запросы) внутри собственно БД и исполняемых модулей, а также кэшировать результаты запросов к данным.

2.5 Проектирование модулей

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

Программные модули системы:

— модуль «ввода данных»;

— модуль «редактирования ввода данных»;

— модуль «справочники»;

— модуль «редактирования справочников»;

— модуль «пароль»;

— модуль «администрирование»;

— модуль «просмотра отчетов»

— CloseForm.

Модуль «CloseForm» позволяет при закрытии формы главного меню закрывать его в оригинальном виде.

Выводы по главе

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

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

3. Реализация и аттестация информационной системы

3.1 Реализация приложения

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

Формы представляют собой интерфейсы или диалоговые окна, в которых происходит работа с вводом, редактированием информации.

Для обеспечения защиты от несанкционированного доступа к информации, связанной с учетом заявок на ремонт предусмотрена система паролей (рисунок 3.1) при загрузке ИС, если пароль верный, то пользователь допускается к работе с АИС.

Рисунок 3.1 — Окно входа в ИС Ниже представлена форма разработанного приложения, отображающая кнопки, поля, вводимые данные. При разработке пользовательского интерфейса, было создано меню в виде кнопочной формы. Ниже изображен разработанный интерфейс главной формы (рисунок 3.2), программный код VBA (приложение Б, рисунок Б.1). В главной форме расположены основные кнопки для работы с ИС, которые представляют собой переходы на формы справочников, ввода данных, отчетов, администрирования.

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

Рисунок 3.2 — Главная форма Рисунок 3.3 — Форма справочники На следующем рисунке 3.4 изображена форма авторизации пользователя, для входа под своими идентификационными данными.

Рисунок 3.4 — Форма авторизации После авторизации, автоматически происходит переходит на форму ввода данных в виде полей для заполнения данных и кнопок, для работы непосредственно по нарядам подвижного состава, представленную на рисунке 3.4, (программный код VBA (приложении Б, рисунок Б.2).)

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

Рисунок 3.4 — Форма ввода данных На следующем рисунке 3.5 представлена форма для просмотра отчетности по сходам автомашин парка предприятия.

Рисунок 3.5 — форма просмотра отчетности по автомашинам На рисунке 3.6 представлена форма для ввода, редактирования данных по ремонту единицы подвижного состава по выбранному наряду («Листок учета»).

Рисунок 3.6 — форма «Листок учета»

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

Рисунок 3.7 — форма создания отчетов На следующем рисунке 3.8 изображено окно на вход формы защиты БД.

Рисунок 3.8 — форма защиты БД.

Формы нормативно-справочной информации изображены на рисунках Е.1-Е.5 в приложении Е. Выходные документы изображены на рисунках Д.1-Д.13 в приложении Д.

3.2 Взаимодействие приложения с источниками данных (технология доступа к данным, sql-запросы, хранимые процедуры)

Для того чтобы пользователь ИС мог использовать информацию хранящуюся в базе данных СУБД Microsoft SQL Server 2003, необходимо выбрать и реализовать технологию доступа к базе данных. Основной технологией доступа к данным, выступают sql-запросы (приложение Г, рисунки Г.1-Г.15). На рисунке 3.9 показан sql-запрос, отображающий существующие на выбранную дату наряды автопарка на форме.

Рисунок 3.9 — Пример sql-запроса На следующем рисунке 3.10 отображен sql-запрос, осуществляющий выборку и группировку сформированных листов учета по гаражному номеру.

Рисунок 3.10 — Пример sql-запроса Хранимые данные записаны в таблицах среды разработки ИС.

Таблица «Механик ОТК» хранит информацию, которая включает в себя: ИД гаражного номера, время выезда, заезда автомашины, ее гаражный номер, дату выписки и закрытия ремонта, а также причины схода, все данные таблицы являются реквизитами автомашин при обследовании, рисунок 3.11.

Рисунок 3.11 — Таблица «Механик ОТК»

Таблица «Лист учета» изображенная на рисунке 3.12 хранит информацию о количестве начисленных технических обслуживаний по всем гаражным номерам.

Рисунок 3.12 — Таблица «Лист учета»

Остальные таблицы с данными ИС в приложении Г, рисунках Г.16-Г.21.

3.3 Тестирование приложения

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

Тестирование — процесс выполнения программы или части программы, с намерением или целью найти ошибки;

Контроль — попытка найти ошибки в тестовой, или моделируемой среде;

Испытание — попытка найти ошибки, выполняя программу в заданной реальной среде;

Аттестация — авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом;

Отладка не является разновидностью тестирования. Хотя «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки.

Испытания программного продукта производятся с использованием следующей справочной литературы:

ГОСТ Р28 195−89 Оценка качества программных средств.

ISO/IEC 9126: 1991 Information Technology Software Product Quality Characteristics.

Стандарты разработки ПО ESA PSS-05−0-1991.

Тестирование ИС осуществлялась на основе тестового примера методом черного ящика (приложение К). Тестирование методом «Черного ящика» предполагает обработку системы как «непрозрачного объекта», таким образом, знание внутренней структуры в явном виде не используется. Тестирование этим методом обычно подразумевает проверку функциональных возможностей. Синонимами понятия метода «Черного ящика» являются: поведенческое тестирование, функциональное тестирование, метод непрозрачного ящика, метод закрытого ящика. При тестировании программного обеспечения методом «Черного ящика» тестировщик знает только набор вводимых параметров и ожидаемые на выходе результаты, каким образом программа достигает этих результатов ему неизвестно. Тестировщик никогда не проверяет программный код и не нуждается в дополнительном знании программы кроме как в ее техническом описании. Были заданы тестируемые функции комплекса, желаемые результаты и результаты после тестирования /28/.

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

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

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

Проверен текст на её чувствительность к отдельным особым значениям входных данных и были добавлены соответствующие тесты.

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

Комплексное тестирование — процесс поисков несоответствия системы ее исходным целям. Это наиболее творческий из всех видов тестирования. Оно состоит из следующих шагов:

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

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

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

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