Разработка информационной системы организации. Документ Microsoft Word (3). Ис система, предназначенная для сбора, передачи, обработки, хранения и выдачи информации для достижения поставленной цели

• Название: Ис система, предназначенная для сбора, передачи, обработки, хранения и выдачи информации для достижения поставленной цели
• Анкор: Разработка информационной системы организации
• Дата: 30.05.2022
• Размер: 80.56 Kb.
• Имя файла: Документ Microsoft Word (3).docx
• Тип: Документы; #556879
• страница: 6 из 7

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

1.6.6 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.

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


1.6.7 Требования по стандартизации и унификации.

Система должна быть построена с использованием стандартных и

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


1.6.8 Требования к математическому обеспечению:

← универсальность (возможность применения в условиях часто меняющегося законодательства);
← алгоритмическая надежность;
← точность.
Уровень хранения данных в системе должен быть построен на основе СУБД MySQL. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД MySQL.
ИС будет связана с БД «МТ-онлайн».

1.6.9 Требования к информационному обеспечению:

• система должна обеспечивать однократный ввод;
• должны быть разработаны внутренние классификаторы и справочники для функционирования системы.
Используемые при разработке языки высокого уровня должны обеспечивать решение всех задач по реализации функций системы. Система будет написана на языке PHP с использованием БД MySQL. Запросы БД осуществляются на языке MySQL.
Допускается использование стандартных языков высокого уровня, отвечающих требованиям реализации задач предметной области.
Способ организации диалога с пользователем должен обеспечивать:
← уменьшение вероятности совершения оператором случайных ошибочных действий;
← предусматривать логический контроль ввода данных;

1.6.10 Требования к программному обеспечению.

Программные средства должны функционировать под операционной системой Windows XP и выше.
В состав комплекса должны следующие технические средства:
← Сервер БД;
← ПК пользователей;
← ПК администраторов;
← Информационно-справочные терминалы;
Устанавливаются минимальные требования к техническим характеристикам ПК пользователя и ПК администратора:
← Процессор: INTEL CoreX2-180 2 ГГц или AMD Athlon 64X 2ГГц.
← ОЗУ: 1024 Mb
← HDD: 320 Gb

1.6.11 Требования к организационному обеспечению:

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

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

1.6.12 Порядок контроля и приёмки системы:

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

1.6.13 Требования к документированию:

По окончанию выполнения поставленного задания разработчик должен предоставить в трех экземплярах: инструкцию по эксплуатации АИС, ГОСТ 24.208-80, текст программы, спецификацию, смету.

1.6.14 Источники разработки:

ТЗ разрабатывалось на основе ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы», ГОСТ 2.301 «Единая система конструкторской документации. Форматы», ГОСТ 2.105 «Единая система конструкторской документации. Общие требования к текстовым документам».

1.6.15 Этапы решения задачи:

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

Таблица 1 Этапы решения задачи.
|Наименование этапа работ |Номер недели |
|Получение задания на курсовую работу |5 |
|Изучение технического задания, его детализация, подбор литературы |6 |
|Сбор и анализ требований пользователей |7 |
|Проектирование базы данных и разработка приложений |8-10 |
|Реализация и тестирование |12 |
|Подготовка расчетно-пояснительной записки |13 |
|Сдача курсового проекта на проверку |14

|Защита курсового проекта |15-17 |


Проектная часть


2.1 Описание модели проектируемой информационной системы

Функциональная модель процесса формирования заявок в нотации IDEF0 при использовании проектируемой системы представлена на рисунках 5 и 6. Также, на рисунке 7 и 8 представлена диаграмма деятельности бизнес-процесса и описание макро шагов бизнес-процесса, диаграмма Use Case (Рисунок 9), диаграмма состояний работы консультанта (Рисунок 10), диаграмма последовательности работы консультанта (Рисунок 11 и Рисунок 12).

[pic]
Рис. 5 - Функциональная модель процесса формирования заказа (как должно быть)
[pic]
Рис. 6 - Функциональная модель процесса формирования заказа в нотации IDEF0 (как должно быть).


[pic]
Рис. 7 - Диаграмма деятельности бизнес-процесса

[pic]
Рис.8 - Описание макро шагов бизнес–процесса

[pic]
Рис.9 – диаграмма Use Case системного администратора


[pic]
Рис.10 – диаграмма Use Case клиента


2.2 Формы первичных документов.

