Внедрение базы данных "Библиотека" в Челябинском энергетическом колледже

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Основания для разработки и требования к программе

1.1 Классический период разработки программного обеспечения

1.2 Понятие внедрения программного продукта

1.3 Понятие базы данных

1.4 Анализ существующих баз данных

2. Внедрение базы данных «Библиотека»

2.1 Постановка задачи

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

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

2.4 Пользовательский интерфейс базы данных

2.4.1 Виды интерфейсов

2.4.2 Интерфейс БД «Библиотека»

2.5 Тестирование программы

2.5.1 Методика тестирования программных систем

2.5.2 Тестирование программы

2.6 Внедрение и сопровождение базы данных

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

2.6.2 Руководство программиста

Заключение

Список использованных источников

Введение

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

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

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

В данной дипломной работе рассматривается процесс внедрения базы данных «Библиотека» в Челябинском энергетическом колледже.

1. Основания для разработки и требования к программе

1.1 Классический период разработки программного обеспечения

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

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

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

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

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

3) Выбирается методология разработки ПО и начинается разработка (Кодирование). Достаточно популярна методология итерационного проектирования, ориентированная на использование RAD-средств и систем автоматической генерации исходных текстов на основе созданной формальной модели. Такой подход хорош тем что позволяет быстро создать первый работающий прототип программы, когда ещё окончательно требование к программе не определены, а в дальнейшем, на следующих итерациях, постепенно детализировать и реализовывать конкретные возможности, пропущенные по каким-то причинам на предыдущей итерации.

В процессе разработки необходимо:

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

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

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

5) После того как заказчик удовлетворён качеством продукта, начинается его внедрение - подготовка к окончательному запуску в эксплуатацию. Если приложение многопользовательское, нередко требуются сформировать и настроить локальную сеть, установить серверы, инсталлировать вспомогательные программы.

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

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

1.2 Понятие внедрения программного продукта

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

Второй этап проекта внедрения программного продукта - разработка технического задания. Техническое задание (ТЗ) включает в себя описание всех справочников системы, всех алгоритмов расчета, отчетных форм, АРМ (Автоматизированных рабочих мест) пользователей и описание разграничения прав доступа пользователей.

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

Третий этап проекта - настройка системы (автоматизация). Настройка системы включает в себя формирование в программе всех справочников системы, настройка всех алгоритмов расчета, форм ввода и отчетных форм, ввод пользователей системы и настройка прав доступа. Продолжительность данного этапа напрямую зависит от квалификации специалистов и от уровня сложности поставленной задачи. Среднее время, отводимое на настойку системы, составляет 1 -1,5 месяца.

Четвертый этап проекта - тестирование программного продукта (системы). Тестирование системы включает в себя подготовку демонстрационного примера, внесение тестовых данных, проверку алгоритмов расчета и исправление обнаруженных ошибок. В среднем на этап тестирование отводится 2 недели.

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

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

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

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

1.3 Понятие базы данных

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

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

СУБД организует хранение информации таким образом, чтобы ее было удобно:

- просматривать,

- пополнять,

- изменять,

- искать нужные сведения,

- делать любые выборки,

- осуществлять сортировку в любом порядке.

Классификация баз данных:

1. По характеру хранимой информации:

- фактографические (картотеки),

- документальные (архивы).

2. По способу хранения данных:

- централизованные (хранятся на одном компьютере),

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

3. По структуре организации данных:

- табличные (реляционные),

- иерархические.

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

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

Реляционная база данных, по сути, представляет собой двумерную таблицу.

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

В реляционной БД используются четыре основных типов полей:

- числовой;

- символьный (слова, тексты, коды и т.д.);

- дата (календарные даты в форме «день/месяц/год»);

- логический (принимает два значения: «да» - «нет» или «истина» - «ложь»);

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

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

СУБД используются информационно-поисковые системы (ИПС), которые выполняют следующие функции:

- хранение большого объема информации;

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

- добавление, удаление и изменение хранимой информации;

- вывод ее в удобном для человека виде.

1.4 Анализ существующих баз данных

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

Во многих библиотеках колледжей работают автоматизированные системы. Мы рассмотрим некоторые из них.

База данных «Библиотека колледжа»

1. База данных основана на программе MS Access 97, предназначена для автоматизации поиска книг в библиотеке.

2. Требования для работы программы.

На компьютере должен быть установлен MS Access 97 или MS Access 2000. Разрешение экрана монитора 800*600.

3. Принцип работы.

Сначала необходимо:

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

