Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Складской учет» (Моделирование бизнес-процессов)

Содержание:

Введение

Одним из основных факторов влияния научно-технического прогресса на все сферы деятельности человека является широкое использование новых информационных технологий.

Автоматизация предприятий традиционно начинается с внедрения системы бухгалтерского учета. Если раньше подобные проекты часто выполнялись собственными силами компаний, то сегодня они полностью перешли введение внешних разработчиков и интеграторов. Если ранее, внедрение средств комплексной автоматизации деятельности предприятия было уделом крупного бизнеса. То сегодня уже любой бизнес, в том числе малый и средний, все больше заинтересован во включении этого ПО как составной части в ERP-системы (Enterprise Resource Planning).

Системы автоматизации бухгалтерского учёта начали внедрять на предприятиях одними из первых среди всех информационных систем. Причина этого понятна – в процессе ведения учёта выполняется большое число рутинных операций, при ручной обработке документов практически постоянно нужно вносить в них одни и те же служебные данные. Ведение аналитического учёта с ростом числа документов резко усложняется, также велика вероятность "механической" ошибки, которую бухгалтер может допустить, заполняя документы или подсчитывая сводные показатели. Разумеется, двойная запись всех операций позволяет выявлять такие ошибки, однако не всегда бывает просто локализовать их и найти нужный документ, в который необходимо внести коррективы. Наконец, работа с большими объёмами документов требует значительных затрат человеческих ресурсов и рабочего времени, что вызывает соответствующе финансовые затраты, не имеющие прямого экономического эффекта. Эти и ряд других причин стимулировали достаточно бурное развитие систем автоматизации бухгалтерского учёта.

На сегодняшний день системы автоматизации бухучёта, как и многие другие продукты, используемые предприятиями, подразделяются на системы, являющиеся составной частью ERP-систем, и самостоятельные решения.

Одной из важных составляющих бухгалтерского учета является складской учет предприятия. На каждом предприятии, которое проводит товарные операции, ведется складской учет.

Склад – специальное помещение для хранения чего-нибудь; запасы товаров, материалов, сложенных в одном месте.

Складской учет включает в себя отслеживание прихода и расхода товаров на складе и перемещение товаров между складами и в магазины.

Поскольку склады работают с большими потоками товаров, учёт этих потоков требует немало усилий, рутинных операций. При помощи автоматизированных информационных систем работа бухгалтера по ведению складского учета может быть облегчена. Автоматизация складского учета призвана повысить эффективность выполнения основных функций бухгалтера по складскому учёту и улучшить оперативность принятия решений, повысить производительность труда, снизить количество вычислительных ошибок в процессе обработки информации, содействовать эффективному и безопасному хранению информации и доступу к ней. На основе ранее введенных данных впоследствии можно получить информацию о товарах, имеющихся на складе, и провести анализ по какому-либо признаку.

Наименование темы разработки – "Складской учет".

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

Полное наименование программного продукта: "Учет+".

1 Глава. Построение бизнес-процессов «как есть».

  1. Описание предметной области. Постановка задачи.

Предметная область информационной системы - это материальная система или система, характеризующая элементы материального мира, информация о которой хранится и обрабатывается. Предметная область рассматривается как некоторая совокупность реальных объектов и связей между ними.

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

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

Склад обязан вести учет продукции, находящейся на временном хранении, составление карточек, кладовых книг, описей, приходных и расходных накладных, ордеров по учету прихода, расхода, наличия, остатков продукции на складе, учет выполнения заказов по отгрузке и разгрузке готовой продукции, составление отчетов о загрузке складских площадей.

Рассмотрим типичные бизнес-процессы складского учета на не автоматизированном гипотетическом складе. Такое рассмотрение проводится с целью выявить недостатки существующей системы складского учета, а так же показать необходимость автоматизации склада.

Процедура принятия продукции на склад:

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

В ходе работы склада, он нуждается в инвентаризации, которая включает в себя такие стадии как: ответственный работник по переучету продукции, в сопровождении книги переучета, отправляется на склад, и в ручную осматривает и переписывает данные о товаре и его количестве; после этого данные сверяются в книге учета товаров, лицами ответственными за документы отчетности на складе и составляется соответствующий отчет, по данным переучета продукции.

