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

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

Разработка и внедрение информационной системы «Автовокзал»

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

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

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

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

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

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

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

Выводы к разделу

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

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

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

3. РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

3.2 Взаимодействие приложения с источниками данных

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

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

Выводы к разделу

4. УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМ ПРОЕКТОМ

4.1 Выбор жизненного цикла разработки программного обеспечения

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

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

4.4 Идентификация ресурсов проекта

4.5 Оценка длительности разработки программного обеспечения

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

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

4.8 Оценка стоимости разработки программного обеспечения

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

Выводы к разделу

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ Б - ПРОТОТИПЫ ИНТЕРФЕЙСА

ПРИЛОЖЕНИЕ В - СТРУКТУРНЫЕ КАРТЫ КОНСТАНТАЙНА

ПРИЛОЖЕНИЕ Г - ТАБЛИЦЫ ТЕСТОВЫХ ДАННЫХ

ПРИЛОЖЕНИЕ Д - ПРОГРАММНЫЙ КОД МЕТОДОВ И ФУНКЦИЙ 3

ВВЕДЕНИЕ

Данная дипломная работа посвящена разработке и внедрению модуля автоматизации сбора информации аналитически данных продажи билетов и работы компании в целом на примере ОАО «Автовокзал».

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

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

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

Являясь крупнейшим предприятием в сфере автоперевозок на юге России, ОАО «Автовокзал» имеет в своём составе 55 автовокзалов и автостанций, расположенных по всей Ростовской области. Ежегодно предприятие обслуживает более 6 миллионов пассажиров, из которых свыше 1 миллиона пользуются различными льготами.

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

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

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

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

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

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

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

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

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

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

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

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

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

Использование статистики продаж билетов в Интернет

Основная масса статистических данных приведена нам из Интернета. Точнее с сайтов занимающихся онлайн продажей билетов. По данным Интернет компании Romir Monitoring в первом квартале 2005 года услугами Интернет магазина воспользовалось лишь 11% жителей России. Но ежеквартально эта цифра растет, но достигнуть стопроцентной онлайн продажи не получиться.

Для ведения статистики практически все сайты используют модули языков программирования Интернет приложений. В основном используется язык PHP (Hypertext Preprocessor) - скриптовый язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных.

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

Автоматизированная система «Автовокзал91»

Компания «ВПИ» Firm «API» разработала специализированное программное обеспечение для автовокзалов городов Украины; Днепропетровске, Львове, Херсоне, Симферополе.

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

Система работает с 1991 года по настоящее время. Программный комплекс данной системы со временем усовершенствовался и модернизировался.

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

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

Автоматизированная система управления автовокзалом «Olven»

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

Система «Olven» построена по трехуровневой схеме «клиент-сервер» и состоит их системы управления базой данных (СУБД), сервера приложений и клиентской программы, реализующей в себе функциональность всех рабочих мест системы. Взаимодействие компонентов системы осуществляется по протоколу TCP/IP с использованием протокола XML. Сервер приложений представляет собой веб-сервер, с библиотекой необходимых программ, реализующих функциональность системы.

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

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

АИС продажа билетов

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

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

В настоящее время рассматриваемая на предприятии информационная система «Продажи билетов», реализована в среде FoxPro, функционирующей под оболочкой DOS 2.6 и сетевых ОС Novell Netware, как консольное приложение, с помощью которой ведется обработка данных - учет продажи и бронирования билетов.

Выбор Foxpro DOS 2.6 и сетевых ОС Novell Netware обусловлен в первую очередь минимизацией требований, предъявляемых к технике на рабочих местах. Количество одновременно работающих пользователей в сети ограничивается лишь версией Novell.

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

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

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

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

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

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

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

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

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

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

Акционерное общество «Автовокзал» являясь крупнейшим предприятием в сфере автоперевозок на юге России, ОАО «Автовокзал» имеет в своём составе 55 автовокзалов и автостанций, расположенных по всей Ростовской области. Об объёмах работы предприятия можно судить и по состоянию маршрутной сети.

Каждый день от перронов автовокзалов, принадлежащих объединению, отправляются более 1800 рейсов по 374 маршрутам. Основным направлением деятельности компании является перевозка пассажиров.

Пассажирские перевозки осуществляются как в города России, так и по территории других стран.

С автовокзалов предприятия прямым сообщением отправляются автобусы, следующие по маршрутам в города Германии, Болгарии, Украины, страны Закавказья и республики Северного Кавказа, в населённые пункты Краснодарского и Ставропольского краёв, Воронежской, Волгоградской и Астраханской областей.

Организационная структура компании изображена в соответствии с рисунком 1.1



Рисунок 1.1 - Организационная структура компании
OAO «Автовокзал»

Согласно уставу открытого акционерного общества «Автовокзал», зарегистрированным регистрационной палатой администрации города Ростова-на-Дону № 2091-РП от 06 октября 1993 года, общество осуществляет следующие виды деятельности:

