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

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

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

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

– Создание единой БД студентов Благовещенского филиала СГА;

– Создание форм для работы с данными, такие как: внесение, удаление, изменение данных о студентах и группах;

– Создание формы для внесения оплаты за обучение;

– Создание формы для получения отчетов об оплате за обучение;

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

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

2.2 Анализ аналогичных информационных систем из исследуемой области

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

1С: Бухгалтерия: на сегодняшний день – это одно из самых распространенных ПО для автоматизации бухгалтерского учёта. При приобретении программы семейства 1С, необходимо, чтобы была проведена правильная установка и настройка, а также в некоторых случаях может понадобиться вводный консультационный курс.

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

Перечислим некоторые положительные характеристики «1С: Бухгалтерии»:

– Данное ПО позволяет вести все существующие виды налогового и бухгалтерского учёта;

– «1С: Бухгалтерия» - это универсальных бухгалтерская программ, которая может использоваться в самых различных организациях. Т.к данное ПО основанно на платформе «1С: Предприятие», её можно использовать под конкретные нужды бизнеса. Подобная гибкость позволят решить самые различные вопросы;

– В нашей стране регулярно происходят различные изменения в законодательстве связанном с ведением бухгалтерского и налогового учёта. Поэтому, разработчики «1С» следят за всеми изменениями в налоговом законодательстве и своевременно обновляют формы отчётности в программе;

– С помощью «1С: Бухгалтерия 8» возможно решение даже самых сложных задач, благодаря её высокой производительности;

– Совместно с «1С: Бухгалтерией» можно использовать MS SQL Server;

Однако, как и в любом ПО в «1С: Бухгалтерии» имеются некоторые недостатки:

– Чаще всего для решения всех поставленные перед ПО задач, необходимо дорабатка в соответствии с конкретными требованиями предприятия (в том числе и по автоматизации ведения бухгалтерского и налогового учёта);

– В процессе перехода с другой бухгалтерской программы на «1С: Бухгалтерию» не редко возникают трудности при переносе всей информации. Значительную часть информации нередко приходится переносить вручную.

– В «1С: Бухгалтерии» затруднен поиск ошибок, сделанных во время обработки документов;

– Программа «1С: Бухгалтерия» сложное ПО, требующее специального обучения [16].

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

Так же имеется ряд преимуществ:

– обеспечивает интеграцию всех кадровых задач ВУЗа;

– простота эксплуатации;

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

– наличие большого количества готовых отчетов, создаваемых в Microsoft Word и Microsoft Excel. В системе реализованы различные статистические отчеты с построением соответствующих диаграмм

И ряд недостатков, в основном схожих с «1С: Бухгалтерия».

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

Разрабатываемая информационная подсистема позволит:

– вносить персональные данные студентов (такие как ФИО, дата рождения, серия и номер паспорта, адрес проживания, номер телефона, год поступления и год выпуска);

– систематизировать информацию о студентах (поиск по различным критериям);

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

– вести учёт оплаты студентом обучения, с возможностью выдачи отчёта об оплате на данный момент.

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

2.3 Обоснование выбора среды разработки

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

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

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

– СУБД MySQL;

– веб-сервер Apache;

– PHPMyAdmin - веб-интерфейс для администрирования СУБД MySQL;

– язык написания сценариев PHP5;

– язык разметки страниц гипертекста HTML;

– Notepad - текстовый редактор

В качестве СУБД используется MySQL 5.0. MySQL отвечает всем необходимым требованиям:

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

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

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

Основные конкурентные преимущества MySQL:

– производительность (поэтому многие компании например такие, как Google и Yahoo используют именно MySQL)

– масштабируемость (к примеру, в компании Omniture в реальном масштабе времени используется 7000 серверов MySQL)

– надежность (в коде проприетарных продуктов содержится намного больше уязвимостей)

– простота использования, простота внедрения (установка вместе с скачкой займёт в среднем 15 минут)

– открытая и модульная разработка

– низкие совокупные затраты (платить нужно только при потребности в поддержке) [23, 25]

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

Для разработки и реализации подсистемы по учету персональных данных для Благовещенского филиала СГА был выбран язык написания сценариев. РНР – это широко используемый язык сценариев общего назначения с открытым исходным кодом. Важным преимуществом языка PHP перед такими языками, как языков Perl и C заключается в возможности создания HTML документов с внедренными командами PHP. Так же отличием PHP от какого-либо кода, выполняющегося на стороне клиента, например, JavaScript, является то, что PHP-скрипты выполняются на стороне сервера. Как средство разработки Web-приложений РНР сейчас является одним из самых популярных языков. PHP прост для освоения, и вместе с тем способен удовлетворить запросы профессиональных программистов [1, 8].