Отгрузка товаров со склада проходит следующие стадии:

  • получатель товара подает накладную на отгрузку товара;
  • контролер проверяет эту накладную и регистрирует ее в книге учета входящих документов;
  • далее контролер дает указание работникам склада на поиск нужной продукции и отгрузки ее;
  • затем получатель товара проводит его осмотр, на счет того нужный ли товар отгрузили и в нужном количестве;
  • контролер регистрирует в книге учета факт отгрузки товара;
  • далее контролер выдает получателю груза сопроводительный документ по отгрузке товара;
  • далее происходит непосредственно отгрузка товара техническими средствами.

Проанализировав ситуацию на складе и выявив все минусы, постараемся создать такую систему, которая бы автоматизировала следующие операции на складе:

  • регистрация документов осуществляется с помощью ЭВМ;
  • поиск товаров для отгрузки будет проводиться путем поиска соответствующего товара в БД и просмотра информации о месте его хранении (номер склада).
  • формирование документов отчетности, будет производиться системой автоматически.

В результате вся работа с бумагами будет проводиться с использованием компьютеров, не нужно будет возится с кучей бумаг.

При помощи ЭВМ на складе автоматизирован учет поступления и отгрузки товаров, учет входящих и исходящих документов, количественный учет. В общем объеме учетных работ эти задачи имеют значительный удельный вес. Их автоматизация позволяет сократить ручные операции, ускорить обработку информации, повысить точность учета. В памяти ЭВМ хранится и может быть выдана на печать детальная информация о количестве поступления и отгрузки конкретного товара по каждому документу в случае несовпадения величины запаса с данными машинного учета.

Главное назначение автоматизированной системы в данном случае – повысить эффективность выполнения основных функций работников склада.

Автоматизация управления процессами на складе, повышает его оперативность и эффективность. Критериями выбора технических средств являются:

  • надежность функционирования системы;
  • функциональная полнота системы; быстродействие;
  • минимизация затрат на стоимость: аппаратных средств, прикладных систем, сопровождения системы, развития системы.

Постановка задачи

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

Под автоматизированной системой понимается система методов и способов сбора, накопления, хранения, поиска, обработки и защиты управленческой информации на основе применения развитого программного обеспечения, средств вычислительной техники и связи, а также способов, с помощью которых эта информация предоставляется пользователям.

Структура конкретной автоматизированной системы для своей реализации предполагает наличие трех компонентов: комплекса технических средств, состоящего из средств вычислительной, коммуникационной и организационной техники; системы программных средств, состоящей из системного (общего) и прикладного программного обеспечения; системы организационно-методического обеспечения, включающей инструктивные и нормативно-методические материалы по организации работы управленческого и технического персонала в рамках конкретной автоматизированной системы обеспечения управленческой деятельности.

Потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных. Притом, что любая развитая семантическая модель данных, как и реляционная модель, включает структурную, манипуляционную и целостную части, главным назначением семантических моделей является обеспечение возможности выражения семантики данных. Наиболее простым является составление ER-диаграммы. ER-диаграмма просто реализуется в реляционную модель: сущность становится таблицей, атрибуты - идентификаторами преобразуются в первичные ключи, а остальные атрибуты - в столбцы.

Бизнес-процессы - это последовательность взаимосвязанных активностей или задач, которые приводят к созданию определенного продукта или услуги для потребителей. Часто бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов. Бизнес-процесс начинается со спроса потребителя и заканчивается его удовлетворением. Бизнес-процесс может быть декомпозирован на несколько подпроцессов, которые имеют собственные атрибуты, однако также направлены на достижение цели основного бизнес-процесса. При описании бизнес-процессов используются различные методологии и соответствующие нотации, такие как: IDEF0, IDEF3, DFD.

    1. Выбор средства для моделирования бизнес-процессов

Обобщая положение процессного подхода, можно определить цель бизнес- процессов как удовлетворение требований клиентов процесса, которых можно разделить на пять разных типов:

- первичные клиенты - те, которые получают первичный выход (результат);

- вторичные клиенты - те, которые находятся вне процесса и получают вторичные выходы (результаты);

- косвенные клиенты - те, которые не получают первичного выхода, но являются следующими в цепочке, поэтому более поздний по времени выход отображается на них;

