Построение функциональной модели AS-IS

 

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

CASE средства (Computer - Aided Software Engineering) – это инструмент, который позволяет автоматизировать процесс разработки информационной системы и программного обеспечения. Разработка и создание информационных систем управления организацией связаны с выделением бизнес-процессов, их анализом, определением взаимосвязи элементов процессов, оптимизации их инфраструктуры и т.д. [1] Основной целью применения CASE средств является сокращение времени и затрат на разработку информационных систем, и повышение их качества.

Многие современные CASE средства предоставляют возможности для моделирования практически всех предметных областей деятельности организаций. [19]

Из общего разнообразия CASE средств, существующие на сегодняшний день, можно выделить три группы. Эти группы связаны с этапами разработки информационных систем и их жизненным циклом. [8] Классификация CASE средств осуществляется в зависимости от того, какие из этапов разработки они поддерживают.

Выделяют следующие группы CASE средств:

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

- CASE средства нижнего уровня. Эти CASE средства сфокусированы на последних этапах разработки информационной системы – проектирование, разработка программного кода, тестирование и внедрение. CASE средства нижнего уровня зависят от данных, которые предоставляют средства верхнего уровня. Они используются разработчиками приложений и помогают создать информационную систему, однако не являются полноценными инструментами разработки программного обеспечения. [4]

- Интегрированные CASE средства (I – CASE). Эти CASE средства охватывают полный жизненный цикл разработки информационной системы. Они позволяют обмениваться данными между инструментами верхнего и нижнего уровня. [21, 22]

Основными характеристиками CASE средств, важными с точки зрения моделирования и оптимизации бизнес-процессов, являются следующие:

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

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

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

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

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

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

BPwin – это программное обеспечение, которое было выпущено разработчиками из ltd. Logic Works. Основное назначение утилиты – поддержка созданий систем контроля информации. Считается принадлежащим к средствам верхнего уровня.

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

Впервые программа выпущена в 1995 году в сопутствии с другим программным средством моделирования Erwin, который был создан для процессов моделирования потоков информации. Дальнейшей разработкой программного обеспечения занималась фирма Platinum Tech. Версию BPwin 4.0 и некоторые предыдущие разрабатывали специалисты из СА Technologies.

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

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

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

Прежде чем пытаться выбрать существующую или создать собственную информационную систему, а затем внедрить ее, необходимо проанализировать, как работает система в настоящее время. Для этого строится функциональная модель AS-IS. Анализ этой функциональной модели позволяет понять, где находятся наиболее слабые и сильные места организации или процесса. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ - модели новой организации процессов. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных путей выполнения работы и документирования того, как система будет функционировать в будущем.

Модель AS-IS - это модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. [13, 17] Построение функциональной модели AS-IS позволяет четко зафиксировать какие информационные объекты используются при выполнении функций различного уровня детализации. На основе анализа текущих процессов была создана следующая AS-IS модель, которая позволяет выделить и систематизировать процессы, протекающие в данной системе при её функционировании. Главная контекстная диаграмма данной модели приводится на рисунке 2.

 

Рисунок 2 - Контекстная диаграмма

 

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

1) Справка из Соц. Защиты

2) Сотрудники

3) Программное обеспечение

4) Технические средства

5) Документация

6) Руководство пользователя

7) Приказ о назначении соц. стипендии

На следующей диаграмме представлен процесс создания базы данных. (Рисунок 3)

 

Рисунок 3 – Процесс создания базы данных

 

Исходя из модели AS-IS построенной с помощью CASE средства BPwin можно сделать вывод, без автоматизированной системы не обойтись, а требования к системе описаны далее.

 

Требования к программному продукту

 

Автоматизированная система управления учёта студентов, получающих социальную стипендию позволяет:

1) Вести учёт студентов, обучающихся в колледже.

2) Вести учёт студентов, получающих социальную стипендию.

3) Хранить информацию о группах и специальностях колледжа.

4) Создавать автоматически приказ о назначении социальной стипендии.

5) Ввод данных.

6) Вывод данных.

7) Изменение данных.

8) Возможность поиска (фильтрации) по базе данных информации, по группам.

9) Возможность поиска (фильтрации) по базе данных информации, по студентам.

10) Возможность поиска (фильтрации) по базе данных информации, по специальностям.

Далее рассмотрены требования, предъявляемые к программному продукту.

1. Требования к программе

1.1. Требования к функциональным характеристикам

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

1.1.1. Ввод данных.

1.1.2. Вывод данных.

1.1.3. Изменение данных.

1.1.4. Возможность поиска (фильтрации) по базе данных информации, по группам.

1.1.5. Возможность поиска (фильтрации) по базе данных информации, по студентам.

1.1.6. Возможность поиска (фильтрации) по базе данных информации, по специальностям.

1.1.7. Создание автоматического отчёта

1.1.8. Учёт студентов обучающихся в колледже

1.1.9. Учёт студентов, получающих социальную стипендию

