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

Аннотация

Данная расчетно-пояснительная записка содержит описание разработки «АИС учета успеваемости студентов ВУЗа: результаты сессии».

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

Реферат

Записка 77 с., 34 рис., 10 табл., 11 ист., 3 прил.

БАЗА ДАННЫХ, ВУЗ, ДЕКАНАТ, ФАКУЛЬТЕТ, КАФЕДРА, ИНСТИТУТ, УНИВЕРСИТЕТ, СТУДЕНТ, СЕССИЯ, ОЦЕНКА, ПРЕДМЕТ, ПРЕПОДАВАТЕЛЬ, УСПЕВАЕМОСТЬ, БАЛЛ.

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

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

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

Рецензия

на квалификационную работу студента кафедры

«Компьютерные системы и сети»

Вуза

Ф.И.О.

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

Состав проекта:

1) расчетно-пояснительная записка на 78 листах;

2) графическая часть объемом 6 листов формата А1;

3) приложения.

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

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

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

Этап проектирования был посвящен подробному описанию структуры системы и базы данных. Проведен анализ некоторых из существующих систем управления базами данных. На основе их сравнения для реализации базы данных была выбрана СУБД Microsoft Access. Разработан пользовательский интерфейс.

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

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

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

Рецензируемая работа удовлетворяет квалификационным требованиям, заслуживает оценки Отлично, а студент Бельгубаев М.А. присвоения степени бакалавра.

Зам. директора НИИ ИСУ, к.т.н. С.Е. Кондаков

Оглавление

ВВЕДЕНИЕ

1 Анализ предметной области и выбор концепции проектирования БД

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

1.1.1 Определение недостатков существующей системы обработки информации

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

1.3 Выбор и обоснование модели базы данных

1.4 Выбор и обоснование архитектуры базы данных

1.5 Обоснование выбора технологии проектирования

2 Технико-экономическое обоснование разработки

2.1 Расчет затрат на разработку системы

2.2 Формирование денежного потока

2.2.1 Расчет поступлений денежных средств

2.2.2 Финансирование проекта по этапам разработки

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

• Введение

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

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

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

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

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

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

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

1 Анализ предметной области и выбор концепции проектирования БД

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

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

1.1.1 Определение недостатков существующей системы обработки информации

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

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

Рассмотрим организационные недостатки:

Минимально используется персональный компьютер. ПЭВМ применяется в основном для создания различных отчетов, которые формируются вручную (MS Excel). Это связано с низкой подготовкой сотрудников в области применения ПЭВМ.

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

Отсутствие средств для оптимального решения основных операций.

Нерациональное использование средств информационных технологий.

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

Установленное программное обеспечение под ОС Windows XP лицензионное. Используются в своей деятельности в основном приложения пакета Microsoft Office, в частности электронные таблицы Excel для ведения простых однотабличных баз учета и поиска информации по этим базам. Дисциплина резервного хранения не установлена правилами, поэтому резервное хранение осуществляется путем записи файлов на лазерный диск по усмотрению сотрудников.

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

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

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

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

Можно выделить следующие цели автоматизированного варианта решения задачи:

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

- автоматизированная подготовка документов;

- повышение степени достоверности обработки информации о студентах;

- повышение степени защищенности информации;

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

АИС учета успеваемости студентов должна обеспечивать выполнение следующих основных функций:

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

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

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

- поиск заданного студента по фамилии или номеру зачетной книжки;

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

- выборка всех неуспевающих студентов;

- диаграмма - средний балл по каждому предмету;

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

- средняя оценка по предметам и группам (перекрестный);

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

- прием нового студента;

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

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

- формирование личной ведомости успеваемости;

- передача устаревших данных в архив (данные об отчисленных студентах должны копироваться в архив и удаляться из текущей базы данных);

- выводить следующие документы на печать:

- прейскурант платных образовательных услуг;

- диаграмма средней успеваемости;

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

- ведомость успеваемости студентов по группам и предметам.

1.3 Выбор и обоснование модели базы данных

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

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

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

