Разработка автоматизированной информационной системы учета заявок на ремонт подвижного состава на примере предприятия РМ ПАТП-6
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
ния её в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечёт за собой значительные изменения в системе, после внесения, которых она должна пройти повторное тестирование.
Во время процесса аттестации должны быть выполнены различные типы проверок документации требований:
-проверка правильности требований;
Системы, предназначены для разных пользователей с различными потребностями, и поэтому набор требований будет равными для всех пользователей системы. Однако дальнейшие размышления и анализ могут привести к необходимости введения дополнительных или новых функций.
-проверка на непротиворечивость;
Это означает, что в требованиях не должно быть противоречащих друг другу ограничений и различных описаний одной и той же системной функции.
-проверка на полноту;
Должна содержать требования, которые определяют все системные функции и ограничения, налагаемые на систему.
-проверка на выполнимость;
Существует ряд методов аттестации требований:
-обзор требований;
-прототипирование;
-генерация тестовых сценариев;
-автоматизированный анализ непротиворечивости.
Диаграмма потоков пользовательского интерфейса используется для изучения взаимосвязей между основными элементами пользовательского интерфейса.
Прототипы позволяют решать три основные задачи: прояснение и завершение процесса формулировки требований, исследование альтернативных решений и создание конечного продукта.
Прототип показывает внешний вид экранов пользовательского интерфейса и позволяет осуществлять частичную навигацию между ними. Он позволяет пользователям исследовать поведение предполагаемой системы в тех или иных ситуациях для уточнения требований, а также выяснить, смогут ли они с помощью системы, основанной на прототипе, выполнять свою работу. Диаграмма потоков пользовательского интерфейса показана на рисунке 1.6.
Рисунок 1.6 - Диаграмма потоков пользовательского интерфейса
Выводы
В данном разделе был проведен процесс анализа предметной области, собраны необходимые требования к разрабатываемой системе, осуществлено бизнес-моделирование процессов, выполнено специфицирование и аттестация требований к программному продукту, что позволило приступить к следующей стадии разработки, проектирование информационной системы.
2. Проектирование информационной системы
.1 Архитектурное проектирование
Одним из важнейших этапов разработки является архитектурное проектирование, которое заключается в сборе всех возможных пожеланий к работе системы, которые только могут прийти в голову пользователям и аналитикам. Позднее эти данные должны будут систематизированы и структурированы, но на данном этапе в ходе интервью с пользователями и изучения документов, аналитик должен собрать как можно больше требований к будущей системе, что не так просто, как кажется на первый взгляд. Пользователи часто сами не представляют, что они должны получить в конечном итоге.
На этапе тестирования ИС используется как локальное приложение.
На этапе эксплуатации ИС будет использоваться как многопользовательское приложение, существует несколько способов перехода системы на многопользовательский доступ.
Планируется в дальнейшем, переход работы приложений в организации на SQL, следовательно, можно перекинуть хранилища данных Access на SQL, а интерфейсы пользователя использовать в Access/12/.
Осуществить настройку Access на многопользовательский доступ, MS Access имеет такую функцию.
Архитектурное проектирование предполагает выбор архитектуры, на которой будет базироваться информационная система.
Для проектирования информационной системы применима клиент-серверная технология. Данная технология обеспечивает большую скорость вычислений, надёжность хранимых данных, легкость поддержки информационной системы.
Под клиент-серверным приложением мы будем понимать информационную систему, основанную на использовании серверов баз данных. Общее представление информационной системы в архитектуре клиент-сервер изображено на рисунке 2.1.
Со стороны клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс, выполняющий все вычисления, операции ввода/выводы, редактирования и сохранения данных.
На сторону SQL - сервер приходится только одна функция - это хранение введённых данных.
Рисунок 2.1 - Представление информационной системы в архитектуре клиент-серверная
Под сервером обычно понимают процесс, который обеспечивает функции по управлению базой данных и предоставляет необходимые ресурсы процессам-клиентам, посылающим запросы на соответствующий вид обслуживания. Задачей клиента является инициирование связи с сервером, определение вида запроса на обслуживание, получение от сервера записей из базы данных, подтверждение окончания обслуживания. Все вопросы, связанные с синхронизацией работы клиентов и управлением выделением им необходимых ресурсов при работе с базой данных, возлагаются на сервер.
Архитектура СУБД типа клиент-сервер дает возможность организовать содержательную обработку данных в интересах конечных пользователей на рабочих станциях.
Архитектура СУБД типа к?/p>