б) расставить книги по полкам шкафов, заполняя справочники авторов, тем, издательств, городов, года издания, количества страниц;

в) поиск книги осуществляется путем выбора автора и названия книги.

База данных «Biblia»

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

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

База данных «Библиоман»

Для большего удобства пользователя при поиске и открытии нужного текста была создана система управления базами данных «Библиоман». Она представляет собой отдельную программу, работающую в тесной связи с Макс-Ридэром. «Библиоман» предоставляет незрячим пользователям возможность удобной навигации по каталогу библиотеки, включая сортировку по автору, названию и так далее; быстрый поиск по начальным буквам, а также полноценный поиск по заданной комбинации символов. Найденный в Библиомане текст одним нажатием «Enter» открывается в Макс-Ридэре. Кроме того имеется возможность редактировать базу данных и вести журнал учета прочитанных книг.

База данных «Библиотека», представленная в данном дипломном проекте, предназначена для хранения и обработки сведений о книгах, сведений о студентах и выданным им книгах. Она имеет возможность редактировать данные. Учитываются требования к надёжности: контроль вводимой информации; блокировка некорректных действий пользователя. Соблюдена целостность хранимой информации. Имеется система поиска нужной читателю книги.

2. Внедрение базы данных «Библиотека»

2.1 Постановка задачи

База данных «Библиотека» была разработана для ведения картотеки, учета выдачи книг, в библиотеке Челябинского энергетического колледжа им. С.М. Кирова.

Предназначена для хранения информации, о читателях, о книгах, о выданных читателям книгах.

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

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

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

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

Основания для внедрения

Система внедряется на основании задания дипломного проекта, выданного Челябинским энергетическим колледжем им. С.М.Кирова.

Назначение

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

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

Требования к функциональным возможностям.

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

- хранить информации о студентах и выданным им книгах;

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

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

- контроль вводимой информации;

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

- целостность хранимой информации;

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

Система должна работать на IBM PC- совместимых компьютерах.

Минимальная конфигурация компьютеров:

Требованию к серверу:

- процессор не менее 1000 МГц;

- оперативная память не менее 512 Мб;

- место на жестком диске не менее 1 Гб;

- ОС-Windows XP;

- InterBase 6,5;

Требования к клиенту:

- оперативная память не менее 512 Мб;

- место на жестком диске не менее 800 Мб;

- ОС-Windows XP;

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

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

Процесс внедрения программы должен содержать следующие этапы:

1) Подобный анализ технического задания.

2) Тестирование и отладка программы.

3) Подготовка программной документации.

4) Ввод в эксплуатацию.

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

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

Таблица «Студенты» включает в себя поля:

- IDСтудента;

- Ф.И.О;

- Группа;

- Курс.

Таблица «Личные данные студентов» включает в себя поля:

- IDСтудента;

- Фамилия;

- Имя;

- Отчество;

- Город;

- Улица;

- Дом;

- Квартира;

- Телефон;

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

- Дата зачисления.

Таблица «Книги» включает в себя поля:

- IDКниги;

- Название книги;

- Автор.

Таблица «Дополнительная информация о книгах» включает в себя поля:

- IDКниги;

- Второй автор;

- Третий автор;

- Тип издания;

- Том/томов;

- Место издания;

- Издательство;

- Дата издания;

- Объём книги;

- Предметная рубрика;

- Цена;

- Индекс УДК;

- Хранится;

- Количество копий;

- Диск;

- Примечание.

Таблица «Инвентарные номера» включает в себя поля:

- IDКниги;

- Инвентарный номер;

- Наличие.

Таблица «Абонемент» включает в себя поля:

- IDСтудента;

- IDКниги;

- Инвентарный номер;

- Название книги;

- Автор;

- Дата выдачи.

Для анализа предметной области опишем все входящие в неё объекты в виде ER- диаграммы рисунок 1.



Рисунок 1. - ER- модель базы данных

Алгоритм работы представлен на рисунке 2.

Размещено на http://www.allbest.ru/

Рисунок 2. - Алгоритм работы программы

2.4 Пользовательский интерфейс базы данных

2.4.1 Виды интерфейсов

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

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

Символьный интерфейс используется обычно при работе видеосистемы в текстовом режиме. Информация выводится на экран монитора посимвольно. До появления Windows все операционные системы, в том числе MS DOS и ее оболочка Norton Commander, предоставляли пользователю символьный интерфейс. Он достаточно экономичен по потреблению ресурсов и способен обеспечить вполне комфортную работу пользователя. Исключение составляет интерфейс командной строки операционной системы MS DOS, который требует от пользователя знания синтаксиса команд. Следует заметить, что символьный интерфейс Norton Commander не вызывает особых трудностей у неквалифицированного пользователи и может использоваться в графическом режиме работы монитора.

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

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

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

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

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

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

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