1.1.10. Хранение информацию о группах и специальностях колледжа

2.2. Требования к надежности

2.2.1 Требования к обеспечению надежного функционирования программы

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

2.2.2. Время восстановления после отказа

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

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

3. Условия эксплуатации

3.1. Климатические условия эксплуатации

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

3.2. Требования к квалификации и численности персонала

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

а) задача поддержания работоспособности технических средств

б) задачи установки (инсталляции) и поддержания работоспособности

3.3. Требования к составу и параметрам технических средств

3.3.1. В состав технических средств должен входить персональный компьютер (ПК), выполняющий роль сервера, включающий в себя:

3.3.1.1. Процессор Pentium-2.0Hz, не менее;

3.3.1.2. Оперативную память объемом, 1Гигабайт, не менее;

3.3.1.3. HDD, 40 Гигабайт, не менее;

3.3.1.4. Операционную систему Windows;

3.3.3. Требования к защите информации и программ.

Требования к защите информации и программ не предъявляются т.к. за защиту информации и программы отвечает разработчик приложения, а в моём случаи это Microsoft.

Таким образом, проведён анализ предметной области и построена функциональная модель AS-IS, в которой были выявлены узкие места в работе сотрудника учебного отдела, занимающего учётом студентов, получающих социальную стипендию. К этим узким местам относятся временные затраты и работа, выполненная вручную. Исходя из модели AS-IS построенной с помощью CASE средства BPwin можно сделать вывод, без автоматизированной системы сложно осуществлять учёт студентов.

ГЛАВА 2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ СТУДЕНТОВ, ПОЛУЧАЮЩИХ СОЦИАЛЬНУЮ СТИПЕНДИЮ

 

2.1 Техническое задание на разработку базы данных

 

1. Введение

1.1. Наименование программы

Наименование программы: "Автоматизированная система управления учета студентов, получающих социальную стипендию "

1.2. Назначение и область применения

Программа предназначена для создания, управления содержимым автоматизированной системы, содержащим следующие данные:

1.2.1. Список студентов колледжа

1.2.2. Раздел с распределением учебных групп по специальностям

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

1.2.4. Список студентов получающих социальную стипендию

2. Требования к программе

2.1. Требования к функциональным характеристикам

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

2.1.1. Ввод данных.

2.1.2. Вывод данных.

2.1.3. Изменение данных.

2.1.4. Возможность поиска (фильтрации) по базе данных информации, по группам.

2.1.5. Возможность поиска (фильтрации) по базе данных информации, по студентам.

2.1.6. Возможность поиска (фильтрации) по базе данных информации, по специальностям.

2.2. Требования к надежности

2.2.1. Требования к обеспечению надежного функционирования программы

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

а) организацией бесперебойного питания технических средств;

б) использованием лицензионного программного обеспечения;

в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;

г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

2.2.2. Время восстановления после отказа

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

2.2.3. Отказы из-за некорректных действий пользователей системы

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

3. Условия эксплуатации

3.1. Климатические условия эксплуатации

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

3.2. Требования к квалификации и численности персонала

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

а) задача поддержания работоспособности технических средств;

б) задачи установки (инсталляции) и поддержания работоспособности

3.3. Требования к информационной и программной совместимости

3.3.1. Требования к информационным структурам и методам решения

База данных работает под управлением Microsoft SQL Server. Используется много поточный доступ к базе данных. Необходимо обеспечить одновременную работу с программой с той же базой данной модулей экспорта внешних данных.

3.3.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются.

3.3.3. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

4. Стадии и этапы разработки

4.1. Стадии разработки

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

1. разработка технического задания;

2. рабочее проектирование

3. внедрение

4.2. Этапы разработки

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

1. разработка программы

2. разработка программной документации

3. испытания программы

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

4.3. Содержание работ по этапам

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1. постановка задачи

2. определение и уточнение требований к техническим средствам

3. определение требований к программе

4. определение стадий, этапов и сроков разработки программы и документации на неё

5. согласование и утверждение технического задания

На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.

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

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

1. разработка, согласование и утверждение и методики испытаний

2. проведение приемо-сдаточных испытаний

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

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

 

2.2 Проектирование базы данных учёта студентов, получающих социальную стипендию

 

Анализ предметной области целесообразно разбить на три фазы:

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

2)Выявление информационных объектов и связей между ними.

3)Построение концептуальной модели предметной области и проектирование концептуальной схемы БД. [11]

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

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

Вторая фаза анализа предметной области состоит в выборе информационных объектов, задании необходимых свойств для каждого объекта, выявлении связей между объектами, определении ограничений, накладываемых на информационные объекты, типы связей между ними, характеристики информационных объектов. [15] При выборе информационных объектов постараемся ответить на ряд вопросов:

На какие классы можно разбить данные, подлежащие хранению в БД?

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

Какие наиболее интересные характеристики (с точки зрения пользователя) каждого класса данных можно выделить?