- транспортно-экспедиционная деятельность;

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

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

- оказание сервисных услуг;

- организация общепита;

- рекламные услуги;

- гостиничные услуги;

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

- оказание услуг по техническому осмотру автотранспортных средств;

- оптово-розничная торговля;

- торговля горюче-смазочными материалами с открытием автозаправочных станций;

- оказание услуг по хранению, бытовых и иных услуг.

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

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

На этапе проведения анализа были сформулированы следующие задачи исследования системы:

- изучение пассажиропотока и спроса населения в пассажирских перевозках;

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

- контроль над исполнением графиков движения и диспетчерское сопровождение автобусов на маршрутах;

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

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

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

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

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

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

Выбор методологии проектирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- эргономичность пользовательского интерфейса;

- ввод и редактирование различных видов данных;

- надежное хранение информации;

- вывод конечных результатов в удобном и наглядном для пользователя виде;

- возможности сравнения, редактирования, сортировки;

- создание форм отчетности для печати бланков и результатов.

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

При обработке сформированных данных были составлены следующие виды отчетных документов, для предоставления статистики в АИС:

- сведения о работе АТП;

- показатели работы рейса;

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

- плановое задание по доходам;

- оперативные сведения;

- перевозка пассажиров;

- доходы от продаж билетов по месяцам;

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

- отчет о предварительной продаже билетов на формирующиеся и транзитные рейсы;

- отчет о льготном проезде;

- сведения о предоставлении льготного проезда в автобусах;

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

- станционное расписание движения автобусов;

- коэффициенты повышения тарифов на перевозку пассажиров за месяцы.

Результатом проектирования на данной стадии является разработка технико-экономического обоснования (ТЭО) необходимости создания дополнительного модуля «Анализ статистических данных продажи билетов» в соответствии с приложением А.

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

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

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

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

В процессе формирования требований принимали участие следующие лица:

* директор и заместитель директора по общим вопросам;

* разработчики информационной системы;

* сотрудники финансово - экономического отдела компании.

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

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

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

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

Самым удобным отражением моделирования бизнес-процессов является тип диаграмм IDEF0 (Integration Definition for Function Modeling). С точки зрения функциональности системы. В рамках методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой. Данный тип диаграммы отображает систему в целом, как комплексную совокупность функций системы.

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

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

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

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

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

Схематичное отображение в рамках методологии IDEF0 основной деятельности компании ОАО «Автовокзал» «Продажа билетов» изображено на рисунке 1.2.

Рисунок 1.2 - Продажа билетов

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

Пример декомпозиции контекстной работы показан на рисунке 1.3

Рисунок 1.3 - Декомпозиция «Продажа билетов»

На рисунке 1.4 изображена дальнейшая декомпозиция работы «Ведение справочников».



Рисунок 1.4 - Декомпозиция работы «Ведение справочников»

Рисунок 1.5 - Декомпозиция работы «Создание отчета»

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

Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

На рисунке 1.6 изображена схема документирования процесса получения отчетности.

Рисунок 1.6 - Схема документирования процесса получения отчетности, DFD диаграмма

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

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

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

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

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

Требования, описывающие общее ограничения системы.

Требования к представлению системы.

Для описания требований целесообразно использовать условные обозначения представленные в таблице 1.1.

Таблица 1.1- Условные обозначения требований

Обозначение	Описание
F	Функциональные требования, описывающие желательные функциональные возможности или вариант использования.
С	Требования, описывающие общее ограничения системы.
Р	Требования к представлению системы.

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

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

Таблица 1.2 - Функциональные требования к информационной системе

Название	Описание
F: Анализ загрузки рейсов	Подсистема должна автоматизировать функцию выбора данных из базы, формируемой автоматизированной системы «Продажа и бронирования билетов» для анализа загрузки рейсов автовокзала. Автоматизировать режимы получения аналитических данных, сведения о срывах и не заходах автобуса, анализ пассажиропотока, расчеты коэффициента использования вместимости автотранспорта по временному промежутку, проданных билетов, расчеты коэффициента использования вместимости автотранспорта по временному промежутку, проданных билетов, выручки, наполняемость автобусов в соответствии с заданным дизайном и технологией

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

Таблица 1.3 - Описание системных требований

Название	Описание
С: Архитектура	Программный комплекс должен быть реализован в соответствии с архитектурой «клиент - сервер». Система должна обеспечивать обработки информации с централизованным хранением данных. Основная функциональность информационной системы должна быть реализована на «клиенте». Взаимодействие «клиента» с «сервером» должно осуществляться посредством SQL- запросов.
С :Среда разработки	В качестве среды разработки приложения должна использоваться Microsoft Visual FoxPro 9.0.
С: Взаимодействие приложения с источником данных	Для взаимодействия приложения с базой данных должны использоваться стандартизированные технологии и интерфейс Open Database Connectivity (ODBC), удаленные представления используют для удаленных источников данных SQL синтаксис.
С :База данных	В качестве модели данных должна использоваться реляционная модель.

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

