Формирование базовых документов



ДЕПАРТАМЕНТ ОБРАЗОВАНИЯ ГОРОДА СЕВАСТОПОЛЯ

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ ГОРОДА СЕВАСТОПОЛЯ «СЕВАСТОПОЛЬСКИЙ ТОРГОВО-ЭКОНОМИЧЕСКИЙ ТЕХНИКУМ»

 

Цикловая комиссия информационных дисциплин

 

СОЗДАНИЕ ПРОЕКТА АВТОМАТИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ РАБОТЫ С БИБЛИОТЕЧНЫМ ФОНДОМ

 

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

    Исполнитель: Студент группы ИС 9-1 Очная форма обучения Специальность: 43.02.11«Информационные системы (по отраслям)» ___________/­­­­­­­­­­­­В.К. Сусло/­­­­­­­­­­­­ « ___ » __________20__ г.   Руководитель: _____________ /Я.О. Кучеренко / « ___ » ____________ 20__ г.

­­­­­­­­­­­­­­­­­­­­

 

Допустить к защите:

Рецензент _____________ / ­­­­­­­­­___________________   /

«____»______________________ 20__ г.

 

Оценка                                                       Дата                          

 

Председатель Государственной

экзаменационной комиссии                         /___________________/

 

 

Севастополь, 2018


 

СОДЕРЖАНИЕ

 

ВВЕДЕНИЕ

 

Раздел 1. Исследовательская часть.

1.1 Анализ предметной области

1.2 Формирование базовых документов

 

Раздел 2. Конструкторско-технологическая часть.

 

2.1 Проектирование информационной системы;

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

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

2.4 Тестирование и отладка информационной системы.

 

Раздел 3 .Технико-экономическая часть

 

 

ЗАКЛЮЧЕНИЕ

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

 ПРИЛОЖЕНИЕ А

 ПРИЛОЖЕНИЕ Б



Введение

 

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

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

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

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

Исходя из поставленной цели, определены основные задачи:

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

2. Провести характеристику и анализ объекта исследования.

3. Разработать требования к информационной системе.

4. Разработать структуру информационной системы.

5. Разработать графический макет и дизайн информационной системы. Разработать базу данных.

6. Разработать программные модули.

 

 

Раздел 1. Исследовательская часть

 

1.1 Анализ предметной области.

 

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

Данная информационная система разрабатывалась c помощью базы данных Microsoft Access 2007. Access входит в набор инструментальных программных средств, является настольной СУБД, легка в использовании даже для неспециалистов в программировании, именно поэтому мы выбрали данную среду для разработки нашей информационной системы.

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

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

Система управления базами данных MS Access поддерживает реляционную модель данных с механизмом ссылочной целостности. Поэтому в базах данных СУБД MS Access данные представляются в виде таблиц и функциональных бинарных связей между таблицами. Дополнительное средство представления данных - запросы. Запрос представляет собой виртуальную таблицу, которая формируется по требованию на основе заранее составленного описания запроса по данным из физических таблиц базы данных. Никаких других различий между физическими таблицами и запросами нет. Во всех операциях они участвуют на равных правах.     Основное назначение запросов - представление для вывода дополнительной информации, а также скрытие от пользователей сложных запросов: пользователь обращается к системе с простым запросом к виртуальным данным, а всю работу по их формированию (по заранее составленному сложному запросу) берет на себя СУБД.

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

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

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

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

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

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

В окне базы данных Access 2000 появились новые средства просмотра и манипулирования объектами базы данных:

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

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

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

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

- выбор объекта путем ввода его имени.

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

- поддерживается блокировка на уровне записей в дополнение к обычной блокировке, которая блокировала все записи на 4-кбайтной странице.

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

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

- поддержка мирового 16 разрядного стандарта кодировки символов Unicode;

- поддержка работы с данными в формате валюты евро. Чтобы увидеть на экране значение величины в формате евро-валюты, можно использовать установку (#,###.##) свойства Формат.

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

- использование Microsoft ActivX Object (ADO) для доступа и манипулирования данными в базах данных сервера.

 

Формирование базовых документов

 

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

1)Реестр заинтересованных лиц №1;             (Приложение 1)

2) Реестр заинтересованных лиц № 2; (Приложение 2)

 3) Матрица требований №1; (Таблица 1)

4) Матрица требований №2. (Таблица 2)

5) Концепт проекта; (Таблицы 3,4)

6) Построение ИСР (Рисунок 1)

7) техническое задание для разрабатываемой информационной системы в соответствии с ГОСТом 34.602-89.

 

 

