Разработка информационной подсистемы по учету персональных данных для Благовещенского филиала СГА



Отношение 1

id студента	ФИО	Дата рождения	Пас-порт	Кем выдан	Прописка	Дата выдачи	Номер телефо-на	Дата поступ-ления	Дата выпус-ка

Отношение 2

id оплаты	id студента	Сумма

Рисунок 6 - Результат анализа связи «Студенты - Оплата»

Рассмотрим двунаправленную связь разного типа «Группы - Студенты», показанную на рисунке 7.

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

Сущность «Группы»

id группы	Номер	Специальность

Сущность «Студенты»

id студента	ФИО	Дата рождения	Пас-порт	Кем выдан	Пропис-ка	Дата выдачи	Номер телефо-на	Дата поступ-ления	Дата выпус-ка

Рисунок 7 - Связь «Группы - Студенты»

Отношение 3

id группы	Номер группы	Специальность

Отношение 4

id студента	id группы	ФИО	Дата рождения	Паспорт	Кем выдан



Прописка	Дата выдачи	Номер телефона	Дата поступления	Дата выпуска

Рисунок 8 -Результат анализа связи «Группы - Студенты»

Рассмотрим двунаправленную простую связь «Стоимость- Группы», показанную на рисунке 9.

Сущность «Стоимость»

id цены	Сумма

Сущность «Группы»

id группы	Номер	Специальность

Рисунок 9 - Связь «Стоимость - Группы»

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

Отношение 5

id группы	Номер	Специальность

Отношение 6

id цены	id группы	Сумма

Рисунок 10 - Результат анализа связи «Стоимость-Группы»

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

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

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

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

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

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

2.6.3 Физическое проектирование

Целью физического проектирования является представление логического проектирования в форме, пригодной для реализации в конкретной СУБД. При физическом проектировании происходит трансформация сущностей в таблицы, а атрибутов в поля [10].

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

Отношение 1 - таблица «Студенты»;

Отношение 2 - таблица «Студенты-Оплата»;

Отношение 3 - таблица «Группы»;

Отношение 4 - таблица «Студенты-Группы»;

Отношения 5 - таблица «Группы-Стоимость».



Таблица 6 - Физическое представление отношения «Студенты»

Название поля	Тип данных	Условия	Индексация
1	2	3	4
id студента	Числовой	>0	Да
ФИО	Текстовый	-	Да
Дата рождения	Дата/время	-	Нет
Паспорт	Числовой	-	Да
Кем выдан	Текстовый	-	Нет
Прописка	Текстовый	-	Нет
Дата выдачи	Дата/время	-	Нет
Номер телефона	Текстовый	-	Да
Год поступления	Числовой	-	Да
Год выпуска	Числовой	-	Да

Таблица 7 - Физическое представление отношения «Студенты-Оплата»

Название поля	Тип данных	Условия	Индексация
1	2	3	4
id оплаты	Числовой	>0	Да
id студента	Числовой	>0	Да
Оплата	Числовой	-	Да

Таблица 8 - Физическое представление отношения «Группы»

Название поля	Тип данных	Условия	Индексация
1	2	3	4
id группы	Числовой	>0	Да
Номер группы	Числовой	-	Да
Специальность	Тектовый	-	Да

Таблица 9 - Физическое представление отношения «Студенты-Группа»

Название поля	Тип данных	Условия	Индексация
1	2	3	4
id студента	Числовой	>0	Да
id группы	Числовой	>0	Да
ФИО	Текстовый	-	Да
Дата рождения	Дата/время	-	Нет
Паспорт	Числовой	-	Да
Кем выдан	Текстовый	-	Нет
Прописка	Текстовый	-	Нет
Дата выдачи	Дата/время	-	Нет
Номер телефона	Текстовый	-	Да
Год поступления	Числовой	-	Да
Год выпуска	Числовой	-	Да

Таблица 10 - Физическое представление отношения «Группа-Стоимость»

Название поля	Тип данных	Условия	Индексация
1	2	3	4
id стоимости	Числовой	>0	Да
id группы	Текстовый	-	Да
Сумма	Числовой	-	Да

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



3. НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.1 Понятие надежности программного обеспечения

