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

СОДЕРЖАНИЕ ВВЕДЕНИЕ

1. АНАЛИЗ ДЕЯТЕЛЬНОСТИ БЛАГОВЕЩЕНСКОГО ФИЛИАЛА СГА

1.1 Краткая характеристика предприятия

1.2 Средства для анализа предметной области

1.3 Организационная структура предприятия

1.4 Анализ документооборота предприятия

1.4.1 Документооборот с внешними объектами

1.4.2 Документооборот с внутренними объектами

1.5 Анализ комплекса программных средств

1.6 Анализ локальной вычислительной сети

1.7 Анализ аппаратного обеспечения

1.8 Анализ программного обеспечения

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3 Руководство пользователя ЗАКЛЮЧЕНИЕ СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ПРИЛОЖЕНИЯ ВВЕДЕНИЕ Одним из важных условий обеспечения надежного функционирования любого предприятия является наличие развитой информационной системы.

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

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

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

Для достижения поставленной цели, были выделены следующие задачи:

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

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

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

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

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

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

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

1.АНАЛИЗ ДЕЯТЕЛЬНОСТИ БЛАГОВЕЩЕНСКОГО ФИЛИАЛА СГА

1.1 Краткая характеристика предприятия Благовещенский филиал СГА — это негосударственное аккредитованное частное образовательное учреждения высшего профессионального образования. Создано в г. Благовещенске, в установленном законодательством РФ и Уставом СГА порядке. Является обособленным структурным подразделением СГА, осуществляющим часть функций академии, в том числе функции представительства, и имеющим правовое положение в соответствии со статьей 55 Гражданского Кодекса РФ, статьей 5 Закона РФ «О некоммерческих организациях» и ФЗ «Об образовании в Российской Федерации».

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

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

Местонахождение (юридический адрес): 675 000, Амурская область, г. Благовещенск, ул. Политехническая, д.82/2.

Данное предприятие не является юридическим лицом, имеет самостоятельный счет, открываемый в соответствии с законодательством Российской Федерации, печать со своим наименованием и с изображением организационной символики СГА.

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

Невозможно построить качественный проект без построения подробной модели предметной области. Моделирование процессов, как правило, выполняются с помощью CASE-средств. К таким средствам относят BPwin, Silverrun, Oracle Designer, Rational Rose. В данной выпускной квалификационной бакалаврской работе для моделирования процессов был выбран BPwin.

BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD). Все описанные подходы входят в семейство стандартов IDEF. Каждая из них решает свои специфические задания. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно все диаграммы.

1.3 Организационная структура предприятия Структура Благовещенского филиала представлена в приложение А, на рисунке А1 и включает в себя несколько отделов, каждый из которых выполняет определенные функциональные задачи.

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

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

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

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

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

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

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

соблюдение кодекса корпоративной этики;

соблюдение внутреннего трудового распорядка СГА.

Бухгалтерия:

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

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

организация ведения бухгалтерского учёта, связанного с деятельностью филиала, в соответствии с Федеральным Законом «О бухгалтерском учёте» и локальными и организационно-распорядительными актами академии, своевременно представляет первичные документы и отчеты в бухгалтерию академии;

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

участие во взаимодействие с ИФНС по месту нахождения филиала и оперативно подчиненных ему структурных подразделений академии по вопросам деятельности филиала и оперативно подчиненных ему структурных подразделений академии, представляет налоговые декларации по уплате местных налогов в соответствующие органы;

подготовка отчетности в налоговые органы, органы Пенсионного фонда, ФСС и Росстат, в том числе в электронном виде;

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

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

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

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

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

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

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

повышение профессиональной квалификации в сроки, установленные программами повышения квалификации СГА;

соблюдение кодекса корпоративной этики;

соблюдение внутреннего трудового распорядка СГА.

Отдел по обеспечению образовательной деятельности:

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

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

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

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

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

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

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

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

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

повышение профессиональной квалификации в сроки, установленные программами повышения квалификации СГА;

создание служебных произведений;

соблюдение кодекса корпоративной этики;

соблюдение внутреннего трудового распорядка СГА;

Отдел информационных технологий:

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

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

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

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

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

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

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

повышение профессиональной квалификации в сроки, установленные программами повышения квалификации СГА;

создание служебных произведений;

соблюдение кодекса корпоративной этики;

соблюдение внутреннего трудового распорядка СГА.

14 Анализ документооборота предприятия Документооборот — это движение документов с момента их получения или создания до завершения исполнения, отправки адресату или сдачи на хранение.

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

1.4.1 Документооборот с внешними объектами Благовещенский филиал СГА взаимодействует со следующими организациями:

межрайонная инспекция ФНС России № 1 по Амурской области;

управление Пенсионного Фонда РФ По г. Благовещенску;

амурское региональное отделение фонда социального страхования РФ;

сбербанк России;

министерство образования и науки Амурской области;

администрация г. Благовещенска;

СГА г. Москва.

Филиал предоставляет межрайонной инспекции ФНС России № 1 по Амурской области: бухгалтерскую и налоговую отчетность, налоговые декларации и налоговые отчисления.

Управление Пенсионного Фонда РФ По г. Благовещенску, за счет отчислений обеспечивает выплату ежемесячных пособий, пенсий.

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

Филиал СГА предоставляет Сбербанку России платежные поручения, банк предоставляет филиалу информацию о состоянии счета;

Министерство образования и науки Амурской области предоставляет филиалу разрешение на ведение образовательной деятельности.

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

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

Схема документооборота Благовещенского филиала СГА с внешними объектами представлена в приложении Б, на рисунке Б1.

