АИС учета успеваемости студентов ВУЗа: результаты сессии

Время выполнения, дни

Зарплата и отчисления, руб.

Машинное время

и обслуживание, руб.

Электроэнергия, руб.

Накладные расходы, руб.

Всего затрат, руб.

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

Руководитель, бизнес-аналитик

3

4 639,08

143,40

17,57

354,55

5 154,50

2. Разработка требований к создаваемой системе

Руководитель, бизнес-аналитик

2

3 092,72

95,60

11,71

236,36

3 436,40

3. Проектирование системы

Руководитель, бизнес-аналитик, программист

4

9 159,04

239,00

29,28

554,55

9 981,87

4. Проектирование БД

Руководитель, бизнес-аналитик, программист

4

9 159,04

239,00

29,28

554,55

9 981,87

5. Кодирование системы

Руководитель, программист

5

8 298,80

167,30

20,50

436,37

8 922,96

6. Тестирование

Руководитель, программист

3

4 979,28

143,40

17,57

409,09

5 549,34

Продолжение таблицы 2.7

7. Доводка системы (устранение выявленных недостатков)	Руководитель, программист	3	4 979,28	95,60	11,71	245,46	5 332,05
8. Тестирование и анализ результатов	Руководитель, бизнес-аналитик, программист	2	4 579,52	119,50	14,64	290,91	5 004,57
9. Разработка документации	Руководитель, программист	2	3 319,52	71,70	8,78	190,91	3 590,92
10. Установка и внедрение системы	Руководитель, программист	2	3 318,52	95,60	11,71	272,73	3 699,56
Всего		30	46 366,76	1 410,10	172,75	3 545,47	50 672,00

График финансирования проекта по этапам разработки представлен на рисунке 2.2.

Рисунок 2.2 - Финансирование проекта по этапам разработки

Как видно из таблицы 2.7 и рисунка 2.2, наибольших сумм требуют этапы проектирования системы и БД, а также кодирование.

2.3 Анализ рисков

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

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

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

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

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

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

Таким образом, общая сумма необходимых затрат на разработки автоматизированной системы составляет 50 672,00 рублей.

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

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

3.1 Разработка структуры информационной системы

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

Рисунок 3.1 - Контекстная диаграмма потоков данных системы учета успеваемости студентов

В основе модели лежат понятия внешней сущности, процесса, хранилища данных и потока данных

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

Преподаватель должен иметь возможность:

· Вводить выставленные студентам оценки;

· Просмотр данных о выставленных ранее оценках.

Деканат должен иметь возможность:

· Ввод, просмотр и редактирование данных о студентах факультета;

· Ввод, просмотр и редактирование данных о кафедрах факультета и специальностях;

· Ввод, просмотр и редактирование данных о группах и учебном плане на текущий семестр;

· Получать данные для анализа успеваемости студентов и групп.

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

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

- подсистемы записи, просмотра и изменения данных о кафедрах и специальностях на факультете;

- подсистемы работы с группами;

- подсистемы работы со студентами.

Рисунок 3.2 - Детализирующая диаграмма потоков данных системы

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

Рисунок 3.3 - Структурная схема системы

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

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

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

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

3.2 Инфологическое проектирование системы

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

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

Основными сущностями системы являются: Студент и Предмет (изучаемый учебный курс).

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

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

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

Для получения справок различного рода потребуются сущности, определяющие структуру организации:

· Факультеты;

· Кафедры;

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

· Группы.

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

Определим атрибуты каждой сущности и уточним их типы.

Факультет:

· ID (ключевое поле);

· Название факультета.

Кафедра:

· ID (ключевое поле);

· Название кафедры.

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

· ID (ключевое поле);

· Название специальности.

Группа:

· Номер группы (ключевое поле).

Студент:

· Номер зачетки (ключевое поле);

· Ф.И.О.;

· Номер личного дела;

· Личные данные.

Образовательная услуга:

· ID (ключевое поле);

· Название услуги;

· Справочные данные;

· Цена услуги.

Предмет:

· ID (ключевое поле);

· Название предмета.

Семестровый план:

· ID (ключевое поле);

· Количество часов.

Тип контроля:

· ID (ключевое поле);

· Контроль.

Сессия:

· ID (ключевое поле);

· Дата;

· Оценка.

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

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

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

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

Отношение находится в 3-ей нормальной форме, если оно представлено во 2-ой нормальной форме и не имеет не входящих в

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

