Санкт-Петербургский  Гуманитарный университет профсоюзов

Кафедра информатики  
 
 
 

КУРСОВАЯ  РАБОТА

по дисциплине

«ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ»

на тему:

«Моделирование бизнес-процессов в информационной системе  
высшего учебного заведения»  

Выполнила

     студентка 3 курса

     экономического факультета,  
ПИ в экономике

     Исакова Е.К. 

Научный руководитель

доцент кафедры

информатики и математики, к.т.н.

Путькина  Л.В. 
 

     Дата защиты ________________

Оценка _____________________

____________________________

(подпись руководителя)   

Санкт-Петербург

2009

Содержание

Введение

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

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

     В настоящее время ведутся масштабные разработки компонентов единого  образовательного информационного пространства, выполняемые в рамках федеральных целевых программ «Развитие единой образовательной информационной среды», «Электронная Россия», проектов Национального фонда подготовки кадров, а также научных программ Министерства образования и науки РФ. Все они сопровождаются обеспечением правовой и нормативно-технической базы (стандарты министерства образования и науки, регламенты, рекомендации), гармонизированным с требованиями национальных (ГОСТ Р) и международных (ИСО, МЭК) стандартов и обеспечивающей создание информационной продукции конкурентоспособного качества.

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

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

Раздел 1. Постановка задачи разработки информационной системы

1.1. Задание на разработку информационной системы

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

1.2. Характеристика объекта управления

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

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

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

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

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

1.3. Структура информационной системы

     Данная  информационная система состоит  из следующих объектов: вуз, в котором  происходит подготовка специалистов различных  направлений; специальности, на которых учатся студенты, делятся по факультетам и кафедрам; дисциплины, которые изучают студенты во время обучения в вузе (рис.1). 

Рис.1 Структура информационной системы

Раздел 2. Функциональная модель  
бизнес-процесса

2.1. Моделирование в  IDEF0

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

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

 
Рис.2 Нотация IDEF0 «Обучение студента»

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

     Модель  содержит четыре типа диаграмм:

• контекстную  диаграмму;

• диаграммы декомпозиции (для каждого объекта диаграммы может быть только одна декомпозиция);

• диаграмма  дерева узлов;

• диаграммы  только для экспозиции (FEO).

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

 
Рис.3 Декомпозиция нотации IDEF0 «Обучение студента»

2.2. Расчет оценки функциональной модели

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

     При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. В диалоге Activity Properties на вкладке Cost указывается частота проведения данной работы в рамках общего процесса (Frequency) и продолжительность (Duration). Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются (рис.4). Этот достаточно упрощенный принцип подсчета справедлив, если работы выполняются последовательно. Встроенные возможности BPwin позволяют разрабатывать упрощенные модели стоимости, которые тем не менее оказываются чрезвычайно полезными при предварительной оценке затрат.

 
Рис.4 Задание стоимости работ в диалоге Activity Cost диаграммы «Обучение студента»

     Результаты  стоимостного анализа наглядно представляются на специальном отчете BPwin - Activity Cost Report (рис.5).

 
Рис.5 Отчет для диаграммы «Обучение  студента» 

2.3. Node Tree

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

 
Рис.6 Фрагмент диаграммы дерева узлов

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

2.4. Моделирование FEO-Diagram

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

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

 
Рис.7 Нотация FEO «Проведение лекционных и практических занятий»

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

2.5. Моделирование в DFD

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

     В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой (рис.8).

 
Рис.8 Нотация DFD «Написание студентами работ для контроля знаний»

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

2.6. Моделирование в IDEF3

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

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

     IDEF3 может быть также использован  как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все  необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа (рис.9).

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

 
Рис.9 Нотация IDF3 «Проведение итогового контроля»

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

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

 
Рис.10 Декомпозиция нотации «Проведение итогового контроля» IDF3-Scenario Diagram «Проведение экзамена»

2.7. Swim Lane моделирование

     Диаграммы нового типа - Swim Lane, использующие методологию Process Flow Network и могут быть добавлены  в модель, содержащую диаграммы IDEF3 (рис.11). Диаграммы Swim Lane иллюстрируют несколько параллельных потоков, что позволяет отобразить процесс вместе с зависящими от него процессами как параллельные потоки на одной диаграмме. Кроме того, на диаграммах Swim Lane можно указать роли исполнителей работ, тем самым более качественно задокументировать роли и ответственности. Swim Lane диаграммы можно добавлять к любой модели в BPwin для более наглядного изображения течения процесса. Эти диаграммы используют методологию IDEF3 и показывают горизонтальные полосы, которые представляют участие в процессе ролей.

 