- внешние клиенты - те, которые находятся за пределами торговой организации, но получают выход процесса, а именно: дистрибьюторы, агенты, розничные продавцы, другие организации;

- внешние клиенты - непосредственно потребители.

Таким образом, можно построить алгоритмы обособления бизнес-процесса с учетом того, что разные клиенты фактически порождают и определяют состав и типы бизнес – процесса торгового предприятия. Механизм построения нового бизнеса-процесса базируется на взаимодействии таких элементов:

1. Наличие продукта (процедуры), относительно которого необходимо выделить бизнес - процесс.

2. Потребность руководства в управленческой информации относительно данного бизнес - процесса.

3. Существующая система бухгалтерского и управленческого учета.

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

5. Наличие персонала, способного выполнять ролевые функции в команде.

К требованиям и ограничениям процесса моделирования нового бизнес – процесса складского учета следует отнести такие:

1. Информация на этапах моделирования бизнес - процесса должна быть понятной, непротиворечивой и регламентной, поэтому должен осуществляться постоянный мониторинг необходимой информации.

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

3. При определении границ этапов моделирования бизнес - процессов должна быть получена информация, которая разрешает руководителю предприятия сопоставлять результаты этапов по результатам, которые можно получить.

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

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

6. Количество этапов бизнес - процесса влияет на количество и периодичность временных точек реализации управленческого цикла за счет необходимости измерения, обработки, передачи информации относительно детализированных бизнес - процессов.

7. Ошибки управления бизнес - процессом должны быть ограничены допустимым уровнем представления (детализации) бизнес - процесса. Модели описания бизнес - процесса и механизма его управления должны быть адекватные реальным процессам, которые отображены в стоимостном представлении согласно системе управленческого и бухгалтерского учета. Относительно бизнес – процесса складского учета необходимо выполнить моделирование:

- приема товара на склад от поставщика;

- комплектация и выдачу товаров со склада;

- инвентаризацию товаров на складе (при условии его комплексной автоматизации).

Основные объекты в процессе продажи товара

Основным объектом торговой деятельности является продукт, потребительские свойства которого не изменяются в процессе осуществления данной деятельности.

Основной объект бухгалтерского учета в торговле – товары. Поэтому правильная обработка всех операций, связанных с товарами, должна находиться в центре внимания бухгалтерского подразделения организации, осуществляющей торговлю.

Основные задачи учета товаров и их реализации состоят в том, чтобы обеспечить контроль над состоянием товарных запасов и их сохранностью на складах.

Аналитический учет поступления товаров в торговле ведется на складах и в бухгалтерии. Документами первичного учета, на основании которых принимаются на склад товары, являются товарно-транспортные накладные, счета-фактуры и другие сопроводительные документы. Эти документы материально ответственные лица вместе с товарным отчетом сдают в бухгалтерию.

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

1.3. Требования к автоматизированной системе

Программа должна обеспечивать выполнение перечисленных ниже функций:

Для покупателя:

  • Поиск товара по его наименованию;
  • Выбрать нужные позиции (товары) и приобрести их;
  • Оформить заявку на товар;
  • Формирование и печать прайс-листа.

Для работников магазина:

      1. Контроль над безопасностью (выдача паролей);
      2. Обеспечить различные права доступа сотрудникам магазина;
      3. Закупить товар;
      4. Продать товар;
      5. Перемещение товара (со склада на склад, со склада в магазин, с магазина в магазин, из магазина на склад);
      6. Поиск товара по его наименованию;
      7. Формирование и печать накладных (расходных, приходных), прайс-листа.

Требования к временным характеристикам программы не предъявляются.

Входные данные программы – единицы товаров с указанием наименования, цены, количества.

Выходные данные программы – накладные, прайс-листы.

Накладные и прайс-листы должны быть представлены в виде отдельных файлов *.txt, организованных определенным образом.

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

Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:

  • организацией бесперебойного питания технических средств; использованием лицензионного программного обеспечения;
  • регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998г. "Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств";
  • регулярным выполнением требований ГОСТ 51188-98. Защита информации;
  • испытания программных средств на наличие компьютерных вирусов;
  • спецификация по безопасности;
  • отказы из-за некорректных действий оператора.

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

  • Идентификация пользователя для входа в программу.