Вывод 1: В ходе рассмотрения раздела №1 я провел анализ предметной области моей будущей АИС и вывел список документов, которые мне понадобятся для подтверждения созданной АИС и, непосредственно для ее разработки и дальнейшего ввода в эксплуатацию.

 

Раздел 2. Конструкторско-технологическая часть

 

 2.1 Проектирование информационной системы.

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

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

К основным средствам проектирования можно отнести:

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

-системы автоматизированного проектирования (САПР), предполагающие использование ЭВМ на всех этапах создания АИС.

Общие требования, предъявляемые к средствам проектирования:

-полный охват всего процесса создания АИС;

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

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

- доступность в освоении и несложность (простота) в реализации;

-возможность организации процесса проектирования в режиме интерактивного взаимодействия разработчика системы, проектировщика и ЭВМ;

- адаптируемость и экономическая эффективность.

Среди методов проектирования выделяют:

-оригинальное проектирование;

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

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

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

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

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

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

2. разработка автоматизированных систем проектирования.

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

Типовое проектирование - индустриальный метод создания АИС, использующий ТПР и ППП. Этот метод характеризуется наличием проверенных, типовых организационно-экономических, технических, информационных, математических и программных средств автоматизации управления. Применение данного метода позволяет снизить трудоемкость, снизить стоимость и сократить сроки проектирования, повысить качество проектирования. Процесс типового проектирования заключается в выборе и привязке обеспечивающих подсистем в соответствии с требованиями конкретной АИС. Типовая часть АИС представляет собой комплекс информационного, программного и технического обеспечения. Типовой характер информационного обеспечения достигается путем строгого соблюдения единства структуры информационной базы, состава массивов, форм входных и выходных документов. Типовой характер программного обеспечения достигается использованием ППП, и типовой характер технического обеспечения достигается применением ЭВМ одного или совместных типов.

 

 

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

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

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

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

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

 

2.2 Выбор средств разработки информационной системы.

 

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

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

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

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

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

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

· характеристик моделируемой предметной области;

· целей, потребностей и ограничений будущего проекта ИС, включая квалификацию участвующих в процессе проектирования специалистов;

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

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

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

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

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

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

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

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

· наличием потребности как в традиционных приложениях, связанных с обработкой транзакций и решением регламентных задач, так и в приложениях аналитической обработки (поддержки принятия решений), использовать нерегламентированные запросы к данным большого объёма;

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

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

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

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

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

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

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

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

Вывод: на основании вышеописанного, я принял решение выбрать для проектирования моей АИС программу «Ramus Education», потому что она проста в использовании и более наглядно способна отразить нужные мне аспекты и особенности строения схем и связей.

 

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

 

Приступая к разработке АИС для создания схемы работы системы я использую программу «Ramus Education», скриншоты системы из которой представляю ниже. (рис. 1), (рис 2).

 

Рис. 1 «Базовый уровень АИС для библиотечного фонда»

 

 

Рис. 2 «Дочерняя диаграмма АИС для библиотечного фонда»

 

Функции, выпоняемые АИС: 1)заполнение информации о книгах;

                                   2) выполнение запросов пользователей;

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

 

 

2.4 Тестирование и отладка информационной сисемы.

 

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

Процесс отладки включает:

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

-  диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);

-  внесение исправлений в программу с целью устранения ошибок.

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

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

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

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

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

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

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

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

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

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

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

2. Необходимой частью тестового набора данных должно быть описание предполагаемых значений результатов тестовых прогонов. Тестирование как процесс многократного выполнения про­граммы проводится на многочисленных входных наборах данных. Чтобы определить правильность полученных в результате очеред­ного тестового прогона данных, необходимо знать ожидаемый ре­зультат. Таким образом, тестовый набор данных должен включать в себя два компонента: описание входных данных, описание точного и кор­ректного результата, соответствующего набору входных данных. Этот принцип сложно, а в некоторых случаях и невозможно реализовать на практике. Сложность его заключается в том, что при тестировании программы (модуля) необходимо для каждого входного набора данных рассчитать вручную ожидаемый результат или найти допустимый интервал изменения выходных данных. Процесс этот трудоемкий даже для небольших про­грамм, так как он требует ручных расчетов, следуя логике алгоритма программы. Из рассмотренного принципа, который трудно реализуем, но которого следует придерживаться логически, вытекает следующий.

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

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

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

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

Вывод 2: В ходе тестирования АИС, не было выявлено никаких недостатков и сериозных побочных эффектов, которые могли бы «свести на нет» работу всей системы в целом.

 

Раздел 3. ТЕХНИКО-ЭКОНОМИЧЕСКАЯ ЧАСТЬ

 


Дата добавления: 2018-04-05; просмотров: 76; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!