Значимость надежности как одного из главных характеристик качества программного обеспечения массового применения еще более возрастает в условиях индустриального производства программ, когда программное обеспечение выступает в качестве программной продукции [26]. Свойство надежности во всех нормативных документах обязательно входит в систему показателей качества программного обеспечения, тем самым подчёркивая важность этого свойства. В теории надежности существуют свои основные понятия. К ним в первую очередь относятся понятия надежности.

Даны основные понятия, термины и определения по ГОСТ 27.002 - 89 - «Надежность в технике».

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

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

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

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



3.2 Понятие отказа

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

Далее приведены основные термины понятия отказа по ГОСТ 27.002 - 89 - «Надежность в технике».

Отказ - событие, заключающееся в нарушении работоспособного состояния объекта.

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

Причина отказа - явления, процессы, события и состояния, вызвавшие возникновение отказа объекта.

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

Критичность отказа - совокупность признаков, характеризующих последствия отказа [17].

Отказы можно разделить на [9]:

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

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

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

- эргатические - возникают из-за некорректных действий пользова-телей.

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

3.3 Модели надежности программного обеспечения

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

Модели надежности программного обеспечения можно разделить на две группы:

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

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

Аналитические модели так же можно разделить на две группы:

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

статические, в которых появление отказов не связано со временем, а учитывается число количества ошибок от числа тестовых программ [20].

Приведем примеры каждого вида моделей надёжности программного обеспечения:

аналитические динамические модели: модель Шумона, модель Ла Падула, модель Джелинского - Моранды, модель Шика -- Волвертона, модель Муса, модель переходных вероятностей;

аналитические статические модели: модель Миллса, модель Липова, простая интуитивная модель, модель Коркорэна, модель последовательностей испытаний Бернулли, модель Нельсона;

эмпирические модели: модель сложности, модель определяющая время доводки программы.

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

3.4 Простая интуитивная модель

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

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

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

(1)

Где

(2)

(3)

N- общее число ошибок в программе;

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

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

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

3.5 Расчёт надежности по простой интуитивной модели

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

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

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

N1.1 = 3;

N2.1 = 6;

N12.1 = 6;

E1.1 = N1.1/ N12.1 = 3/6;

E2.1 = N2.1/ N12.1 = 1;

N1 = 12.

Получается, что число ошибок, обнаруженных обоими пользователями, составило 6, а значения коэффициентов E1 и E2 в соответствии с формулами (2) и (3) - 3/7 и 1соответственно. Предполагаемое общее число ошибок в программе рассчитанное по формуле (1) и составило 12 ошибок.

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

N1.2 = 2;

N2.2 = 3;

N12.2 = 4;

E1.2 = N1.2 / N12.2 = 2/4;

E2.2 = N2.2 / N12.2 = 3/4;

N2 = 10.

Таким образом, общее число ошибок составило 4, а значения коэффициентов E1 и E2 в соответствии с формулами (2) и (3) - 2/4 и 3/4 соответственно. Предполагаемое общее число ошибок в программе вновь было рассчитано по формуле (1) и составило 10 ошибки (4 из которых были успешно найдены и ликвидированы).

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

N1.3 = 2;

N2.3 = 1;

N12.3 = 2;

E1.3 = N1.3 / N12.3 = 1/2;

E2.3 = N2.3 / N12.3 = 1;

N3 = 4.

Таким образом, число обнаруженных составило 2, а значения коэффициентов E1 и E2 в соответствии с формулами (2) и (3) - 1/2 и 1 соответственно. Предполагаемое общее число ошибок в программе вновь было рассчитано по формуле (1) и составило 4 ошибки (3 из которых были успешно найдены и ликвидированы).

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

Результаты тестирования занесены в таблицу 10.

Таблица 14 - Результаты тестирования

Номер теста	N1.i	N2.i	N12.i	E1.i	E2.i	Ni
1	3	6	6	3/6	1	12
2	3	2	4	3/4	0.5	10
3	2	1	2	0.5	1	4
4	1	1	1	1	1	1

На рисунке 1 изображен график зависимости количества предполагаемых ошибок N от номера теста i.

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

Рисунок 11 - Зависимость количества ошибок N от количества тестов



4. РЕАЛИЗАЦИЯ

4.1Описание разработанного программного обеспечения

На данный момент реализованы модули подсистемы такие, как «Идентификация», «Студенты», «Оплата», «Отчёты», «Работа с БД». Рассмотрим каждый из них.

«Идентификация»

