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

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

     Расчет  за отгруженную продукцию осуществляется по платежному поручению (Приложение 5). В зависимости от условий договора может осуществляться предоплата (датой оплаты считается дата поступления денежных средств на счет «РУСКАН Поволжский») или оплата с отсрочкой платежа. Как правило, с крупными покупателями, с которыми организация сотрудничает длительное время, оформляется договор с отсрочкой платежа, с   мелкими покупателями – договор с предоплатой.

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

Характеристика  задачи:

    1) Место решения: бухгалтерия.

    2) Цель решения: определение задолженности по каждому покупателю и в целом по филиалу.

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

- бухгалтеру – информация о сумме задолженности покупателей на конец периода для составления бухгалтерской отчетности;

- менеджеру по логистике, офис-менеджеру – информация по сумме и срокам возникновения задолженности для планирования работы с покупателями;

- директору филиала – информация по сумме и срокам задолженности для контроля над деятельностью сотрудников филиала.

     4) Периодичность решения: каждые четыре недели, ежемесячно к третьему числу, ежедневно (для оперативного учета), по запросу.

     5) Входные документы:

     - товарно-транспортная накладная;

     - платежное поручение;

     - отчет о дебиторской и кредиторской задолженности по состоянию на дату (за предыдущий период).

     6) Выходные документы:

     - отчет о дебиторской и кредиторской задолженности по состоянию на дату (Приложение 6).

3. Разработка технического  проекта на основе  использования стандарта  «Унифицированный  процесс разработки  ПО»

     3.1. Выявление и анализ  требований к программному  обеспечению для  задачи «Учет расчетов  с покупателями»

          3.1.1 Концепция

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

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

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

     - оперативный учет задолженности покупателей;

     - получение отчетов и другой  документации по состоянию расчетов  с покупателями;

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

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

          Формулировка  проблемы

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

     В решении вышеизложенных проблем  заинтересован бухгалтер и руководитель филиала. 

 

           Характеристика пользователя

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

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

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

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

          Характеристика  продукта

     Предлагаемый  программный продукт предназначен для решения задачи «Учет расчетов с покупателями».

     Функции приложения:

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

     - организация поиска в базе  данных;

     - расчет задолженности покупателя  на дату;

     - контроль полученных результатов  и анализ;

     - формирование отчетов для передачи  в подразделения филиала (административно-хозяйственный  отдел, департамент торговли, директору  филиала. Организационная структура  управления представлена в Приложении 7);

     - настройка системы на конкретного исполнителя;

     - взаимодействие в реальном масштабе  времени с внешними системами. 
3.1.2. Модель прецедентов

     В международном стандарте UP модель прецедентов – результат анализа функциональных требований.

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

     Прецеде́нт (англ. Use Case, а также: вариант использования, сценарий использования) — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними актерами (англ. Actors).

     В понятие «актер» входят люди, компьютерные системы и процессы. Прецедент описывает взаимодействие программной системы с актерами в виде последовательности сообщений.

     Прецеденты  были предложены Иваром Якобсоном и  значительно популяризированы Алистером Коберном.

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

     Диаграмма прецедентов (Рис. 3) – диаграмма, на которой отображаются актеры, прецеденты и связи между ними. Диаграмма прецедентов – основной метод визуализации для модели поведения системы.

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

      Рис. 3. Диаграмма прецедентов 

Развернутое описание процесса (прецедента «Расчет задолженности покупателя»)

     Основной  исполнитель: бухгалтер.

     Заинтересованные  лица и их потребности:

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

     Покупатель. Заинтересован в обеспечении  своей потребности в товарах.

     Бухгалтер. Заинтересован в безошибочном ведении  учета, «прозрачности» и информационности учета.

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

      Предварительные условия:

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

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

      Основной  успешный сценарий:

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

            Расширения (альтернативные потоки событий):

      2а.  Система вышла из строя.

         1. Бухгалтер перезагружает  систему, регистрируется, инициирует  восстановление прерванного состояния.

         2. Система восстанавливает  прерванное состояние.

             2а. Система определяет причину сбоя.

1. Система сообщает об ошибке бухгалтеру, регистрирует ошибку и переходит в начальное состояние.
2. Бухгалтер заново запускает запрос.

     2б.  Система выдает ошибку, не выполняет  запрос.

         1. Бухгалтер устраняет  ошибку (например, исправляет интервал дат). Если самостоятельно устранить ошибку не получается, обращается к работнику ИТ-отдела.