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

Тип работы:
Курсовая
Предмет:
Программирование


Узнать стоимость

Детальная информация о работе

Выдержка из работы

Содержание

Введение

1 Формирование требований к системе учета успеваемости студентов на основе рейтинговой системы

1.1 Разработка диаграммы вариантов использования

1.1.1 Выявления акторов

1.1.2 Выявления вариантов использования

1.1.3 Диаграммы вариантов использования

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

2.1 Диаграмма потоков данных

3 Проектирование ПС

3.1 Проектирование архитектуры ПС

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

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

4 Реализация ПС

4.1 Выбор средств реализации

4.2 Реализация информационного обеспечения

4.3 Реализация пользовательского интерфейса

4.4 Реализация функциональности ПС

4.5 Организация взаимодействия приложения с БД

5 Тестирование ПС

Заключение

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

Приложение, А Видение

Приложение Б Архитектура БД

Введение

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

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

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

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

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

1 Формирование требований к системе учета успеваемости студентов на основе рейтинговой системы

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

1.1 Разработка диаграммы вариантов использования

Разработка диаграммы вариантов использования производится в три этапа. Сначала выявляются акторы и производится их описание. Затем, исходя из описания, выявляются варианты использования акторов. И на третьем этапе строится диаграмма вариантов использования.

1.1.1 Выявления акторов

Краткое описание акторов представлено в таблице 1.

Таблица 1. Выявление акторов

Актор

Краткое описание

Преподаватель

Регистрирует данные о посещаемости и успеваемости студентов по своему предмету. Просматривает, редактирует или удаляет внесенные данные. Просматривает обработанные данные. Анализирует их.

Студент

Просматривает внесенные преподавателем данные по предмету. Просматривает обработанные данные. Получает и просматривает оповещения в случае неудач.

1.1.2 Выявление вариантов использования

Выявление вариантов использования представлено в таблице 2.

Таблица 2. Выявление вариантов использования

Основной актор

Наименование

Формулировка

Преподаватель

Регистрация данных

Этот вариант использования позволяет преподавателю передавать данные о посещаемости и успеваемости студента в программу

Преподаватель

Вывод регистрированных данных

Этот вариант использования позволяет преподавателю просматривать только что внесенные данные

Преподаватель

Корректировка данных

Преподаватель может редактировать или удалить неправильно введенные данные

Преподаватель

Вывод обработанных данных

Преподаватель может просмотреть обработанные программой данные

Преподаватель

Анализ

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

Студент

Вывод регистрированных данных

Этот вариант использования позволяет студенту просматривать внесенные преподавателем данные

Студент

Вывод обработанных данных

Студент может просмотреть данные, обработанные программой

Студент

Оповещение

Программа, на основе анализа данных преподавателем, посылает оповещения о результатах студенту

1.1.3 Разработка диаграммы вариантов использования

Все варианты использования показаны на рисунке 1.

учет успеваемость студент рейтинговая система

Рис. 1. Диаграмма вариантов использования

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

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

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

ПС подразумевает следующие типы пользователей:

— Студент

— Преподаватель

— Администратор

— Модератор

— СоМодератор

Рассмотрим подробно взаимодействие типа пользователя «Преподаватель» с ПС.

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

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

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

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

2.1 Диаграмма потоков данных

Рис. 2. Диаграмма потоков данных

3 Проектирование

3.1 Проектирование архитектуры ПС

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

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

2) Изолировать архитектуру доступа к данным, так чтобы она могла поддерживать различные лежащие в основе хранилища данных, не требуя внесения изменений на уровне бизнес-объектов. Подобным образом, внесение изменений в бизнес-объекты или уровни представления тоже должно быть возможным без изменения другого уровня. Это называется отделением уровней друг от друга.

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

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

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

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

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

Уровень доступа к данным (Data Access Layer — DAL) — это код, который выполняет отправляемые в базу данных запросы на извлечение данных, их обновление, вставку или удаление. Этот код наиболее близок к базе данных и поэтому ему должны быть известны все детали базы данных, т. е., схема таблиц, имена полей, хранимых процедур, представлений и т. д.

Уровень бизнес-логики (Business Logic Layer — BLL) — получает данные возвращаемые уровнем DAL и передает их уровню пользовательского интерфейса, но кроме того он добавляет верификационную логику и вычисляемые свойства, делая некоторые из свойств персональными или доступными только для чтения, а так же методы экземпляра и статические методы для удаления, редактирования, вставки и извлечения данных.

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

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

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

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