Данная подсистема реализована на языке PHP, с использованием запросов на языке SQL, для оформления внешнего вида применяются язык HTML и каскадные страницы стилей CSS. Отвечает подсистема за разграничение доступа пользователей.

Рисунок 12 - Модуль «Идентификация»

При правильном вводе логина и пароля, пользователю открывается приветственное окно.

Рисунок 13 - Приветственное окно

В случае неправильного ввода пользователь увидит сообщение об ошибке.

2. «Студенты»

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

Рисунок 14 - Модуль «Студенты»

Модуль так же реализован на языке PHP, используются запросы на языке SQL, для оформления внешнего вида применяются язык HTML и каскадные страницы стилей CSS.

3. «Оплата»

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

Модуль «Оплата» реализован на языке PHP, используются запросы на языке SQL, для оформления внешнего вида применяются язык HTML и каскадные страницы стилей CSS.

Рисунок 15 - Модуль «Оплата»



4. «Отчёты»

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

Рисунок 16 - Модуль «Отчёты»

Модуль реализован на языке PHP, используются запросы на языке SQL, для оформления внешнего вида применяются язык HTML и каскадные страницы стилей CSS.

5.«Работа с БД»

Модуль предназначен для выполнения запросов. Пользователь отправляет запрос по средствам языка SQL через экранные формы. Запрос обрабатывается и выдается результат.

Примеры экранных форм

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

Форма внесения данных

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



Рисунок 17 - Форма внесения данных о студенте

Форма внесения данных о новой группе аналогична форме внесения данных о студенте.

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

В форме для редактирования возможно удаление или изменение уже существующих данных.

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

Рисунок 18 - Форма выбора данных для редактирования

Рисунок 19 - Форма для редактирования



Форма отчёта

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

Рисунок 20 - Форма для выбора отчёта

Рисунок 21 - Пример отчёта

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

Руководство пользователя предназначено для сотрудников Благовещенского филиала СГА.

Для авторизации в системе введите имя пользователя и пароль, выданные вам администратором системы, в соответствующие поля, если у вас нет данных вход вам не доступен (Рисунок 12).

После авторизации в системе выберите нужную вкладку (Рисунок 13).

Вкладка студенты содержит формы для поиска, внесения, редактирования данных о студентах и группах (Рисунок 14). Для того что бы внести новые данные о студенте нажать кнопку «Внесение данных», после чего заполнить все поля и нажать «Внести данные». Для поиска нужной информации необходимо нажать кнопку «Поиск данных», ввести нужные критерии для поиска, нажать кнопку «Найти и вывести». Система обработает ваш запрос и выведет полученный результат. Для удаления или редактирования данных нажмите кнопку «Редактирование данных» (Рисунок 18). Внесите необходимые корректировки и сохраните.

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

Вкладка «Отчёт» содержит формы для выдачи отчётов. Для того, что бы получить необходимый отчёт, нужно выбрать критерий для формирования отчёта и нажать кнопку «Найти и вывести». Далее полученный отчёт вы можете сохранить или распечатать (Рисунок 20).

ЗАКЛЮЧЕНИЕ

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

проведен анализ деятельности предприятия;

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

определены и описаны функциональные и обеспечивающие подсистемы;

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

проведено проектирование базы данных;

разработан проект информационной подсистемы;

реализована информационная подсистема.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Мазуркевич, А.В. MB РНР: Настольная книга программиста / Мазуркевич А.В. - М.: Новое знание, 2003. -- 480 с.

Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. [Электрон. Ресурс].

Волкова В.Н. Информационные системы: Учеб. пособие / Под ред. В.Н. Волковой, Б.И. Кузина. - СПб.: СПбГТУ, - 2001. - 216 с.

Гарсиа-Молина, Г. Системы баз данных: Полный курс. / Г. Гарсиа-Молина, Д.Д. Ульмон, Д. Уидом.- М. : Вильямс, 2011. - 1088 с.

Гвоздева, Т.В. Проектирование информационных систем : учеб. Пособие / Т.В. Гвоздева, Б.А. Баллод. - Ростов н/Д : Феникс, 2009. - 508 с.

Голицына, О.Л. Информационные системы: учеб. пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. - М.: ФОРУМ: ИНФРА-М, 2008. - 496 с.

Грекул, В.И. Проектирование информационных систем / В.И.Грекул - М : Интернет-университет информационных технологий, 2005. - 304 с.