Проверка корректности вводимых данных. При несовпадении вводимого пароля с установленным по умолчанию в программе доступ запрещается и требует повторного введения.

Минимальные требования к оборудованию:

  • Процессор: Pentium 90 МГц;
  • Объем оперативной памяти: 256 Мб;
  • Свободного места на диске 10-15 Мб.

Требования к операционной системе:

  • Microsoft Windows XP и выше.

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

  • Bor1and De1phi 7.0

Требования к пользователю:

  • Опытный пользователь ПК с опытом работы в розничной торговле.

2 Глава. Построение бизнес-процессов

2.1 Предлагаемые мероприятия по улучшению бизнес-процессов

Процесс разработки программного обеспечения подразумевает создания множества артефактов, одним из видов которых являются модели.

Модели – это абстракция, описывающая моделируемую систему с определенной точки зрения и на определенном уровне абстрагирования, которая создается архитекторами и проектировщиками и представляет законченный взгляд на систему. программный автоматизированный

Диаграмма вариантов использования.

Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма – это описание сценария поведения, которому следуют действующие лица (Actors). Отражает объекты, как системы, так и предметной области и задачи, ими выполняемые. [Приложение 1]

На диаграмме изображены следующие действующие лица (актеры):

  1. поставщик;
  2. зав.складом;
  3. переупаковщик;
  4. грузчики;
  5. тмц;
  6. отдел инвентаризации;
  7. подразделение.

Диаграмма показывает процесс работы склада и передвижение (товарно-материальных ценностей). Весь процесс описывается следующим образом: Актер «Поставщик» поставляет товарно-материальную ценность актеру «Зав.складом», «Подразделение» отправляет заказ на товарно-материальную ценность актеру «Зав.складом», он поставляет товарно-материальную ценность на склад (принимает «Зав.складом»), «Зав.складом» отправляет товарно-материальную ценность на переупаковку актёру «Переупаковщик», но только в том случае если «Переупаковщик» получит «заявку на переупаковку», в противном случае «Зав.складом» отправляет заявку на размещения товарно-материальной ценности «Грузчикам 1-го отдела» которые, в свою очередь, непосредственно размещают товарно-материальную ценность. Далее товарно-материальную ценность перемещают в зону отгрузки, там ее принимают «Грузчики 2-го отдела», и если «Зав.складом» отправляет им заявку от подразделения (заказчика), они привозят и отгружают товар «Подраздлению». Так же «Отдел инвентаризации» может провести инвентаризацию товарно-материальной ценности, но только в том случае если получит соответствующую заявку.

Диаграммы логического представления

После проектирования диаграммы вариантов использования нужно спроектировать диаграммы логического представления проектируемой системы. Логическое представление показывает, как система будет реализовывать поведение, описанное в вариантах использования. Оно дает подробную картину составных частей системы и описывает взаимодействие этих частей. Логическое представление включает конкретные классы, диаграммы классов и диаграммы состояний. С их помощью конструируется детальный проект создаваемой системы.

Логическое представление содержит:

  1. диаграмма использования (рисунок 1);
  2. диаграмму классов (рисунок 2);
  3. диаграммы последовательности и кооперации (рисунок 3, 4);
  4. диаграммы состояний (рисунок 5);
  5. Диаграммы деятельности и компонентов (рисунок 6,7);
  6. Диаграмма развертывания (рисунок 8).

На этой диаграмме показано взаимодействие классов, как и куда происходит перемещение и его учет.