Какие имена можно присвоить выбранным наборам характеристик?

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

1) Категория

2) Группы

3) Приказ

4) Организация

5) Социальная стипендия

6) Специальность

7) Студенты

 

Таблица 1 - Логическая структура информационных объектов

Наименование информационного объекта	Имя файла таблицы	Наименование поля	Идентификатор поля	Размер поля
				Всего	Точно
1	2	3	4	5	6
Категория	Categories	Код категории	ID_Categories	6	6
		Наименование категории	The name of the category	10	10
Группы	Groups	Группа	ID_Group	6	6
		Специальности	ID_Specialnosti	8	8
		Курс	Kurs	1	1

 

Продолжение таблицы 1
1	2	3	4	5	6
Приказ	Order	Номер приказа	№_Order	6	6
		Дата приказа	Date of order	10	10
		Дата начисления стипендии	The accrual date of a scholarship	10	10
		Номер справки для назначения социальной стипендии	The reference number for the appointment of social grants	5	5
Организация	Organizations	Номер организации	ID_Organizations	6	6
		Название организации	Organization name	255	255
Социальная стипендия	Social scholarship	Номер зачетной книжки	Number_ZK	6	6
		Номер справки для назначения социальной стипендии	The reference number for the appointment of social grants	5	5
		Кем выдана справка	ID_Organizations	3	3
		Дата выдачи справки	Date of issue of the certificate	10	10
		Начало действия справки	Getting started with help	10	10
		Конец действия справки	The end of the reference	10	10
		Категория	ID_Categories	6	6
Специальность	Specialties	Код специальности	ID_Specialnocti	8	8
		Название специальности	Name_Sp	255	255
Студенты	Students	Номер зачетной книжки	Number_ZK	6	6
		Группа	ID_Grоup	255	255
		Фамилия	Surname	255	255
		Имя	Name	255	255
		Отчество	Middlename	255	255
		Дата рождения	Birthdate	10	10
		Серия	Series	4	4
		Номер	Number	6	6
		Кем выдан	Issued by whom	255	255
		Дата выдачи	Date of issue	10	10
		Код подразделения	Division code	7	7
		СНИЛС	SNILS	14	14

 

3. Построение концептуальной модели предметной области

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

Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области (ПО) и выявляемых в результате анализа данных. [16, 18]

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

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

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

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

 

Специальность

Состоит

Группа

Учатся

Студенты

Получают

Социальная стипендия

Включает

Организация

Категория

Выдаёт

Отображается

Приказ

Рисунок 4 – Концептуальная модель базы данных учёта студентов, получающих социальную стипендию

 

Определение взаимосвязей и построение ИЛМ  

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

- связь 1:1 предполагает, что в каждый момент времени одному экземпляру сущностей А соответствует не более одного экземпляра сущности В;

- связь 1:М предполагает что одному экземпляру сущности А, соответствует нуль, один или несколько экземпляров сущности В;

- связь М:М предполагает что, в каждый момент времени одному экземпляру сущности А соответствует нуль, один или несколько экземпляров сущности В и наоборот. 

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

 

Таблица 2 – Взаимосвязь информационных объектов

Главный информационный объект	Подчиненный информационный объект	Ключ связи	Тип отношения
1	2	3	4
Специальности	Группы	Код специальности	1:М
Группы	Студенты	Группа	1:М
Студенты	Социальная стипендия	Номер зачетной книжки	1:М
Организации	Социальная стипендия	Номер организации	1:М
Категории	Социальная стипендия	Код категория	1:М
Социальная стипендия	Приказ	Номер справки для назначения социальной стипендии	1:М

 

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

Принципы построения информационно-логической модели: [34]

- все информационные объекты должны быть разбиты на уровни;

- информационные объекты одного уровня должны быть построены в одну линию;

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

- наименования объектов на краях стрелок должны совпадать;

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

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

B Ai0AFAAGAAgAAAAhADj9If/WAAAAlAEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAF55+47sBwAASk8AAA4AAAAAAAAAAAAAAAAALgIAAGRycy9lMm9Eb2MueG1s UEsBAi0AFAAGAAgAAAAhAIXztaTdAAAABgEAAA8AAAAAAAAAAAAAAAAARgoAAGRycy9kb3ducmV2 LnhtbFBLBQYAAAAABAAEAPMAAABQCwAAAAA= ">

Код группы Код специальности Курс обучения

Специальности

Код специальности Название специальности

Группы

Студенты

Номер зачетной книжки Код группы Фамилия Имя Отчество Дата рождения Серия Номер Кем выдан Дата выдачи Код подразделения СНИЛС

Организация

Код организации Название организации

Категория

Код категории Название категории

Социальная стипендия

Номер зачетной книжки Номер справки для назначения социальной стипендии Код организации Дата выдачи справки Начало действия справки Конец действия справки Код категория

Приказ

Номер приказа Дата приказа Дата начисления стипендии Номер справки для назначения социальной стипендии

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

 

 

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