Зандстра, М. PHP. Объекты шаблоны и методики программирования / М.Зандстра.- М. : Вильямс, 2011. - 560 с.

Карповский, Е.Я., Чижов, С.А. Надежность программной продукции / Е.Я Карповский, С.А Чижов. - К.: Тэхника, 1990. - 160 с.

Кириллов, В.В. Основы проектирования реляционных баз данных. [Электрон. Ресурс].

Криницкий, Н.А. Автоматизированные информационные системы / Н.А. Криницкий, Г.А. Миронов, Г.Д. Фролов. - Л.: Наука, 1982. - 382 c.

Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем / С.В Маклаков. - М.: «Диалог-МИФИ», 2013 - 306 с.

Майерс, Г. Надежность программного обеспечения: моногр. / Г. Майерс. - М.: Мир, 2008. - 360 c.

Мартишин, С.А. Основы теории надежности информационных систем: учеб. пособие /С.А. Мартишин . - М.: Инфра-М, Форум, 2015. - 256 с.

Муссиано, Ч. HTML и XHTML. Подробное руководство, 6-е издание / Ч.Муссиано. - СПб: Символ-Плюс, 2008. - 752 с.

. Печерский, В.В. Внедрение ERP-решений на платформе «1С:Предприятие 8»» / В.В. Печерский. - СПб: БХВ-Петербург, 2015. - 160 с.

Таейр, Т. Надежность программного обеспечения / Т. Таейр, М. Липов, Э. Нельсое. - М.: ИЛ, 2008. - 323 c

Сиганова,Т.В. Делопроизводство и документооборот: Учебное пособие / Т.В. Сиганова. - Омск: Омск. Гос. Ун-т, 2004. - 71 с.

Советов, Б.Я. Информационные технологии: Учебник для вузов / Б.Я. Советов, В.В. Цехановский. - М.: Высшая шк., 2005. - 263 с.

Суханова, Н.В., Кабак, И.С. Курс лекций по дисциплине «Надежность и тестирование программного обеспечения»/ Н.В. Суханова, И.С. Кабак.-М.: МГТУ «Станкин», 2013.-61 с.

Таненбаум, Э. Компьютерные сети: 5-е издание. / Э. Таненбаум.- М.: Питер, 2012. - 992 с.

Титтел Э., Ноубл Дж. HTML, XHTML и CSS для чайников, 7-е издание / Э. Титтел, Дж.Ноубд.М-Диалектика, 2011. -- 400 с.

Томсон Л. Разработка Web-приложений на РНР и MySQL /Л. Томсон. - : СПб: ООО «ДиаСофтЮП», 2003. -- 672 с.

Ульман, Д., Уидом, Д. Введение в системы баз данных / Д. Ульман, Д. Уидом. - : М.: «Лори», 2000. - 374с.

Ульман, Л. MySQL. Руководство по изучению языка. / Л. Ульман. - М. : «ДМК Пресс», 2009. - 356 с.

Усенко, О.А. Модели и методы оценки надежности программного обеспечения информационных систем: учеб. пособие. /О.А. Усенко. - Таганрог: ТТИ ЮФУ, 2008. - 40 с.

Хольцнер, С . РНР в примерах. / С. Хольцнер. - М.: «Бином-Пресс», 2007. - 352 с.

Хансен, Г., Хансен, Д. Базы данных. Разработка и управление. / Г.Хансен, Д. Хансен. - М.: Бином, 2000. - 704 с.

Хомоненко, А.Д., Цыганков, В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений/ А.Д. Хомоненко, В.М Цыганков, М.Г Мальцев. - СПб.: «КОРОНА принт», 2002. - 672с.

Шаньгин, В. Ф. Информационная безопасность. / В. Ф Шаньгин. - М.: «ДМК-Пресс», 2014. - 702 с.



ПРИЛОЖЕНИЕ А

Организационная структура Благовещенского филиала СГА

Рисунок А1 - Организационная структура Благовещенского филиала СГА



ПРИЛОЖЕНИЕ Б

Документооборот Благовещенского филиала СГА

Рисунок В1 - Внешний документооборот

Рисунок В2 - Внутренний документооборот



ПРИЛОЖЕНИЕ В

Схема локальной вычислительной сети Благовещенского филиала СГА