между собой.

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

— aspnet_Fakultets (таблица для хранения факультетов),

— aspnet_Kafedraes (таблица для хранения кафедр),

— aspnet_Speciales (таблица для хранения специальностей).

Также, необходимо создать таблицы, которые бы хранили пользователей ПС — таблица aspnet_Users и роли пользователей aspnet_Roles. Для того чтобы обеспечить взаимодействие данных между двумя этими таблицами необходимо создать промежуточную таблицу aspnet_UsersInRoles, т. е. эта таблица в которой будет храниться соответствие между пользователем и ролями которыми он обладают.

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

Каждый пользователь обладает индивидуальными характеристиками, которые также необходимо хранить, для этого создадим таблицу профилей пользователей — aspnet_Profile. Помимо всего пользователь может быть студентом или преподавателем, следовательно, необходимо создать таблицу, которая бы хранила учебные группы — aspnet_Grups и таблицу, которая бы непосредственно хранила студентов в конкретной учебной группе — aspnet_UsersInGrup, а так же таблицу, которая бы хранила соответствие между преподавателем, его предметом и группами, у которых он ведет конкретный предмет — aspnet_UsersRolesGrups.

Ниже на рисунке 4 представлено логическое проектирование базы данных.

Рис. 4. Логическое проектирование базы данных.

Также по конкретным предметам будут существовать определенные темы, которые будут хранится в таблице — aspnet_Thems, а данные темы будут регистрироваться в определенном семестре, поэтому также понадобится таблица которая бы хранила семестры — aspnet_Semestor.

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

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

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

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

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

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

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

Рис. 4. схематический пользовательский веб интерфейс

4. Реализация ПС

4.1 Выбор средств реализации

Для реализации данного программного средства будет выбрана среда разработки MS Visual Studio 2005. Данная среда включает такие элементы разработки как: интегрированную СУБД Microsoft SQL Server 2005 Express Edition, языки программирования С++, С#, J#, Visual Basic, новейшие веб технгологии ASP. NET 2. 0, Ajax, интегрированный веб сервер для тестирования веб приложений, а так же очень развитую IDE среду и многое другое. Все вышеперечисленное дает большие возможности для быстрой и надежной разработки этого программного средства, а так же его отладки, тестирования и развертывания.

Система будет разработана как приложение ASP. NET 2.0 на языке программирования Visual С# с использованием СУБД Microsoft SQL Server 2005 Express Edition.

4.2 Реализация информационного обеспечения

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

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

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

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

Таким образом, мы получаем, что для полноценной структуры нашей ИС необходимо 4 основные сущности и 1 дополнительная.

Основные:

· Пользователь;

· Приложение;

· Членство;

· Роль.

Дополнительные:

· ПользовательРоль.

Атрибуты сущностей

Рассмотрим подробным образом все атрибуты описанных выше сущностей.

Пользователь (aspnet_Users):

· ApplicationId — id ПС, необходимо для хранения учетной записи пользователя для множества ПС;

· UserId — хранит уникальный порядковый номер пользователя;

· UserName — хранит выбранное пользователем имя;

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

· LastActivityDate — хранит дату, когда пользователь в последний раз регистрировался на сайте или в последний раз проходил аутентификацию.

Приложение (aspnet_Application):

· ApplicationId — хранит уникальный порядковый номер ПС;

· ApplicationName — хранит имя ПС;

· LoweredApplicationName — хранит имя приложения в нижнем регистре;

· Description — краткое описание ПС.

Членство (aspnet_Membership):

· ApplicationId — хранит уникальный порядковый номер ПС;

· UserId — хранит уникальный порядковый номер пользователя;

· Password — хранит пароль указанный пользователем;

· PasswordFormat — указывает формат, в котором пароль должен храниться. Возможные значения Clear, Encrypted, Hashed (В нашем ПС мы будем использовать Hashed);

· Email — хранит адрес электронной почты, указанной пользователем;

· LoweredEmail — хранит адрес электронной почты, в нижнем регистре;

· PasswordQuestion — хранит вопрос указанный пользователем, на случай восстановления пароля;

· PasswordAnswer — хранит ответ, на указанный пользователем пароль, на случай восстановления пароля;

· IsApproved — хранит пометку о том, была ли активизирована учетная запись пользователя;