- графические объекты сохраняют свое стандартизованное назначение и по возможности местоположение на экране.

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

2.4.2 Интерфейс БД «Библиотека»

Стартовое окно программы показано на рисунке 3

Рисунок 3. - Стартовое окно программы

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

Рисунок 4. - Окно подключения к базе данных

В поле база данных вводится место размещения базы данных. Далее следует ввести имя пользователя и пароль. Стандартным пользователем является SYSDBA, а стандартным паролем masterkey. После правильного ввода появится главное окно программы. Цвет фона главного окна серый.

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

1. Файл

1.1 Выход

2. Библиотека

2.1 Абонемент

2.2 Студенты

2.3 Книги

3. Правка

3.1 Студенты

3.2 Книги

3.3 Выбираемые поля

4. Помощь

4.1 О программе

Наиболее востребованные пункты меню, продублированы кнопками панели инструментов, расположенными ниже строки меню, а также контекстным меню.

1. Книги

2. Студенты

3. Абонемент

4. Правка книги

5. Правка студенты

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

Рисунок 5. - Абонемент

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

Рисунок 6. - Студенты и редактирование студентов

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



Рисунок 7. - Книги и редактирование книги

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

Рисунок 8. - Добавление, изменение и удаление выбираемых полей

2.5 Тестирование программы

2.5.1 Методика тестирования программных систем

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

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

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

1. Тестирование элементов. Цель - индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».

Рис. 9. - Спираль процесса тестирования ПС

2. Тестирование интеграции. Цель - тестирование сборки модулей в программную систему. В основном применяют способы тестирования «черного ящика».

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

4. Системное тестирование. Цель - проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций.

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

Ответ практика обычно основан на статистическом критерии: «Можно с 95%-ной уверенностью сказать, что провели достаточное тестирование, если вероятность безотказной работы ЦП с программным изделием в течение 1000 часов составляет по меньшей мере 0,995».

1. Тестирование элементов

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

Тестированию подвергаются:

- интерфейс модуля;

- внутренние структуры данных;

- независимые пути;

- пути обработки ошибок;

- граничные условия.

Интерфейс модуля тестируется для проверки правильности ввода-вывода тестовой информации. Если нет уверенности в правильном вводе-выводе данных, нет смысла проводить другие тесты.

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

Наиболее общими ошибками вычислений являются:

1) неправильный или непонятый приоритет арифметических операций;

2) смешанная форма операций;

3) некорректная инициализация;

4) несогласованность в представлении точности;

5) некорректное символическое представление выражений.

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

1) сравнение различных типов данных;

2) некорректные логические операции и приоритетность;

3)ожидание эквивалентности в условиях, когда ошибки точности делают эквивалентность невозможной;

4) некорректное сравнение переменных;

5) неправильное прекращение цикла;

6) отказ в выходе при отклонении итерации;

7) неправильное изменение переменных цикла.

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

1) донесение об ошибке невразумительно;

2) текст донесения не соответствует, обнаруженной ошибке;

3) вмешательство системных средств регистрации аварии произошло до обработки ошибки в модуле;

4) обработка исключительного условия некорректна;

5) описание ошибки не позволяет определить ее причину.

И, наконец, перейдем к граничному тестированию. Модули часто отказывают на «границах». Это означает, что ошибки часто происходят:

1) при обработке n-го элемента n-элементного массива;

2) при выполнении m-й итерации цикла с т проходами;

3) при появлении минимального (максимального) значения.

Тестовые варианты, ориентированные на данные ситуации, имеют высокую вероятность обнаружения ошибок.

Тестирование элементов обычно рассматривается как дополнение к этапу кодирования. Оно начинается после разработки текста модуля. Так как модуль не является автономной системой, то для реализации тестирования требуются дополнительные средства, представленные на рис. 10.

Рисунок 10. - Программная среда для тестирования модуля

Дополнительными средствами являются драйвер тестирования и заглушки. Драйвер - управляющая программа, которая принимает исходные данные (InData) и ожидаемые результаты (ExpRes) тестовых вариантов, запускает в работу тестируемый модуль, получает из модуля реальные результаты (OutData) и формирует донесения о тестировании. Алгоритм работы тестового драйвера приведен на рисунке 11.