Рисунок В1 - Схема локальной вычислительной сети



ПРИЛОЖЕНИЕ Г

Концептуальная и функциональная модели подсистемы

Рисунок Г1 - Концептуальная модель подсистемы

Рисунок Г2 - Функциональная модель подсистемы



ПРИЛОЖЕНИЕ Д

Логическая и физическая модель данных

Рисунок E1 - Логическая модель данных

Рисунок E2 - Физическая модель данных

ПРИЛОЖЕНИЕ Е

Техническое задание

1 Общие сведения

1.1 Полное наименование системы и ее условное обозначение

Информационная подсистема по учету персональных данных для Благовещенского филиала СГА

СГА - Современная гуманитарная академия;

ИПСУПДС - информационная подсистема по учету персональных данных

1.2 Шифр темы

ИПС-УПДС

1.3 Наименование предприятий разработчика и заказчика системы, их реквизиты

Заказчик: Благовещенский филиал СГА.

Реквизиты заказчика: г. Благовещенск, ул. Политехническая, 82/2.

Разработчик: студентка четвертого курса физико-математического факультета, специальности «Информационные системы и технологии» Благовещенского государственного педагогического университета Калашникова Оксана Сергеевна.

1.4 Перечень документов, на основании которых создается подсистема

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

1.5 Плановые сроки начала и окончания работ

Срок начала работ: 25.01.2015 г.

Срок окончания работ: 1.06.2015 г.

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

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

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

2 Назначение и цели создания подсистемы

2.1 Назначение подсистемы

Информационная подсистема необходима для:

1.Хранения данных;

Оперативного доступа к данным, хранящимся на сервере, с любого компьютера, подключенного к сети филиала СГА;

3.Добавление новых данных на сервер СГА с любого компьютера, подключенного к сети СГА;

4.Разграничение прав доступа к файлам;

5. Формирование отчетов в электронном и печатном виде;

6. Формирование запросов по определенным критериям.

2.2 Цели создания подсистемы

Целями создания подсистемы являются:

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

- сокращение времени поиска необходимых данных и предоставление дополнительной информации;

- удобство для сотрудников;

- надежное и эффективное хранение данных с разграничением прав доступа;

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

В результате создания подсистемы должны быть улучшены значения следующих показателей:

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

время, затрачиваемое на информационно-аналитическую деятельность.

3 Характеристика объекта автоматизации

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

До внедрения системы:

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

После внедрения:

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

4 Требования к системе

4.1 Требования к системе в целом

4.1.1 Требования к структуре и функционированию подсистемы

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

4.1.2 Требования к численности и квалификации персонала системы и режиму его работы

В состав персонала, необходимого для обеспечения эксплуатации ИПСУПДС в рамках соответствующих подразделений Заказчика, необходимо выделение следующих ответственных лиц:

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

- пользователь (сотрудник), который может просматривать соответствующие данные, вносить корректировки и дополнять БД;

- техник - сотрудник, обеспечивающий функционирование технических средств;

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

- самостоятельно включать и отключать ПК и периферийное оборудование от электропитания;

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

- вводить данные с клавиатуры;

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

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

К администратору ИПСУПДС, помимо требований, предъявляемых выше, предъявляются перечисленные ниже дополнительные требования:

- знание состава и структуры баз данных, применяемых в подсистеме УПДС;

- способность решать задачи администрирования ИПСУПДС;

- знание методов и приемов работы с модулями разрабатываемой подсистеме УПДС;

- установку и настройку параметров функционирования СУБД;

- диагностические процедуры по определению целостности БД средствами СУБД;

- резервное копирование и восстановление данных средствами СУБД и общего программного обеспечения.

К технику предъявляются перечисленные ниже требования:

- защита данных;

- модернизация существующего ПО и установка нового;

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

- защита сети от вирусов;

- поддержка работоспособности рабочих станций.

Возможно совмещение обязанностей администратора и техника.

4.1.3 Требования к показателям назначения подсистемы

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

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

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

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

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

Требования к надежности системы устанавливаются в соответствии со следующими стандартами:

- ГОСТ 27.002-89 Надежность в технике. Основные понятия. Термины и определения;

- ГОСТ 27.003-90 Надежность в технике. Состав и общие правила задания требований по надежности.

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

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

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

предупреждение ошибок пользователей и правильная реакция на возникшие ошибки.

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

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

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