Разработанная модель находится в 3-ей нормальной форме т.к.:

- атрибуты сущностей являются атомарными;

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

- в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.

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

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

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

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

Эффективность функционирования системы, использующей БД, зависит как от выбора архитектуры БД, так и от выбора СУБД. К современным многопользовательским СУБД относятся Microsoft Access, Oracle, Microsoft SQL Server, SyBase, InterBase, Informix и др.

Выбор СУБД определяется несколькими критериями.

В первую очередь при выборе СУБД необходимо принимать во внимание следующие факторы:

- максимальное число пользователей одновременно обращающихся к базе;

- уровень квалификации персонала.

При выборе СУБД будем руководствоваться следующими критериями:

- быстродействие;

- надежность;

- развитые возможности масштабирования и администрирования;

- соотношение цены и качества.

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

На сегодня известно большое число различных серверов баз данных SQL. Ведущими серверными СУБД являются: Oracle8i, IBM DB2, Microsoft SQL Server и Informix.

Oracle8i

Пакет Oracle8i наделен самым развитым набором функций для работы с языком Java и доступа к данным через Интернет, системой оптимизации одновременного доступа. Практически единственным недостатком данной СУБД является сложность администрирования. Среди основных свойств СУБД Oracle следует отметить такие, как:

высочайшая надежность;

возможность разбиения крупных баз данных на разделы (large-database partition), что дает возможность эффективно управлять гигабайтными базами;

наличие универсальных средств защиты информации;

эффективные методы максимального повышения скорости обработки запросов;

свободные таблицы (в других СУБД все таблицы заполняются сразу при создании);

распараллеливание операций в запросе;

наличие широкого спектра средств разработки, мониторинга и администрирования;

ориентация на интернет технологии.

СУБД Microsoft SQL Server

Важнейшие характеристики данной СУБД - это:

1. простота администрирования;

2. возможность подключения к Web;

3. быстродействие и функциональные возможности механизма сервера СУБД;

4. наличие средств удаленного доступа;

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

IBM DB2

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

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

СУБД Informix

Новейшая CУБД от Informix - СУБД Centaur базируется на реляционной БД Informix Dynamic Server 7.3 и объектно-реляционной БД Informix Universal Data Option, сочетающей в себе высокое быстродействие Dynamic Server при работе с данными с универсальностью и мультимедиа функциями Universal Data Option. Новая система оснащена средствами объектно-ориентированного конструирования баз данных, создания специализированных таблиц и программ индексирования; в ее состав входят средства, позволяющие пользователям встраивать в запросы собственные функции и не полагаться исключительно на стандартные средства SQL.

Microsoft Access 2000

Access - это, прежде всего, система управления базами данных (СУБД).

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

Access мощное приложение Windows; впервые производительность СУБД органично сочетается с теми удобствами, которые имеются в распоряжении пользователей Microsoft Windows. С помощью объектов OLE и компонентов Microsoft Office (Excel, Word, PowerPoint и Outlook) можно превратить Access в настоящую операционную среду баз данных. С помощью новых расширений для Internet можно создавать формы, которые будут напрямую взаимодействовать с данными из World Wide Web, и транслировать их в представление на языке HTML, обеспечивающее работу с такими продуктами, как Internet Explorer и Netscape Navigator [9].

При всем этом Access не просто СУБД. Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет использовать одновременно несколько таблиц базы данных. При этом можно существенно упростить структуру данных, облегчая тем самым выполнение поставленных задач. Таблицу Access можно связать с данными, хранящимися на большой ЭВМ или на сервере. С другой стороны, можно использовать таблицы, созданные в среде Paradox или dBASE. Полученные результаты можно быстро и легко связать и объединить с данными из электронных таблиц Excel. Работая в среде Microsoft Office, пользователь получает в свое распоряжение полностью совместимые между собой Access и Word, Excel и PowerPoint [3].

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

В Access в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных на уровне ядра (что предотвращает несовместимые операции обновления или удаления данных). Кроме того, таблицы в Access снабжены средствами проверки допустимости данных, предотвращающими некорректный ввод вне зависимости от того, как он осуществляется, а каждое поле таблицы имеет свой формат и стандартные описания, что существенно облегчает ввод данных. Access поддерживает все необходимые типы полей, в том числе текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка и поля объектов OLE. Если в процессе специальной обработки в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений.

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

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

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

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

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

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

