Автор: Пользователь скрыл имя, 16 Февраля 2011 в 22:48, курсовая работа
Целью данного курсового проекта является описание унифицированного процесса разработки программного обеспечения для задачи «Учет расчетов с покупателями».
Задачи курсового проекта:
- узнать о требованиях по сертификации программных продуктов, приводить программные продукты к требованиям действующих стандартов;
- рассмотреть теоретические аспекты построения моделей бизнес-процессов по
методологиям IDEF0 и UML;
- построить модели деятельности предприятия по методологии IDEF0;
- разработать систему «Расчеты с покупателями» для формирования отчета о задолженности покупателей за период и на дату;
- построить модель прецедентов, описать прецеденты, построить диаграммы программных классов и диаграмму последовательности для конкретного прецедента в рамках языка моделирования UML.
• диаграммы только для экспозиции (FEO).
Функциональная
модель рассматриваемой задачи была
построена в среде Allfusion Process Modeler.
Диаграммы типа DFD и FEO в данной курсовой
работе рассмотрены не будут.
Рис.
1. Дерево иерархии задач «Деятельность
филиала «РУСКАН Поволжский» ООО «РУСКАН
Дистрибьюшн» по реализации продукции
ROYAL CANIN»
Графический
язык IDEF0 удивительно прост и
Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы.
Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:
левая сторона имеет значение “Вход” (Input);
верхняя сторона имеет значение “Управление” (Control);
правая сторона имеет значение “Выход” (Output);
нижняя сторона имеет значение “Механизм” (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
Рис. 2. Функциональный блок
Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А0”. Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.
После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания.
После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели [1].
Обычно
IDEF0-модели несут в себе сложную
и концентрированную
∙ ограничение количества функциональных блоков на диаграмме тремя-шестью.
Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание.
∙ Ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.
Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.
2.1. Построение и
описание диаграммы
бизнес-процессов
Описание TOP-диаграммы (процесса A-0)
Деятельность филиала «РУСКАН Поволжский» ООО «РУСКАН Дистрибьюшн» по реализации продукции ROYAL CANIN
Входные данные:
Выходные данные:
Управление:
Работа филиала «РУСКАН Поволжский» ООО «РУСКАН Дистрибьюшн» осуществляется на основе Устава Общества, Положения о филиала, федеральных законов и нормативно-правовых актов, Положений по бухгалтерскому учету, Правил внутреннего распорядка.
Механизм:
Описание процесса A0
Бизнес-процессы:
A1: Управление заказами. Покупатель оставляет заявку на продукцию офис-менеджеру. Тот, исходя из остатков продукции на складе и планов отгрузки другим покупателям, составляет план поставок продукции на склад филиала (если продукция на складе в недостаточном количестве) и корректирует план отгрузок.
A2: Управление реализацией.
A3: Решение экономических вопросов. Сюда входит планирование деятельности филиала на предстоящий период, ведение отчетности, управление финансами.
A4:
Управление кадрами. Решаются вопросы
удовлетворения потребностей организации
в специалистах требуемой квалификации,
осуществляется контроль за рациональным
использованием трудовых ресурсов, учитывается
отработанное время по табельным номерам.
Описание процесса A3
Бизнес-процессы:
A31: Бухгалтерский учет. Ведутся все виды учета и отчетности, контроль за сохранностью товарно-материальных ценностей.
A32: Планирование деятельности компании. На основе экономического анализа результатов производственно-хозяйственной деятельности филиала составляется бизнес-план, разрабатываются перспективные планы развития.
A33:
Управление финансами. Осуществляется
контроль за наличием и рациональным использованием
денежных средств, контроль выполнения
плана реализации и прибыли; происходит
учет всех совершаемых денежно-финансовых
операций; анализируется и регулируется
финансовое состояние филиала, оценивается
его платежеспособность.
Описание процесса A31
Бизнес-процессы:
A311: Учета расчетов с покупателями.
A312: Расчет и начисление заработной платы (на основе табельного учета).
A313: Складской контроль наличия и движения материальных ресурсов.
A314:
Контроль состояния и движения основных
средств.
Контекстная
диаграмма и диаграммы
2.2 Описание процесса
«Учет расчетов с покупателями»
Экономико-
Отношения с покупателями возникают в результате сбыта им продукции. Сбыт продукции представляет собой комплекс организационно-технических и финансово-экономических мероприятий, связанных с поставкой и реализацией готовой продукции.
Сбыт может осуществляться в форме отгрузки или отпуска.
Отгрузка – это отправка продукции транспортом потребителю или посреднику. При этом поставщик как субъект отгрузки обычно организует транспортировку.
Отпуск – это сдача продукции грузополучателю, который самостоятельно организует доставку продукции по назначению. В качестве грузополучателей могут выступать как предприятия-потребители, так и посреднические фирмы, которые получают продукцию для дальнейшей перепродажи.
Самостоятельное значение имеет понятие поставка, т.е. фактический отпуск или отгрузка продукции потребителям в соответствии с договорами.
Продукция, подлежащая сбыту, обязательно проходит стадию реализации, так как должна быть не только отправлена продавцом, но и оплачена покупателем. Под реализацией понимается в основном оплата стоимости продукции, получение денежных средств (выручка).
Деятельность филиала «РУСКАН Поволжский» ООО «РУСКАН Дистрибьюшн» - это реализация продукции ROYAL CANIN, производимой ЗАО «РУСКАН».
Процесс
сбыта продукции оформляется
накладными, выписываемыми ответственными
работниками в двух экземплярах
(основание составления
По факту реализации продавец также выписывает счет-фактуру (Приложение 3) и счет (Приложение 4), содержащие реквизиты поставщика и покупателя (наименование, адрес, обслуживающий банк, р/счет и др.), а также другие реквизиты согласно требованиям налогового законодательства РФ (наименования товаров, ед. измерения, количество и цену (по каждой позиции), итоговую сумму счета, сумму НДС, всего к оплате). Выписанные счета-фактуры регистрируются в «Журнале выданных счетов-фактур».
На предприятии используется два варианта оплаты продукции покупателями: предоплата и оплата в течение определенного договором срока с момента отгрузки.
Информация о работе Описание унифицированного процесса разработки программного обеспечения