4.1.5 Требования безопасность

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

Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».

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

Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».

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

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

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

4.1.6 Требования к эргономике

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

дизайн экранных форм должен быть удобен и понятен;

эргономические решения должны быть едиными для всех компонентов и модулей подсистемы;

интерфейс пользователей должен способствовать уменьшению вероятности совершения случайных ошибочных действий;

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

4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов подсистемы

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

Условия эксплуатации оборудования рабочих мест сотрудников должны соответствовать нормальным климатическим условиям, определенным в ГОСТ 27201-87 и иметь следующие значения:

температура воздуха от 15С до 25С;

относительная влажность от 45% до 75% при 25С;

атмосферное давление от 630 мм. рт. ст. до 800 мм. рт. ст;

Электропитание технических средств подсистемы должно осуществляться от сети 220В (50Гц).

Ремонт вычислительной техники должен производиться в специализированных сервисных центрах квалифицированным персоналом.

4.1.8 Требования к защите информации от несанкционированного доступа

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

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

ИПСУПДС должна соответствовать требованиям РД Гостехкомиссии РФ "Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации" предъявляемым к системам с классом защиты 1Г.

4.1.9 Требования к защите от влияния внешних воздействий

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

4.2 Требования к видам обеспечения

4.2.1 Требования к информационному обеспечению

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

- информацию о зарегистрированных пользователях;

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

- информационные сообщения и объявления.

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

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

4.2.2 Требования к лингвистическому обеспечению

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

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

4.2.3 Требования к программному обеспечению

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

4.2.4 Требования к техническому обеспечению

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

- одноядерный процессор с тактовой частотой 2.0 ГГц;

- объем оперативной памяти от 2 Гб;

- размер дискового пространства от 200 Гб;

- устройство чтения компакт-дисков (DVD, CD);

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

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

- минимум двухъядерный процессор с частотой от 2.5 Ггц;

- оперативная память от 2 Гбайт;

- дисковое пространство: не менее 500 Гбайт;

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

- источник бесперебойного питания;

- устройство чтения компакт-дисков DVD;

- устройства ввода информации - клавиатура, мышь.

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

- процессор с частотой от 2.5 Ггц и количеством ядер от 4 и выше;

- оперативная память от 4 Гбайт;

- накопители на жестких магнитных дисках: объемом не менее 500 Гбайт в количестве;

- источник бесперебойного питания;

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

- устройства ввода информации - клавиатура, мышь.

5 Состав и содержание работ по созданию системы

Работы по созданию системы выполняются в несколько этапов согласно ГОСТ 19.102-77 - «ЕСПД. Стадии разработки»;:

исследование предметной области (продолжительность - 1 месяц)

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

проектирование. Разработка эскизного проекта. Разработка технического проекта (продолжительность - 1 месяца);

разработка рабочей документации. Адаптация программ (продолжительность - 2 месяца);

ввод в действие (продолжительность - 1 месяц).

6 Порядок контроля и приёмки подсистемы

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

Методы испытания, включают в себя:

- проверку правильности ввода информации;

- ручное заполнение баз данных;

- вывод отчетов по каждому виду запросов;

- просмотр отчетов.

7 Требования к составу и содержанию работ по созданию подсистемы

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

- приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМ;

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

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

- ознакомление администратора подсистемы с его обязанностями;

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

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

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

8 Требование к документированию

Состав и содержание документации должны соответствовать требованиям ГОСТ 34.201-89 и нормативно-технических документов (комплекса стандартов и руководящих документов на автоматизированные системы и единой системы программной документации).

При сдаче проекта исполнитель передает заказчику следующие документы:

- техническое задание;

- описание подсистемы;

- руководство пользователя.

Проектирование, создание ИПС и оформление документации должно основываться на следующих стандартах:

- ГОСТ 7.1-2003 - «Библиографическое описание документа. Общие требования и правила составления»;

- ГОСТ 19.102-77 - «ЕСПД. Стадии разработки»;

- ГОСТ 19.104-78 - «ЕСПД. Основные надписи»;

- ГОСТ 19.508-79 - «Руководство по техническому обслуживанию. Требования к содержанию и оформлению»;

- ГОСТ 24.301-80 - «Общие требования к выполнению текстовых документов»;

- ГОСТ 34.601-90 - «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

Размещено на Allbest.ru