p align="left">Среда разработки - Microsoft Access Язык программирования - Microsoft Visual C# Операционная система - Windows XP Третья категория - это требования к представлению (Р). Требования к представлению описывают формирование требований к интерфейсу программного обеспечения для заказчика. Интерфейс должен быть удобным в использовании и простым в понимании. Четвертой категорией является требования к рискам (R). Данная категория требований направлена на то, чтобы уменьшить риск некорректного внесения данных в систему. Поэтому должно выполнятся требование соответствия полей с занесёнными данными. Также система должна обеспечивать сохранность данных о технических средствах. Данный раздел также включает в себя формирование «Технического задания» (ТЗ) и составление «Технико-экономического обоснования» (ТЭО). Целью разработки ТЭО и ТЗ проекта АИС является оценка основных параметров, ограничивающих проект информационной системы, обоснование выбора и оценка основных проектных решений по отдельным компонентам проекта. Параметризация позволяет определить требования к системе, оценить существующую информационную систему, определить пригодность типовых решений в проекте ИС, выбрать проектные решения в соответствии с предъявляемыми требованиями к АИС. К основным компонентам ТЭО относятся: - характеристика исходных данных о предметной области; - обоснование цели создания ИС; - обоснование автоматизируемых подразделений, комплекса автоматизируемых задач, выбора комплекса технических средств, программного и информационного обеспечения; - разработка перечня организационно-технических мероприятий по проектированию системы; - расчёт и обоснование эффективности выбранного проекта; - выводы о техническом уровне проекта и возможности дальнейших разработок; На основании технико-экономического обоснования строится техническое задание. ТЭО и ТЗ представлены в ПРИЛОЖЕНИЯХ Б и В. 1.6 Выбор методологии проектирования информационной системыВ настоящее время одним из распространенных методов методологии проектирования информационных систем являются методологии структурного подхода, сущность которого заключается в разбиении системы на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.В структурном анализе используются следующие виды моделей (диаграмм):- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;- DFD (Data Flow Diagrams) диаграммы потоков данных;- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру программного обеспечения, структурные схемы программ и диаграммы экранных форм. Все эти модели в совокупности позволяют достаточно просто и полностью описать деятельность организации, выявить все преимущества и недостатки функционирования, и на основе этого оптимизировать деятельность кампании после разработки информационной системы.Выводы к разделуДанная глава является очень важной в разработке ПО. Без анализа и сбора требований невозможно будет приступить к разработке самой информационной системы.Визуальное моделирование оказало большое влияние на развитие ТС ПО вообще и CASE-средств в частности. Понятие CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение этого понятия, ограниченное только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО. [19] В процессе моделирования каждый аспект деятельности предприятия сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами. [43] Моделирование бизнес-процессов является важной составной частью проектов по созданию информационных систем. Отсутствие таких моделей является одной из главных причин неудач многих проектов. [14] На стадии разработки выявляются более детальные требования к системе, выполняется высокоуровневый анализ предметной области и проектирование для построения базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта. Самым важным результатом стадии разработки является описание будущей системы. На данном этапе были собраны все необходимые материалы и определены требования к разрабатываемой информационной системе. В дальнейшем неизбежны незначительные изменения в деталях, однако, серьезные изменения маловероятны. 2 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ2.1 Архитектурное проектированиеАрхитектурное проектирование программного обеспечения информационной системы нужно для того, чтобы определить главные компоненты системы и способы их взаимодействия. Архитектура ПО ИС разрабатывается с учетом удобства использования системы, функциональности, производительности, гибкости, возможности повторного использования, ограничений технологических и экономических. Информационная система учёта техники выполнено как автономное приложение. Такой тип архитектуры объясняется тем, что на одном рабочем месте находится один сотрудник, нет необходимости одновременного доступа к данным БД с разных рабочих мест, следовательно, нет необходимости в многоуровневой архитектуре. Ещё в автономном приложении меньшее количество затрат при его использовании, так как нет необходимости приобретать и устанавливать SQL сервер, который необходим при многоуровневой архитектуре. Всё вышесказанное позволяет сделать вывод, что на данный момент архитектура информационной системы учёта техники выбрана целесообразно текущему положению дел в милиции. 2.2 Проектирование пользовательского интерфейсаНа первом этапе проектирования информационной системы создаются электронные формы ввода-редактирования данных. В разрабатываемой информационной системе учёта технических средств были спроектированы следующие формы:Рисунок 2.1 - Главная форма программыЧтобы начать работу с программой нужно сначала нажать «Файл», затем «Открыть», а потом выбрать нужное: «Справочники», «Карточки учета», «Резервное копирование» или «Формы» (Рисунок 2.2)Рисунок 2.2 - выбор нужной формыРисунок 2.3 - вкладка «Справочники»Вкладка «Справочники» (рисунок 2.3) содержит в себе формы «Персонал», «Должности», «Службы», «Группы аппаратуры» и «Материалы».Рисунок 2.4 - вкладка «Карточки учета»Вкладка «Карточки учета» (рисунок 2.4) содержит в себе формы «Возврат материала», «Заявки на материал», «Изменения в конструкции», «Инвентаризация средств связи», «Итоговый учет работы по годам», «Карточки учета материалов», «Приходной ордер», «Результаты проверки инспектирующими лицами», «Сведения о движении изделия», «Списание материала», «Техническое обслуживание», «Требования на выдачу материалов» и «Учет технического обслуживания».Рисунок 2.5 - меню «Правка»Меню «Правка» содержит (рисунок 2.1.5) - «Отменить», «Вернуть», «Вырезать», «Копировать», «Вставить», «Удалить», «Выделить все», «Найти», «Заменить».Рисунок 2.6 - меню «Вид»Меню «Вид» (рисунок 2.6) содержит - «Панель инструментов», «Панель статуса», «Установка даты», «Параметры программы», «Параметры объектов», «Параметры полей».Рисунок 2.7 - меню «Таблица»Меню «Таблица» (рисунок 2.1.7) содержит - «Изменить», «Добавить», «Удалить», «В начало», «Назад», «Вперед», «В конец», «Сортировка», «Фильтр», «Поиск».Рисунок 2.8 - меню «Окно»Меню «Окно» (рисунок 2.8) содержит - «Сведения о программе», «Скрыть», «Очистить», «Переключить».2.3 Проектирование баз данных Этапы проектирования баз данных:1. Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия: обследование предметной области, изучение ее информационной структуры, выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами, моделирование и интеграция всех представлений. По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. 2. Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей. 3. Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д. [34]Информационная система учёта оргтехники и средств связи имеет модель данных, включающую логический и физический уровни.Для проектирования базы данных был использован ERwin 4.0 разработанный Computer Associates Int. ERwin - мощный и удобный инструмент для построения модели данных. Он обеспечивает высочайшую продуктивность труда при разработке и сопровождении приложений с использованием баз данных. На протяжении всего процесса - от логического моделирования требований к информации и бизнес-правил, которые определяют базу данных, до оптимизации физической модели в соответствии с заданными характеристиками - ERwin позволяет наглядно отобразить структуру и основные элементы БД. [19] ERwin - не только лучший инструмент для проектирования баз данных, но и средство для их быстрого создания. ERwin оптимизирует модель в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств, ERwin автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций, таких как отношения многие-ко-многим, в их реализацию на физическом уровне. Облегчает проектирование баз данных. Для этого достаточно создать графическую E-R модель (объект-отношение), удовлетворяющую всем требованиям к данным и ввести бизнес-правила для создания логической модели, которая отображает все элементы, атрибуты, отношения и группировки. [20] Логическая модель данных представлена на рисунке 2.9. Рисунок 2.9 - Логическая модель данных База данных информационной системы учёта технических средств и средств связи разработана в Microsoft Office Access 2003. На первом этапе была разработана структура данных и построена схема данных. Структуры данных. Выяснив основную часть данных можно приступать к созданию структуры базы, то есть структуры ее основных таблиц. 1. Работа начинается с составления генерального списка полей - он может насчитывать десятки и даже сотни позиций. 2. В соответствии с типом данных, размещаемых в каждом поле, определяют наиболее подходящий тип для каждого поля. 3. Далее распределяют поля генерального списка по базовым таблицам. На первом этапе распределение производят по функциональному признаку. Цель - обеспечить, чтобы ввод данных в одну таблицу производился, по возможности, в рамках одного подразделения, а еще лучше - на одном рабочем месте. 4. В каждой из таблиц намечают ключевое поле. В качестве такого выбирают поле, данные в котором повторяться не могут. Если в таблице вообще нет ни каких полей, которые можно было бы использовать, как ключевые, всегда можно ввести дополнительное поле типа Счетчик - оно не может содержать повторяющихся данных по определению. [16] В целом структура данных включает в себя набор таблиц с атрибутами и выглядит следующим образом: Рис 2.10 - Общая структура данных учёта платежей Далее необходимо рассмотреть присутствующие в структуре данных таблицы с описанием их атрибутов и связей между ними: 1. Таблица «Группы аппаратуры» (Рис 2.11); Рисунок 2.11 - таблица «Группы аппаратуры» Поля таблицы (рис. 2.12): Рисунок 2.12 - поля таблицы «Группы аппаратуры» В данной таблице ключевым является поле «ID тех средства», которое служит для обеспечения целостности данных. «Наименование аппаратуры» берется из таблицы «Материалы», «Спецификация» из таблицы «Спецификация». 2. Таблица «Возврат материала» (рис.2.13); Рисунок 2.13 - Таблица «Возврат материала» Поля таблицы (рис. 2.14): Рисунок 2.14 - поля таблицы «Возврат материала» В данной таблице ключевым является поле «ID». «Материал принял» и «Материал сдал» берется из таблицы «Персонал», «Наименование тех средств» из таблицы «Материалы». 3. Таблица «Должность» (рис. 2.15); Рисунок 2.15 - таблица «Должность» Поля таблицы (рис. 2.16): Рисунок 2.16 - поля таблицы «Должность» Представленная таблица содержит поле должность, она необходима для связки таких таблиц, как «Изменения в конструкции во время эксплуатации и ремонта», «Персонал», «Результаты проверки инспектирующими лицами», «Сведения о движении изделия при эксплуатации», «Учет технического обслуживания» по полю «ID должности».
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
|