процедуры, поддерживающие редактирование данных и корректную запись их в базу данных;

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

процедуры, поддерживающие обеспечение целостности базы данных;

процедуры, поддерживающие защиту базы данных от несанкционированного доступа;

процедуры, отвечающие за контроль вводимой в ПЭВМ информации, уменьшающие процент ошибок оператора при вводе данных;

другие процедуры.

Для реализации задачи целесообразно использовать СУБД Access. СУБД Access поставляется в пакете Microsoft Office, и в дополнительном её приобретении нет необходимости. По программированию в СУБД Access выпущено достаточно много литературы, которую можно прибрести за относительно невысокую стоимость. Следовательно, чтобы минимизировать расходы на реализацию системы, выбрана СУБД Access.

3.4 Даталогическое проектирование системы

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

Применительно к выбранной СУБД сущности можно представить в табличном виде, которые представлены в таблице 3.1.

Таблица 3.1 Описание таблиц БД

1.1.1.3.4.1. Сущность	1.1.1.3.4.2. Таблица	1.1.1.3.4.3. Поле	1.1.1.3.4.4. Тип	1.1.1.3.4.5. Комментарий
Факультет	Факульте-ты	ID НазваниеФакультета	Счетчик Текстовый[30]	Хранение списка факультетов Первичный ключ
Кафедра	Кафедры	ID НазваниеКафедры ФакультетID	Счетчик Текстовый[70] Числовой	Хранение списка кафедр на факультете Первичный ключ Внешний ключ
Специаль-ность	Специаль-ности	ID НазваниеСпециальности КафедраID	Счетчик Текстовый[70] Числовой	Хранение списка специальностей на кафедре Первичный ключ Внешний ключ

Продолжение таблицы 3.1

1.1.1.3.4.6. Сущность	1.1.1.3.4.7. Таблица	1.1.1.3.4.8. Поле	1.1.1.3.4.9. Тип	1.1.1.3.4.10. Комментарий
Группа	Группы			Хранение списка групп на специальности
		Nгруппы СпециальностьID	Текстовый[8] Числовой	Первичный ключ Внешний ключ
Студент	Студенты	№ Зчетки Ф.И.О. № Дела ЛичныеДанные ГруппаID	Текстовый[8] Текстовый[100] Текстовый[10] Memo Текстовый[8]	Хранение списка студентов в группе Первичный ключ Внешний ключ
Образова-тельная услуга	Образова-тельные услуги	ID НазваниеУслуги СправочныеДанные ЦенаУслуги	Счетчик Текстовый[150] Memo Денежный	Хранение списка образовательных услуг Первичный ключ
Предмет	Предметы	ID НазваниеПредмета ОбразУслугаID	Счетчик Текстовый[80] Числовой	Хранение списка предметов в рамках данной образовательной услуги Первичный ключ Внешний ключ
Семестро-вый план	Семестро-вый план	ID ГруппаID ПредметID Кол-во часов	Счетчик Текстовый[8] Числовой Числовой	Хранение списка предметов на текущий семестр для данной группы Первичный ключ Внешний ключ Внешний ключ

Продолжение таблицы 3.2

1.1.1.3.4.11. Сущность	1.1.1.3.4.12. Таблица	1.1.1.3.4.13. Поле	1.1.1.3.4.14. Тип	1.1.1.3.4.15. Комментарий
Тип контроля	Тип контроля	ID Контроль	Счетчик Текстовый[30]	Хранение списка возможных вариантов контроля (экзамен, зачет, зачет с оценкой и т.д.) Первичный ключ
Сессия		ID Дата Оценка СтудентID ПредметID ТипКонтроля	Счетчик Дата/время Текстовый[7] Текстовый[8] Числовой Числовой	Хранение списка предметов на текущий семестр для данной группы Первичный ключ Внешний ключ Внешний ключ Внешний ключ

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

Кратко охарактеризуем типы полей СУБД Access:

· Поле текстового типа содержит символьные данные (до 255 символов), причем независимо от назначенной длины в поле данного типа хранится только введенное количество символов;

· Поле МЕМО может содержать до 65535 символов. Оно не может быть ключевым или индексным;

· Поле числового типа предназначено для хранения числовых данных;

· Денежный тип предназначен для хранения данных, точность представления которых - до четырех знаков после запятой, а целая

часть содержит до 15 знаков;

· Поле «Дата/время» предназначено для представления даты и времени;

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

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