Термин «модель данных» был введен американским математиком Коддом в 1970 г. при обосновании реляционной модели данных. Это понятие соответствует такому смысловому аспекту термина «модель», который понимается как средство, инструмент для моделирования.

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

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

Таким образом, в понятие «модель данных» входят три составляющие:

- средства для организации данных;

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

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

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

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

Исторически основными классическими моделями данных в этом узком смысле были иерархическая, сетевая и реляционная модели данных.

В настоящее время развиваются и постреляционные подходы.

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

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

- иерархическая;

- сетевая;

- реляционная;

- объектно-ориентированная.

Рассмотрим подробнее перечисленные модели данных.

1.1.1.1. Иерархическая модель

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

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

Древовидная модель представлена многочисленными ранними языками баз данных, включая DL/1 фирмы IBM, M и Язык Описания Данных КОДАСИЛ. Все эти системы представляют данные непосредственно в виде дерева и могут оперировать с сетевыми данными (которые могут иметь связи "многие-ко-многим"). С математической точки зрения эти базы данных описываются математической теорией графов. Во многих реализациях этих систем можно создать (возможно ограниченное) отображение в реляционную модель, которая позволяет использовать SQL/ODBC в качестве интерфейса на уровне запросов.

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии - подчиненным (рисунок 1.1). Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим».

Рисунок 1.1 - Схема иерархической модели данных

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

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

Недостатки: из нижних уровней иерархии нельзя направить информационный поиск по вышележащим узлам.

1.1.1.2. Сетевая модель

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

Сетевые модели также создавались для малоресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" - поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база - это самый верный способ потерять данные".

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

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



Рисунок 1.2 - Схема сетевой модели данных

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

Реляционная модель

Реляционная модель данных (РМД) название получила от английского термина relation - отношение. Ее предложил в 70-е годы сотрудник фирмы IBM Эдгар Кодд. При соблюдении определенных условий отношение представляется в виде двумерной таблицы, привычной для человека. Большинство современных БД для персональных ЭВМ являются реляционными.

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

Реляционная (или основанная на таблицах) модель базы данных безусловно наиболее часто используется сегодня и представлена как большими коммерческими пакетами, как Oracle, Sybase, Informix, Ingres и Gupta, так и маленькими как DBaseIV, Access, FoxPro, Alpha4 и Paradox. Все они основаны на первой теоретической работе Кодда и др. 1970 года. Из трех моделей, реляционная модель имеет наиболее хорошую математическую базу, включающую реляционную алгебру и реляционное исчисление. Последнее является основой языка запросов SQL и расширения ODBC, которые широко применяются для подключения пользовательского интерфейса в 2-х и 3-х слойных приложениях клиент/сервер.

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

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

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

Рисунок 1.3 - Схема реляционной модели данных

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

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

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

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

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

В настоящее время СУБД реляционного типа имеют наибольшее применение.

1.1.1.3. Объектно-ориентированная модель

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

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

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

1.4 Выбор и обоснование архитектуры базы данных

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

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

Локальные БД располагаются на том же компьютере, что и приложения, работающие с ним (рисунок 1.4). Работа с такими БД происходит, как правило, в однопользовательском режиме. При необходимости, можно запустить на компьютере другое приложение, одновременно осуществляющее доступ к этим же данным.

Рисунок 1.4 - Локальная БД

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

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



Рисунок 1.5 - Архитектура «Файл-сервер»

Для ее реализации предназначены персональные СУБД (Paradox, dBase, Access и др.) Эта архитектура централизованных баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором хранятся файлы централизованной базы данных. Основная часть обработки данных осуществляется на файл-сервере, откуда запрашиваемые файлы передаются на рабочие станции пользователей. Центральный сервер выполняет роль хранилища файлов, не участвуя в обработке самих данных. После завершения работы пользователи копируют файлы с обработанными данными обратно на сервер, откуда их могут взять и обработать другие пользователи. На основе скопированных файлов централизованной базы данных пользователи могут создавать на своих рабочих станциях локальные базы данных.

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

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

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

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

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

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



Рисунок 1.6 - Архитектура «Клиент-сервер»