Так же для разработки подсистемы понадобится язык разметки страниц гипертекста HTML (HyperText Markup Language - язык маркировки гипертекстов). Говоря проще, это набор средств для описания визуальных свойств (позиция, размер, цвет и т.д.) различных элементов, в частности текста или графики. Под гипертекстовым документом подразумеваются документы с гипертекстовыми ссылками - указателями на другие гипертекстовые документы [15].

Для написания кода подсистемы выбран текстовый редактор Notepad.

Основные особенности Notepad [8]:

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

–поддержка большого количества языков (C, C++, Java, XML, HTML, PHP, Java Script, ASCII, VB/VBS, SQL, CSS, Pascal, Perl, Python, Lua, TCL, Assembler);

–WYSIWYG (печатаешь и получаешь то, что видишь на экране);

–настраиваемый пользователем режим подсветки синтаксиса;

–автозавершение набираемого слова;

–одновременная работа с множеством документов;

–одновременный просмотр нескольких документов;

–поддержка регулярных выражений поиска/замены;

–полная поддержка перетягивания фрагментов текста;

–динамическое изменение окон просмотра;

–автоматическое определение состояния файла;

–увеличение и уменьшение;

–использование заметок;

–выделение скобок при редактировании текста;

–запись макроса и его выполнение.

2.4 Характеристика функциональных подсистем

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

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

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

В проектируемую подсистему должны входить следующие компоненты:

1) Подсистема " Идентификация" – модуль необходим для авторизации пользователя в системе.

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

3) Подсистема " Оплата" – Этот модуль служить для внесения в БД информации о платежах за обучение. Так же имеет функцию внесения полной суммы за весь период обучения конкретной группы.

4) Подсистема " Отчеты" – Предназначена для выписки отчетов об оплате по различным параметрам.

5) Подсистема «Работа с БД» – Подсистема служит для выполнения запросов по средствам языка SQL

Концептуальная модель системы построена в среде проектирования BPWin и представлены в приложении Г на рисунках Г1.

Основными объектами модели являются [12]:

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

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

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

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

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

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

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

В роли управления выступают закон " Об образовании в Российской Федерации", устав филиала, распоряжения СГА г. Москва, правила и процедуры.

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

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

2.5 Характеристика обеспечивающих подсистем

2.5.1Подсистема организационного обеспечения

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

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

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

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

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

– средство разработки структуры базы данных ERWin;

– СУБД MySQL;

– веб-сервер Apache;

– PHPMyAdmin - веб-интерфейс для администрирования СУБД MySQL;

– язык написания сценариев PHP5;

– язык разметки страниц гипертекста HTML;

– Notepad - текстовый редактор

– построение модели информационных потоков предприятия и его отделов производим в пакете BPWin.

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

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

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

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

В задачи администратора также входит:

– создание учетных записей пользователей;

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

– обучение и поддержка пользователей;

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

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

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

– защита сети от вирусов.

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

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

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

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

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

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

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

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

2.5.3 Подсистема технического обеспечения

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

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

– Процессор с частотой от 3, 2Ггц или более;

– Оперативная память объемом от 2 Гб или более;

– жесткий диск объёмом не менее 80 Гб;

– ЖК-монитор 17", допустимы и ЭЛТ-мониторы;

– Устройства ввода-вывода (мышь, клавиатура);

– Сетевой адаптер со скоростью подключения к сети 100 Мбит/сек.

Для печати документов используются сетевые лазерные принтеры Xerox в количестве двух штук.

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

В настоящий момент ЛВС имеет сетевую архитектуру Fast Ethernet. Сеть смонтирована на базе неэкранированной витой пары пятой категории (UTP), все обжимы и активное оборудование также пятой категории, скорость передачи данных: 100 Мбит/с.

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

– процессор с частотой 2, 5 ГГц;

– объем оперативного запоминающего устройства не менее 2 Гб;

– объем постоянного запоминающего устройства 80 Гб;

– сетевая карта для подключения к сети Ethernet;

– принтер;

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

На сервере должно находиться устройство записи DVD-R-дисков для ежедневного создания резервных копий базы данных.

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

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

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

– средство разработки структуры базы данных ERWin;

– СУБД MySQL;

– серверное программное обеспечение Apache HTTP;

– язык написания сценариев PHP5;

– язык разметки страниц гипертекста HTML;

– Notepad - текстовый редактор.

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

2.5.5 Подсистема информационного обеспечения

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

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

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

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

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

- организация занесения информации в БД;

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

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

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