Для лучшей наглядности были созданы следующие классы:

  1. «Подразделение» (подразделение выполняет функцию клиента который заказывает у склада необходимое количество с помощью класса «АИС» (собственно «АИС» – это и есть олицетворение нашей разрабатываемой системы).

В него были включены следующие атрибуты: «Код подразделения» (для того чтобы сотрудники склада ориентировались кому и куда отправлять), «номер» (это номер который требуется заказать у сотрудников склада) и собственно «Телефон» (номер для обратной связи).

Диаграмма классов

Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

Диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. [Приложение 1]

Базовыми отношениями между классами в языке UML являются:

  • Отношение зависимости;
  • Отчет – Admin, Пользователь, Товары, Склады
  • База Данных – Admin, Пользователь, Товары, Склады
  • Отношение ассоциации;
  • Admin – Товары, Admin – Склады, Пользователь – Товары, Пользователь – Склады, Товары – Склады
  • Отношение обобщения;
  • Form – Отчет, Авторизация, MainForm, База Данных, Admin, Товары, Склады, Пользователь
  • Отношение реализации.

Диаграмма последовательности

Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов. Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений.

События, инициируемые при входе в программу с правами пользователя.

События, инициируемые при входе в программу с правами пользователя. [Приложение 1]

Диаграмма кооперации

Диаграмма кооперации так же является разновидностью диаграммы взаимодействия, и в контексте языка UML описывает динамический аспект взаимодействия объектов при реализации отдельных вариантов использования. Проще говоря это диаграмма последовательности только в другом представлении. [Приложение 1]

Диаграммы состояний

Главное предназначение диаграммы состояний – описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла.

Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых событий.

Диаграмма характеризует состояния и переходы всей программы.

Диаграмма характеризует различия в управлении функциональными возможностями складов и магазинов в программе. [Приложение 1]

Диаграмма деятельности

Диаграмма деятельности – это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.

Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на этих диаграммах также присутствуют обозначения состояний и переходов. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние выполняется только при завершении этой операции. [Приложение 1]

Диаграмма компонентов

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей. При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей. Диаграмма компонентов определяет архитектуру разрабатываемой системы. [Приложение 1]

Диаграмма компонентов разрабатывается для следующих целей:

  1. визуализации общей структуры исходного кода программной системы;
  2. спецификации исполняемого варианта программной системы;
  3. обеспечения многократного использования отдельных фрагментов программного кода;
  4. представления концептуальной и физической схем баз данных.

Диаграмма развертывания

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

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения.

Представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками.

Эта диаграмма завершает процесс ООАП для конкретной программной системы. [Приложение 1]

При разработке диаграммы развертывания преследуют следующие цели:

  1. определить распределение компонентов системы по ее физическим узлам;
  2. показать физические связи между всеми узлами реализации системы на этапе ее исполнения;
  3. выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.

Спроектированная диаграмма говорит о том, что программное обеспечение устанавливает на компьютеры подразделения и на компьютеры склада, а связь с «Облаком»(где хранится БД) и связь между подразделением и складом осущестляется по Локальной/Глобальной сети.

2.2 Моделирование бизнес-процессов

Программа "Учет+" написана на языке Bor1and De1phi 7.0.

В состав проекта "Учет + " входит:

  1. главный файл проекта FirmU.dpr;
  2. 1 модуль с расширением.pas, содержащие процедуры и функции;
  3. 1 файл форма с расширением.dfm,, являющиеся графическим представлением приложения;
  4. файлы с расширением.dcu – скомпилированные модули;
  5. 8 файлов с расширением.dat- содержащие данные:
      • Shops.dat – содержит наименования магазинов;
      • Storages.dat – содержит наименование складов;
      • На Автозаводе. dat – содержит ассортимент данного объекта;
      • На Гая,100. dat – содержит ассортимент данного объекта;
      • На Речпорте. dat – содержит ассортимент данного объекта;
      • На Нариманова,8.dat – содержит ассортимент данного объекта;
      • На Ульяновском,30. dat – содержит ассортимент данного объекта;
      • На Центральном Рынке. dat – - содержит ассортимент данного объекта.
  6. файл Firm.exe – исполняемый файл проекта.

Проект вызывается запуском файла Firm.exe.

Описание главной формы проекта

Главная форма проекта выглядит следующим образом:

Эта форма является стартовой для всех ролей. На форме расположены элементы управления:

1) Слева расположена панель кнопок.

2) Окно авторизации.

3) Рабочая область.

4) Информация о компании.

Оценки уровня ошибок

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

В данном программном продукте системные ошибки не проверяются.

Оценка качественных характеристик

Характеристики качества:

Мера

Оценка

Надежность

Доступность-готовность

Относительное время работоспособного функционирования

Вероятность

0,99

Эффективность

Временная эффективность

Время отклика – получение результатов на типовое задание

Пропускная способность – число типовых заданий, исполняемых в единицу времени

Секунды

Число в секунду

1

1