Достоинствами такой архитектуры являются:

- Низкая нагрузка на сеть, в которой циркулирует только нужная информация.

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

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

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

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

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

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

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

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

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

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

база данных состоит из одного файла, имеющего расширение «.mdb» (формат Microsoft Access 2000).

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

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

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

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

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

1.5 Обоснование выбора технологии проектирования

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

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

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

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

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

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

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

Основные этапы, на которые разбивается процесс проектирования базы данных информационной системы, следующие [4]:

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

- Исследование предметной области применения и выявление требований конечных пользователей и решаемых задач.

- Анализ данных: сбор основных данных (объекты, связи между объектами).

- Построение диаграммы «сущность-связь» базы данных.

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

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

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

4. Реализация базы данных (оценка при неудовлетворительных эксплуатационных характеристиках).

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

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

Процесс построения инфологической модели состоит из следующих шагов:

- определение сущностей;

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

- задание первичных и альтернативных ключей;

- определение атрибутов сущностей;

- приведение модели к требуемому уровню нормальной формы.

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).

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

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

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

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

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

- Данные до включения в базу данных должны проверяться на достоверность;

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

- Разрешение проблем, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

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

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

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

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

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

2 Технико-экономическое обоснование разработки

2.1 Расчет затрат на разработку системы

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

а) руководитель проекта, знающий предметную область, формулирующий техническое задание на разработку;

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

в) программист, непосредственно занимающийся разработкой АИС и технической документации.

1.1.1.3.1.1.1. Таблица 2.1 Перечень этапов разработки системы и исполнителей

Этап разработки	Исполнители	Период
1.Анализ предметной области и существующих систем	Руководитель проекта	3
	Бизнес-аналитик	3
2. Разработка требований к создаваемой системе	Руководитель проекта	2
	Бизнес-аналитик	2
3. Проектирование системы	Руководитель проекта	3
	Бизнес-аналитик	4
	Программист	3
4. Проектирование БД (разработка структуры БД, входных и выходных данных)	Руководитель проекта	3
	Бизнес-аналитик	4
	Программист	3
5.Кодирование системы	Руководитель проекта	2
	Программист	5
6.Тестирование	Руководитель проекта	3
	Программист	3
7.Доводка системы (устранение выявленных недостатков)	Руководитель проекта	1
	Программист	3
8.Тестирование и анализ результатов	Руководитель проекта	2
	Бизнес-аналитик	2
	Программист	1
9.Разработка документации	Руководитель проекта	1
	Программист	2
10.Установка и внедрение системы	Руководитель проекта	2
	Программист	2

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

Срок разработки системы составляет 30 дней. Календарный график работ приведен на рисунке 2.1.

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

Таблица 2.2Исходные данные для расчета заработной платы исполнителей

Специалист	Месячная зарплата, руб.	Дневная зарплата, руб.
Руководитель проекта	16 000	727.27
Бизнес-аналитик	11 000	500
Программист	13 000	590.90

Рисунок 2.1 - Календарный график работ

Расчет заработной платы участников разработки приведен в таблице 4.3.

Таблица 2.3 Расчет заработной платы

Специалист	Время работы, дни	Сумма оплаты, руб.	ЕСН, руб.	Зарплата и отчисления, руб.
Руководитель	22	15 999.94	4 159.98	20 159.90
Бизнес-аналитик	15	7 500.00	1 950.00	9 450.00
Программист	22	12 999.80	3 379.94	16 379.74
Итого		23 512.93	9 489.92	45 989.64

Таким образом, расходы на оплату труда составляют 22 336,45 рублей.

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

При разработке системы были использованы 3 компьютера стоимостью 20 000 рублей каждый, помимо них в помещении будут работать и другие устройства, потребляющие 200-300 КВт в месяц.

Компьютеры и устройства принадлежат заказчику. Годовая норма амортизации компьютеров 24%. Расходы на обслуживание оборудования составляют 25% амортизационных отчислений.