Рис.11 «Swim Lane Diagram»

2.8. Organization Charts

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

 
Рис.12 Фрагмент диаграммы «Organization Chart»

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

 
Рис.13 Определение группы ролей 

 
Рис.14 Определение ролей в Role Dictionary (фрагмент) 

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

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

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

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

3.1. Логическая модель данных в 3НФ из ERWin

     ERWin облегчает проектирование баз данных. Для этого достаточно создать графическую E-R модель (объект-отношение), удовлетворяющую всем требованиям к данным и ввести бизнес-правила для создания логической модели, которая отображает все элементы, атрибуты, отношения и группировки. Для расширения возможностей ERWin можно воспользова уникальной поддержкой пользовательских свойств для ввода в модель любой дополнительной информации, значимой для вашей деятельности.  
Развитые средства моделирования помогают лучше спроектировать базу данных. Предусмотрены возможности манипулирования атрибутами путем их буксировки, внесения изменений и нормализации "на лету". Средства редактирования непосредственно на диаграммах позволяют вносить в модель изменения, не открывая специальных диалоговых окон. Навигация по отношениям обеспечивает быстрое перемещение в больших моделях для перехода к родительским или дочерним объектам. Формируемые системой отчеты позволяют быстро проверить корректность спроектированной базы данных.

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

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

     ERWin имеет два уровня представления модели - логический и физический. Логическая структура базы данных строится в соответствии с определенными информационными объектами и связями между ними. В результате моделирования получена логическая структура будущей базы данных (рис.15).

     В данной структуре присутствуют связи  «много-ко-многим» между всеми сущностями.  
Рис.15 Логическая модель данных

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

3.2. Выбор и обоснование  СУБД

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

     Этим  требованиям отвечают многие современные СУБД, в том числе и Access. Microsoft Access включает в себя традиционные технологии и возможности реляционных СУБД, предоставляет средства создания базы нормализованных данных и форм для диалоговой работы с ней и удобным графическим интерфейсом. С построением базы нормализованных данных тесно связана разработка и эффективная реализация задач пользователя. Для рения многих задач достаточно использовать такие объекты Access, как формы, запросы ,отчеты. Эти объекты легко создаются в диалоговом режиме. Для реализации целостного приложения пользователя в некоторой предметной области возникает необходимость в создании макросов и модуле на языке Visual Basic for Applications (VBA). Механизм обработки событий, возникающих в процессе диалоговой работы с данными, позволяет объединять в приложении пользователя отдельные запросы, формы и отчеты и получать нестандартные рения в практических приложениях пользователя.

     Программа Microsoft Access 2000 является реляционной СУБД, которая может функционировать под управлением операционных систем Windows 95/98/Me, Windows NT, Windows XP, и позволяет реализовать поставленную цель. Обеспечивает удобство работы пользователя: имеется возможность создания пользовательских интерфейсов при использовании Visual Basic для приложений, автоматизация разработки различных объектов. Для построения и выполнения запросной функции в Access 2000 очень удобным и доступным является язык запросов по образцу QBE, поддерживаемый мощным интерфейсом пользователя, а также встроенный язык запросов SQL, который является удобным языком управления базами данных.

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

3.3. Физическая модель данных в 4НФ из ERWin

     ER-диаграммы  были приняты в качестве основы  для создания стандарта IDEF1X. Предварительный  вариант этого стандарта был  разработан в военно-воздушных  силах США и предназначался  для увеличения производительности при разработке компьютерных систем. В 1981 году этот стандарт был формализован и опубликован организацией ICAM (Integrated Computed Aided Manufacturing), и с тех пор является наиболее распространенным стандартом для создания моделей баз данных по всему миру.

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

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

     Этот  процесс называется прямым проектированием  (Forward Engineering). Тем самым достигается масштабируемость – создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERWin СУБД. С другой стороны, ERWin способен по содержимому системного каталога или SQL – скрипту воссоздать физическую и логическую модели данных. На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и, затем, сгенерировать ее системный каталог. Следовательно, ERWin позволяет решить задачу по переносу структуры данных от одного сервера на другой. Например, можно перенести структуру данных с Oracle на Infornix (или наоборот) или перенести структуру dbf -файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент - серверной системе.