2.5.6 Подсистема технологического обеспечения

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

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

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

Вся внесенная информация сохраняется в базе данных в течение пяти лет, а также происходит резервирование данных на DVD-R-диски.

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

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

– ГОСТ 19.001-77 – Общие положения;

– ГОСТ 19.004-80 – Термины и определения;

– ГОСТ 19.101-77 – Виды программ и программных документов;

– ГОСТ 19.102-77 – Стадии разработки;

– ГОСТ 19.103-77 – Обозначение программ и программных докумен-тов;

– ГОСТ 19.105-78 – Общие требования к программным документам;

– ГОСТ 19.106-78 – Требования к программным документам, выпол-ненным печатным способом;

– ГОСТ 19.402-78 – Описание программы;

– ГОСТ 19.502-78 – Описание применения. Требования к содержанию и оформлению;

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

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

– ГОСТ 24.202-80 – Требования к содержанию документа “Технико-экономическое обоснование создания АСУ”;

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

– ГОСТ 24.103-84 – Автоматизированные системы управления. Основные положения;

– ГОСТ 24.104-85 – Автоматизированные системы управления. Общие требования;

– ГОСТ 34.201-89 – Виды, комплектность и обозначение документов при создании автоматизированных систем;

– ГОСТ 34.601-90 – Автоматизированные системы. Стадии создания.

2.6Проектирование базы данных

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

2.6.1.1 Назначение сущностям описательных атрибутов

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

1. «Студенты»;

2. «Группы»;

3. «Оплата»;

4. «Стоимость»;

5. «Пользователи»;

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

Сущность «Студенты» содержит данные о всех студентах Благовещенского филиала СГА;

Сущность «Группы» содержит данные о составе групп;

Сущность «Договор» содержит данные об оплате за обучение конкретным слушателем;

Сущность «Стоимость» содержит полную стоимость за весь период обучения конкретной группы;

Сущность «Пользователи» содержит учетные данные пользователя;

Описательные атрибуты для сущностей представлены в таблице 1-5.

Таблица 1 – Спецификация атрибутов сущности «Студенты»

Таблица 2 – Спецификация атрибутов сущности «Группа»

Таблица 3 – Спецификация атрибутов сущности «Оплата»

Таблица 4 – Спецификация атрибутов сущности «Стоимость»

Таблица 5 – Спецификация атрибутов сущности «Пользователи»

2.6.1.2Назначения сущностям ключевых атрибутов

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

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

Для сущности «Оплата» ключевым атрибутом является id оплаты, так как этот атрибут однозначно сопоставляет оплату за обучение конкретному студенту.

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

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

2.6.1.3 Определение связей между сущностями

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

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

В модели «сущность-связь» существует несколько типов связи: «один-к-одному», «один-ко-многим», «многие-ко-многим». Связь «один-к-одному» означает, что в каждый момент времени каждому экземпляру сущности А соответствует 1 и только 1 экземпляр сущности В и наоборот. Связь «один-ко-многим» обозначает, что одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В, но каждому экземпляру сущности В соответствует только 1 экземпляр сущности А. Связь «многие-ко-многим» показывает, что одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В и наоборот [10].

Исходя из анализа предметной области, установим связи между сущностями:

1) Связь «Студенты-Оплата» показана на рисунке 1.

Рисунок 1 – Студент-Оплата

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

2) Связь «Студенты-Группы» показана на рисунке 2.

Рисунок 2- Студенты-Группы

Между этими сущностями имеется связь имеется связь «один-ко-многим». Несколько студентов могут входить в состав одной группы.

3) Связь «Стоимость-группы» показана на рисунке 3.

Рисунок 3 – Стоимость-Группы

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

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

Модель «сущность-связь»

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

Рисунок 4 – Модель «сущность-связь»

2.6.2 Логическое проектирование

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

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

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

– Анализ полученных отношений на соответствие трем нормальным формам [24].

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

Исходя из вышеперечисленных связей, сформируем отношения для проектируемой БД.

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

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

Сущность «Оплата»

id оплаты

Сумма

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

id студента

ФИО

Дата рождения

Паспорт

Кем выдан

Прописка

Дата выдачи

Номер телефона

Дата поступления

Дата выпуска

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

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

Отношение 1

Отношение 2

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

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

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

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

id группы

Номер

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

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

id студента

ФИО

Дата рождения

Паспорт

Кем выдан

Прописка

Дата выдачи

Номер телефона

Дата поступления

Дата выпуска

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

Отношение 3

Отношение 4

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

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

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

id цены

Сумма

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

id группы

Номер

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

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

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

Отношение 5

Отношение 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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