Энергопотребление каждого компьютера составляет 200 Вт/ч. Стоимость одного кВт/час электроэнергии составляет 1,83 рублей. Компьютеры работают 8 часов в день. Разработка ведется в помещениях и на оборудовании заказчика. Расходы на оплату машинного времени (амортизация), обслуживание оборудования, электроэнергию, зарплату разработчикам, накладные расходы несет заказчик.

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

Так как работы велись при пятидневной рабочей неделе, то в году получается 251 рабочий день. Тогда при годовой сумме амортизации одного компьютера, равной 20 000 * 0,24 = 4 800 рублей, дневная сумма амортизации 4 800 /251 = 19,12 рублей. Таким образом, стоимость машинного времени, например, для руководителя равна 22 * 19,12 = 422,40 рублей.

Данные о затратах машинного времени приведены в таблице 2.4.

1.1.1.3.2. Таблица 2.4 - Затраты машинного времени

Специалист	Время работы, дни	Стоимость машинного времени, руб.
Руководитель	22	420,64
Бизнес-аналитик	15	286,80
Программист	22	420,64
Всего		1 128,08

Таким образом, сумма затрат на машинное время равна 1 128,08 рублей.

Затраты на обслуживание оборудования составляют 25% от стоимости машинного времени и равны 1 128,08* 0,25 = 282,02 рублей.

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

1.1.1.3.3. Таблица 2.5 - Затраты на электроэнергию

Специалист	№ компьютера	Время работы, дни	Расходы на электроэнергию, руб.
Руководитель	1	22	64,42
Бизнес-аналитик	2	15	43,92
Программист	3	22	64,42
Всего	172,75

Затраты на электроэнергию, потребляемую компьютерами, составляют 172,75 рублей. Стоимость электроэнергии, потребляемой другими приборами за месяц, составляет 250*1,83=457,50 рублей. Таким образом затраты на электроэнергию составляют 630,25 рублей.

Общая сумма затрат на разработку приведена в таблице 2.6.

1.1.1.3.4. Таблица 2.6 - Затраты на разработку

Статья затрат	Сумма, руб.
Зарплата и отчисления	45 989.64
Стоимость машинного времени	1 128,08
Затраты на обслуживание	282,02
Затраты на электроэнергию	172,75
Накладные расходы	3 545,47
Всего	54 663.43

Таким образом, на разработку АИС учета успеваемости студентов требуется 54 663.43 рублей.

2.2 Формирование денежного потока

2.2.1 Расчет поступлений денежных средств

Разработка АИС учета успеваемости студентов осуществлялась по заказу деканата университета МГТУ, поэтому все права на владение принадлежат этому учебному заведению. Необходимо оценить эффективность внедрения такой системы для единственного заказчика.

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

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

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

в)специалисты по информатизации выявили исчисляемые и неисчисляемые эффекты от внедрения системы.

Исчисляемые эффекты:

- отсутствие временных затрат на создание или оформление первичных и отчетных документов, которые теперь формируются автоматически. Дневная экономия рабочего времени работника деканата составит в среднем 2 часа. Таким образом, при зарплате (куда входят 26% отчислений на единый социальный налог) сотрудника деканата в 12000 рублей в месяц, 8-часовом рабочем дне и 5-дневной рабочей неделе (в среднем 22 рабочих дня в месяц) сумма дневной экономии составит:

12000 /(22*8) * 2 = 136,36 рублей.

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

- отсутствие временных затрат на начисление зарплаты. Дневная экономия рабочего времени бухгалтера составит в среднем 0,5 часов:

13120/(22*8) * 0,5 = 37,27 рублей.

Таким образом, от внедрения системы каждый день экономится 582,72 рублей.

Неисчисляемые эффекты:

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

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

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

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

д) отсутствие необходимости хранения информации на бумажных носителях.

На основе получаемых при внедрении автоматизированной системы исчисляемых эффектов был выявлен срок окупаемости проекта. Он равен отношению затрат на разработку к сумме ежедневной прямой экономии: 54663,43 / 582,72 = 93 дня. Дальнейшее использование информационной системы несет заказчику прибыль. На основании этого руководитель проектной организации утвердил окончательное решение о разработке системы. Был утвержден срок разработки проекта - 30 рабочих дней.