· Свойство «Обязательное поле» определяет, обязательным или необязательным является ввод данных в это поле;

· «Размер поля» позволяет указать длину поля;

· «Значение по умолчанию» позволяет указать значение данного поля, которое задается автоматически;

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

Структура данных сущностей представлена в таблице 3.2.

Таблица 3.2 - Описание структуры данных сущностей

Сущность	Имя поля	Тип Данных	Размер поля	Значение по умол-чанию	Обяза-тельное поле	Индексированное поле
Факультет	ID	Счетчик	Длинное целое			Да (совпадение не допускается)
	Название фак-та	Текстовый	30		Да	Да (допускается совпадение)
Кафедра	ID	Счетчик	Длинное целое			Да (совпадение не допускается)
	Факультет ID	Числовой	Длинное целое	0	Да	Да (допускается совпадение)
	Название кафедры	Текстовый	70		Да	Да (совпадение не допускается)
Специаль- ность	ID	Числовой	Длинное целое	0	Нет	Да (совпадение не допускается)
	КафедраID	Числовой	Длинное целое	0	Да	Да (допускается совпадение)
	Название спец-ти	Текстовый	100		Да	Да (совпадение не допускается)

Продолжение таблицы 3.2

Сущность	Имя поля	Тип Данных	Размер поля	Значение по умол-чанию	Обяза-тельное поле	Индексированное поле
Группа	№ Группы	Текстовый	8		Да	Да (совпадение не допускается)
	Спец-тьID	Числовой	Длинное целое	0	Нет	Нет
Студент	№ Зачетки	Текстовый	8		Да	Да (совпадение не допускается)
	Ф.И.О.	Текстовый	100		Да	Да (допускается совпадение)
	ГруппаID	Текстовый	50		Нет	Нет
	№ Дела	Текстовый	10		Нет	Нет
	Личные данные	Поле МЕМО			Нет	Нет
Образователь-ная услуга	ID	Счетчик	Длинное целое			Да (совпадение не допускается)
	Название услуги	Текстовый	150		Да	Да (совпадение не допускается)
	Справоч-ные данные	Поле МЕМО			Нет	Нет
	Цена услуги	Денежный		0	Нет	Нет
Предмет	ID	Счетчик	Длинное целое			Да (совпадение не допускается)
	ОбразУслу-гаID	Числовой	Длинное целое	0	Нет	Нет
	Название предмета	Текстовый	80		Да	Да (допускается совпадение)
Семестровый план	ID	Счетчик	Длинное целое			Да (совпадение не допускается)
	ГруппаID	Текстовый	8		Да	Нет
	ПредметID	Числовой	Длинное целое	0	Да	Нет
	Кол. часов	Числовой	Длинное целое	0	Нет	Нет
Тип контроля	ID	Счетчик	Длинное целое			Да (совпадение не допускается)
	Контроль	Текстовый	30		Да	Нет
Сессия	ID	Счетчик	Длинное целое			Да (совпадение не допускается)
	Дата	Дата/Время			Да	Нет
	СтудентID	Текстовый	8		Нет	Нет
	ПредметID	Числовой	Длинное целое	0	Нет	Нет
	Тип Контроля	Числовой	Длинное целое	0	Нет	Нет
	Оценка	Текстовый	7		Нет	Нет

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

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

Рисунок 3.5 - Даталогическая модель данных

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

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

Для ввода данных, и их отображения в рамках работы разработан

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

При запуске программы автоматически загружается форма «Главная форма» представленная на рисунке 3.6.

Рисунок 3.6 - Вид формы «Главная форма» АИС учета успеваемости студентов

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

Форма «Данные об институте» служит для ввода и редактирования данных о структуре института. Вид формы представлен на рисунке 3.7.

Рисунок 3.7 - Вид формы «Данные об институте»

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

а) б)

в)

г)

Рисунок 3.8 - Вид формы «Факультеты» (а), «Кафедры» (б), «Специальности» (в), «Предметы» (г)

д)

Рисунок 3.8 - Вид формы «Образовательные услуги»

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

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

Форма «Данные о студентах и группах» служит для работы со студентами и группами. Вид этой формы представлен на рисунке 3.9.

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

Форма «Группы и семестровый план», представленной на рисунке 3.10, служит для добавления, просмотра и редактирования группы или семестрового плана группы.

Рисунок 3.9 - Вид формы «Данные о студентах и группах»