Входной информацией являются данные о клиенте представлена в таблице 2. Также, в заказе содержится информация о заказе (Таблица 3) и данные о заказанном товаре (Таблица 4).
Таблица 2 - Данные о клиенте
|Наименование реквизита |Идентификатор |Тип данных |Разрядность |
|Код пользователя |ID (pr_key) |Числовой |10 |
|Логин |LOGIN |Текстовый |20 |
|Пароль |PAS |Числовой |20 |
|ФИО |FIO |Текстовый |50 |
|Электронная почта |EL |Текстовый |50 |
|Город |CITY |Текстовый |20 |
|Адрес |ADRESS |Текстовый |100 |
|Телефон |TELEPHONE|Числовой |15 |
|Уровень доступа |ACCESS |Текстовый |5 |


Таблица 3 - Данные о заказах
|Наименование реквизита |Идентификатор |Тип данных |Разрядность |
|Номер заказа |ID_zak (pr_key) |Числовой |10 |
|Код пользователя |ID |Числовой |10 |
|Дата составления |DATA |Дата/время |- |
|Сумма заказа |SUM |Числовой |20 |
|Статус |ST |Текстовый |50 |
|Доставка |GETING |Текстовый |15 |
Таблица 4 - Данные о товарах
|Наименование реквизита |Идентификатор |Тип данных |Разрядность |
|Код товара |ID_tov (pr_key) |Числовой |10 |
|Название |TOVAR |Текстовый |100 |
|Фирма изготовитель |FIRMA |Текстовый |100 |
|Техн. характер. |ABOUT |Текстовый |500 |
|Кол-во |KOLVO |Числовой |3 |
|Цена за ед. |CENA |Числовой |15 |

2.3 Формы результатных документов

Выходной информацией являются данные начала и окончания проверки
Таблица 5 - «отчет о фиормировании заказа»
|Наименование реквизита |Идентификатор |Тип данных |Разрядность |
|Номер заказаD_Zak |Числовой |10 |
|Логин заказчика |LOGIN |Текстовый |20 |
|Наименование товара |TOVAR |Текстовый |100 |
|Количество |KOLVO |Числовой |3 |
|Сумма |SUM |Числовой |20 |

2.4 Классификаторы с описанием их структур

Для удобства использования информации, являющейся довольно устойчивой (неизменной) во времени, носящей справочный характер в АЭИС следует разработать локальные классификаторы.
Создам локальный классификатор заказов по № заказчика, дате заказа и сумме заказа. Используем для классификатора фасетный метод (Таблица 6).

Таблица 6 - Классификатор заказов
|Наименование кодируемого |Разрядность кода |Система кодирования |Система классификации |Вид классификатора |
|множества объектов | | | | |
|Номер заказа |16 |Параллельная |Фасетная |Локальный |
|Номер заказчика |6 |Порядковая |Отсутствует |Локальный |
|Дата составления |6 |Отсутствует |Отсутствует |Локальный |
|Номер данного заказа |4 |Порядковая |Отсутствует |Локальный |

Классификатор имеет кодировку.050513010203001, где 050513 – это дата заказа, 010203 – номер заказа, 001 – номер текущего заказа.

Пример классификатора содержится в таблице 7.
|Дата заказа |Номер заказа |Номер данного заказа |
|05.05.13 |010203 |001 |
|12.05.13 |123456 |002|
|14.05.13 |001002 |001 |
|19.05.13 |201301 |003 |

2.5 Описание информационной модели

Для решения задач данной автоматизированной информационной системы необходима информация о поступивших заказах от покупателей, информация о поставленных товарах:
• Наименование товара;
• Фирма производитель;
• Тех.Характ.;
• Кол-во;
• цена единицы.
Поступивший заказ заносится в базу данных, и в дальнейшем из заказов в базе данных формируется список заказанных товаров, который содержит следующую информацию:
• Код заказа;
• ФИО покупателя;
• адрес покупателя;
• Наименование товара;
• Сумма.
В отделе продаж анализируются список заказов, сопоставляется список проданных товаров со списком поставленных товаров, выявляются необходимые товары и составляется заявка.
В заявке содержится информация о необходимых товарах и их количестве. В дальнейшем заявка передается начальнику склада, а затем уже со склада курьер из службы доставки забирает товар и передает его покупателю.
Вся эта информация берётся из базы данных, которая имеет структуру, проиллюстрированную на рисунке 10.


[pic]
Рис. 10- Информационная модель

Программная часть


3.1 Обоснование технико-экономической эффективности выбора ПО для реализации подсистемы методом анализа иерархии

Для выбора наиболее эффективной среды разработки воспользуюсь методом анализа иерархий.
Метод анализа иерархий применяется при необходимости принятия решения по выбору одной из нескольких альтернатив. При этом необходимым условием применения этого метода является наличие общих характеристик совокупности сравниваемых объектов. Эти характеристики служат в конечном итоге критериями выбора наилучшей альтернативы.
Рассмотрю в качестве оцениваемых критериев 3 наиболее важные, с точки зрения разработки автоматизированной информационной системы, качества языков программирования PHP, Ruby, Perl и Python: скорость обработки запросов (S), трудоёмкость создания АИС (C), стоимость хостинга с поддержкой данного языка (W).