Рисунок 11. - Алгоритм работы драйвера тестирования

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

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

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

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

2. Тестирование интеграции

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

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

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

- потеря данных при прохождении через интерфейс;

- отсутствие в модуле необходимой ссылки;

- неблагоприятное влияние одного модуля на другой;

- подфункции при объединении не образуют требуемую главную функцию;

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

- проблемы при работе с глобальными структурами данных.

Существует два варианта тестирования, поддерживающих процесс интеграции: нисходящее тестирование и восходящее тестирование. Рассмотрим каждый из них.

Нисходящее тестирование интеграции

В данном подходе модули объединяются движением сверху вниз по управляющей иерархии, начиная от главного управляющего модуля.

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

Рассмотрим пример на рисунке 10. Интеграция поиском в глубину будет подключать все модули, находящиеся на главном управляющем пути структуры (по вертикали). Выбор главного управляющего пути отчасти произволен и зависит от характеристик, определяемых приложением. Например, при выборе левого пути прежде всего будут подключены модули Ml, М2, М5. Следующим подключается модуль М8 или Мб (если это необходимо для правильного функционирования М2). Затем строится центральный или правый управляющий путь.

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

Рисунок 12. - Нисходящая интеграция системы

Опишем возможные шаги процесса нисходящей интеграции.

1. Главный управляющий модуль (находится на вершине иерархии) используется как тестовый драйвер. Все непосредственно подчиненные ему модули временно замещаются заглушками.

2. Одна из заглушек заменяется реальным модулем. Модуль выбирается поиском в ширину или в глубину.

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

4. Если в модуле-драйвере уже нет заглушек, производится смена модуля-драйвера (поиском в ширину или в глубину).

5. Выполняется возврат на шаг 2 (до тех пор, пока не будет построена целая структура).

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

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

Существуют 3 возможности борьбы с этим недостатком:

1) откладывать некоторые тесты до замещения заглушек модулями;

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

3) подключать модули движением снизу вверх.

Первая возможность вызывает сложности в оценке результатов тестирования.

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

- заглушка А - отображает трассируемое сообщение;

- заглушка В - отображает проходящий параметр;

- заглушка С - возвращает величину из таблицы;

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

Рисунок 13. - Категории заглушек

Категории заглушек представлены на рисунке 13.

Очевидно, что заглушка А наиболее проста, а заглушка D наиболее сложна в реализации.

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

Третью возможность обсудим отдельно.

Восходящее тестирование интеграции

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

Рассмотрим шаги методики восходящей интеграции.

1. Модули нижнего уровня объединяются в кластеры (группы, блоки), выполняющие определенную программную подфункцию.

2. Для координации вводов-выводов тестового варианта пишется драйвер, управляющий тестированием кластеров.

3. Тестируется кластер.

4. Драйверы удаляются, а кластеры объединяются в структуру движением вверх. Пример восходящей интеграции системы приведен на рисунке 12.

Модули объединяются в кластеры 1,2,3. Каждый кластер тестируется драйвером. Модули в кластерах 1 и 2 подчинены модулю Ма, поэтому драйверы D1 и D2 удаляются и кластеры подключают прямо к Ма. Аналогично драйвер D3 удаляется перед подключением кластера 3 к модулю Mb. В последнюю очередь к модулю Мс подключаются модули Ма и Mb.

Рассмотрим различные типы драйверов:

- драйвер А - вызывает подчиненный модуль;

- драйвер В - посылает элемент данных (параметр) из внутренней таблицы;

- драйвер С -отображает параметр из подчиненного модуля;

- драйвер D - является комбинацией драйверов В и С.

Очевидно, что драйвер А наиболее прост, а драйвер D наиболее сложен в реализации. Различные типы драйверов представлены на рисунке 14.

Рисунок 14. - Различные типы драйверов

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

Сравнение нисходящего и восходящего тестирования интеграции

Нисходящее тестирование:

1) основной недостаток- необходимость заглушек и связанные с ними трудности тестирования;

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

Восходящее тестирование:

1) основной недостаток - система не существует как объект до тех пор, пока не будет добавлен последний модуль;

2) основное достоинство - упрощается разработка тестовых вариантов, отсутствуют заглушки.

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

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

1) реализует несколько требований к программной системе;

2) имеет высокий уровень управления (находится достаточно высоко в программной структуре);

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

4) имеет определенные требования к производительности обработки.

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

3. Тестирование правильности

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

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

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

1) системную спецификация;

2) план программного проекта;

