Разработка автоматизированной системы учета заявок пользователей

На основании выявленных требований разрабатывается техническое задание (ТЗ) на создаваемую систему и, по необходимости, частные технические задания на ее компоненты (подсистемы). ТЗ создается на основе ГОСТ 34.602-89. ТЗ на создание автоматизированной системы включает следующие основные разделы:

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

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

В разделе «Характеристика объекта автоматизации» проводятся общие сведения о предприятии согласно его уставу, перечень основных видов деятельности и бизнес-процессов.

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

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

 

6. Аттестация требований

 

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

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

• проверка правильности требований;

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

• проверка на непротиворечивость;

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

• проверка на полноту;

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

• проверка на выполнимость;

Существует ряд методов аттестации требований:

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

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

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

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

 

Рисунок 1.6 – Диаграмма потоков пользовательского интерфейса

 

Выводы

 

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

 

 

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

 

2.1 Архитектурное проектирование

 

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

На этапе тестирования ИС используется как локальное приложение.

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

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

Осуществить настройку Access на многопользовательский доступ, MS Access имеет такую функцию.

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

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

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

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

На сторону SQL - сервер приходится только одна функция – это хранение введённых данных.

 

 

Рисунок 2.1 – Представление информационной системы в архитектуре «клиент-серверная»

 

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

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

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

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

 

2.2 Проектирование  пользовательского интерфейса

 

При проектировании прототипов пользовательского интерфейса была использована СУБД Access.

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

В состав любой СУБД входят языки двух типов:

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

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

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

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

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

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

Прототип пользовательского интерфейса верхнего уровня можно посмотреть ниже на рисунке 2.2.

 

Рисунок 2.2 - прототип пользовательского интерфейса верхнего уровня

 

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

 

Рисунок 2.3 - прототип пользовательского интерфейса нижнего уровня

 

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

 

2.3.1 Концептуальное  проектирование БД

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

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

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

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

 

Рисунок 2.4 - Концептуальная модель.

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

2.3.2 Разработка логической  модели данных

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

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

Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, она необязательно должна быть выражена средствами именно реляционной модели данных. На рисунке представлена логическая модель (рисунок 2.5).

Рисунок 2.5 – Логическая модель

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

 

2.3.3 Разработка физической  модели данных

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