· CreateDate — хранит дату регистрации пользователя.

· LastLogindate — хранит дату последний регистрации.

Роль (aspnet_Roles);

· ApplicationId — хранит уникальный порядковый номер ПС;

· RoleId — хранит уникальный порядковый номер роли;

· RoleName — хранит имя роли;

· LoweredRoleName — хранит имя роли в нижнем регистре;

· Description — хранит краткое описание роли.

ПользовательРоль (aspnet_UsersInRoles):

· UserId — хранит уникальный порядковый номер пользователя;

· RoleId — хранит уникальный порядковый номер роли.

Данная сущность выстраивает отношение между пользователем и доступными для него ролями.

Генерация базы данных

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

1. Создание Б Д;

2. Создание таблиц и полей;

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

Рассмотрим каждый из этих этапов более подробно.

Создание БД

Осуществление этого этапа будет производить при помощи Microsoft Visual Studio 2005. При нажатии на кнопку Tools в панели меню, выпадет список команд. Нажав на команду Connect to Database появляется окно (рис. 5), в котором выбираем название сервера из выпадающего списка, затем можно выбрать уже созданную ранее БД или ввести новое имя для БД, а так же можно прикрепить файл БД, если он был создан в другом месте.

Рис. 5

В нашем случае впишем новое название для базы ASPNETDB. На сервере в папке Data будет создана БД с таким названием. В Microsoft Visual Studio 2005, открыв Server Explorer, можно увидеть эту БД и список различных папок для работы с ней (рис. 6).

Рис. 6

Так же можно создать БД с помощью следующей SQL команды:

CREATE DATABASE ASPNETDB

Создание таблиц и полей

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

CREATE TABLE ASPNET_USERS (

APPLICATIONID UNIQUEIDENTIFIER NOT NULL,

USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

USERNAME NVARCHAR (256) NOT NULL,

LOWEREDUSERNAME NVARCHAR (256) NOT NULL,

LASTACTIVITYDATE DATETIME NOT NULL

)

CREATE TABLE ASPNET_APPLICATIONS (

APPLICATIONID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

APPLICATIONNAME NVARCHAR (256) NOT NULL,

LOWEREDAPPLICATIONNAME NVARCHAR (256) NOT NULL,

DESCRIPTION NVARCHAR (256) NULL

)

CREATE TABLE ASPNET_MEMBERSHIP (

APPLICATIONID UNIQUEIDENTIFIER NOT NULL,

REFERENCES APPLICATIONS (APPLICATIONID),

USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

REFERENCES USERS (USERID),

PASSWORD NVARCHAR (128) NOT NULL,

PASSWORDFORMAT INT NOT NULL,

EMAIL NVARCHAR (256) NULL,

LOWEREDEMAIL NVARCHAR (256) NULL,

PASSWORDQUESTION NVARCHAR (256) NULL,

PASSWORDANSWER NVARCHAR (128) NULL,

ISAPPROVED BIT NOT NULL,

CREATEDATE DATETIME NOT NULL,

LASTLOGINDATE DATETIME NOT NULL

)

CREATE TABLE ASPNET_ROLES (

APPLICATIONID UNIQUEIDENTIFIER NOT NULL,

REFERENCES APPLICATIONS (APPLICATIONID),

ROLEID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

ROLENAME NVARCHAR (256) NOT NULL,

LOWEREDROLENAME NVARCHAR (256) NOT NULL,

DESCRIPTION NVARCHAR (256) NULL

)

CREATE TABLE USERSINROLES (

ROLEID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

REFERENCES ROLES (ROLEID),

USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

REFERENCES USERS (USERID),

)

После выполнения вышеописанных запросов, мы получим необходимые нам таблицы и связи между ними (рис. 7).

Рис. 7.

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

Примеры использования запросов и хранимых процедур

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

Примеры использования запросов и хранимых процедур

Данный запрос позволяет отобразить все роли, которыми наделен пользователь «User»:

SELECT aspnet_Roles. RoleName

FROM aspnet_UsersInRoles INNER JOIN

aspnet_Users ON aspnet_UsersInRoles. UserId = aspnet_Users. UserId INNER JOIN

aspnet_Roles ON aspnet_UsersInRoles. RoleId = aspnet_Roles. RoleId

WHERE (aspnet_Users. UserName = 'User')

Данный запрос позволяет узнать, когда был зарегистрирован в системе пользователь «User»:

SELECT aspnet_Membership. CreateDate

FROM aspnet_UsersInRoles INNER JOIN

aspnet_Users ON aspnet_UsersInRoles. UserId = aspnet_Users. UserId INNER JOIN

aspnet_Roles ON aspnet_UsersInRoles. RoleId = aspnet_Roles. RoleId INNER JOIN

aspnet_Membership ON aspnet_UsersInRoles. UserId = aspnet_Membership. UserId

WHERE (aspnet_Users. UserName = 'User')

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

SELECT aspnet_Users. UserName, aspnet_Membership. IsApproved

FROM aspnet_UsersInRoles INNER JOIN aspnet_Users ON aspnet_UsersInRoles. UserId = aspnet_Users. UserId INNER JOIN

aspnet_Roles ON aspnet_UsersInRoles. RoleId = aspnet_Roles. RoleId INNER JOIN

aspnet_Membership ON aspnet_UsersInRoles. UserId = aspnet_Membership. UserId

WHERE (aspnet_Membership. IsApproved = 1)

Данная хранимая процедура, позволяет получить имя пользователя, зная его Email:

ALTER PROCEDURE dbo. aspnet_Membership_GetUserByEmail

@ApplicationName nvarchar (256),

@Email nvarchar (256)

AS

BEGIN

IF (@Email IS NULL)

SELECT u. UserName

FROM dbo. aspnet_Applications a, dbo. aspnet_Users u, dbo. aspnet_Membership m

WHERE LOWER (@ApplicationName) = a. LoweredApplicationName AND

u. ApplicationId = a. ApplicationId AND u. UserId = m. UserId AND

m. LoweredEmail IS NULL

ELSE

SELECT u. UserName

FROM dbo. aspnet_Applications a, dbo. aspnet_Users u, dbo. aspnet_Membership m

WHERE LOWER (@ApplicationName) = a. LoweredApplicationName AND

u. ApplicationId = a. ApplicationId AND

u. UserId = m. UserId AND

LOWER (@Email) = m. LoweredEmail

IF (@@rowcount = 0)

RETURN (1)

RETURN (0)

END

Данная хранимая процедура позволяет создать пользователя в системе:

ALTER PROCEDURE [dbo]. aspnet_Users_CreateUser

@ApplicationId uniqueidentifier,

@UserName nvarchar (256),

@IsUserAnonymous bit,

@LastActivityDate DATETIME,

@UserId uniqueidentifier OUTPUT

AS

BEGIN

IF (@UserId IS NULL)

SELECT @UserId = NEWID ()

ELSE

BEGIN

IF (EXISTS (SELECT UserId FROM dbo. aspnet_Users

WHERE @UserId = UserId))

RETURN -1

END

INSERT dbo. aspnet_Users (ApplicationId, UserId, UserName, LoweredUserName, IsAnonymous, LastActivityDate)

VALUES (@ApplicationId, @UserId, @UserName, LOWER (@UserName), @IsUserAnonymous, @LastActivityDate)

RETURN 0

END

В приложение Б детально показана структура базы данных.

4.3 Реализация пользовательского интерфейса

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

1) Открыть MS Visual Studio 2005.

2) Выбрать разрабатываемый проект.

Рис. 8. Шаг 1 и 2

3) Открыть окно Solution Explorer, правой кнопкой мыши кликнуть по названию проекта и выбрать пункт под названием Add New Item. Далее выбрать необходимый нам элемент, а именно Master Page.

Рис. 9. Шаг 3.

После того как мастер страница создана, в нее необходимо поместить следующий код:

< %@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage. master. cs" Inherits="MasterPage" %>

< !DOCTYPE html PUBLIC «-//W3C//DTD XHTML 1.0 Transitional//EN» «http: //www. w3. org/TR/xhtml1/DTD/xhtml1-transitional. dtd">

< html xmlns="http: //www. w3. org/1999/xhtml" >

< head runat="server">

< title>Система учета успеваемости< /title>

< /head>

< body>

< form id="form1″ runat="server">

< div id="header">

< div id="headerleft"> < /div>

< div id="headercenter" >

< table><tr><td width = 40> </td><td style="text-align:center"> Система учета успеваемости студентов< br />

на основе рейтинговой системы< br />

< br />

< small>web: <a href = «http: //speedy. dyndns. info» style="text-decoration:underline">http://speedy. dyndns. info</a></small> < /td></tr></table>

< /div>

< div id="headerright">

< div id="loginbox">

< asp: LoginView ID="LoginView1″ runat="server">

< AnonymousTemplate>

< asp: Login ID="Login1″ runat="server" DisplayRememberMe="False" DestinationPageUrl="~/forModerators/Def. aspx" LoginButtonText="Вход" TitleText="" PasswordLabelText="Пароль" UserNameLabelText="Имя" FailureText="Ошибка ввода данных">

< LayoutTemplate>

< table border="0″ cellpadding="1″ cellspacing="0″ style="border-collapse:collapse">

< tr>

< td>

< table border="0″ cellpadding="0">

< tr>

< td>

< asp: Label ID="UserNameLabel" runat="server" AssociatedControlID="UserName"> Имя</asp:Label></td>

< td>

< asp: TextBox ID="UserName" runat="server" Width="150px"> </asp:TextBox>

< asp: RequiredFieldValidator ID="UserNameRequired" runat="server" ControlToValidate="UserName"

ErrorMessage="User Name is required." ToolTip="User Name is required." ValidationGroup="ctl00 $ctl00 $Login1"> *</asp:RequiredFieldValidator>

< /td>

< /tr>

< tr>

< td>

< asp: Label ID="PasswordLabel" runat="server" AssociatedControlID="Password"> Пароль</asp:Label></td>

< td>

< asp: TextBox ID="Password" runat="server" TextMode="Password" Width="150px"> </asp:TextBox>

< asp: RequiredFieldValidator ID="PasswordRequired" runat="server" ControlToValidate="Password"

ErrorMessage="Password is required." ToolTip="Password is required." ValidationGroup="ctl00 $ctl00 $Login1"> *</asp:RequiredFieldValidator>

< /td>

< /tr>

< tr>

< td colspan="2″ style="color:red">

< asp: Literal ID="FailureText" runat="server" EnableViewState="False"> </asp:Literal>

< /td>

< /tr>

< tr>

< td colspan="2">

< asp: Button ID="Button2″ runat="server" CommandName="Login" Text="Вход" ValidationGroup="ctl00 $ctl00 $Login1″ />

< asp: Button ID="Button1″ runat="server" Text="Регистрация" OnClick="Button1_Click" />  

< /td>

< /tr>

< /table>

< /td>

< /tr>

< /table>

< /LayoutTemplate>

< /asp:Login>

< /AnonymousTemplate>

< LoggedInTemplate>

< div id="welcomebox">

< asp: LoginName ID="LoginName1″ runat="server" FormatString="Имя: {0}" /> <br />

< small>

< asp: HyperLink ID="lnkProfile" runat="server" Text="Изменить пароль" NavigateUrl="~/ChangePassword. aspx" /> <br />

< asp: LoginStatus ID="LoginStatus1″ runat="server" LogoutAction="Redirect" LogoutPageUrl="~/Default. aspx" LogoutText="Выход" />

< /small>

< /div>

< /LoggedInTemplate>

< /asp:LoginView>

< /div>

< /div>

< /div>

< div id="headermenu">

< asp: Table ID="Table1″ runat="server" Width="100%" Height="60px">

< asp: TableRow ID="TableRow1″ runat="server" HorizontalAlign="Center" VerticalAlign="Middle">

< asp: TableCell ID="TableCell1″ runat="server">

< asp: SiteMapDataSource ID="siteMapDataSource1″ runat="server" />

< asp: Menu ID="mnuHeader" runat="server" CssClass="headermenulink" DataSourceID="siteMapDataSource1″ Orientation="Horizontal" MaximumDynamicDisplayLevels="0″ SkipLinkText="" StaticDisplayLevels="2″ > </asp:Menu>

< /asp:TableCell>

< /asp:TableRow>

< /asp:Table>

< /div>

< div id="content">

< div id="leftcol">

< div id="leftcontent">

< table width = 120 border = 0 cellpadding=0 cellspacing=0 >

< tr>

< td>

<a href = «http: //banners. ru» class = «menu"> БАННЕРЫ</a><br />

< br />

<a href = «http: //adv. wiw. ru/adclick. php? n=a80785c2">

< asp: Image ID="Image2″ runat="server" ImageUrl="~/image/adview. php. gif" AlternateText="Баннер игры" Width="120px" /> </a><br />

< br />

< h5 class = «menu"> ЕЩЕ ССЫЛКИ

< asp: HyperLink ID="HyperLink1″ runat="server" NavigateUrl="~/About. aspx" CssClass="menu">О программе< /asp:HyperLink>

< asp: HyperLink ID="HyperLink2″ runat="server" NavigateUrl="http: //money. yandex. ru/" CssClass="menu"> Купить</asp:HyperLink>

<a href = «http: //yurok. homeip. net:8080» class = «menu"> Обменник</a>

< /h5>

<a href = «http: //vkontakte. ru/id5328106"><asp:Image ID="Image3″ runat="server» AlternateText="Я В сборной =)" ImageUrl="~/image/a_cb11fa37. jpg"

Width="120px" /> </a><br />

< /td>

< /tr>

< /table> < br />

< /div>

< /div>

< div id="centercol">

< div id="centercontent">

< table width="600″ border=0>

< tr><td valign="middle">

< asp: ContentPlaceHolder ID="MainContent" runat="server"> </asp:ContentPlaceHolder>

< /td></tr>

< /table>

< /div>

< /div>

< div id="rightcol">

< div id="rightcontent">

< /div>

< /div>

< /div>

< div id="footer">

< asp: Table ID="Table2″ runat="server" Width="100%" Height="60px">

< asp: TableRow ID="TableRow2″ runat="server" HorizontalAlign="Center" VerticalAlign="Middle">

< asp: TableCell ID="TableCell2″ runat="server">

< small>

Copyright & copy; BigMany-Company 2007 — 2008< br/>

Server by <a href = «http: //speedy. dyndns. info">Speedy</a><br/>

Дизайн и проект разработан Логачевым Ю. А. и Бондаревым Я. П.

< /small>

< /asp:TableCell>

< /asp:TableRow>

< /asp:Table>

< /div>

< /form>

< /body>

< /html>

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

< %@ Page Language="C#" MasterPageFile="~/MasterPage. master" AutoEventWireup="true" CodeFile="Default. aspx. cs" Inherits="_Default" Title="Система учета успеваемости: Главная страница" %>

< asp: Content ID="Content1″ ContentPlaceHolderID="MainContent" Runat="Server">

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

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

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

< asp: Button runat="server" ID="btnSearch" Text="Поиск" OnClick="btnSearch_Click" />

Или

Рис. 10. Добавление управляющего элемента «Button»

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

body

{

background-image: url (fonplus. jpg);

margin: 0px;

font: 12px Verdana, Tahoroa, sans-serif;

}

a

{

text-decoration: none;

color: #191 970;

}

a: hover

{

text-decoration: underline;

color: #191 970;

}

A IMG { border: none; }

#header

{

width: 100%;

height: 150px;

}

#headerleft

{

width: 15%;

float: left;

}

#headercenter

{

width: 55%;

float: left;

text-align: center;

font-size: 16px;

font-weight: bold;

margin-top: 45px;

}

#headerright

{

width: 30%;

float: left;

}

#loginbox

{

position: absolute;

top: 30px;

right: 5px;

}

#headermenu

{

width: 100%;

height: 60px;

background: url (menu. jpg) repeat-x;

}

. headermenulink

{

font: bold 18px Arial Black uppercase;

}

#content

{

width: 100%;

min-height: 300px;

float: left;

}

#leftcol

{

width: 25%;

float: left;

}

#centercol

{

width: 74%;

float: left;

}

#centercontent

{

margin: 15px;

text-align: left;

}

#leftcontent

{

margin: 15px;

text-align: right;

}

#rightcontent

{

margin: 0px;

}

a. menu: link,

a. menu: visited

{

font-weight: normal;

}

a. menu: active

{

color: Orange;

}

a. menu: hover

{

border-left-width: 7px;

border-left-style: solid;

border-left-color: #516A88;

color: #CF4343;

}

a. menu,

h5. menu

{

display: block;

padding: 2px;

text-align: center;

text-decoration: none;

background-color: #FAFAFA;

font-weight: normal;

border-top: 1px solid #516A88;

color: #191 970;

}

#rightcol

{

width: 18%;

float: left;

}

#footer

{

float: left;

width: 100%;

height: 60px;

background: url (menu. jpg) repeat-x;

}

#ramka