3) спецификацию требований к ПС; работающий или бумажный макет;

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

5) спецификация проектирования;

6) листинги исходных текстов программ;

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

8) руководства по работе и инсталляции;

9) ехе-код выполняемой программы;

10) описание базы данных;

11) руководство пользователя по настройке;

12) документы сопровождения; отчеты о проблемах ПС; запросы сопровождения; отчеты о конструкторских изменениях;

13) стандарты и методики конструирования ПС.

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

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

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

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

4. Системное тестирование

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

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

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

записать результаты тестов, чтобы использовать их как доказательство невиновности в случае «указания причины»;

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

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

5. Тестирование восстановления

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

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

6. Тестирование безопасности

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

Тестирование безопасности проверяет фактическую реакцию защитных механизмов, встроенных в систему, на проникновение.

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

- попытки узнать пароль с помощью внешних средств;

- атака системы с помощью специальных утилит, анализирующих защиты;

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

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

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

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

7. Стрессовое тестирование

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

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

Примеры:

- генерируется 10 прерываний в секунду (при средней частоте 1,2 прерывания в секунду);

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

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

- генерируются варианты, вызывающие переполнение виртуальной памяти;

- проектируются варианты, вызывающие чрезмерный поиск данных на диске.

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

8. Тестирование производительности

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

Тестирование производительности проверяет скорость работы ПО в компьютерной системе. Производительность тестируется на всех шагах процесса тестирования. Даже на уровне элемента при проведении тестов «белого ящика» может оцениваться производительность индивидуального модуля. Тем не менее, пока все системные элементы не объединятся полностью, не может быть установлена истинная производительность системы. Иногда тестирование производительности сочетают со стрессовым тестированием. При этом нередко требуется специальный аппаратный и программный инструментарий. Например, часто требуется точное измерение используемого ресурса (процессорного цикла и т. д.). Внешний инструментарий регулярно отслеживает интервалы выполнения, регистрирует события (например, прерывания) и машинные состояния. С помощью инструментария испытатель может обнаружить состояния, которые приводят к деградации и возможным отказам системы.

2.5.2 Тестирование программы

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

Тестирование программы.

Тест 1. Запуск программы.

Ожидаемый результат: Корректный запуск программы.

Результат: Программа запускается без ошибок.

Тест 2. Подключение к базе данных.

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

Результат: При верно введённых данных подключение к серверу установлено.

Тест 3. Запрос на изменение данных.

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

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

Тест 4. Проверка контроля входных данных.

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

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

Тест 5. Проверка корректного отображения данных.

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

Результат: Данные отображаются верно.

Тест 6. Проверка корректного удаления данных.

Ожидаемый результат: После удаления данных отображаются изменения в таблице.

Результат: Изменения отображаются.

Тест 7. Появление элементов управления после подключения.

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

Результат: После подключения появляются все элементы управления.

Тест 8. Запуск и работа программы параллельно с другими программами.

Ожидаемый результат: Запуск и работа программы, если в оперативную память её загружено ещё несколько программ.

Результат: Программа запускается и работает.

Тест 9. Выход из программы.

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

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

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

2.6 Внедрение и сопровождение базы данных

база данные библиотека книга

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

Назначение программы:

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

Условия выполнения программ:

- центральный процессор с тактовой частотой 1000 MГц;

- объём оперативной памяти не менее 512 Мб;

- свободного пространства на жестком диске 100 Мб;

- стандартный манипулятор «Мышь»;

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

- операционная система не ниже Windows XP;

- стандартный монитор с расширением экрана 1280х1024;

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

Стартовое окно программы показано на рисунке 15.

Рисунок 15. - Стартовое окно программы

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

Рисунок 16. - Окно подключения к базе данных

В поле база данных вводится место размещения базы данных. Далее следует ввести имя пользователя и пароль. Стандартным пользователем является SYSDBA, а стандартным паролем masterkey. После правильного ввода появится главное окно программы. Цвет фона главного окна серый.

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

5. Файл

5.1 Выход

6. Библиотека

6.1 Абонемент

6.2 Студенты

6.3 Книги

7. Правка

7.1 Студенты

7.2 Книги

7.3 Выбираемые поля

8. Помощь

8.1 О программе

Наиболее востребованные пункты меню, продублированы кнопками панели инструментов, расположенными ниже строки меню, а также контекстным меню.

6. Книги

7. Студенты

8. Абонемент

9. Правка книги

10. Правка студенты

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

Рисунок 17. - Абонемент

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



Рисунок 18. - Студенты и редактирование студентов

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