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

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

Классическая схема анализа изображена на рисунке 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/.

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

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

 

 

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

 

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

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

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

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

 

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

 

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

 

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

 

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

 

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

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