Рисунок 3.10 - Вид формы «Группы и семестровый план»

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

На форме размещены компоненты навигации, которые позволят просматривать записи. Для работы с записями БД предусмотрены соответствующие кнопки (Факультеты, Кафедры, Специальности, Студенты). Для удаления и добавления учебных групп предусмотрены кнопки и . Кнопка «Перенести группу в архив» переносит все данные о выбранной группе в архив.

Для работы со студентами служит форма «Студенты», представленная на рисунке 3.11.

Рисунок 3.11 - Вид формы «Студенты»

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

В окне «Студенты группы» отображается список студентов выбранной группы и личные данные. Для просмотра и редактирования списка предусмотрены кнопки навигации, а также кнопки добавления и удаления записи. Для поиска нужного студента установлена кнопка . Для работы с записями БД предусмотрены соответствующие кнопки (Факультеты, Кафедры, Специальности, Группы).

Кнопка «Неуспевающие студенты» предназначена для вывода отчета о неуспевающих студентах.

Кнопка «Личная ведомость успеваемости студента» предназначена для вывода отчета об успеваемости конкретного студента на текущее время.

Кнопка «Исключить студента» предназначена для переноса всех данных об исключенном из института студенте в архив.

Для работы с результатами сдачи сессии служит форма «Сессия», представленная на рисунке 3.12.

Рисунок 3.12 - Вид формы «Сессия»

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

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

Для ввода новой оценки предусмотрены выпадающие списки предметов, типов контроля и оценок, а также кнопка «Записать».

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

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

Рисунок 3.13 - Вид формы «Отчеты и запросы»

3.6 Проектирование запросов и отчетов базы данных

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

В конкретном случае спроектированы запросы, на основе которых строятся отчеты для вывода информации:

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

· Ведомость успеваемости студентов;

· Список неуспевающих студентов;

· Расчет количества студентов по группам;

· Список студентов по группам;

· Ведомость успеваемости группы;

· Средний балл по предметам в группе;

· Средний балл по предметам и группам;

· Прейскурант платных образовательных услуг.

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

Рассмотрим запрос «Результаты сдачи сессии». Вид запроса представлен на рисунке 3.14.

Рисунок 3.14 - Вид запроса «Результаты сдачи сессии»

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

ГруппаID (№ группы) в таблице СТУДЕНТЫ, и по полю ДАТА в таблице СЕССИЯ. Параметры для фильтрации по полю ГруппаID и ДАТА вводятся пользователем при выполнении запроса (рисунок 3.15).

а) б)

в)

Рисунок 3.15 - Ввод параметра фильтрации по дате (а,б) и по № группы (в)

Преобразуем этот запрос в перекрестный (рисунок 3.16) для формирования ведомости успеваемости группы.

Рисунок 3.16 - Вид запроса «Результаты сдачи сессии»

На основе этого запроса формируется «Ведомость успеваемости группы» представленный на рисунке 3.17.

Рисунок 3.17 - «Ведомость успеваемости группы»

Рассмотрим запрос «Средний балл по предметам в группе». Вид запроса представлен на рисунке 3.18.

Рисунок 3.18 - Вид запроса «Средний балл по предметам в группе»

На основе этого запроса формируется отчет «Средний балл по предметам в группе» представленный на рисунке 3.19.

Рисунок 3.19 - Вид отчета «Средний балл по предметам в группе»

Ниже представлены формируемые системой отчеты.

Рисунок 3.20 - Вид отчета «Ведомость успеваемости студентов»

Рисунок 3.21 - Вид отчета «Личная ведомость успеваемости студента»

Рисунок 3.22 - Вид отчета «Неуспевающие студенты»

Рисунок 3.23 - Вид отчета «Расчет количества студентов по группам»

Рисунок 3.24 - Вид отчета «Список студентов по группам»

Рисунок 3.25 - Вид отчета «Прейскурант платных образовательных услуг»

3.6 Разработка графа диалога

Основных элементов диалога (экранных форм) в системе 5:

1) «Главная форма»;

2) Форма «Группы и семестровый план»

3) Форма «Студенты»;

4) Форма «Сессия»;

5) Форма «Отчеты и запросы».

Описание основных элементов диалога представлено в таблице 3.3.

Таблица 3.3