2.2.2 Финансирование проекта по этапам разработки

Целесообразно представить финансирование проекта по этапам разработки, описанным в таблице 3. Сумма средств, направленных на финансирование каждого этапа складывается из средств на оплату труда, затрат на машинное время и обслуживание оборудования, накладных расходов, а также электроэнергию (таблица 2.7).

Таблица 2.7 - Финансирование проекта по этапам разработки

Содержание работы	Исполнители

Подобные документы

• Проектирование базы данных для автоматизации контроля сессионной успеваемости студентов ВУЗа и составления приложения к диплому

  Выбор методологии проектирования и системы управления базами данных. Описание предметной области и проектирование физической структуры базы данных. Реализация проекта в MS SQL Server 2008. Построение инфологической модели. Ограничения целостности связи.
  
  курсовая работа [679,2 K], добавлен 22.01.2013
  

• Разработка информационной системы для обслуживания предметной области "Картотека ГИБДД"

  Анализ проектирования баз данных на примере построения программы ведения информационной системы картотеки ГИБДД. Основные функции базы данных. Обоснование выбора технологий проектирования и реализации базы данных. Описание информационного обеспечения.
  
  курсовая работа [753,0 K], добавлен 27.08.2012
  

• Разработка информационной системы ОВД г. Донецка

  Анализ решений по автоматизации предметной области. Выбор методологии проектирования информационной системы. Обоснование выбора платформы. Взаимодействие приложения с источниками данных. Выбор жизненного цикла разработки программного обеспечения.
  
  дипломная работа [3,7 M], добавлен 18.12.2010
  

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

  Этапы проектирования информационных систем. Корпоративные информационные системы, тенденции их развития. Требования к организации базы данных. Основные концепции реляционных баз данных. Выбор системы проектирования. Логическая структура приложения.
  
  дипломная работа [2,2 M], добавлен 20.12.2012
  

• Проектирование и разработка базы данных "Аэропорт"

  Цели проектирования базы данных "Аэропорт": обработка информации о рейсах, расписании самолетов и билетах. Анализ предметной области. Принцип работы модели. Особенности реализации информационной системы. Среда программирования клиентского приложения.
  
  лабораторная работа [2,4 M], добавлен 07.01.2014
  

• Информационная система учета и контроля успеваемости и посещаемости студентов ЮТИ ТПУ

  Проблема повышения оперативности учета и контроля посещаемости и успеваемости студентов ЮТИ ТПУ. Разработка информационной системы, требования к ней. Информационное обеспечение задачи, автоматизация предметной области. Описание интерфейса системы.
  
  дипломная работа [2,6 M], добавлен 17.07.2012
  

• Автоматизизация работы менеджера

  Анализ работы менеджера по продажам. Определение недостатков существующей системы обработки информации. Обоснование необходимости разработки информационной системы. Выбор варианта реализации задач автоматизации. Разработка пакета прикладных программ.
  
  курсовая работа [49,3 K], добавлен 20.02.2012
  

• Проектирование информационной технологии АРМ

  Технико-экономическая характеристика предметной области. Обоснование необходимости и цели использования информационных технологий для решения задачи. Выбор технологии проектирования, разработка АРМ. Расчет показателей экономической эффективности проекта.
  
  дипломная работа [2,8 M], добавлен 11.03.2010
  

• Проектирование базы данных "Аудиотека"

  Анализ и оценка эффективности существующей системы обработки информации. Выбор технических и программных средств. Описание этапов проектирования базы данных "Аудиотека" и ее особенностей. Разработка инфологической модели и программного приложения.
  
  курсовая работа [877,9 K], добавлен 06.06.2013
  

• Моделирование бизнес-процессов учета успеваемости студентов в высшем учебном заведении

  Характеристика высшего учебного заведения "МФПА", структура подразделений учебной части. Анализ диаграммы дерева узлов, стадии проектирования информационной системы учета успеваемости студентов. Основные особенности построения модели "Как должно быть".
  
  курсовая работа [3,1 M], добавлен 12.04.2012
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам