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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

3.3.1.1. процессор Pentium-2.0Hz, не менее;  
3.3.1.2. оперативную память объемом, 2Гигабайт, не менее;  
3.3.1.3. HDD, 80 Гигабайт, не менее;  
3.3.1.4. операционную систему Windows 2000 Server или Windows 2003; 
3.3.1.5. Interbase

 

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

 

 

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

 

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

 

3.4.1.1. Структура баз данных

Смотреть по документу ниже

 

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

 

Администраторы системы должны иметь возможность редактировать  таблицы базы данных (добавление, редактирование)

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

 

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

 

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

 

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

 

Системные программные  средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 2000 Server или Windows 2003 и Interbase.

 

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

 

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

 

3.5. Специальные требования

 

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

 

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

 

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

 

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

 

5. Технико-экономические  показатели

 

5.1. Экономические преимущества разработки

 

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

 

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

 

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

 

Разработка должна быть проведена в три стадии:  
1. разработка технического задания;  
2. рабочее проектирование;  
3. внедрение.

 

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

 

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

1. разработка программы;  
2. разработка программной документации;  
3. испытания программы.

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

 

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

 

На этапе разработки технического задания должны быть выполнены  перечисленные ниже работы:  
1. постановка задачи;  
2. определение и уточнение требований к техническим средствам;  
3. определение требований к программе; 
4. определение стадий, этапов и сроков разработки программы и документации на неё;  
5. согласование и утверждение технического задания.  
На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.  
На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации.  
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:  
1. разработка, согласование и утверждение и методики испытаний;  
2. проведение приемо-сдаточных испытаний;  
3. корректировка программы и программной документации по результатам испытаний.  
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика.

 

7. Порядок контроля  и приемки

 

7.1. Виды испытаний

 

Приемо-сдаточные испытания  должны проводиться на объекте Заказчика  в оговоренные сроки.  
Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний.  
Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний

 

7.2. Общие требования  к приемке работы

 

На основании Протокола  проведения испытаний Исполнитель  совместно с Заказчиком подписывает  Акт приемки-сдачи программы в  эксплуатацию

 

 

 

Разработка  формальной модели решения задачи

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

• администратор системы;
• директор/завуч;
• классный руководитель/преподаватель;
• учащийся;
• родитель;
• технический персонал.

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

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

Разрабатываемая программа - комплексный программный продукт, области применения которого включают:

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

Рис. 1. Модель построения системы

 

 

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

 

Проектирование физической структуры  таблиц базы данных и связей осуществлялось при помощи инструментальной среды Erwin фирмы LogicWorks. ERWin - средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных.

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

В ERwin существуют два уровня представления и моделирования — логический и физический. Логический уровень означает прямое отображение фактов из реальной жизни.

Целевая СУБД, имена объектов и  типы данных, индексы составляют второй (физический уровень модели Erwin).

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

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

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

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

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

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

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

- генерация базы данных.

Опишем атрибуты выделенных ранее  сущностей предметной области:

Учащийся:

- полное имя;

- пол;

- дата рождения;

- дата поступления;

- дата выбытия;

- адрес прописки;

- социальное положение;

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

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

- дата постановки диагноза;

- поставленный диагноз;

- физкультурная группа.

Родитель:

- полное имя;

- дата рождения;

- контактный телефон;

- комментарий.

Класс:

- год обучения;

- буква;

Предмет:

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

Учебная программа:

- название предмета;

- год обучения.

Оценки Учащихся:

- полное имя учащегося;

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

Родители Учащихся:

- полное имя учащегося;

- полное имя родителя.

Дополнительная декомпозиция отношений  не выполнялась, так как связи  «многие-ко-многим» отсутствуют.

Проведем  последовательную нормализацию схем отношений.

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

Рассмотрим  отношение 

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

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

Разбиваем отношение на 4 отношения:

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

R2 (полное имя, социальное положение)

R3 (полное имя, поставленный диагноз)

R4 (полное имя, физкультурная группа)

Данные отношения находятся в 1NF.

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

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

R2 (код ребенка, полное имя, социальное положение)

R3 (код ребенка, полное имя, поставленный диагноз)

R4 (код ребенка, полное имя, физкультурная группа)

Данные отношения находятся в 2NF. Устанавливаем отношения между этими таблицами и проверяем таблицы на соответствие их третьей нормальной форме (3NF).