1.4.2 Документооборот с внутренними объектами Отделы Благовещенского филиала СГА, взаимодействуют между собой и директором внутри организации:

бухгалтерия;

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

отдел информационных технологий.

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

Схема документооборота Благовещенского филиала СГА с внешними объектами представлена в приложении Б, на рисунке Б2.

1.5 Анализ комплекса программных средств

В СГА имеется специальное разработанное ПО SQL server 2003, 1C:

контроль Успеваемости и Листа ожидания (КУиЛО) успеваемость студента.

луч-Транспорт передача данных как от филиала в Москву, так и с Москвы в филиал;

комплекс ПО: Луч-Анкета-Студент, Психологическое тестирование программы разработанные специалистами СГА для тестирование студентов (абитуриентов и выпускников), и мониторинга данных;

«Нормоконтроль» проверяет письменные работы на соответствие шаблона, для дальнейшей загрузки на Московский сервер и оценивания работы преподавателем.

1.6 Анализ локальной вычислительной сети

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

Локальная сеть на 25 компьютеров через сетевой коммутатор, с доступом в интернет через маршрутизатор.

Сетевая архитектура — Fast Ethernet. Архитектура Fast Ethernet — это эволюционное развитие классической архитектуры Ethernet. Основное достоинство: пропускная способность сегментов сети до 100 Мб/с, сохранение метода случайного доступа Ethernet, сохранение звездообразной топологии сетей и поддержка традиционных сред передачи данных — витой пары и оптоволоконного кабеля.

Также использование Fast Ethernet позволяет осуществлять доступ к файлам и принтерам, исполнять приложения.

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

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

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

сервер БД — Intel Pentium D 3ГГЦ, 4GB ОЗУ, HDD 320GB, HDD 500GB, ЖК-монитор 17″, допустимы и ЭЛТ-мониторы, устройства ввода-вывода (мышь, клавиатура);

файловый сервер — Intel Pentium 4 2,4ГГЦ, 1GB ОЗУ, HDD 120 GB, HDD 1TB, ЖК-монитор 17″, допустимы и ЭЛТ-мониторы, устройства ввода-вывода (мышь, клавиатура);

сервер приложений — Intel Pentium Dual-Core 2,5ГГЦ, 4GB ОЗУ, HDD 80GB, HDD 500GB, ЖК-монитор 17″, допустимы и ЭЛТ-мониторы, устройства ввода-вывода (мышь, клавиатура);

компьютер инженера — Intel Core i3 3,4ГГЦ, 8GB ОЗУ, HDD 80G, HDD 500GB, ЖК-монитор 17″, допустимы и ЭЛТ-мониторы, устройства ввода-вывода (мышь, клавиатура);

компьютер менеджера — Intel Celeron 2.5ГГЦ, 2GB ОЗУ, HDD 320GB (4шт), ЖК-монитор 17″, допустимы и ЭЛТ-мониторы, устройства ввода-вывода (мышь, клавиатура);

компьютер Бухгалтера — Intel Core i3 2,5 ГГЦ, 2GB ОЗУ, HDD 5000G, ЖК-монитор 17″, допустимы и ЭЛТ-мониторы, устройства ввода-вывода (мышь, клавиатура);

компьютер студента — Intel Celeron 1,8ГГЦ, 1GB ОЗУ, HDD 120GB (20шт), ЖК-монитор 17″, допустимы и ЭЛТ-мониторы, устройства ввода-вывода (мышь, клавиатура).

1.8 Анализ программного обеспечения

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

Windows server 2003;

Windows XP pro;

Windows7 pro;

Office 2003;

Antivirus Kaspersky;

Internet explorer (для работы студентов, сбербанк онлайн бизнес, контур экстерн).

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

наличие большого количества готовых отчетов, создаваемых в 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 — язык маркировки гипертекстов). Говоря проще, это набор средств для описания визуальных свойств (позиция, размер, цвет и т. д.) различных элементов, в частности текста или графики. Под гипертекстовым документом подразумеваются документы с гипертекстовыми ссылками — указателями на другие гипертекстовые документы.

Для написания кода подсистемы выбран текстовый редактор 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 Характеристика функциональных подсистем Функциональная подсистема — подсистема, реализующая одну или несколько взаимосвязанных функций, представляет собой комплекс задач с высокой степенью информационных связей между задачами. Состав функциональных подсистем во многом определяется особенностями системы и обслуживают определенные виды деятельности предприятия, характерные для его структурных подразделений и функций управления.

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

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

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

Подсистема «Идентификация» — модуль необходим для авторизации пользователя в системе.

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

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

Подсистема «Отчеты» — Предназначена для выписки отчетов об оплате по различным параметрам.

Подсистема «Работа с БД» — Подсистема служит для выполнения запросов по средствам языка 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-дисков для ежедневного создания резервных копий базы данных.

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

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

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

— СУБД MySQL;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.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Инфологическое проектирование Назначение сущностям описательных атрибутов На основании исследования предметной области и целей создания информационной подсистемы были выделены следующие сущности:

«Студенты»;

«Группы»;

«Оплата»;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отношение 1

Отношение 2

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

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

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

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

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

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

Отношение 3

Отношение 4

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

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

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

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

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

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

Отношение 5

Отношение 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 = ¾;

N2 = 10.

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

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

N1.3 = 2;

N2.3 = 1;

N12.3 = 2;

E1.3 = N1.3 / N12.3 = ½;

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

N3 = 4.

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

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

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

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

На рисунке 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. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании системы в процессе эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

Условия эксплуатации оборудования рабочих мест сотрудников должны соответствовать нормальным климатическим условиям, определенным в ГОСТ 27 201–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 — «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».