Файл: "Разработка информационной системы менеджера по продажам салона сотовой связи".docx
Добавлен: 25.10.2023
Просмотров: 269
Скачиваний: 9
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Затем весь комплект модулей проходит системный тест – тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
Последний тест информационной системы – приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.
Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.
Для построения некоторых типов диаграмм используется редактор dia. Dia — кроссплатформенный свободный редактор диаграмм, часть GNOME Office, но может быть установлен независимо. Он может быть использован для создания различных видов диаграмм: блок-схем алгоритмов программ, древовидных схем, статических структур UML, баз данных, диаграмм сущность-связь, радиоэлектронных элементов, потоковых диаграмм, сетевых диаграмм и других.
Dia расширяема новыми наборами объектов, которые описываются с помощью файлов в формате, основанном на XML.
Глава 2. Проектная часть
2.1. Требование к информационной системе
На первом этапе проектирования информационной системы появляются вопросы: «Какой она должна быть и что она должна делать?» Ответить на эти вопросы можно описав требования. Подробно о требованиях я говорил в прошлой главе. Сейчас пришло время рассказать, какие требования были предъявлены к проектируемой информационной системе. Легче всего их представить в виде таблицы (табл. 2).
Таблица 2. Требования к информационной системе
| Бизнес требования | 1. Хранение всех данных в БД. 2. Сокращение времени обработки заказа. 3. Ведение учета поставок. 4. Автоматический расчет суммы покупок |
| Пользовательские требования | 1. Вывод краткой информации о товаре. 2. Возможность поиска товара по критериям 3. Простая форма оформления заказа |
| Функциональные требования | 1. Возможность просматривать имеющиеся на складе товары. 2. Возможность быстрого добавления и изменения данных. 3. Возможность просмотра поставщиков. |
| Нефункциональные требования | 1. Внешний вид. 2. Быстрое восстановление после сбоя. |
Так же система должна быть простой для обучения и в использовании. Новые сотрудники не должны испытывать неудобства в использовании. Экономия времени должно стать конкурентным преимуществом использования системы по сравнению с другими идентичными программами, представленными на рынке. Быстрота работы – тоже необходимое требование, все по той же причине. Все документы системы сохраняются в электронном виде и автоматически отправляются в базу данных. Таким образом, сокращается использование бумаги.
2.2. Создание бизнес-модели в стандарте IDEF0
Для наглядного изображения модели информационной системы, лучше всего подходят диаграммы IDEF0. IDEF0 — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность.
Стандарт IDEF0 представляет организацию как набор функций, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того, есть правило стороны: — стрелка входа приходит всегда в левую кромку активности, — стрелка управления — в верхнюю кромку, — стрелка механизма — нижняя кромка, — стрелка выхода — правая кромка. Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализировался до необходимого уровня. Также для того что бы быть правильно понятым существуют словари описания активностей и стрелок. В этих словарях можно дать описания того какой смысл вы вкладываете в данную активность либо стрелка.
Также отображаются все сигналы управления, которые на диаграмме потоков данных не отображались. Данная модель используется при организации бизнес – проектов и проектов, основанных на моделировании всех процессов, как административных, так и организационных
Для описания бизнес-модели я использовал техническое средство BPwin. BPwin является мощным средством моделирования и документирования бизнес-процессов.
Диаграммы IDEF0 наглядны и просты для понимания, в то же время они формализуют представление о работе компании, помогая с легкостью находить общий язык между разработчиком и будущим пользователем приложения.
Основными элементами диаграммы являются активности и дуги (стрелки), которые изображают взаимосвязи и отношения активностей друг с другом. Дуги могут быть нескольких типов: вход, выход, управление и ресурсы. На каждой диаграмме обычно располагается от 3 до 6 активностей, это обусловлено тем, что такое количество активностей является оптимальным для восприятия сознанием. Модель BPwin представляет собой набор иерархически связанных и упорядоченных диаграмм, каждая из которых является конкретизацией (декомпозицией) активности предыдущего верхнего уровня. Каждая модель имеет одну диаграмму верхнего уровня, которая содержит только одну активность, определяющую общую функцию моделируемого процесса. Модели имеют так называемые “точки зрения”, определяющие ракурс, под которым рассматривается процесс. Например, для рассмотрения процесса может быть выбрана точка зрения начальника отдела компании, где происходит моделируемый процесс.
Построение функциональной модели информационной системы начинается с описания функционирования системы в целом в виде контекстной диаграммы ( 1). В центре расположен блок «рабочее место менеджера по продажам». С левой стороны в виде стрелок изображены интерфейсные дуги, обозначающие входные данные. Под входными данными понимаются материалы и документы, необходимые для функционирования системы. В нашей информационной системе входные данные:
– Приходные накладные;
– Заключение о неисправности.
С верхней части к блоку приставлены дуги, обозначающие то, что регламентирует работу системы. В нашем случае:
– Законодательные акты;
– Правила приема товаров;
– Правила бухгалтерского учета;
– Должностные обязанности.
Нижние дуги отображают участников, непосредственно работающих и постоянно сталкивающихся с информационной системой. Это могут быть как люди, так и программное обеспечение. В нашем случае это:
– Менеджер по продажам;
– Программа регистратор;
– Управляющий магазином.
Здесь не учтены клиенты, так как они не являются непосредственными участниками работы в информационной системе. Всю деятельность осуществляют выше названные элементы.
На выходе мы получаем:
– Документ «Ежедневный отчет о продажах».
Это единственный документ, который получается в результате непосредственной работы системы. Выручка и прочие факторы – результат действий работников торговой точки. Информационная система напрямую на них не влияет.
Далее следует функциональная декомпозиция – система разбивается на подсистемы, и каждая подсистема описывается отдельно
Затем каждая подсистема, при необходимости, разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции. В результате декомпозиции первого уровня (см. 1) получаем блоки:
– Прием товара;
– Регистрация продажи;
– Формирование отчетов;
– Возврат товара;
– Инкассация.
Блок прием товара описывает процесс регистрации товара в базе данных от момента получения приходных накладных по электронной почте, до подтверждения принятия товара. Входными данными здесь являются приходные накладные. На выходе мы имеем каталог товаров, который формируется, путем добавления новых товаров в базу данных. Прием товара регламентируется законодательными актами, правилами приема товара, должностными обязанностями и правилами бухгалтерского учета. Непосредственными участниками процесса являются менеджер по продажам, программа регистратор и управляющий магазина.
Декомпозиция третьего уровня блока «Прием товара» полностью демонстрирует процесс регистрация вновь поступившего товара. Сначала по электронной почте с сервера управления базами данных поступают приходные накладные в электронном виде. Загрузив их, заранее становится известно, какие товары поступят. Данные из приходной накладной переносятся в реестр принятого товара – электронный документ, формирующий список нового товара. Из этого реестра список товара, после учета и записи товара, поступает в каталог товаров торговой точки.
После того, как товар занесен в базу данных, он готов к продаже. Процесс регистрации продажи изображен на блоке номер 2. На выходе получаются кассовый чек и x-отчет. Перед продажей товара, менеджер находит в электронном каталоге искомый товар. Совершив эту операцию, он получает подробную информацию о товаре с описанием и отображением его статуса. Далее, одной кнопкой менеджер выводит товар в поле окно продаж, где отображаются выбранные товары. В окне отображается список позиций, цена товара и сумма покупки. Подтвердив регистрацию покупки, программа регистратор удаляет проданные товары из каталога и отправляет на печать документы – кассовый чек и гарантийный талон.
Активный блок формирование отчетов описывает процессы, составления отчетов. В результате декомпозиции этого блока, мы получаем следующую диаграмму (см. 1).
После любых активных действиях, информационная система заносит всю информацию о процессах в Лист продаж – главный отчет о проделанной за день работе. Здесь отображаются все операции с товарами и выручкой. На входе мы имеем следующие документы:
– x-отчет;
– расходно-кассовый ордер;
– кассовый чек.
X – отчет – это предварительный итог о проделанной финансовой работе. Расходно-кассовый ордер – документ, фиксирующий списание денежных средств.
После формирования итогового листа продаж и сверки его показателей с x-отчетом, снимается z – отчет – конечный итог о проделанной финансовой работе, после его снятия работа с кассой – запрещена. Одновременно с этим формируется и отправляется на сервер управления базами данных отчет о продажах за день.
Информационная система так же выполняет и другие важнейшие функции, такие как инкассация и возврат товара. Подробнее процесс инкассации представлен на диаграмме декомпозиции
Инкассация — это прием, перевозка и сдача денежных средств и ценностей в кредитную организацию для последующего зачисления на расчетный счет юридического либо физического лица.
Сегодня инкассация является одной из самых востребованных банковских услуг. Инкассация выполняется ежедневно. Для начала информационная система рассчитывает выручку в кассе, суммируя продажи и произведенные ею финансовые операции. В результате такого пересчета, получаем данные о выручке. После чего, нажатием соответствующей кнопки, формируется необходимый пакет документов, на основании которых, программа списывает денежные средства. После операции инкассации распечатывается в двух экземплярах расходно-кассовый ордер. Так выглядит процесс инкассации денежных средств банку.
Блок декомпозиции возврат товара (см. 1) описывает процедуру принятия товара от клиента, согласно закону о защите прав потребителей. Для начала в отдельном окне регистрируется прецедент, создается соответствующая запись в реестре принятого товара. Записываются данные о товаре и клиенте. После, автоматически делается соответствующая запись в листе продаж. Затем производится процесс списания денежных средств и инкассации денежных средств (см. 1). Этот процесс был подробно описан выше.