Используемость ресурсов

Относительная величина использования ресурсов ЭВМ при нормальном функционировании программного средства

Вероятность

0,2

Практичность

Понятность

Четкость концепции ПС

Демонстрационные возможности

Наглядность и полнота документации

Порядковая

Хорошая

Отличные

Отличная

Простота использования

Простота управления функциями

Комфортность эксплуатации

Среднее время ввода заданий

Среднее время отклика на задание

Порядковая

Порядковая

Секунды

Секунды

Отличная

Хорошая

1

1

Изучаемость

Трудоемкость изучения применения ПС

Продолжительность изучения

Объем эксплутационной документации

Объем электронных учебников

Чел.-часы

Часы

Страницы

Кбайт

1

4

57

0

Привлекательность

Субъективные или экспертные оценки

Порядковая

Хорошая

Сопровождаемость

Анализируемость

Стройность архитектуры программ

Унифицированность интерфейсов

Полнота и корректность документации

Порядковая

Хорошая

Хорошая

Отличная

Изменяемость

Трудоемкость подготовки изменений

Длительность подготовки изменений

Чел.-часы

Часы

3

3

Стабильность

Устойчивость к негативным проявлениям при изменениях

Порядковая

Хорошая

Тестируемость

Трудоемкость тестирования изменений

Длительность тестирования изменений

Чел.-часы

Часы

2

2

Мобильность

Адаптируемость

Трудоемкость адаптации

Длительность адаптации

Чел.-часы

Часы

2

1

Простота установки

Трудоемкость инсталляции

Длительность инсталляции

Чел.-часы

Часы

0,05

0,05-0,1

(3-5 минут)

Существование-соответствие

Стандартизация интерфейсов с аппаратной и операционной средой

Порядковая

Хорошая

Замещаемость

Трудоемкость замены компонентов

Длительность замены компонентов

Чел.-часы

Часы

2

2

2.2 Моделирование бизнес-процессов

Оцениваются действующие лица A (Actor)

Весовые коэффициенты:

Тип действ. лица

Вес

простой

1

Оцениваются варианты использования UC (Use Case)

В зависимости от количества классов, выделяемых на этапе анализа:

Тип

Количество классов

Вес

простой

<5

5

Общий весовой показатель объектных точек UUCP (Unadjusted Use Case Points):

UUCP = A + UC=1+5=6

Техническая сложность проекта

Значение TCF вычисляется по формуле:

TCF = 0,6 + (0,01 * ?(Ti * Весi))= 0,92

Показатель

Описание

Вес

Т 1

Распределенная система

2

0

Т 2

Высокая производительность

1

4

Т 3

Работа пользователей в режиме online

1

0

Т 4

Сложная обработка данных

1

2

Т 5

Повторное использование кода

1

1

Т 6

Простота установки

0,5

5

Т 7

Простота использования

0,5

5

Т 8

Переносимость

2

4

Т 9

Простота внесения изменений

1

5

Т 10

Параллелизм

1

0

Т 11

Специальные требования безопасности

1

3

Т 12

Непосредственный доступ к системе для внешних пользователей

1

4

Т 13

Специальные требования к обучению пользователей

1

0

Уровень квалификации разработчиков EF

EF = 1,4 + (-0,03 * ?(Fi * Весi))=0,635

Показатель

Описание

Вес

F1

Знакомство с технологией

1,5

5

F2

Опыт разработки

0,5

2

F3

Опыт использования ООП

1

4

F4

Наличие ведущего аналитика

0,5

2

F5

Мотивация

1

5

F6

Стабильность требований

2

5

F7

Частичная занятость

-1

5

F8

Сложные языки програм-мирования

1

2

UCP = UUCP * TCF * EF=5*0,92*0,635=3,5

Общее количество показателей, имеющих значение больше 3, равно 5, следует использовать 28 человек на одну UCP.

3,5 *28=98,14 часов затрачено на разработку проекта.

Протокол тестирования

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

  1. Время запуска программы – менее 2 секунд.
  2. Время для импорта исходных данных (5 записей): 1 секунда.
  3. Фатальные ошибки, приводящие к потере системой работоспособности или порче данных, не обнаружены.
  4. Выявлено 3 незначительных ошибок, из-за которых не следует останавливать распространение программного продукта, но в следующей версии необходимо устранить их, чтобы придать программе законченность.
  5. Интерфейс для ввода и поиска нового продукта удобен и не требует внесения изменений в новой версии.