Таблица 8 - Шкала предпочтений

|Степень превосходства |Определение |
|0 |Объекты не сравнимы

|
|1 |Объекты одинаково важны |
|3 |Умеренное превосходство одного над другим |
|5 |Существенное превосходство одного над другим |
|7 |Значительное превосходство одного над другим |
|9 |Абсолютное превосходство одного над другим |
|2,4,6,8 |Промежуточные значения степени превосходства |


Для получения оценок значимости сравниваемых критериев была построена матрица попарного сравнения (Таблица 9), в которую внесены результаты попарного сравнения рассматриваемых критериев.

Таблица 9 - Матрица попарного сравнения

|  |S |C |W |yi |yiн |λi |
|S |1 |2 |4 |2,000 |0,558 |0,977 |
|C |0.5 |1 |3 |1,145 |0,320 |1,065 |
|W |0.25 |0.3333 |1 |0,437 |0,122 |0,976 |
|Сумма |1.75 |3.3333 |8 |3,582 |1,000 |3,018 |


Оценка компонент собственного вектора каждого критерия вычисляется по формуле (1), а по формуле (2) эта оценка нормализуется.

[pic] (1)

[pic] (2)

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

Индекс согласованности вычисляется по следующей формуле:

[pic]

λmax вычисляется по следующей формуле:

[pic]

где [pic]

ИС=(3,018-3)/2=0,005

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

идеальных матриц разного размера приведены в таблице 10.

Таблица 10 - Значения случайной согласованности

|Размер матрицы |1 |2 |
| |S |C |W | |
| |0,14 |0,24 |0,63 | |
|PHP |0,33 |0,22 |0,47 |0,3951 |
|Ruby |0,2 |0,24 |0,23 |0,2305 |
|Python |0,33 |0,11 |0,09 |0,1293 |
|Perl |0,14 |0,42 |0,21 |0,2527 |


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

Дерево функций системы представляет собой декомпозицию ее функций и служит основой для формирования системы.
Для системного администратора АЭИС, дерево функций будет выглядеть следующим образом (рисунок 11):
[pic]
Рис. 11 - Дерево функций администратора

Для клиента, дерево функций будет выглядеть так (рисунок 12): [pic]
Рис. 12 - Дерево функций клиента


3.3 Сценарий диалога

Структура сценария диалога дает возможность определить состав кадров диалога, содержание каждого кадра и их соподчиненность.
Структура сценария диалога представляется в виде орграфа. Граф диалога – ориентированный взвешенный граф, каждой вершине которого сопоставлена конкретная картинка на экране или определенное состояние диалога, характеризующееся набором доступных пользователю действий. Дуги, исходящие из вершин, показывают возможные изменения состояний при выполнении пользователем указанных действий.
На рисунке 13 изображен орграф сценария диалога оператора информационной системы.
[pic]
Рис. 13 - Сценарий диалога системного администратора


Таблица 15 - Описание узлов для орграфа диалога системного администратора
|№ вершины графа |Операция |
|0

|вход в систему |
|1 |просмотр товаров |
|2 |добавление новых товаров |
|3 |просмотр заказов |
|4 |просмотр учётных записей клиентов |
|5 |Редактирование информации |
|6 |Удаление товара |
|7 |Изменение статуса заказа |
|8 |Удаляем заказ |
|9 |Подтверждение регистрации |
|10 |Удаление учетной записи клиента |
|11 |Выход |


Орграф сценария диалога клиента с системой изображен на рисунке 14.
[pic]
Рис. 14 - Сценарий диалога клиента

Таблица 17 - Описание узлов орграфа диалогов для клиента
|№ вершины графа |Операция |
|0 |вход в систему |
|1 |просмотр каталогов товаров |
|2 |просмотр заказов|
|3 |оформление заказа |
|4 |отмена заказов |
|5 |Выход |

3.4 Дерево программных модулей

На рисунке 15 представлено дерево программных модулей, построенное на основе результатов, полученных в предыдущем пункте. Описание функций, выполняемых каждым из модулей, содержится в таблице 18.
[pic]
Рис. 15 - Дерево программных модулей

Таблица 18 - Описание функций программных модулей
|Идентификатор модуля |Выполняемые функции |
|Index.html |Главная страница |
|Login.php |Авторизация аккаунта |
|Registration.php |Регистрация аккаунта |
|View_zak.php |Просмотр заказа |