Название формы	Отображаемые и редактируемые сущности БД	Операции
Главная форма		Главная кнопочная форма, открывающая другие формы для работы с системой
Группы и семестровый план	1) Группа; 2) Семестровый план; 3) Факультет; 4) Кафедра; 5) Специальность;	Ввод, хранение, редактирование и удаление данных о группах и семестровом плане для групп. Перенесение данных о группе завершившей учебу в институте в архив,
Студенты	1) Студент; 2) Факультет; 3) Кафедра; 4) Специальность; 5) Группа;	Ввод, хранение, редактирование и удаление данных о студентах. Поиск студента. Исключение студента (передача данных о студенте в архив). Вывод личной ведомости успеваемости студента.
Сессия	1) Студент; 2) Группа; 3) Предмет; 4) Факультет; 5) Кафедра; 6) Специальность;	Ввод, хранение, редактирование и удаление данных об успеваемости студента.
Отчеты и запросы		Кнопочная форма для формирования необходимых запросов и отчетов

Переход от главной формы к другим экранным формам осуществляется нажатием соответствующих кнопок на форме.

Граф диалога АИС Учета успеваемости студентов представлен на рисунке 3.26.

4 Технологическая часть

4.1 Разработка методики тестирования

Тестирование - процесс выполнения программ с целью обнаружения ошибок. Различают три стратегии тестирования:

1) Ручное тестирование - предназначено для начального периода разработки. Используются следующие основные методы:

- инспекция входного текста;

- сквозные просмотры;

- «проверка за столом»;

- оценка посредством просмотра.

2) Тестирование программы по принципу «черного ящика» (при неизвестной структуре).

Исчерпывающее тестирование (перебор всех возможных вариантов входной информации, практически не применяется в сложных системах);

Разумное тестирование (частичный перебор). Методами стратегии частичного перебора являются:

- эквивалентные разбиения;

- анализ граничных значений;

- анализ причинно-следственных связей;

- метод положения об ошибке.

3) Тестирование программы по принципу «белого ящика».

Принципы тестирования:

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

- необходимо проверять действия программ на неверных данных.

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

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

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

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

- название всех полей введены и не дублируют друг друга;

- определены типы всех полей;

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

А также, неправильные классы эквивалентности:

- не введено название хотя бы одного поля;

- названия отдельных полей одинаковы;

- не задан тип хотя бы одного поля;

- в качестве первичного ключа выбрано более одного поля;

- первичный ключ не задан.

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

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

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

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

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

Заключение

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

В результате проведена следующая работа:

Приведена технико-экономическая характеристика предметной области;

Проведен анализ предметной области и сформулированы требования к БД;

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

на основе инфологической модели разработана даталогическая модель БД;

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

спроектирована система запросов к БД;

спроектирована группа отчетов для БД;

выполнено комплексное тестирование и отладка БД.

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

Список литературы

1. Брешенков А.В., Губарь А.М. Проектирование объектов баз данных в среде Access: Учеб. Пособие для вузов. - М.: Изд-во МГТУ, им. Н.Э. Баумана, 2006. - 184 с: ил.

2. Когаловский М.Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика, 2002.

3. Мишенин, А.И. Теория экономических информационных систем: Учеб. для вузов / А.И. Мишенин.- 4-е изд., доп. и перераб. -М. : Финансы и статистика, 2001. - 240 с. : ил.

4. Гурвиц Г. Разработка реального приложения в среде клиент-сервер. - “ДВГУПС”, 2005. - 120 с.

5. Дейт К. Введение в системы баз данных/Пер. с англ. М.:Наука, 1980. 463 с.

6. Домарев В.В. Защита информации и безопасность компьютерных систем. - К.: “ДиаСофт”, 1999. - 480 с.

7. Ирвин М., Праг К. Access 2000. Библия пользователя. - М.: “Диалектика”, 2000. - 1040 с.

8. Оскерко В.С., Пунчик З.В. Практикум по технологиям баз данных. - Мн.: “БГЭУ”, 2004. - 170 с.

9. Паронжанов С. Объектно-ориентированные средства анализа, проектирования и реинжениринга информационных систем. - М.: Учебные материалы конференции «Индустрия программирования 96». 1996 г. с.117-123.

10. Фуфаев Д.Э., Фуфаев Э.В. Базы данных. - М.: “Академия”, 2005. - 320 с.

11. СанПиН 2.2.2.542 - 96. Санитарно-эпидемиологические правила и нормативы. Гигиенические требования к персональным электронно-вычислительным машинам и организации работы. - М: Издательство стандартов, 2003.