В ходе тестирования программы были выявлены следующие недочеты:

  • Малый масштаб рабочей области.
  • Не реализован поиск товара.
  • В отчетах в столбике цены не выводятся значения.
  • Не реализована возможность отказа от товара при оптовой закупке.

Изменения, внесенные в программу по результату тестирования: не устранен недочет – не реализована возможность отказа от товара при оптовой закупке.

Выводы по итогам тестирования:

  1. Фатальные ошибки, приводящие к потере системой работоспособности или порче данных, не обнаружены.
  2. Ошибок, мешающих распространению продукта, не выявлено.

Заключение

Проект разработан для автоматизации деятельности работников оптовой и розничной сетей продажи товаров. В структуру проекта входят таблицы, отчеты. Вся информация о накладных на поступление/ на выбытие товара, о количестве и ценах хранится в электронном виде. Среди многообразия хозяйственных операций на торговом предприятии учет товарных операций является наиболее трудоемким, так что проект увеличивает производительность труда менеджера и продавца, контролирует их деятельность на предмет ошибок.

Преимущества:

  1. Программный продукт увеличивает производительность труда продавца-консультанта, менеджера по продажам.
  2. Все документы формируются на основе выбора данных из справочников, что дает возможность быстрее вводить данные и избегать ошибок, к тому же программа при этом берет на себя основной объем по контролю целостности данных.
  3. Пользователю приводится каталог товаров с их наличным количеством и ценами.
  4. Достаточно простой интерфейс. Время на обучение мало – порядка 0.5 часа. Программа не требует от пользователя специальной подготовки.
  5. Контроль над вводом данных:
    • ввод данных денежного и числового формата;
    • контроль над тем, чтобы поля не были пустыми (например, поле "наименование товара");
    • контроль над тем, чтобы размер заказа не превышал количество находящегося в наличии товара.

Недостатки:

  1. Программа не тестировалась на больших БД;
  2. Не реализована возможность отказа от товара при оптовой закупке.

Список литературы

  1. Информационные системы в экономике. Балдин К.В., Уткин В.Б.(2008,5-е изд., 395 с.)
  2. Типовые ошибки в управлении складом // Логистика. 2015. № 1 (98). С. 58-61.Ловков Д.А.
  3. Фаронов В.В. DELPHI 2005. Разработка приложений для баз данных и Интернета – СПб.: Питер, 2006 г.
  4. Управление логистическим процессом на складе // Инновационная наука. 2016. № 4-1. С. 198-200. Литвинов С.
  5. Богс, М.У. UML и Rational Rose/ М.У. Богс. – М.: Лори, 2001. – 411с
  6. Буч, Г. Язык UML Руководство пользователя/ Г. Буч, Д. Рамбо, А. Джекобсон. – СПб.: ДМК Пресс, 2004. – 525с.
  7. Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование/ Т. Кватрани. – М.: ДМК Пресс, 2001. – 295с.
  8. 1. Ларман К. Применение UML и шаблонов проектирования/ К. Ларман. –М.: Вильямс, 2002. – 340с.
  9. Леоненков А.В. Самоучитель UML/ А.В. Леоненков. –СПб.: BHV-СПб, 200. – 632с.
  10. Мацяшек Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML/ Л.А. Мацяшек. –М.: Вильямс, 2002. – 250с.
  11. Портал магистров Донецкого национального технического университета, раздел – о языке UML.
  12. Логистика: учеб.-М.: ТК Велби, Изд-во Проспект,2006.- 488 с.Титов В.И.
  13. Управления складским технологическим процессом // Научная мысль. 2015. № 2. С. 87-90.Кравчук А.А.

Приложение 1

Рисунок 1 – диаграмма вариантов использования

Рисунок 2 – диаграмма классов

Рисунок 3 – диаграмма последовательности

Рисунок 4 – диаграмма кооперации

Рисунок 5 – диаграмма состояний

Рисунок 6 – диаграмма деятельности

Рисунок 7 – диаграмма компонентов

Рисунок 8 – диаграмма развертывания