Таблица 1.4 - Описание требований к представлению

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

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

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

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

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

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

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

- проверка на выполнимость.

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

Диаграмма потоков пользовательского интерфейса представлена на рисунке 1.7.



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

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

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

Выводы к разделу

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

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

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

В процессе анализа требований был разработан комплекс моделей предметной области.

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

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

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

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

Архитектура клиент-сервер разделяет компоненты приложения и размещает их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

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

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

Компонент меню «Система» используется для настройки доступа к данным из различных систем управления базами данных. Например, при наличии программы, работающей с данными из базы данных SQL, компонент меню «Система» позволит использовать программу для доступа к данным в базе данных FoxPro. Компонент «Источник данных» используется для настройки приложений, чтобы обеспечить им доступ к данным из различных систем управления базами данных.

Для реализации программного модуля мною была выбрана технология Open DataBase Connectivity (открытая система связи с базами данных).

ODBC представляет собой набор динамических библиотек DLL, которые обслуживают подключение и работу с конкретным типом базы данных. При запросе на подключение к определенной, заранее описанной базе «активизируется» определенная DLL - драйвер этого типа БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 2.1 - Концептуальная модель базы данных

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



Рисунок 2.2 - Логическая модель базы данных

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



Рисунок 2.3 - Физическая модель базы данных

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

- анализ пассажиропотока (Analpass);

- анализ работы АТП (Atp_Anal)

- выручка за багаж (Bagaj_D)

- показатели работы рейса (Coef_CRT)

- срывы и незаходы автобусов (FailRejs)

- плановое задание по доходам (FuturDoh)

- перевозка пассажиров фактическая (LoadFact)

- периодичность рейсов (MinSched)

- положение по продажам (NegPass)

- справка о неприбытиях и опозданиях автобусов по АТП (NerpOATP)

- оперативные сведения (Oper_All)

- сведения о работе АТП по выполнению условий«Договора об организации и перевозки» (OrderAtp)

- расчет потребности кассовых ведомостей (OrderCnt)

- перевозка пассажиров дальнего следования (PassKmAV)

- доходы по месяцам от продаж (PlanDoh)

- анализ предварительной продажи билетов на формирующиеся рейсы (Pr_SalSv)

- отчет о предварительной продаже билетов на формирующиеся и транзитные рейсы (Pre_Sale)

- льготный проезд (Priv_All)

- сведения о предоставлении льготного проезда в автобусах по отдельным категориям лиц (Privileg)

- обслуживающее АТП (SoldTis1)

- сведения о продаже билетов, выручке и наполняемости автобусов (SoldTisk)

- станционное расписание движения автобусов (St_Sched)

- коэффициент повышения тарифов на перевозку пассажиров за месяцы (TarifRat)

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

Согласно требованиям к разрабатываемой системе, а так же согласно требованиям стороны заказчика, для создания разрабатываемой информационной системы анализа продажи проездных билетов на примере ОАО «Автовокзал» был выбран Microsoft Visual FoxPro 9.0.

Первоначальное название FoxPro - FoxBase. Данный продукт разработка компании Fox Software. Начало разработки данного продукта было положено еще в 1984 году. С течением времени в 1992 году компания Fox Software объединилась с компанией Microsoft и новые версии продукта обрели ряд новых функций а так же приставку «Visual». Последняя версия оригинального FoxPro - версия 2.6 - работала под Mac OS, DOS, Windows и Unix. Уже в версии Visual FoxPro 3.0 список поддерживаемых платформ сократился до Mac OS и Windows, а в более поздних версиях -- уже только до Windows.

Текущая версия Visual FoxPro основана на Component Object Model (COM), и Microsoft утверждает, что .NET-версии продукта не будет. COM - это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих распределённых компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт COM был разработан в 1993 году корпорацией Майкрософт как основа для развития технологии Object Linking and Embedding (OLE) - технология связывания и внедрения объектов в протокол.

Технология OLE уже позволяла создавать так называемые «составные документы». Например, в пакете Microsoft Office эта технология позволяла включать диаграммы Microsoft Excel в документы Microsoft Word. Стандарт же COM должен был унифицировать процесс создания, внедрения и связывания таких внедряемых объектов, а также стандартизировать разработку приложений, использующих внедряемые объекты.

Visual FoxPro это визуальная среда разработки систем управления реляционными базами данных, выпускаемая в настоящее время корпорацией Майкрософт. Последней версией продукта является Microsoft Visual FoxPro 9.0, данный продукт использует язык программирования FoxPro. Среда разработки версии 7.0 может работать в операционных системах Windows 9x и ядра NT, версии 8.0 и 9.0 -- только в Windows XP, 2000, 2003. Среда исполнения версий 8.0 и 9.0 работает под любой версией Windows, начиная с 98.