Автор: Пользователь скрыл имя, 16 Февраля 2011 в 22:48, курсовая работа
Целью данного курсового проекта является описание унифицированного процесса разработки программного обеспечения для задачи «Учет расчетов с покупателями».
Задачи курсового проекта:
- узнать о требованиях по сертификации программных продуктов, приводить программные продукты к требованиям действующих стандартов;
- рассмотреть теоретические аспекты построения моделей бизнес-процессов по
методологиям IDEF0 и UML;
- построить модели деятельности предприятия по методологии IDEF0;
- разработать систему «Расчеты с покупателями» для формирования отчета о задолженности покупателей за период и на дату;
- построить модель прецедентов, описать прецеденты, построить диаграммы программных классов и диаграмму последовательности для конкретного прецедента в рамках языка моделирования UML.
В случае предоплаты счет для оплаты выписывается на основании заявки покупателя. Реализация осуществляется после поступления денежных средств на р/с продавца, о чем свидетельствует выписка банка. Во втором случае оплата должна поступить в течение 3-15 дней с момента отгрузки.
Расчет
за отгруженную продукцию
В договоре предусмотрены штрафные санкции, но фактически начисление штрафов не производится ввиду нематериальности сумм и специфики условий договора.
Характеристика задачи:
1) Место решения: бухгалтерия.
2) Цель решения: определение задолженности по каждому покупателю и в целом по филиалу.
3) Назначение задачи и потребители результатной информации: предоставление данных по учету расчетов с покупателями необходимо
- бухгалтеру – информация о сумме задолженности покупателей на конец периода для составления бухгалтерской отчетности;
- менеджеру по логистике, офис-менеджеру – информация по сумме и срокам возникновения задолженности для планирования работы с покупателями;
- директору филиала – информация по сумме и срокам задолженности для контроля над деятельностью сотрудников филиала.
4) Периодичность решения: каждые четыре недели, ежемесячно к третьему числу, ежедневно (для оперативного учета), по запросу.
5) Входные документы:
-
товарно-транспортная
- платежное поручение;
- отчет о дебиторской и кредиторской задолженности по состоянию на дату (за предыдущий период).
6) Выходные документы:
- отчет о дебиторской и кредиторской задолженности по состоянию на дату (Приложение 6).
3. Разработка технического проекта на основе использования стандарта «Унифицированный процесс разработки ПО»
3.1. Выявление и анализ требований к программному обеспечению для задачи «Учет расчетов с покупателями»
3.1.1 Концепция
Цель создания курсового проекта – собрать, проанализировать и представить формализованное описание высокоуровневых потребностей и возможностей системы учета расчетов с покупателями. Подробное изложение того, как система учета расчетов с покупателями выполняет эти потребности, представлено в прецедентах и дополнительных спецификациях.
Потребности пользователя:
-
регистрация, накопление и
- оперативный учет задолженности покупателей;
-
получение отчетов и другой
документации по состоянию
-
анализ полученной информации
для планирования поступления
денежных средств,
-
получение стандартных форм и
отчетов для предоставления в
органы финансового контроля
и налогообложения.
Формулировка проблемы
Существующая система учета расчетов с покупателями не обладает гибкостью, неустойчива к сбоям, не обеспечивает интеграцию с внешними системами. Существует несоответствие программного обеспечения экономическим и информационным потребностям филиала. В результате происходит снижение точности и своевременности обработки данных и, как следствие, к затруднению планирования деятельности филиала, что сказывается на эффективности функционирования.
В
решении вышеизложенных проблем
заинтересован бухгалтер и
Характеристика пользователя
Программа предназначена для пользователей невысокой квалификации. Для ее использования не требуется высоких знаний в области компьютерных техники. Программа понятна и проста в эксплуатации.
Пользователь должен обладать знаниями в области бухгалтерского учета (конкретнее: организации расчетов с покупателями), иметь элементарные навыки работы с компьютером и офисной техникой (принтером, сканером, факсом).
Предусмотрено два типа пользователей: оператор и бухгалтер по учету расчетов с покупателями, возможно их слияние. Работа бухгалтера чаще всего включает множество рутинных операций. Применение программы позволит максимально уменьшить ручной труд. Основные обязанности бухгалтера сводятся к вводу информации с первичных документов в базу данных и формированию выходных документов.
Ввод
– узкое место в
Характеристика продукта
Предлагаемый
программный продукт
Функции приложения:
-
организация ввода достоверной
информации в режиме реального
времени (включает в себя
- организация поиска в базе данных;
-
расчет задолженности
-
контроль полученных
-
формирование отчетов для
- настройка системы на конкретного исполнителя;
-
взаимодействие в реальном
3.1.2. Модель прецедентов
В международном стандарте UP модель прецедентов – результат анализа функциональных требований.
На основе языка UML модель прецедентов включает в себя диаграмму прецедентов и описание каждого прецедента в отдельности с соответствующими диаграммами последовательности (в рамках данного курсового проекта будет развернуто описан только один прецедент).
Прецеде́нт (англ. Use Case, а также: вариант использования, сценарий использования) — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними актерами (англ. Actors).
В понятие «актер» входят люди, компьютерные системы и процессы. Прецедент описывает взаимодействие программной системы с актерами в виде последовательности сообщений.
Прецеденты были предложены Иваром Якобсоном и значительно популяризированы Алистером Коберном.
Прецеденты служат для документирования функциональных требований к программным системам. Прецедент описывает некоторый целостный фрагмент поведения системы, не вдаваясь при этом в особенности внутренней структуры субъекта. Определение прецедента содержит все свойственные ему виды поведения: основную последовательность, различные варианты стандартного поведения и различные исключительные ситуации с указанием ответной реакции на них. С точки зрения пользователя некоторые из видов поведения выглядят как ошибочные. Однако для системы ошибочная ситуация является одним из вариантов поведения, который должен быть описан и обработан.
Диаграмма прецедентов (Рис. 3) – диаграмма, на которой отображаются актеры, прецеденты и связи между ними. Диаграмма прецедентов – основной метод визуализации для модели поведения системы.
Диаграмма
прецедентов позволяет
Рис.
3. Диаграмма прецедентов
Развернутое описание процесса (прецедента «Расчет задолженности покупателя»)
Основной исполнитель: бухгалтер.
Заинтересованные лица и их потребности:
Организация.
Заинтересована в максимальном объеме
реализации товаров и своевременном
поступлении средств от покупателей,
а также в своевременной
Покупатель. Заинтересован в обеспечении своей потребности в товарах.
Бухгалтер. Заинтересован в безошибочном ведении учета, «прозрачности» и информационности учета.
Торговый представитель. Заинтересован в максимальной отгрузке продукции и в минимальной просрочке платежа покупателем (своевременном поступлении средств от покупателя) для получения бонусов.
Предварительные условия:
Результаты: введена первичная информация по реализации, первичная информация по оплате товаров для расчета задолженности покупателей за расчетный месяц, определена задолженность за расчетный период.
Основной успешный сценарий:
Расширения (альтернативные потоки событий):
2а. Система вышла из строя.
1. Бухгалтер перезагружает
систему, регистрируется, инициирует
восстановление прерванного
2. Система восстанавливает прерванное состояние.
2а. Система определяет причину сбоя.
2б. Система выдает ошибку, не выполняет запрос.
1. Бухгалтер устраняет ошибку (например, исправляет интервал дат). Если самостоятельно устранить ошибку не получается, обращается к работнику ИТ-отдела.
Информация о работе Описание унифицированного процесса разработки программного обеспечения