{

PADDING-RIGHT: 4px;

PADDING-LEFT: 4px;

BORDER-LEFT-COLOR: #333 399;

BORDER-BOTTOM-COLOR: #333 399;

PADDING-BOTTOM: 4px;

MARGIN: 4px;

CURSOR: help;

BORDER-TOP-STYLE: inset;

BORDER-TOP-COLOR: #333 399;

PADDING-TOP: 4px;

BORDER-RIGHT-STYLE: inset;

BORDER-LEFT-STYLE: inset;

BACKGROUND-COLOR: #ffff66;

TEXT-ALIGN: justify;

FONT-VARIANT: small-caps;

BORDER-RIGHT-COLOR: #333 399;

BORDER-BOTTOM-STYLE: inset

}

4.4 Реализация функциональности ПС

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

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

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

using System. Web. Security;

using System. Web. UI;

using System. Web. UI. WebControls;

using System. Web. UI. WebControls. WebParts;

using System. Web. UI. HtmlControls;

using System. Data. SqlClient;

using System. Web. Configuration;

/// Summary description for BasePage

/// < /summary>

public class BasePage: System. Web. UI. Page

{

}

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

public partial class Account: BasePage

{

public class ImageTemplate: ITemplate — класс унаследованный от интерфейса, при помощи которого создаются шаблоны графических изображений;

public class LabelTemplate: ITemplate — класс унаследованный от интерфейса, при помощи которого создаются шаблоны текстовых полей;

public class DropDownListTemplate: ITemplate — класс унаследованный от интерфейса, при помощи которого создаются шаблоны выпадающих списков;

public class CheckboxTemplate: ITemplate — класс унаследованный от интерфейса, при помощи которого создаются шаблоны чекбоксов;

private void BindNameThem () — функция отвечает за наполнение конкретного элемента темами;

private void DelUp () — функция отвечает за обновление конкретных элементов по наступлению событий обновить, удалить;

private void BingGrid1Proc () — функция наполняет необходимый элемент процентным значениями;

private void AddNewThem () — функция отвечает за добавление новой темы;

private void TxBoxBind () — функция отвечает за наполнение определенного текстового поля конкретной информацией;

private void ChBox () — функция наполняет определенный элемент, элементами типа чекбокс;

private void Dd () — функция отвечает за обновление и наполнение данными, целого ряда элементов;

private void BindGrid () — функция наполняет определенный элемент данными;

protected bool PreDetected (string value) — функция производит определенную проверку данных по полученному значению;

public void Detected (int b) — функция производит определенную проверку данных по полученному значению; }

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

4.5 Организация взаимодействия приложения с БД

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

1) Прописать в конфигурационном файле настройки.

< ?xml version="1. 0″ encoding="UTF-8″?> <!--

--> <configuration xmlns="http: //schemas. microsoft. com/. NetConfiguration/v2. 0">

< connectionStrings>

< add name="aspnetdb" providerName="System. Data. SqlClient" connectionString="Data Source=. SQLExpress; integrated Security=True; User Instance=True; AttachDBFilename=|DataDirectory|ASPNETDB. MDF" />

< /connectionStrings>

2)Получить строку подключения к серверу БД.

public string Connect (){

string connString = WebConfigurationManager. ConnectionStrings["LocalSqlServer"]. ConnectionString;

return connString; }

3)Открыть соединение с сервером по полученной стороке подключения.

SqlConnection thisConnection1 = new SqlConnection (Connect ());

thisConnection1. Open ();

4)Написать необходимый запрос на сервер.

string query = «Insert INTO Thems (name_them, data) VALUES (@name_them, @data)»;

5)Создать команду для выполнения запроса по существующему соединению.

SqlCommand cmd = new SqlCommand (query, thisConnection1);

6)Добавить параметры запроса в комманду.

cmd. Parameters. AddWithValue («@name_them», TextBox1. Text);

cmd. Parameters. AddWithValue («@data», timeVr);

7)Выполнить комманду.

cmd. ExecuteNonQuery ();

8)Закрыть соединение.

thisConnection1. Close ();

5 Тестирование ПС

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

* Регистрация существующего пользователя;

Ответ: пользователь с таким именем уже существует.

* Не все обязательные поля заполнены;

Ответ: невозможность совершения дальнейшего действия.

* Ввод разных данных в поля пароль и подтвердить пароль;

Ответ: неверно подтвержден пароль.

* Ввод почтового адреса, принадлежащего зарегистрированному пользователю;

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

* Попытки зайти под несуществующим логином или неверным паролем;

Ответ: ошибка ввода данных.

* Попытка сохранить данные по посещаемости иили успеваемости без указания темы занятия;

Ответ: необходимо указать тему предмета.

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

Заключение

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

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

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

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

Приложение А

Введение

Цель

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

Краткое содержание

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

Позиционирование

Деловые преимущества

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

Определение проблемы

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

Затрагивает: преподавателей

Следствие: значительная нагрузка на преподавателя

Решение: создание автоматизированной системы обработки оценок и выставления рейтингов, формирования отчетов

Проблема: оповещение студентов в случаях долгов и не аттестаций

Затрагивает: преподаватель

Следствие: значительная нагрузка на преподавателя

Решение: автоматизация процесса оповещения студентов

Определение позиции изделия

Для: образовательных учреждений, в частности ВГТУ

Которой: требуется автоматизировать процесс учета успеваемости студентов

Название

продукта: рейтинговая система успеваемости студентов

Который: автоматически подсчитывает рейтинги студентов и готовит отчеты

В отличие от: ручного процесса обработки данных

Наш продукт: Упрощает процесс учета успеваемости студентов

Описания пользователей

Сведения о пользователях

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

— Администратор (несет полную ответственность за работоспособность данной системы и все ошибки и неполадки, в ней возникающие);

— Модератор / сомодератор (отвечают за конкретные модули программной среды назначенные им администратором);

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

— Студент (просматривает модули программы которые отвечают за предоставление данных по успеваемости, рейтингу, аттестации и др.)

Пользовательская среда

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

Профили пользователей

Типичный представитель

Студент

Описание

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

Тип

Пользователь

Ответственности

Регулярно просматривать свои данные, реагировать на оповещения.

Критерий успеха

Возможность узнать свой рейтинг и данные об аттестации в любой момент времени.

Типичный представитель

Преподаватель

Описание

Пользователь системы, наделенный правами на управление своим предметом.

Тип

Пользователь

Ответственности

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

Критерий успеха

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

Типичный представитель

Администратор

Описание

Пользователь системы, наделенный всеми правами

Тип

Пользователь

Ответственности

Поддерживать работоспособность всего ресурса

Критерий успеха

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

Типичный представитель

Модератор

Описание

Пользователь системы, наделенный полными правами в каком-либо разделе ресурса.

Тип

Пользователь

Ответственности

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

Критерий успеха

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

Типичный представитель

СоМодератор или помошник модератора

Описание

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

Тип

Пользователь

Ответственности

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

Критерий успеха

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

Ключевые потребности пользователей

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

Краткий обзор изделия

Контекст использования системы

Система является законченной независимой разработкой.

Сводка возможностей

Выгоды заказчика

Поддерживающие возможности

Снижение трудоемкости преподавателя

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

Повышение эффективности самоконтроля

Студент может в любой момент времени получить данные о своей успеваемости и аттестации.

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

Система будет использоваться в образовательных учреждениях, в том числе и в ВУЗе.

Возможности продукта

Структурированное описание заказа

Возможность учета успеваемости студента на основе рейтинговой системы.

Расчёт нормативного времени выполнения работ заказа

Выполнение заказа по времени зависит от количества одновременных обращений к приложению и примерно составляет около 2−7 секунд. Так как осуществляется запрос и выборка данных из СУБД, а затем их передача до клиента.

Ограничения

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

Показатели качества

Применимость

Время, необходимое для обучения обычных пользователей — 20 минут, для обучения продвинутых пользователей — 5 минут.

· Время отклика для типичных задач — не более 3 секунд

Надежность

Доступность — время, затрачиваемое на обслуживание системы не должно превышать 1% от общего времени работы.

Среднее время безотказной работы — 90 рабочих дней.

Максимальная норма ошибок или дефектов — 1 ошибка на десять тысяч строк кода.

Другие требования к изделию

Применяемые стандарты

Система должна соответствовать всем стандартам интерфейса пользователя Microsoft® Windows® и Microsoft. NET Framework 2.0.

Системные требования

Минимальные системные требования:

256 Mb памяти

50 Mb свободного дискового пространства

процессор с тактовой частотой 1000 MHz

Операционная система Windows Server 2003/2008

Эксплуатационные требования

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

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

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

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

Интерактивная справка

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

ПоказатьСвернуть
Заполнить форму текущей работой