close

Вход

Забыли?

вход по аккаунту

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

код для вставки
МИНИС
ТЕ,Р С ТВ
О ОБРАЗОВАНИJI И НАУКИ
Р
ОССШ;IСКОЙ
ФЕшрАIдц4
ФЕШРАJЪНОЕ ГОСУДАРСТВЕННОЕ БЮДДЕТНОЕ
оБрАз ов ATEJьHOE учрЕжшниЕ высr I IF,го оБрАзов Аниr{
(орловскIд;1 госудАрствЕ,нныЙ уrшвЕрситЕ,т
имени И.С. ТУРГЕНЕВА>
ВЫШУСКНАЯ КВАЛИФИКАЦИОННАЯ
по направлению подготовки
: 09. 04.
РАБОТА
03 Прикладная информатика
направленность (профиль): Прикладнм информатика в анzlлитической
экономике
Магистранта: Минакова Сергея Витальевича, шифр 150778
Факулътет
:
физико-математический
Тема выпускной квалификационной работы
ИНООРМАЦИОННОЙ
РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ
СИСТЕМЫ УПРДВЛЕНИЯ ДЕЯТЕЛЬНОСТЪЮ КНИ)КНОГО
мАгАзинА
Магистрант: Минаков Сергей Витальевич
Руководителъ
:
/rt
Ломакин,Щенис. Евгеньевич
к.ф.-м.н., доцент
Зав. кафедрой /
(поdпuсь)
,
l.
Орёл
,
^
_-cl
РоП: Селютин Владимир .Щмитриевич
д.-р..п.н, профессор
:
"/"
(поdпuсь)
j
201-'7
4
Содержание
Введение
5
Глава 1 Анализ предметной области
9
1.1 Описание предметной области
9
1.2 Описание свойств ИС, требуемых для решения выбранной задачи
10
1.3 Модель процессов предметной области
15
1.4 Анализ аналогов
22
1.5 Календарно-ресурсное планирование проекта, анализ бюджетных
ограничений и рисков
26
1.6 Расчет заработных плат и страховых взносов
29
1.7 Расчет затрать на оборудование, его эксплуатацию, сырье и
материалы
30
1.8 Определение себестоимости продукта
30
Глава 2 Планирование разработки информационной системы
32
2.1 Функциональные требования к проектируемой системе
32
2.2 Проектирование базы данных
33
2.3 Построение связей между сущностями
43
2.4 Формирование ограничения целостности базы данных
44
2.5 Выбор технологии для реализации ИС
46
2.6 Выбор СУБД
51
2.7 Выбор языка реализации
53
2.8 Концепция MVC
55
Глава 3 Реализация информационной системы
58
3.1 Алгоритм загрузки интерфейсов
58
3.2 Алгоритм продажи книгопечатной продукции
59
3.3 Проектирование логики диалога с пользователями системы
61
Заключение
68
Список используемой литературы
69
Приложение
71
5
Введение
Книга – древний культурный атрибут, которая долгие века остаётся с
человеком. Вначале её использовали для записи событий, научных знаний, а
также религиозных текстов, затем с развитием книгопечатания и зарождением
художественной литературы книга стала частью досуга. Сегодня основным и
традиционным интеллектуальным продуктом, призванным удовлетворять
духовные, научно-познавательные, образовательные, эстетические и этические
потребности человека по-прежнему является книга.
Центральной задачей книжной торговли, как и любого бизнеса, является
эффективная реализация имеющейся продукции, что не возможно без
привлечения как можно большего числа активных потребителей. Обеспечить
выполнение этой задачи возможно с помощью использования всего арсенала
современных информационных технологий.
Сегодня информацию рассматривают как один из основных ресурсов
развития общества, а информационные системы и технологии как средство
повышения производительности и эффективности работы людей. Главное
внимание уделяется рассмотрению информационных систем и технологий с
позиций использования их возможностей для повышения эффективности труда
работников информационной сферы производства и поддержки принятия
решений в организациях (фирмах).
Сейчас для людей особую ценность имеет время, многим его порой
просто не хватает, и разработчики информационных систем понимают это. Они
стараются спроектировать систему так, чтобы система сама подстраивалась под
человека, под его ритм жизни, а не наоборот.
На сегодняшний день компьютеризация охватила весь мир. Сам термин
«компьютеризация»
в
широком
электронно-вычислительной
смысле
техники
во
человека. Главной целью компьютеризации
означает
все
сферы
процесс
внедрения
жизнедеятельности
является улучшение качества
жизни людей за счет увеличения производительности и облегчения условий
6
труда.
Однако,
для
успешного
внедрения
мало
только
электронно-
вычислительной техники, требуется так же программное обеспечение, которое
помогло бы в решении поставленных задач. Но бывает так, что уже
существующих программных продуктов не достаточно для успешного
внедрения и это приостанавливает процесс компьютеризации. В этом случае
ведется разработка нужного программного продукта, ведь без создания
специализированных программ трудно получить желаемые результаты[3].
Информационная система — взаимосвязанная совокупность средств,
методов и персонала, используемых для хранения, обработки и выдачи
информации в интересах достижения поставленной цели. Одной из важнейших
разновидностей
информации
является
информация
экономическая.
Ее
отличительная черта – связь с процессами управления коллективами людей
организацией.
Экономическая
информация
сопровождает
процессы
производства, распределения обмена и потребления материальных благ и
услуг[4].
Автоматизированная информационная система (АИС) — совокупность
программно-аппаратных
средств,
предназначенных
для
автоматизации
деятельности, связанной с хранением, передачей и обработкой информации.
АИС являются, с одной стороны, разновидностью информационных
систем (ИС), с другой — автоматизированных систем (АС), вследствие чего их
часто называют ИС или АС.
АИС может быть определена как комплекс автоматизированных
информационных
технологий,
предназначенных
для
информационного
обслуживания – организованного непрерывного технологического процесса
подготовки
и
выдачи
потребителям
научной,
управленческой
и
др.
информации, используемой для принятия решений, в соответствии с нуждами
для поддержания эффективной деятельности[3].
Актуальность создания и развития АИС заключается в необходимости
отслеживания
всех
операций
деятельности
книжного
магазина,
востребованность в единой базе данных, отсутствие достойных аналогов,
7
экономия времени сотрудников на выполнение ненужной бумажной работы.
Вследствие чего можем сделать вывод, что разработка АИС управления
деятельностью книжного магазина актуальна.
Объектом данного исследования является деятельность книжного
магазина.
Предметом
выступает
автоматизированная
информационная
система управления деятельностью книжного магазина.
Целью
данной
выпускной
квалификационной
работы
является
совершенствование процессов деятельности книжного магазина за счет
разработки автоматизированной информационной системы.
Для достижения данной цели необходимо выполнить следующие задачи:

выполнить
анализ
предметной
области
и
сформулировать
функциональные требования к автоматизированной информационной системе
на его основе;

провести анализ аналогов проектируемой АИС;

изложить значимые преимущества и недостатки аналогов;

обосновать выбор средств разработки;

разработать структуру базы данных для АИС;

реализовать ограничения целостности данных информационной
системы;

разработать основные алгоритмы функционирования АИС;

разработать пользовательский интерфейс АИС и описать логику
диалога с пользователем;

реализовать АИС управления деятельностью книжного магазина.
Выпускная квалификационная работа состоит из введения, трех глав,
заключения, списка использованных источников и приложения.
Во введении обоснована актуальность темы исследования, определены
предмет и объект исследования, поставлены цель и задачи работы, описана
структура работы.
8
В анализе предметной области, описана предметная область системы;
выделены основные задачи и требования к разрабатываемой информационной
системе управления деятельностью книжного магазина; реализована модель
процессов предметной области; проведено календарно-ресурсное планирование
и определена экономическая эффективность.
В разделе проектирования спроектирована база данных и логика диалога
с пользователя с приложением, выбраны средства для реализации ИС.
В разделе реализации проводится описание разработки интерфейса
пользователя, описание основных алгоритмов функционирования системы,
описание примера работы приложения.
В заключении описаны выводы по проделанной работе.
Для выполнения выпускной квалификационной работы необходимо
достичь поставленной цели и выполнить задачи.
9
1 Анализ предметной области
1.1 Описание предметной области
В данной выпускной квалификационной работе объектом исследования
является деятельность книжного магазина, которая подразумевает: продажу,
закупку книгопечатной продукции, управление товаром, учет кадров и
предоставление скидок.
Книжный магазин – это учреждение, производящее розничную
торговлю книгопечатной продукции, а также помещение, в котором
производится такая торговля. Товар закупается у печатных издательств, затем
его везут на склад магазина. Данный вид деятельности осуществляет менеджер
по закупкам.
Книжный магазин представляет собой помещение со стеллажами, на
которых расположена книгопечатная продукция. Каждая полка имеет название,
которое соответствует жанру книг, которые на ней расположены.
Так же в помещении имеется касса, за которой сидит менеджер по
продажам. Все расчеты клиентов проходит через него. Клиент выбирает книгу,
подходит к продавцу, оплачивает книгу, получает чек и забирает продукцию.
Так же при покупке на определенную сумму денег, клиенту выдается скидка.
Клиенты книжного магазина – физические лица, для которых
предусмотрены распространяемые виды товара.
Процесс
продажи
товара
осуществляется
соответствующим
менеджером. Он должен располагать информацией о текущем состоянии
наличия продукции в магазине. Так же менеджер по продаже может
осуществлять
предоставление
скидок
клиентам
сделавшим
заказ
на
определённую сумму денег.
В магазине имеется менеджер по работе с персоналом, который
осуществляет учет кадров. В данный вид деятельности входит:
–
оформление документов на принятие сотрудника на работу;
–
оформление документов на увольнение сотрудника;
10
–
редактирование личных данных сотрудников.
Основная техническая проблема деятельности книжного магазина
заключается в том, что в нем отсутствует единая информационная система
автоматизации деятельности продажи товара, а так же необходимость ведения
учёта информации о состоянии и динамике объектов книжного магазина.
В результате анализа деятельности книжного магазина были выявлены
следующие недостатки и вопросы.
1. В книжном магазине существует разрозненная информационная
база. Информация о клиентах, персонале, заявках и заказах хранится в разных
источниках.
2. Отсутствует возможность анализа информационной базы, каждое из
действий в книжном магазине не фиксируется и в случае возникновения на
вопросы «Кто?», «Когда?» и «Что?» никто не может дать на них ответы.
3. Отсутствует инструмент внесения заявки на закупку товара.
4. Отсутствует инструмент автоматического начисления скидок при
покупки товара на определенную сумму.
Перечисление выявленных недостатков и вопросов обосновывает
необходимость автоматизации основной деятельности книжного магазина.
1.2 Описание свойств АИС, требуемых для решения выбранной
задачи
В анализе предметной области выявили основные проблемы, требующие
реализации в данной выпускной квалификационной работе.
На рисунке 1 представлена диаграмма вариантов использования
разрабатываемой системы, которая позволят более наглядно изобразить роли
пользователей системы, а также действия, которые они могут в ней выполнять.
11
Рисунок 1 – Диаграмма вариантов использования АИС
Действующим лицом на диаграмме являются: менеджер по продажам,
менеджер по работе с персоналом, менеджер по закупке, клиент, которые
12
осуществляют деятельность книжного магазина. На диаграмме актер и
варианты
использования
соединяются
ассоциативными
связями.
Ассоциативная связь устанавливает, какую конкретную роль играет актер при
взаимодействии с экземпляром варианта использования.
Рассмотрим действия, который может выполнять менеджер по работе с
персоналом. Данный актер имеет следующие варианты использования:
редактирование личных данных сотрудников, оформление документов на
принятие сотрудника на работу, который в свою очередь включает в себя
получение информации о сотруднике; оформление документов на увольнение
сотрудника.
Включение (англ. Include) — определяет взаимосвязь базового варианта
использования с другим вариантом использования, функциональное поведение
которого всегда задействуется базовым вариантом использования.
Существует так же связь расширение (англ. Extend) — разновидность
отношения зависимости между базовым вариантом использования и его
специальным случаем.
Теперь рассмотрим вариантах использования менеджера по закупкам.
Заказ товара, имеющий расширение внесение предложения о закупке
продукции, последний осуществляет клиентом и необходим для формирования
статистики товаров, которые клиенты больше всего хотят видеть в книжном
магазине. Вариант использование управление товаром включает внесение
товара в каталог (после чего его можно будет продавать и имеет расширение
редактирование информации о товаре). Так же менеджер по закупкам может
просмотреть каталог товара, чтобы обладать необходимой информацией о
наличии товара в магазине. Данный вариант использования включает в себя
просмотр детальной информации о товаре и поиск его по ключевым словам.
Рассмотрим действия, который
может выполнять менеджер
по
продажам. Данный актер имеет следующие варианты использования: просмотр
каталога товара, необходимый для предоставлении актуальной информации о
наличии продукции в магазине; регистрация клиента, подразумевающий
13
занесения в систему информации о клиенте, который тот может предоставить
по желанию для получения скидки и привилегий; продажа товара, который
включает два варианта использования: выдача чека о покупке и выдача
купленного товара.
Ниже представлен поток событий варианта использования «Продажа
товара».
1. Вариант использования начинается, когда клиент обращается к
менеджеру по работе с клиентами с просьбой выдать ему информацию о
товаре.
2. Менеджер обращается к БД и выбирает информацию о имеющейся
на данный момент времени продукции в магазине.
3. Вся информация выводится на внешний дисплей.
4. Клиент ознакомляется с ней и решает, что делать дальше.
5. Клиент принимает решение о покупке.
6. Клиент оплачивает стоимость товара.
7. Менеджер принимает деньги, вносит их в кассовый аппарат.
8. Далее менеджер помечает товар, как купленный и система
автоматически вносит изменения в БД.
9.
Менеджер
по
продажам
выдает
клиенту
товар,
чек,
свидетельствующий о купле-продаже и сдачу, если таковая имеется.
10. Вся информация о купле-продаже автоматически заносится в реестр
проданной продукции, при необходимости возврата книги, эти данные будут
сверяться с чеком.
11. Процесс завершен.
Будущее информационное решение описанной задачи должно обладать
следующими свойствами:
‒
обеспечивать сбор в единую базу всей накопленной информации в
книжном магазине;
‒
обеспечивать сбор истории всех операций деятельности книжного
магазина (продажа, заказ);
14
‒
предоставлять возможность формирования аналитических отчетов;
‒
отслеживать взаиморасчеты с клиентами;
‒
отслеживать статистику продаж и предложений о закупке для
формирования списка товаров, которые пользуются большой популярностью у
клиентов.
1.3 Модель процессов предметной области
Описание процессов предметной области целесообразно начать с
определения цели, возможных точек зрения и границ модели системы.
Цель – совокупность вопросов, на которые модель должна отвечать с
заданной точностью. Таким образом, для формулирования цели моделирования
необходимо определить наиболее важные вопросы, касающиеся проектируемой
модели.
Определим границы модели. Обычно они подразделяются на границы в
ширину и в глубину. Отражением границы модели в ширину является
контекстная диаграмма, представляющая собой связь системы с внешним
миром. Глубина модели – число уровней её детализации[12].
После того как определены цель, точка зрения и границы модели
начинается моделирование по методологии SADT. Использование мощного
инструмента моделирования с возможностью анализа, документирования и
корректирования бизнес-процессов Ramus Education помогло построить модель
процесса управление деятельностью книжного магазина, представляющую
собой набор диаграмм, имеющих иерархическую структуру. Каждая диаграмма
включает ряд элементов, таких как активности (процессы, функции) и дуги.
Между функциями возможны 4 вида отношений: вход, управление, выход,
механизмы[10].
Анализ функциональной модели позволяет понять, где находятся
наиболее слабые места, где именно будет производиться автоматизация
деятельности предприятия и насколько глубоким изменениям подвергнется
существующая
структура
организации.
Детализация
бизнес-процессов
15
позволяет выявить недостатки организации даже там, где функциональность, на
первый взгляд, кажется очевидной.
Построим контекстную диаграмму (рисунок 2). Контекстная диаграмма
отображает основной процесс деятельности работы книжного магазина.
Рисунок 2 – Контекстная диаграмма «Управление деятельностью книжного
магазина»
Информация о присутствующих на контекстной диаграмме стрелках
сведена в таблицу 1.
Таблица 1 – Описание стрелок контекстной диаграммы
Название
Описание
Тип
1
2
3
Наименование, автор, жанр,
Личные данные
клиентов
год
выпуска,
издательство,
дата, количество и закупочная
цена
продукции
книгопечатной
Входная
16
Продолжение таблицы 1
1
2
Дата,
Данные о книгах
3
список
которую
продукции,
клиент
хотел
бы
Входная
видеть на прилавках магазина
Предложения о
заказе
Личные данные
сотрудников
Книгопечатная
продукция на
продажу
Книгопечатная
продукция на заказ
Каталог клиентов
магазина
Каталог
Имя, фамилия, email, номер
телефона, пароль
Имя,
фамилия,
паспортные
Входная
должность,
данные,
email,
Входная
номер телефона, пароль
Список
книгопечатной
продукции,
которая
была
продана, а так же чеки и
Выходная
отчетность.
Список
книгопечатной
продукции,
которая
была
Выходная
заказана, отчеты по заказам.
Список
магазина,
клиентов
книжного
информация
о
Выходная
скидках для клиентов
Список всех книг магазина
Выходная
Номер чека по проданным
Выходная
существующей
книгопечатной
продукции
Чек
книгам
Каталог сотрудников Информация о
магазина
сотрудниках
книжного магазина
Выходная
17
Продолжение таблицы 1
1
2
3
Законодательство в сфере
защиты прав потребителей
Законодательство РФ
(рассмотрение претензии в
Управляющая
течение 10 дней от даты ее
подачи)
Стоимость,
Политика магазина
сезонный
коэффициент
продажи
Управляющая
продукции
Документы,
Нормативные
документы
устанавливающие
стандарты,
нормы,
определяющие
Управляющая
правила деятельности
Сотрудник
Менеджер по продажам магазина,
книжного
отвечающий
за
Механизм
продажу товара
Менеджер по работе с
персоналом
Клиент
Сотрудник, отвечающий за
учет кадров
Пользователь
книжного магазина
услугами
Механизм
Механизм
Для более детального изучения процесса учёта взаимоотношений с
клиентами на предприятии необходимо провести декомпозицию контекстной
диаграммы (рисунок 3).
18
Рисунок 3 – Декомпозиция контекстной диаграммы «Управление
деятельностью книжного магазина»
Из схемы, изображенной на рисунке 3, становятся понятными основные
блоки. Декомпозиция контекстной диаграммы представлена следующими
пятью активностями:
1. Управление работой с клиентами;
2. Формирование каталога существующей книгопечатной продукции;
3. Управление заказами книжной продукции;
4. Управление продажами книжной продукции;
5. Управление работой с персоналом.
Все из этих процессов отражают процесс взаимодействия менеджера и
клиента. Процесс «Управление работой с клиентами» не является простым и
выходит
за
дальнейшей
границы
модели,
следовательно,
декомпозиции
необходимо
(рисунок
проведение
4).
19
Рисунок 4 – Декомпозиция контекстной диаграммы «Управление работой с
клиентами»
Диаграмма на рисунке 4 представлена тремя активностями.
1. Заполнение анкеты постоянного клиента.
2. Регистрация клиента.
3. Предоставление скидки.
Каждая из выделенных активностей представляет собой простое
понятное действие, декомпозиция которого перейдет границы модели, поэтому
дальнейшая декомпозиция не требуется.
Активность «Управление заказами книжной продукции» отражает
процесс учета данных о заказах книжного магазина. Данный процесс не
является простым и выходит за границы модели, следовательно, необходимо
проведение дальнейшей декомпозиции (рисунок 5).
20
Рисунок 5 – Декомпозиция контекстной диаграммы «Управление заказами
книжной продукции»
Диаграмма представлена тремя активностями.
1. Формирование статистики о популярных книгах.
2. Просмотр каталог существующей книгопечатной продукции.
3. Заказ товара.
Каждая из выделенных активностей представляет собой простое
понятное действие, декомпозиция которого перейдет границы модели, поэтому
дальнейшая декомпозиция не требуется.
Активность «Управление продажами книжной продукции» отражает
процесс учета данных о продажах книжного магазина. Данный процесс не
является простым и выходит за границы модели, следовательно, необходимо
проведение дальнейшей декомпозиции (рисунок 6).
21
Рисунок 6 – Декомпозиция контекстной диаграммы «Управление продажами
книжной продукции»
Диаграмма представлена тремя активностями.
1. Просмотр каталога книг.
2. Получение денежных средств за книгу.
3. Продажа книжной продукции
Каждая из выделенных активностей представляет собой простое
понятное действие, декомпозиция которого перейдет границы модели, поэтому
дальнейшая декомпозиция не требуется.
Активность «Управление работой с персоналом» отражает процесс учета
данных о сотрудниках книжного магазина, процесс оформления документов на
принятия сотрудника на работу и увольнения (добавление новых пользователей
системы, удаление), а так же редактирование личных данных сотрудников.
Данный процесс не является простым и выходит за границы модели,
следовательно, необходимо проведение дальнейшей декомпозиции (рисунок 7).
22
Рисунок 7 – Декомпозиция контекстной диаграммы «Управление работой с
персоналом»
Диаграмма представлена тремя активностями.
1. Оформление документов на принятие на работу.
2. Редактирование данных сотрудников.
3. Оформление документов на увольнение.
Каждая из выделенных активностей представляет собой простое
понятное действие, декомпозиция которого перейдет границы модели, поэтому
дальнейшая декомпозиция не требуется.
1.4 Анализ аналогов
Разрабатываемая автоматизированная система является частью системы
управления,
которая
позволяет контролировать
деятельность
книжного
магазина и имеет ряд инструментов для его функционирования, позволяет
управлять продажами, закупками книгопечатной продукции, вести учет
операций в магазине, учет скидок при покупке товара, позволяет оставлять
предложения клиентов на закупку книг[1].
23
Сейчас существует множество аналогов данной системы. Все они
обладают различными возможностями и направлены на осуществление разных
целей. Однако в ходе рассмотрения этих аналогов не было найдено ни одного,
который был бы полностью схож по функциям с разрабатываемой
системой[14].
В результате поиска конкурентоспособных аналогов АИС деятельности
книжного магазина в сферу рассмотрения попали следующие три аналога
системы.
Один из таких аналогов – система «Microsoft Dynamics». Эта система
предоставляет компании (малого, среднего или крупного бизнеса) средства для
управления всей организацией, начиная с цепочки поставок, закупок и
управления персоналом и заканчивая финансами и проектами совместной
работы. Можно выделить следующие основные особенности этой системы:

автоматизация
производственных
и
торговых
предприятий,
бюджетных и финансовых организаций, предприятий сферы обслуживания и
т.д.

поддержка оперативного управления предприятием;

автоматизация организационной и хозяйственной деятельности;

ведение бухгалтерского учета с несколькими планами счетов и
произвольными измерениями учета, регламентированная отчетность;

широкие возможности для управленческого учета и построения
аналитической отчетности;

решение задач планирования, бюджетирования и финансового
анализа;

расчет зарплаты и управление персоналом.
Еще одним аналогом разрабатываемой АИС является система FurNEXT,
которая имеет следующий ряд особенностей:

правами;
ограниченное число типов пользователей с разграниченными
24

стандартный набор справочников;

клиентская база;

оформление поступления и продажи товара;

просмотр наличия товара;

печать отчетов;

расширенный поиск.

свободные печатные формы;

сессии пользователей.
Еще одной аналогичной системой можно назвать систему «Инталев 24».
Инталев 24 – система управления бизнесом на базе 1С. Функциональные
возможности системы включают управление финансами, бюджетирование,
управление персоналом, CRM, документооборот, управление сервисом,
отчетность и аналитику. Эта система направлена на комплексное управление
организацией.
Все выше перечисленные системы имеют ряд особенностей, однако
каждая из них имеет и недостатки по сравнению с разрабатываемой системой.
Главные же недостатки этих систем является то, что они направлены на
управление организацией в общем случае, не зависимо какое предприятие эта
система управляет и не обращая внимания на частные случаи, в отличие от
разрабатываемой системы, которая ориентирована на управление деятельности
книжного магазина.
Ни один из рассмотренных аналогов не обладает той комбинацией
возможностей, которую имеет разрабатываемая система. На основании всего
вышесказанного можно составить сравнительную таблицу конкурентных
преимуществ, которая расположена ниже.
25
Таблица 2 – Сравнительная таблица конкурентных преимуществ
Критерий
Microsoft
FurNEXT
Интлаев 24
мая АИС
Dynamics
1
Разрабатывае
2
3
4
5
+
-
-
+
+
+
-
+
-
-
-
+
+
-
+
+
+
-
-
+
-
-
-
+
-
-
-
+
Возможность
добавления новых
пользователей
системы
Возможность
документации всех
операций предприятия
Уникальная настройка
прав доступа
Ведение журнала
событий,
происходящих в
системе
Формирование
статистики по покупке
и продаже
Учет скидок и
дисконтных карт
Автоматический
расчет скидки
26
Продолжение таблицы 2
1
2
3
4
5
-
-
-
+
-
-
-
+
Возможность
формирование
предложений для
закупки книгопечатной
продукции
Кроссплатформенность
Как видно из таблицы 2, все рассмотренные системы, помимо очевидных
достоинств, имеют и недостатки, существенные и несущественные. Данное
явление
можно
объяснить
тем,
что
каждая
система,
как
правило,
разрабатывалась для решения четко определенной задачи и является
законченным программным продуктом.
Исходя из всего перечисленного можно сделать вывод, что разработка
автоматизированной информационной системы для управления деятельностью
книжного магазина является актуальной.
1.5 Календарно-ресурсное планирование проекта, анализ бюджетных
ограничений и рисков
Перед началом разработки любого программного продукта необходимо
оценить экономический эффект от его последующего внедрения в производство
либо в любую другую сферу деятельности. Как правило, на рынке уже
существуют аналоги разрабатываемых систем, и конечные пользователи в
первую очередь будут сравнивать стоимость разработки нового программного
продукта со стоимостью покупки уже существующего аналога. Поэтому задача
оценки эффективности разработки программы является основополагающей и
позволяет оценить шансы успеха на рынке ПО[17].
27
Для расчета затрат на этапе проектирования, необходимо, в первую
очередь, составить календарный план работ и определить длительности каждой
работы. В данной работе для определения длительности работ будет
использоваться расчетный метод с использованием экспертных оценок по
формуле 1:
3T i  2T i
max
qi  min
5
Ожидаемая
продолжительность
(1)
работы
qi
рассчитывается,
как
математическое ожидание для  - распределения, Tmin и Tmax - минимальная и
максимальная продолжительность работы, которые назначаются в соответствии
с экспертными оценками. Результат расчетов составим в таблицу 3.
Таблица 3 – Длительность этапа разработки
№
Наименование работы
Длительность работы
работы
tmin
tmax
tожидаемое
1
Изучение технического задания
1
6
5,4
2
Сбор материалов по теме
8
16
11,2
3
Анализ
10
12
10,8
и
структурирование
собранного материала
4
Разработка плана решения задачи
8
20
12,8
5
Знакомство с необходимым ПО
14
20
16,4
6
Написание
теоретической
части
32
48
38,4
практической
части
40
50
44
задачи
7
Разработка
задачи
8
Оформление документации
10
16
12,4
9
Сдача проекта
1
1
1
124
189
152,4
Итого
28
Исходя из длительности этапов разработки, можем построить ленточный
график трудоемкости проекта (Рисунок 8).
Изучение технического задания
Сбор материалов по теме
Анализ и структурирование собранного материала
Разработка плана решения задачи
Знакомство с необходимым ПО
Написание теоретической части задачи
Разработка практической части задачи
Оформление документации
Сдача проекта
Рисунок 8 – Ленточный график трудоемкости проекта
Данные анализа трудозатрат проекта необходимо использовать для
определения численности исполнителей проекта.
Средняя численность исполнителей при реализации отдельных этапов
проекта можно определить, используя формулу 2:
N
где,
qi
qi
F
(2)
- затраты труда на выполнение соответствующего этапа (задачи)
проекта, F - фонд рабочего времени.
Для определения числа исполнителей, сначала, следует определить фонд
времени в текущем месяце, который составляет = 168 часов. Тогда, средняя
численность исполнителей проекта определится значением:
N  153  0,91 . Таким
168
образом, для реализации данного проекта достаточно привлечь одного
исполнителя.
29
1.6 Расчет заработных плат и страховых взносов
По данным таблицы можно определить расходы на заработную плату
исполнителя и отчислений на страховые взносы на обязательное социальное,
пенсионное
и
медицинское
страхование.
Заработную
плату
инженера
принимаем 20000 р.
20000
 1000 р/день, т.е. 125
20
р/час
Расходы на основную заработную плату исполнителей определяются по
формуле:
k
Зосн.з/пл =∑Ti*Ci=(5,4+11,2+10,8+12,8+16,4+38,4+44+12,4+1)*125=19050
i1
где Зосн.з
/ пл
- расходы на основную заработную плату исполнителей
(руб.); k – количество исполнителей; Ti - время, затраченное i-м исполнителем
на проведение исследования (дни или часы); Ci - ставка i-го исполнителя
(руб./день).
Расходы на дополнительную заработанную плату учитывают все выплаты
непосредственно исполнителям за время не проработанное на производстве, но
предусмотренное законодательством, в том числе: оплата очередных отпусков,
компенсация за недоиспользованный отпуск, и др. Величина этих выплат
составляет 20% от размера основной заработной платы[16]:
Зосн.з/пл=0,2*19050 = 3810 р.
Отчисления с заработанной платы состоят в настоящее время в уплате
единого социального налога. Согласно налоговому кодексу РФ применяются
ставки налога для отчисления в пенсионный фонд РФ, фонд социального
страхования, фонды обязательного медицинского страхования (федеральный и
территориальный фонды). Отчисления с заработанной платы составят:
С
З .ОТ 
 ( СЗ.ОСН  СЗ. ДОП )  Н СОЦ = (19050+3810)*0.30 = 6858 р.
30
1.7 Расчет затрать на оборудование, его эксплуатацию, сырье и
материалы
Для работы программиста требуется полностью оборудовать 1 рабочее
место.
Сотруднику
необходимо
приобрести
ноутбук,
мышь,
кресло,
компьютерный стол. Кроме того, для работы необходим хотя бы один принтер.
Затраты на данном этапе составят Сноут + Смышь + Скрес + Сстол + Спринт =
15000+300+2000+4000+4000=25,3 тысяч рублей. Однако по окончании времени
разработки эти предметы могут быть снова проданы, поэтому расходы на их
приобретение
нельзя
напрямую
отнести
в
себестоимость
программы.
Фактически же понесенными расходами можно считать амортизацию данных
технических средств, то есть величину уменьшения их рыночной стоимости в
процессе работы над проектом. При годовой норме 25% амортизация составит
25300*0,25/12= 527 рублей за месяц.
К прочим затратам можно отнести расходы на электроэнергию. Средняя
мощность блока питания компьютеров – 400 Ватт. При длительности проекта в
один месяц компьютеры будут работать 23 дня по 8 часов. Также необходимо
учитывать
освещение
рабочих
мест
и
прочие
накладные
затраты
электроэнергии. Суммарные же затраты составят 400*23*8*=73600 (Ваттчасов), или 73,6 Кватт-часов. При стоимости электроэнергии 2,5 рубля за 1
кВатт-час суммарные затраты на электроэнергию составят 73,6*2,5=184 рублей.
В качестве расходных материалов будет использоваться бумага для
принтера, ручка шариковая, картридж ч/б для лазерного принтера, диск CDRW. Затраты на расходные материалы составят Сбумага + Сручка + Скартридж
+ Сдиск = 300 + 55 + 2700 + 250 = 3305 рублей.
1.8 Определение себестоимости продукта
Для расчета совокупной величины затрат, связанных с выполнением
проекта, все приведенные расчеты сводятся в таблицу 4.
31
Таблица 4 - Смета затрат на выполнение проекта
№
Наименование статьи
Сумма, руб
1
Расходы на оплату труда
22860
2
Отчисления на социальные нужды
6858
3
Оборудования
527
4
Расходы на эксплуатацию оборудования
184
5
Расходные материалы
3305
Итого
33734
Таким образом, разработка и внедрение приложения с учетом специфики
работы отдельного взятого книжного магазина является приоритетнее нежели
покупки готового продукта у сторонних компаний. Это обусловлено тем, что
цена за аналогичный продукт, у компаний предоставляющих ПО, немногим
выше, а также многие из них навязывают сопутствующие программы и
подписки за дополнительную плату.
32
2 Планирование разработки автоматизированной информационной
системы
2.1 Функциональные требования к проектируемой системе
К разрабатываемой АИС деятельности книжного магазина выдвигаются
следующие функциональные требования.
1. Автоматизированная
информационная
система
должна
быть
реализована с использованием объектно-ориентированного подхода, что
позволит добиться масштабируемости и расширяемости системы без привязки
к средствам разработки и программным технологиям[4].
2. Автоматизированная информационная система должна обеспечивать
функции хранения, внесения, выборки информации с использованием СУБД,
что позволит эффективно управлять потоками.
3. Автоматизированная
поддерживать
создание
и
информационная
ведение
учетных
система
записей
должна
пользователей
с
назначением прав доступа для групп участников. Регистрацию пользователей
может производить администратор системы, либо соответствующий менеджер.
4. Автоматизированная
информационная
система
управления
деятельностью книжного магазина должна включать следующие инструменты,
необходимые для ее функционирования.
4.1. Инструмент анализа полученных предложений на закупку
книгопечатной продукции, позволяет формировать спрос;
4.2. Инструмент
автоматической
выдаче
скидки
при
приобретении товара на конкретную сумму, что позволяет эффективно
расходовать время менеджера по продажам;
4.3. Инструмент учета всех продаж, закупок с привязкой на
конкретную дату, пользователя системы, что позволяет собирать
отчетность для анализа текущего состояния предприятия.
33
5. АИС
управления
деятельностью
книжного
магазина
должна
предоставлять механизм регистрации новых клиентов, предоставляя им скидки
и возможность оставлять предложения о закупке книгопечатной продукции.
6. АИС
управления
деятельностью
книжного
магазина
должна
автоматически вести историю действий в системе, а также для каждого
пользователя системы.
2.2 Проектирование базы данных
Данный этап разработки информационной системы включает в себя
концептуальное и логическое проектирование базы данных ИС. На этом этапе
создается независимая от типа СУБД и языка программирования модель
данных с последующей её трансформацией в физическую модель с учётом
выбранной СУБД.
Для проектирования инструментов деятельности книжного магазина
будет разработана концептуальная модель базы данных. Концептуальное
проектирование – построение семантической модели предметной области, то
есть информационной модели наиболее высокого уровня абстракции. Такая
модель создаётся без ориентации на какую-либо конкретную СУБД и модель
данных[9].
Концептуальная модель – это абстрактная модель, определяющая
структуру моделируемой системы, свойства её элементов и причинноследственные связи, присущие системе и существенные для достижения цели
моделирования.
Таким образом, на этапе концептуального проектирования необходимо
выявить сущности, набор атрибутов для всех сущностей (в том числе и
первичные ключи) и построить взаимосвязи между сущностями.
При проектировании схемы БД были выделены сущности, отражающие
структуру информационных массивов ИС, реквизиты (атрибуты) этих
сущностей и связи между сущностями.
34
В результате проведенных работ была построена концептуальная схема,
представляющая логическую модель данных. Приведем описание и анализ
построенной схемы.
Анализ логической модели БД начнем с описания сущностей и
информации, которую они отображают. Результаты анализа сведем в таблицу 3.
Таблица 5 – Описание сущностей концептуальной схемы
Сущность
Содержание информации
1
2
Книга
Жанр
Книга на продажу
Информационный массив для хранения данных о
книгопечатной продукции
Справочник для хранения данных о жанрах книг
Информационный массив, предназначенная для
хранения данных о проданных книгах
Информационный массив, который используется
Продажа
для хранения данных о том какие, когда и кем
были проданы книги
Сотрудник
Должность
Право доступа должности
Право доступа
Клиент
Скидка
Информационный
массив,
работающих,
или
работавших в книжном магазине сотрудников
Справочник должностей сотрудников
Справочник прав доступа к системе для каждого
типа должностей сотрудника
Справочник,
хранящий
права
доступа
к
конкретным участкам системы
Информационный массив, предназначенный для
хранения данных о клиентах книжного магазин
Справочник, хранящий информацию о том какие
скидки действуют в книжном магазине
35
Продолжение таблицы 5
1
2
Информационный массив, предназначенный для
Предложение о заказе
заявок, оставленных клиентами, заказа какойлибо книгопечатной продукции.
Книги на заказ
Информационный массив, предназначенный для
хранения данных о заказанных книгах
Информационный массив, который используется
Заказ
для хранения данных о том какие, когда и кем
были заказаны книги
Статус заказа
Автор книги
Автор
Издательство книги
Издательство
Информационный массив, который используется
для хранения данных о статусе заказа
Информационный массив, предназначенный для
хранения данных об авторах книги
Справочник, хранящий информацию об авторах
Информационный массив, предназначенный для
хранения данных о издательствах книги
Справочник,
хранящий
информацию
об
издательствах
Чтобы перейти к анализу структуры информации, отображаемой
сущностями модели, необходимо перечислить общие требования к реквизитам.
Все реквизиты сущностей БД различаются по признакам уникальности,
обязательности и ограниченности. Каждый реквизит может быть описан
совокупностью признаков, но не менее чем одним.
Уникальность означает, что не может существовать двух однотипных
объектов (двух строк в таблице, описывающей совокупность объектов) с
одинаковым
значением
реквизита.
Свойство
уникальности
может
распространяться на совокупность реквизитов. В этом случае уникальным
36
является сочетание значений реквизитов, которое не может быть повторено в
одной и той же таблице (информационном массиве). Свойством уникальности
обладают все ключевые поля. Частичная уникальность означает отсутствие
повторяемости записей в таблице при наличии определенных условий.
Частичная уникальность может быть совместима с необязательностью или
частичной обязательностью реквизита (реквизитов).
Обязательность
[обязательный,
частично
обязательный,
необязательный] заполнения реквизита указывает, что для данного реквизита
отсутствие
значения
подразумевает
при
(NULL)
наличии
невозможно.
Частичная
дополнительных
обязательность
условий.
База
данных
отслеживает эти условия и, если они имеют место, запрещает значение NULL.
База данных устанавливает минимальные требования по обязательности
реквизитов, которые должны выполняться для любых клиентов базы[9].
Признак
ограниченности
применяется
к
ключевым
(идентифицирующим) и текстовым (строковым) реквизитам. Он определяет
область возможных значений реквизита. По признаку ограниченности реквизит
может
быть
счетчиком
(автоинкрементное
поле),
внешним
ключом,
выбираемым, свободным и форматным. Счетчики и внешние ключи имеют
обычный смысл. Свободный реквизит получает свое значение через свободный,
ничем не ограниченный ввод пользователя. Выбираемый реквизит получает
свое значение через пользовательский выбор из уже сформированного набора
значений или с контролем наличия свободно введенного пользователем
значения в этом наборе. К свободным также относятся прочие не ключевые и
не текстовые реквизиты, то есть даты, денежные и другие. Форматные
реквизиты могут быть представлены набором данных, состоящим из
собственно значения реквизита и дополнительных служебных реквизитов.
Состав и значения дополнительных реквизитов определяется стандартом на
формат.
Учитывая перечисленные требования, результаты анализа реквизитов
для каждой сущности занесем в таблицу 4.
37
Таблица 6 – Описание реквизитов сущностей
Реквизит
Требования
1
2
«Книга»
Код книги
Уникальный. Обязательный. Счетчик
Название
Неуникальный. Обязательный. Свободный
Код автора книги
Неуникальный. Обязательный. Свободный
Код жанра
Неуникальный. Обязательный. Свободный
Описание
Цена продажи
Неуникальный.
Обязательный.
Выбирается
из
справочника «Жанр»
Неуникальный. Обязательный. Свободный
Цена заказа
Неуникальный. Необязательный. Свободный
Обложка
Неуникальный. Необязательный. Свободный
В наличии
Неуникальный. Необязательный. Свободный
«Жанр»
Код жанра
Уникальный. Обязательный. Счетчик
Название
Уникальный. Обязательный. Свободный
Описание
Неуникальный. Необязательный. Свободный
«Книга на продажу»
Код книги на продажу Уникальный. Обязательный. Счетчик
Код книги
Код продажи
Количество
Неуникальный. Обязательный. Указатель на номер
продажи в сущности «sell»
Неуникальный. Обязательный. Указатель на номер
книги в «book»
«Продажа»
Код продажи
Уникальный. Обязательный. Счетчик
38
Продолжение таблицы 6
1
Дата
Код сотрудника
Код клиента
Номер чека
2
Неуникальный. Обязательный. Свободный
Неуникальный.
Необязательный.
Выбирается
из
Необязательный.
Выбирается
из
сущности «staff»
Неуникальный.
сущности «Клиент»
Уникальный. Обязательный. Свободный
«Сотрудник»
Код сотрудника
Уникальный. Обязательный. Счетчик
Имя
Неуникальный. Обязательный. Свободный
Фамилия
Неуникальный. Обязательный. Свободный
Отчество
Уникальный. Обязательный. Свободный
Код должности
Неуникальный.
Обязательный.
Выбирается
справочника «Должность»
Паспорт серия
Уникальный. Обязательный. Свободный
Паспорт номер
Уникальный. Обязательный. Свободный
Паспорт серия
Уникальный. Обязательный. Свободный
Номер телефона
Уникальный. Обязательный. Свободный
Хеш (пароль)
Email
Неуникальный. Обязательный. Свободный
Уникальный. Обязательный. Свободный
«Должность»
Код должности
Уникальный. Обязательный. Счетчик
Название
Неуникальный. Обязательный. Свободный
Описание
Неуникальный. Необязательный. Свободный
«Право доступа»
Код права доступа
Уникальный. Обязательный. Счетчик
из
39
Продолжение таблицы 6
1
Описание
2
Неуникальный. Обязательный. Свободный
«Право доступа должности»
Код должности
Код права доступа
Неуникальный.
Необязательный.
Выбирается
из
Выбирается
из
сущности «Сотрудник»
Неуникальный.
Необязательный.
сущности «Право доступа»
«Клиент»
Код клиента
Уникальный. Обязательный. Счетчик
Имя
Неуникальный. Обязательный. Свободный
Фамилия
Неуникальный. Обязательный. Свободный
Отчество
Номер телефона
Хеш (пароль)
Email
Код скидки
Уникальный. Обязательный. Свободный
Неуникальный. Обязательный. Свободный
Уникальный. Обязательный. Свободный
Неуникальный.
Необязательный.
Выбирается
из
сущности «Скидка»
«Скидка»
Код скидки
Уникальный. Обязательный. Счетчик
Значение
Неуникальный. Обязательный. Свободный
Описание
Неуникальный. Необязательный. Свободный
Лимит
Неуникальный. Необязательный. Свободный
«Предложение о заказе»
Код предложения
Уникальный. Обязательный. Счетчик
о заказе
Код книги
Неуникальный. Обязательный. Выбирается из сущности
«Книга»
40
Продолжение таблицы 6
1
Код клиента
2
Неуникальный. Обязательный. Выбирается из сущности
«client»
Дата
Неуникальный. Обязательный. Свободный
Комментарий
Неуникальный. Обязательный. Свободный
«Книги на заказ»
Код книги на заказ Уникальный. Обязательный. Счетчик
Код заказа
Код книги
Количество
Неуникальный. Обязательный. Указатель на номер
заказа в сущности «Заказ»
Неуникальный. Обязательный. Указатель на номер
книги в «Книга»
Неуникальный. Обязательный. Свободный
«Заказ»
Код заказа
Дата
Код сотрудника
Код статуса заказа
Уникальный. Обязательный. Счетчик
Неуникальный. Обязательный. Свободный
Неуникальный.
Необязательный.
Выбирается
из
сущности «Сотрудник»
Неуникальный. Обязательный. Выбирается из сущности
«Статус заказа»
«Статус заказа»
Код статуса заказа Уникальный. Обязательный. Счетчик
Название
Неуникальный. Обязательный. Свободный
«Автор книги»
Код автора книги
Код автора
Уникальный. Обязательный. Счетчик
Неуникальный. Обязательный. Выбирается из сущности
«Автор»
«Автор»
Код автора
Уникальный. Обязательный. Счетчик
41
Продолжение таблицы 6
1
Имя
Фамилия
2
Неуникальный. Обязательный. Свободный
Неуникальный.
Обязательный.
СвободныйТвоему
организму нужны
Отчество
Неуникальный. Обязательный. Свободный
Описание
Неуникальный. Необязательный. Свободный
«Издательство книги»
Код издательства
Уникальный. Обязательный. Счетчик
книги
Код издательства
Год издания
Неуникальный. Обязательный. Указатель на номер
заказа в сущности «Издательство»
Неуникальный. Обязательный. Свободный
«Издательство»
Код издательства
Наименование
Описание
Уникальный. Обязательный. Счетчик
Неуникальный. Обязательный. Свободный
Неуникальный. Необязательный. Свободный
Следует отметить, что для большинства сущностей первичные ключи
являются суррогатными и не отражают никакие свойства реальных объектов.
Это сделано лишь для удобства.
Схема логической модели базы данных информационной системы
деятельности книжного магазина представлена на рисунке 9.
42
Рисунок 9 – Инфологическая модель базы данных
43
2.3 Построение связей между сущностями
Перейдем
к
описанию
связей
между
сущностями.
В
данной
концептуальной схеме базы данных используется два вида связей: «один ко
многим» и «многие ко многим». Связь «один ко многим» подразумевает то, что
экземпляру родительской сущности соответствует несколько экземпляров
дочерней сущности.
Между сущностями «Книга» и «Жанр» построена связь «один ко
многим», так как один и тот же жанр может быть у нескольких книг
одновременно.
Сущности «Заказ» и «Статус заказа» имеют связь «один ко многим», т.к.
один и тот же статус заказа может быть у нескольких заказов.
Между сущностями «Клиент» и «Скидка» построена связь «один ко
многим», так как одна и та же скидка может быть у нескольких клиентов
книжного магазина.
Сущности «Сотрудник» и «Должность» имеют связь «один ко многим»,
т.к. одна и та же должность может быть у нескольких сотрудников.
Между сущностями «Продажа» и «Клиент» построена связь «один ко
многим», так как один и тот же клиент может учувствовать в нескольких
продажах. Аналогично строится связь между сущностями «Предложение о
заказе» и «Клиент».
Между сущностями «Продажа» и «Сотрудник» построена связь «один
ко многим», так как один и тот же сотрудник может учувствовать в нескольких
продажах. Аналогично
строится связь между сущностями
«Заказ» и
«Сотрудник».
Связь многие ко многим строится с помощью введения новой сущности.
Рассмотрим на примерах.
Для осуществления продаж нам необходимо знать книги, которые мы
продаем, так же знаем, что книг может быть несколько и они могут
учувствовать в других продажах. Связь многие ко многим в данном случае
организовывается следующим образом. Сущность «Продажа» и «Книга на
44
продажу» имеет связь один ко многим, т.к. несколько книг на продажу может
встретится в одной продаже. Сущность «Книга на продажу» и «Книга» имеет
связь один ко многим, т.к. одна книга может учувствовать в нескольких
продажах.
Аналогично организовывается связь связывающая заказ и книги.
Сущность «Заказ» и «Книга на заказ» имеет связь один ко многим, т.к.
несколько книг на заказ может встретится в одном заказе. Сущность «Книга на
заказ» и «Книга» имеет связь один ко многим, т.к. одна книга может
учувствовать в нескольких заказах.
Сущности «Книги» и «Авторы» имеют связь многие ко многим, т.к. У
книги могут быть несколько авторов и один и тот же автор может быть у
нескольких книг. Связь многие ко многим в данном случае организовывается с
помощью введения дополнительной сущности «Автор книги».
Сущности «Книга» и «Издательство» имеют связь многие ко многим,
т.к. У книги могут быть несколько издательств и одно и то же издательство
может быть у нескольких книг. Связь многие ко многим в данном случае
организовывается
с
помощью
введения
дополнительной
сущности
«издательство книги».
2.4 Формирование ограничения целостности базы данных
В
данном
дополнительных
разделе
пояснительной
ограничений
целостности
записки
БД,
приведем
обусловленных
описание
бизнес
правилами, определенными в исследованной нами предметной области. Бизнес
правила могут быть реализованы как на сервере, так и в приложении.
Идеология
архитектуры
«клиент–сервер»
требует
переноса
максимального числа реализаций бизнес–правил на сервер. Однако, поддержку
некоторых ограничений на значения БД, продиктованных особенностями
конкретной
предметной
области,
реализовать
на
сервере
бывает
затруднительно или невозможно. Поддержку таких ограничений целостности
можно реализовать и на уровне клиентского приложения[9].
45
Следует отметить, что существует несколько видов ограничений
целостности данных, а именно: целостность домена, целостность атрибута,
возможность NULL-значений, ссылочная целостность и корпоративные
правила целостности.
Ограничения на значения атрибутов и возможность NULL-значений
выделены на этапе разработки структуры БД АИС в процессе анализа
требований к реквизитам сущностей по признакам обязательности и
ограниченности.
При
анализе
предметной
области
были
выделены
следующие
ограничения целостности базы данных.
1. При удалении одного из значения из связи многие ко многим
необходимо удалять значение из связующей сущности. Например при удалении
значения из сущности «Продажа», мы должны удалить соответствующее
значения из сущности «Книга на продажу».
2. Среди сущностей, выделенных в концептуальной схеме, есть
атрибуты, значения которых не могут быть отрицательными, например, «Номер
телефона», «Паспорт серия», «Количество» и т.п., в связи с этим целесообразно
проверять при вводе данных эти значение на условие больше 0.
3. Каскадная стратегия удаления заказа – при удалении заказа
удаляются все записи из таблиц, в которых хранится информация об этом
заказе;
4. Для определения общего количества ед. товара атрибута «В
наличии» сущности «Книга», который помогает пройти ту или иную операцию,
необходимо учитывать продажи и заказы книг. Таким образом, при вставке
новой записи в таблицу «Книга на продажу» происходит вычисление значения
атрибута «В наличии». Для этого необходимо определить общее количество
данных книг в наличии и вычесть количество проданных этой же книги. При
заказе книги, внесении новой записи в таблицу «Книга на заказ» мы должны
сложить количество заказанных книг и текущее значение атрибута «В
46
наличии». Это необходимо во избежание недоразумений при одновременном
использовании имеющихся запасов для разных операциях.
2.5 Выбор технологии для реализации АИС
Этап выбора технологии для реализации проекта является очень важным
при разработке информационной системы, так как именно на нем определяется
фундаментальная
концепция
разработки.
От
правильного
выбора
информационной технологии зависит будущий облик системы в целом,
перспективы ее дальнейшего развития и возможности совершенствования.
Автоматизированная информационная система деятельности книжного
магазина должна быть организованна так, что предоставляла использование
системы несколько пользователей сразу. Доступ пользователей должен
осуществляться по сети. В процессе работы с системой пользователи будут
использовать одни и те же данные, а, значит, эти данные должны храниться в
каком-то одном месте, то есть на сервере баз данных. Пользователи со своих
машин будут отправлять запросы к серверу, а тот, в свою очередь, будет
выдавать им требуемые данные[19[.
Такая архитектура системы называется клиент/серверной архитектурой
(рисунок 10).
Приведенная структура образует базовый вариант полной системы и
может в дальнейшем наращиваться по желанию пользователя в частности
установки дополнительный АРМ различного назначения.
Центральный сервер (база данных) – хранитель центральной базы
данных и всей информации. На нем происходит автоматическое снятие
резервных копий, архивирование и хранение данных.
47
Рисунок 10 – Структура клиент/серверной архитектуры
АРМ менеджера по работе с продажами – позволяет на основе
оперативных запросов к центральной базе данных формировать продажу книг
по требованию клиента и выполнять их немедленно при их оплате.
При этом менеджер по продажам может следующее.
1. Продавать готовые заказы, сформированные на рабочем месте
администратора главного менеджера.
2. Вносить корректировки в готовый заказ по просьбе клиента.
3. Регистрировать
клиентов
в
базе
данных,
для
дальнейшего
предоставления скидок и привилегий.
При этом все действия менеджера фиксируются в БД и контролируются
правами доступа, заданными руководителем продаж.
АРМ менеджера по закупкам – предназначено для подготовки процесса
закупки и реализации товара.
С помощью АРМ менеджера по закупкам – менеджеры имеют
возможность выполнять следующие действия:

закупать товар;
48

добавлять товар на склад магазина;

удалять товар;

управление информацией о товаре;

подготовка различных форм для статистических и финансовых
отчетов.
Вся работа с базой данных выполняется на сервере. Если клиент
запрашивает какой-либо набор данных, он подготавливается на сервере, и его
копия доставляется клиенту. Реальные данные и индексы никогда не покидают
пределы сервера. Когда клиент запрашивает выполнение операции вставки,
обновления или удаления, сервер получает этот запрос и сам обрабатывает
его[9].
С технической точки зрения термин клиент/сервер связан с двумя
взаимодействующими
процессами.
Клиентский
процесс
запрашивает
у
серверного процесса некую службу, которая, в свою очередь, обрабатывает
запрос клиента. Клиентский и серверный процессы могут быть запущены на
разных компьютерах или на одном. В данном вопросе важно само
взаимодействие
процессов,
а
не
их
физическое
размещение.
В
противоположность настольным базам данных, таким как MicrosoftAccess,
выполняющим всю работу на компьютере клиента, базы данных с
архитектурой «клиент/сервер» подобны библиотекарю, который принимает
запрос клиента, ищет запрошенную информацию и возвращает фотокопию
найденных материалов. Содержащиеся в библиотеке реальные материалы
никогда не выходят из поля зрения библиотекаря. В базах данных с
архитектурой "клиент/сервер" клиент подготавливает запрос на языке SQL
(небольшое текстовое сообщение) и отсылает его на сервер баз данных,
который читает и обрабатывает его. В сервере поддерживается система
безопасности,
индексируются
хранящиеся
материалы,
заносятся
и
обрабатываются данные, выполняются серверные программы, и выполняется
доставка результатов запросов клиенту[1].
49
Вся работа с базой данных выполняется на сервере. Если клиент
запрашивает какой-либо набор данных, он подготавливается на сервере, и его
копия доставляется клиенту. Реальные данные и индексы никогда не покидают
пределы сервера. Когда клиент запрашивает выполнение операции вставки,
обновления или удаления, сервер получает этот запрос и сам обрабатывает его.
Схема работы технологии клиент/сервер изображена на рисунке 11.
Запрос к серверу
БД
Сервер
Клиент
Ответ
Манипуляции с
БД
БД
Рисунок 11 – Схема работы технологии клиент/сервер
Клиент-серверная модель базы данных обладает рядом преимуществ по
сравнению с настольной моделью.
1. Повышена достоверность данных, поскольку они не разбросаны по
всей сети и разным приложениям. Данные обслуживает только один процесс.
2. Ограничения
целостности
данных
и
бизнес-правила
могут
поддерживаться на уровне сервера, в результате чего они строго соблюдаются.
3. Повышена безопасность данных, поскольку база данных хранит их в
пределах одного сервера. Открыть файл данных, защищаемый сервером,
гораздо сложнее, чем файл на рабочей станции.
4. Повышена производительность и лучше сбалансированы рабочие
станции,
поскольку
большая
часть работы
(обработка
базы
данных)
50
выполняется на сервере, а рабочие станции берут на себя только обслуживание
интерфейса пользователя. Поскольку серверный процесс обеспечивает быстрый
доступ пользователя к файлам данных, а большая часть данных кэширована в
памяти,
операции
с
базой
данных
выполняются
быстрее,
чем
в
многопользовательской настольной среде. Сервер баз данных обслуживает всех
пользователей, работающих с приложениями баз данных, таким образом,
гораздо проще оценить стоимость устанавливаемого сервера.
5. В значительной мере сокращаются сетевые потоки. По сравнению с
сетевыми потоками, создаваемыми многопользовательскими настольными
системами, потоки в архитектуре "клиент/сервер" можно сравнить с одиноким
мотоциклистом, несущимся по свободной 10-полосной автостраде. Замена
перегруженной настольной системы базой данных "клиент/сервер" способна
сократить сетевые потоки больше чем на 95%.
6. Снижение сетевых потоков в системах "клиент/сервер" приводит к
тому, что приложения хорошо работают даже в распределенной среде и даже
при наличии медленных соединений.
В клиент-серверной конфигурации базы данных каждая из сторон играет
конкретную роль. Если не упорядочить эти роли, то производительность и
целостность приложения клиент-серверной базы данных существенно снизятся.
Сервер баз данных отвечает за следующее:
‒
обработка запросов на извлечение и модификацию данных;
‒
интенсивная обработка данных.
Клиентский процесс отвечает за следующее:
‒
представление данных пользователю в понятном и удобном
формате;
‒
обеспечение
интерфейса
пользователя
всевозможными
инструментами, данными и отчетами;
‒
отправку запросов серверу;
‒
поддержание всех правил и ограничений базы данных;
‒
поддержание безопасности АИС.
51
Таким образом, на основе всего вышесказанного можно сделать вывод о
том, что технология «клиент/сервер» полностью удовлетворяет требованиям к
разрабатываемой системе управления проектами по созданию программного
обеспечения. А значит именно эта технология и будет использована при
реализации разрабатываемой системы.
2.6 Выбор СУБД
По
сути,
система
баз
данных
представляет
собой
способ
манипулирования информацией. При этом информация может поступать из
различных источников. Например, это могут быть данные, полученные в ходе
исследований, деловые записи, заказы потребителей, спортивная статистка,
отчеты о продажах, отчеты об ошибках или оценки учащихся.
При
выборе
взаимодействия
СУБД
для
разработчиков
разработки
необходимо
инструментов
учитывать
обеспечения
требования
к
разрабатываемым инструментам.
Так как система управления проектами, частью которой являются
разрабатываемые инструменты, является web-приложением и основана на
клиент-серверной архитектуре, то СУБД также должна быть клиент-серверной.
СУБД должна обеспечивать множественный доступ к базе данных и
параллельность обработки запросов, а также обеспечивать возможность
разграничения прав доступа для пользователей. Это требование продиктовано
тем, что люди, которые будут использовать инструменты взаимодействия
группы разработчиков должны быть разделены по своим функциональным
ролям на несколько групп. А значит должны быть различны и права доступа к
различным компонентам системы.
Кроме всего выше сказанного система управления базами данных
должна быть достаточно надежной для того, чтобы она смогла выполнять свою
задачу в случае роста информационной системы. То есть, СУБД должна
обладать масштабируемостью.
52
Существует
много
различных
СУБД,
удовлетворяющих
этим
требованием. Рассмотрим подробно одну из самых популярных систем
управления базами данных MySQL.
MySQL является одной из наиболее приспособленных для применения
в среде webсистемой управления базами данных, так она обеспечивает
эффективную работув условиях ограниченных ресурсов, а также является
достаточно надежной.
В настоящее время авторы MySQLработают над расширением её
возможностей дляиспользованием в критичных бизнес-приложениях, то есть
MySQLконкурирует на равных с СУБД таких производителей, как Oracle, IBM,
Microsoft и Sybase.
Основные преимущества MySQL:

многопоточность, поддержка нескольких одновременных запросов;

оптимизация связей с присоединением многих данных за один
проход;

записи фиксированной и переменной длины;

ODBC драйвер;

гибкая система привилегий и паролей;

гибкая поддержка форматов чисел, строк переменной длины и меток
времени;

интерфейс с языками C и Perl, PHP;

быстрая работа, масштабируемость;

совместимость с ANSI SQL;

бесплатна в большинстве случаев;

хорошая поддержка со стороны провайдеров услуг хостинга;

быстрая поддержка транзакций через механизм InnoDB.
На основе всего вышесказанного можно сделать вывод о том, что данная
система управления базами данных полностью удовлетворяет требованиям
разрабатываемой
информационной
системы
управления
проектами
по
53
созданию программного обеспечения. К тому же, в большинстве случаев, она
является бесплатной.
Таким образом, в качестве СУБД при разработке инструментов
управления деятельности книжного магазина будет использована система
MySQL.
2.7 Выбор языка реализации
Как уже говорилось ранее, разрабатываемая система обеспечения
взаимодействия
группы
разработчиков
должна
быть
реализована
в
соответствии с клиент-серверной архитектурой. Следовательно, что выбор
языка реализации будет базироваться на этом критерии. Как также отмечалось
ранее, в качестве используемой СУБД была выбрана MySQL.
В настоящее время существует большое количество языков, для
реализации web-интерфейсов. Необходимо выбрать оптимальный для более
гибкой реализации проекта.
В рассмотрении языков программирования будем опираться на две две
категории: средства системного уровня и средства уровня приложения.
Рассмотрим средства безопасности системного уровня языка php.
В РНР реализованы механизмы безопасности, находящиеся под управлением
администраторов;
при
правильной
настройке
РНР
это
обеспечивает
максимальную свободу действий и безопасность. РНР может работать в так
называемом
безопасном
режиме
(safemode),
который
ограничивает
возможности применения РНР пользователями по ряду важных показателей.
Например,
можно
ограничить
максимальное
время
выполнения
и
использование памяти (неконтролируемый расход памяти отрицательно влияет
на быстродействие сервера). По аналогии с cgi-bin администратор также может
устанавливать ограничения на каталоги, в которых пользователь может
просматривать и исполнять сценарии РНР, а также использовать сценарии РНР
для просмотра конфиденциальной информации на сервере (например, файла
passwd)[3].
54
Проанализируем средства безопасности уровня приложения в php.
В стандартный набор функций РНР входит ряд надежных механизмов
шифрования. РНР также совместим с многими приложениями независимых
фирм, что позволяет легко интегрировать его с защищенными технологиями
электронной коммерции (e-commerce). Другое преимущество заключается в
том, что исходный текст сценариев РНР нельзя просмотреть в браузере,
поскольку сценарий компилируется до его отправки по запросу пользователя.
Реализация РНР на стороне сервера предотвращает похищение нетривиальных
сценариев пользователями, знаний которых хватает хотя бы для выполнения
команды ViewSource.
Ещё одним немаловажным преимуществом языка php является гибкость.
Поскольку РНР является встраиваемым (embedded) языком, он отличается
исключительной гибкостью по отношению к потребностям разработчика. Язык
PHPcуспехом интегрируется в JavaScript, WML, XML и другие языки. Кроме
того, хорошо структурированные приложения РНР легко расширяются по мере
необходимости
(впрочем,
это
относится
ко
всем
основным
языкам
программирования). Нет проблем и с зависимостью от браузеров, поскольку
перед отправкой клиенту сценарии РНР полностью компилируются на стороне
сервера. В сущности, сценарии РНР могут передаваться любым устройствам с
браузерами, включая сотовые телефоны, электронные записные книжки,
пейджеры и портативные компьютеры, не говоря уже о традиционных ПК.
Программисты, занимающиеся вспомогательными утилитами, могут запускать
РНР в режиме командной строки. Поскольку РНР не содержит кода,
ориентированного на конкретный web-сервер, пользователи не ограничиваются
определенными серверами (возможно, незнакомыми для них). Apache,
Microsoft IIS, NetscapeEnterpriseServer, Stronghold и Zeus — РНР работает на
всех перечисленных серверах. Поскольку эти серверы работают на разных
платформах, РНР в целом является платформенно-независимым языком и
существует на таких платформах, как UNIX, Solaris, FreeBSD и Windows
95/98/NT/2000/XP/2003.
55
Благодаря этим новым возможностям РНР занимает достойное место
среди современных технологий и обеспечивает масштабирование проектов до
необходимых пределов.
2.4 Концепция MVC
Концепция MVC (Model-View-Controller – модель-вид-контроллер)
очень часто упоминается в мире веб программирования в последние годы.
MVC — это не шаблон проекта, это конструкционный шаблон, который
описывает
способ
построения
структуры
нашего
приложения,
сферы
ответственности и взаимодействие каждой из частей в данной структуре.
Впервые она была описана в 1979 году для другого окружения. Тогда не
существовало концепции веб приложения. Tim Berners Lee (Тим Бернерс Ли)
посеял семена World Wide Web (WWW) в начале девяностых и навсегда
изменил мир. Шаблон, который мы используем сегодня, является адаптацией
оригинального шаблона к веб разработке.
Бешеная популярность данной структуры в веб приложениях сложилась
благодаря её включению в две среды разработки, которые стали очень
популярными: Struts и Ruby on Rails. Эти две среды разработки наметили пути
развития для сотен рабочих сред, созданных позже.
Идея, которая лежит в основе конструкционного шаблона MVC, очень
проста:
нужно
чётко
разделять
ответственность
функционирование в нашей системе (рисунок 12).
за
различное
56
Рисунок 12 – Концепция MVC
Приложение разделяется на три основных компонента, каждый из
которых отвечает за различные задачи. Подробно разберём компоненты на
примере.
Контроллер управляет запросами пользователя (получаемые в виде
запросов HTTP GET или POST, когда пользователь нажимает на элементы
интерфейса для выполнения различных действий). Его основная функция —
вызывать и координировать действие необходимых ресурсов и объектов,
нужных для выполнения действий, задаваемых пользователем. Обычно
контроллер вызывает соответствующую модель для задачи и выбирает
подходящий вид.
Модель – это данные и правила, которые используются для работы с
данными, которые представляют концепцию управления приложением. В
любом приложении вся структура моделируется как данные, которые
обрабатываются
определённым
образом.
Что
такое
пользователь
для
приложения — сообщение или книга? Только данные, которые должны быть
57
обработаны в соответствии с правилами (дата не может указывать в будущее, email должен быть в определённом формате, имя не может быть длиннее Х
символов, и так далее).
Модель даёт контроллеру представление данных, которые запросил
пользователь (сообщение, страницу книги, фотоальбом, и тому подобное).
Модель данных будет одинаковой, вне зависимости от того, как мы хотим
представлять их пользователю. Поэтому мы выбираем любой доступный вид
для отображения данных.
Модель содержит наиболее важную часть логики нашего приложения,
логики, которая решает задачу, с которой мы имеем дело (форум, магазин,
банк, и тому подобное). Контроллер содержит в основном организационную
логику для самого приложения (очень похоже на ведение домашнего
хозяйства).
Вид обеспечивает различные способы представления данных, которые
получены из модели. Он может быть шаблоном, который заполняется данными.
Может быть несколько различных видов, и контроллер выбирает, какой
подходит наилучшим образом для текущей ситуации.
Веб приложение обычно состоит из набора контроллеров, моделей и
видов. Контроллер может быть устроен как основной, который получает все
запросы и вызывает другие контроллеры для выполнения действий в
зависимости от ситуации[5].
58
3 Реализация автоматизированной информационной системы
3.1 Алгоритм загрузки интерфейсов
Разрабатываемая
автоматизированная
информационная
система
использует достаточно большое количество алгоритмов обработки данных и
запросов для осуществления доступа к информации, хранящейся в БД АИС.
Поэтому выделим наиболее любопытные.
Одним
из
наиболее
интересных
является
алгоритм
загрузки
интерфейсов, в зависимости от прав доступа пользователя системы представлен
на рисунке 13.
Рисунок 13 – Алгоритм загрузки интерфейсов
При загрузке интерфейсов АИС проверяется есть ли права доступа к
самой системе, то есть авторизовался человек в ней или нет. На следующем
этапе происходит обращение к базе данных, откуда берутся права доступа
59
данного пользователя на интерфейсы системы. После этого пользователь
выбирает интерфейс и происходит сравнение уровня доступа к интерфейсам.
Если у пользователя есть права доступа к интерфейсу, то он может
пользоваться им. Такая цепочка действий позволяет системе разделить права
доступа к интерфейсам для различных групп пользователей. Преимущество
такого способа разделения прав на использование интерфейсов и хранение прав
доступа в базе данных делает систему более гибкой, даёт возможность её
расширять и дополнять.
3.2 Алгоритм продажи книгопечатной продукции
Алгоритм продажи книгопечатной продукции является важным и одним
из основных алгоритмов разрабатываемой информационной систем. Алгоритм
показан на рисунке 14.
При продаже товара мы вводим поисковой запрос, чтобы быстро найти
ту книгопечатную
продукцию,
которую
хочет
купить
клиент. Далее
запрашиваем книгу из БД. Проверяем, нашли ли товар или нет, если нет,
алгоритм завершает работу, если нашли, делаем еще проверку на наличие
товара, в случае отсутствия книги завершаем алгоритм, иначе продолжаем.
Следующим шагом алгоритма является проверка на наличие скидки. Т.к.
скидка напрямую связано с клиентом, то делаем запрос к БД, запрашивая
клиента. Проверяем, что вернуло. Если клиента нет, переходим на следующий
шаг: подсчет суммы, если есть, то запрашиваем доступные скидки для клиента
на сумму его заказа, если есть, привязываем скидку к записи клиента. Если у
клиента есть скидка, то запрашиваем ее из БД.
Следующий шаг это подсчет суммы цены покупки, если есть скидка, то
сумма цены покупки будет подсчитана с учетом этой скидки. Записываем
данные о покупке в БД, оформляем чек.
60
Рисунок 14 – Алгоритма продажи товара
61
3.3 Проектирование логики диалога с пользователями системы
Диалоговый
интерфейс
–
это
подсистема,
обеспечивающая
пользователю доступ к базе данных и передачу данных из базы на экран
пользователя.
Интерфейс
оконного
типа
предполагает
независимость
различных элементов программы, в частности органов управления и рабочей
зоны. Эти элементы располагаются в строго очерченных областях экрана
(которые называются окнами), не мешая друг другу. Окна можно перемещать
по экрану, изменять их размер, раскрывать и закрывать, накладывать друг на
друга. Содержимое одного окна можно прокручивать в любом направлении,
при этом другое окно остается неподвижным.
Описание структуры приложения будет произведено с помощью
рекурсивно транзитивной сети. Логика диалога представляется в виде
направленного графа, где состояния системы – это вершины, а переходы между
обозначенными состояниями – дуги. Дуги обозначают входные сигналы или
обратную связь прикладного интерфейса. Снизу они именуются согласно
действию, которое должна выполнить система при переходе в данное состояние
при определенном входном сигнале, который записывается над дугами.
Достоинства простой транзитивной сети:
−
точное формальное описание диалога;
−
диалог реализуется в простой форме;
−
такая реализация диалога легко редактируется и дополняется.
В разрабатываемой автоматизированной информационной системе
управления деятельностью книжного магазина было выделено три уровня
доступа для трёх групп пользователей. К первой группе относятся менеджеры
по заказам, то есть лица, которые занимаются заказом и редактированием
информации книгопечатной продукции. Пользователи этой группы обладают
достаточно ограниченными правами доступа и могут только просматривать
информацию о товаре, редактировать данные о книгах, вносить новые книги в
каталог, заказывать товар.
62
К следующей группе относятся менеджеры по продажам. Это лица,
которые ведут управление процессом продажи книгопечатной продукции, а так
же процессом управления клиентами книжного магазина. Данная группа
разработчиков обладают достаточно ограниченными правами доступа и могут и
обладают следующими правами доступа: просмотр информации о товаре,
регистрация нового клиента, оформление продажи.
К последней третьей группе относятся менеджеры по работу с
персоналом, то есть люди, осуществляющие контроль сотрудниками книжного
магазина. Они могут вносить информацию о новых сотрудниках, оформлять
документы на принятие, увольнение персонала, редактировать личные данные
сотрудников.
При загрузке интерфейсов происходит запрос в базу данных, где
отыскиваются все права, доступные данной группе пользователей. После этого
происходит загрузка ссылок, благодаря которым происходит переход между
интерфейсами.
Такой механизм позволил ограничить права доступа к
отдельным интерфейсам разные группы пользователей.
Интерфейс отображения каталога товара доступен не только персоналу
магазина, но и клиентам, которые могут просмотреть его на внешнем дисплее,
поэтому данный интерфейс не требует проверки прав доступа.
Для информационной системы управления проектом такая транзитивная
сеть представлена на рисунке 15 и охватывает логику диалога с пользователем
при работе в компонентах связанных с деятельностью книжного магазина.
63
Рисунок 15 – Транзитивная сеть логики диалога с пользователем
В начальном состоянии показывается окно приветствия на котором
можно перейти в каталог товара и на форму авторизации. Здесь выделены
следующие состояния:

S – начальное состояние;

S1 – форма авторизации сотрудников книжного магазина;

S2 – каталог товаров;

F – конечное состояние системы.
Переход из одного события в другое осуществляется при наступлении
следующих событий:
‒
1 – выбран пункт авторизации сотрудника в системе;
‒
2 – выбран компонент просмотра каталога товара;
‒
3 – переход к главной странице системы;
‒
4 – сотрудник вошел как менеджер по продажам;
‒
7 – сотрудник вошел как менеджер по закупкам;
‒
8 – сотрудник зашел как менеджер по работе с персоналом;
‒
5, 6, 9 – выход из учетной записи;
‒
10, 11, 12 – выход из системы;
64
Для того чтобы можно было более наглядно отобразить логику диалога с
пользователем. Далее рассмотрим каждую из них.
На рисунке 16 представлена транзитивная подсеть «Управление
заказами», отображающая логику диалога с пользователем группы менеджер
поп продажам.
Рисунок 16 – Транзитивная подсеть «Управление заказами» логики диалога
Здесь выделены следующие состояния:

S – авторизация под учетной записью менеджера по заказам и вход в
соответствующую панель управления;

S1 – каталог товаров;

S2 – добавление книги в каталог существующей книгопечатной
продукции;

S3 – редактирование данных о каталоге книг;

S4 – просмотр статистики;

S5 – оформление заказа;

S6 – редактирование заказа;

F – выход из учетной записи.
Переход из одного события в другое осуществляется при наступлении
следующих событий:
‒
2 – выбран пункт просмотр каталога товара;
65
‒
3 – выбран компонент добавления добавление книги в каталог
книгопечатной продукции;
‒
5 – выбран пункт редактирование данных о каталоге книг;
‒
6 – выбран компонент просмотр статистики;
‒
9 – открыта форма оформления заказа;
‒
11 – выбран пункт редактирование заказов;
‒
1, 4, 5, 7, 10, 12 – возврат в панель управления менеджера по работе с
заказами;
‒
13 – выход из учетной записи.
Далее
рассмотрим
подсеть
«Управление
продажами»,
которая
представлена на рисунке 17.
Переход в эту подсеть осуществляется при авторизации менеджера по
продажам. При входе в этот компонент пользователю по умолчанию
отображается панель управления данного для данного менеджера.
Рисунок 17 – Транзитивная подсеть «Управление продажами» логики диалога
Здесь выделены следующие состояния:

S – авторизация под учетной записью менеджера по продажам и
вход в соответствующую панель управления;
66

S1 – каталог товаров;

S2 – оформление покупки;

S3 – просмотр истории продаж текущей учетной записи;

S4 – регистрация клиента;

S5 – просмотр каталога клиентов;

S6 – просмотр списка скидок;

S7 – редактирования данных о клиенте;

F – выход из учетной записи.
Переход из одного события в другое осуществляется при наступлении
следующих событий:
‒
1 – выбран компонент просмотр каталога товара;
‒
3 – открыта форма оформления покупки;
‒
5 – выбран пункт просмотр истории продаж для текущей учетной
записи;
‒
7 – открыта форма регистрации клиента;
‒
9 – выбран компонент просмотр каталога клиентов;
‒
11 – выбран пункт просмотр списка книг;
‒
14 – открыта форма редактирование данных о клиенте;
‒
2, 4, 6, 8, 10, 12, 15 – возврат в панель управления менеджера по
работе с продажами;
‒
13 – выход из учетной записи.
Далее рассмотрим подсеть «Управление работой с персоналом», которая
представлена на рисунке 18.
Переход в эту подсеть осуществляется при авторизации менеджера по
продажам. При входе в этот компонент пользователю по умолчанию
отображается панель управления данного для данного менеджера.
67
Рисунок 18 – Транзитивная подсеть «Управление работой с персоналом»
логики диалога
Здесь выделены следующие состояния:

S – авторизация под учетной записью менеджера по заказам и вход в
соответствующую панель управления;

S1 – список сотрудников книжного магазина;

S2 – добавление нового сотрудника в список существующих;

S3 – оформление документов на прием;

S4 – оформление документов на увольнение;

S5 – редактирование данных о сотрудниках;

F – выход из учетной записи.
Переход из одного события в другое осуществляется при наступлении
следующих событий:
‒
1 – выбран пункт просмотр списка сотрудников;
‒
3 – открыта форма добавления нового сотрудника;
‒
5 – выбран пункт оформление документов на прием;
‒
7 – выбран компонент оформление документов на увольнение;
‒
9 – открыта форма редактирование данных о сотрудниках;
‒
2, 4, 6, 8, 10 – возврат в панель управления менеджера по работе с
персоналом;
‒
11 – выход из учетной записи.
68
Заключение
Результатом
проделанной
работы
стала
автоматизированная
информационная система управления деятельностью книжного магазина.
В ходе разработки ВКР была проведена следующая работа:
‒
проведен анализ предметной области;
‒
построены диаграммы вариантов использования и модель процессов
предметной области, связанных с осуществлением основной деятельности
книжного магазина;
‒
рассмотрены существующие аналоги;
‒
проведено
календарно-ресурсное
планирование
и
определена
экономическая эффективность;
‒
сформулированы основные цели и задачи разработки, а также
функции АИС управления деятельности книжного магазина;
‒
произведен выбор средств разработки;
‒
проведено
инфологическое
проектирование
и
проектирование
интерфейса АИС;
‒
разработана
автоматизированная
информационная
система
управления деятельностью книжного магазина.
Разработанная АИС обеспечивает выполнение следующих основных
функций:
‒
обеспечение эффективности процесса продажи книг;
‒
заказ продукции и анализ предложений о закупке;
‒
управление персоналом книжного магазина;
‒
управление клиентами и скидками.
АИС управления деятельностью книжного магазина находится на
стадии тестирования и улучшения с последующим внедрением.
Таким образом, была достигнута основная цель и решены все
поставленные задачи выпускной квалификационной работы.
69
Список использованной литературы
1. Баронов, В.В. Автоматизация управления предприятием [текст] / В.
В. Баронов, Г. Н. Калянов, Ю. Н. Попов, А. И. Рыбников, И. Н. Титовский. –
М.: ИНФРА-М, 2000. – 239 с.
2. Бешелев, С.Д. Экспертные оценки: учебник [текст] / С.Д. Бешелев,
Ф.Г. Гурвич. – М.: Наука, 1973. – 158 с.
3. Братищенко В.В. Проектирование информационных систем. [текст] /
Иркутск: Изд-во БГУЭП, 2004.  84 с.
4. Волков, В.Н. Конспект лекций по предмету «Проектирование
информационных систем» [текст] / Орел: ОрелГТУ, 2006-2007.
5. Вендров
А.М.
Проектирование
программного
обеспечения
экономических информационных систем [текст] / М.: Финансы и статистика,
2000. – 126 с.
6. Глумаков, В.Н. Менеджмент малого бизнеса: учебник [текст] /
Глумаков В.Н. , Максимцова М.М., В.Я. Горфинкеля – М: ВЗФЭИ, 2007 г. – 328 с.
7. Карминский, А.М. Информационные системы в экономике [Текст]: в
2-х ч.: ч. 1. Методология создания / Александр Маркович Карминский, Борис
Васильевич Черников. – М.: Финансы и статистика, 2006. - 336 с.
8. Королькова, Е.М. Риск-менеджмент: управление проектными рисками: учеб. пособие для вузов [текст] / Е.М. Королькова. – Тамбов: ФГБОУ
ВПО «ТГТУ», 2013. – 160 с.
9. Кузнецов С.Д. Основы баз данных.

2-е изд. [текст] / М.: Интернет-
Университет Информационных Технологий; БИНОМ. Лаборатория знаний,
2007.  484 с.
10. Марка, Д. Методология структурного анализа и проектирования
SADT [текст] / Девид А. Марка, Клемент МакГоуэн. – М.: МетаТехнология,
1993. – 240с.
70
11. Маркова, В.Д. Бизнес-планирование: учебник [текст] / В.Д. Маркова,
Н.А. Кравченко.- М.: Проспект, 2009. – 216 с.
12. Монографии, изданные в Российской Академии Естествознания
[электронный
ресурс]:
Автоматизированные
информационные
системы,
Топсахалова Ф.М-Г. – Режим доступа: http://www.rae.ru/monographs/70-2660
13. Мукожев, А.М. Формирование инвестиционного портфеля предприятия питания [текст] / А.М. Мукожев. Новые технологии – 2011. – № 3. – С.
1 – 9.
14. Обзор программных продуктов для расчета проектов [электронный
ресурс].
–
Режим
доступа:
http://www.cfin.ru/software/invest/kozlov.shtml
15. Программные продукты для оценки эффективности проектов
[электронный ресурс]. – Режим доступа: http://fd.ru/articles/1323-programmnyeprodukty-dlya-otsenki-effektivnosti- investitsionnyh-proektov#ixzz3wYufgJyI
16. Репин, В.В. Бизнес-процессы
компании: построение, анализ,
регламентация [текст] / Владимир Владимирович Репин. – М.: - РИА
«Стандарты и качество», 2007. – 240 с.
17. Розенков, Д.А. Классический менеджмент: организационные структуры управления: учеб. пособие [текст] / Д.А. Розенков, Р.Г. Леонтьев –Х:
ДВГУПС, 2012 – 192 с.
18. Российское
Предпосылки
и
предпринимательство
[Электронный
ресурс]:
этапы
–
доступа:
развития.
Режим
http://www.creativeconomy.ru/articles/7807/
19. Роль и место программных продуктов в оценке эффективности
проектов Сб. Роль аналитика в управлении компанией Москва [электронный
ресурс].
–
Режим
доступа:
http://www.bizeducation.ru/library/fin/invest/bersenev.htm
20. Федеральная налоговая служба [Электронный ресурс]: многопредмет. науч. журн./ Моск. физ.-техн. ин-т. – Электрон. журн. – Режим доступа:
http://zhurnul.milt.rissi.ru
71
Приложение
Экранные формы
72
73
74
ý*hd,&Y
l"lipРýt $/ýý,е
ý"т $,} д"
ý
т!}*Ё;,{,"i'ý il.)${."i
Орловский
$
ГУ
t,ii l{ цtа8 lTl'yi\,i{jt\+{
сIIрАвкл
о
на
результатах проверки текстового документа
наличие заимствований
Пповерка выполн9на в системе
'
Ав,гор работы
Антиплагиат.ВУЗ
Минаков Серrей Еитальович
Факультет, кафелра,
номер группы
Фи3икэ-матёматичесlмй
Тип работы
fuПломКаяработа
:фФультет, кафелра аллебры и матем{tтпtlеёк}о( м9тодов в
э]Фномикq..
:. j:i
ii
]
:
:l;l ; l]
],i.:+:]];,:.i
};.lr*=i
Название работы
Название фай,iа
Минаков Ссргей Витальевич,dоох
Лрошент заимс,гвования
?2,1zo^
Проuент цитирования
0%
Проttент оригинаjiьности
71,28О/о
!,aтa проверки
l1:07:ll
l3люня 20l7г.
Мо,lr"ли поиска
Работl, провери",t
[ага ltолписи
J/.//J,r'//;,,
.,
,,
Чтобы убедиться
в поминности справки,
используйте QR-код, который
содержит ссылку на отчет.
..._ , .
,
'',
ответ ,ia вопрос, является nt,t обпaру*чrrое заимfiвование
i<ьфректным, система остадляет на усмотрение проверяющего,
предоставленная информация не помежит использованию в
коммерческих целях.
1/--страниц
Пожаловаться на содержимое документа