Диаграммы UML для бизнес-процесса "Кредитование физических лиц"(Прочитано 20919 раз)
Доброго времени суток!

Мне, как новичку, необходима помощь профессионалов,то есть вас, дорогие аналитики!
 
Сейчас основная моя деятельность--это написание курсовой работы. И если с диаграммой IDEF0,DFD, ER-диаграммой у меня не возникло никаких сложностей, то при выполнении пункта пункта задания  UML  они возникли...

Суть моей проблемы заключается в следующем:  я составила диаграмму прецедентов для процесса "Кредитование ФЛ" (Приложение 1) Следующий пункт- это текстовое  описание четырех вариантов использования в соответствии с методикой UML ( Оформить кредитную заявку, принять решение о возможности кредитования (анализ кредитной заявки включает : анализ документов заемщика на полноту и достоверность, оценку кредитоспособности клиента, проверку кредитной истории и оценку кредитных рисков банка), оформить кредитный договор, составить график платежей по кредиту. Вот в нем и возникли проблемы. :-\ Пожалуйста, помогите!



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

Прецеденты предполагают, что вся эта деятельность автоматизируется (или будет автоматизироваться) какой-то системой? Или вы просто описываете бизнес-процессы с помощью диаграмм?
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



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

Прецеденты предполагают, что вся эта деятельность автоматизируется (или будет автоматизироваться) какой-то системой? Или вы просто описываете бизнес-процессы с помощью диаграмм?

Спасибо за отклик, уважаемый аналитик!
Я учусь по IT-специальности. Прецеденты предполагают, что деятельность будет автоматизироваться. (Собственно, цель курсовой--спроектировать АИС для кредитования физических лиц)



Спасибо за отклик, уважаемый аналитик!
Я учусь по IT-специальности. Прецеденты предполагают, что деятельность будет автоматизироваться. (Собственно, цель курсовой--спроектировать АИС для кредитования физических лиц)

С помощью вариантов использования (прецедентов) описывается порядок взаимодействия пользователей с системой. Это пошаговая процедура, в которой каждый шаг выполняет кто-то из участников (пользователь или система). Если вам давали шаблон или пример описания прецедентов, воспользуйтесь им. Если не давали, то можно использовать табличный шаблон, например, как здесь: http://www.intuit.ru/studies/courses/32/32/lecture/1006?page=2

Я правильно понимаю, что в вашей модели предполагается, что клиент будет одним из пользователей и будет обращаться к системе для оформления кредитной заявки и для оплаты?

Если кредитную заявку формирует сам клиент, то тут можно пофантазировать, придумав диалог с системой, включающий шаги: выбор цели кредита, выбор кредитного продукта, выбор параметров кредита (срок и сумма), загрузка копий документов. Посмотрите по сайтам банков, как это может выглядеть (вот сбербанк, например: http://www.sberbank.ru/moscowoblast/ru/person/credits/).

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

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

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

Ну и про альтернативные сценарии для каждого прецедента не забывайте, конечно - когда что-то идёт не так (у клиента плохая история, договор не найден, паспорт чужой и т. п.)
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Если кредитную заявку формирует сам клиент, то тут можно пофантазировать, придумав диалог с системой

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



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

Фантазировать человеческие и бизнес-взаимодействия через ДВИ имхо не путь джедая:)



Фантазировать человеческие и бизнес-взаимодействия через ДВИ имхо не путь джедая:)

Почему? Настоящему индейцу завсегда везде... Т.е., какая разница? (мы же не про ПО, а про АИС)



Фантазировать человеческие и бизнес-взаимодействия через ДВИ имхо не путь джедая:)

Нет, здесь речь не о ДВИ, а о самом варианте использования.

Если бы речь шла о разработке реальной АБС, то, конечно, вместо фантазий нужно было бы описывать настоящие бизнес-процессы кредитного отдела.

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Почему? Настоящему индейцу завсегда везде... Т.е., какая разница? (мы же не про ПО, а про АИС)

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

Если бы речь шла о разработке реальной АБС, то, конечно, вместо фантазий нужно было бы описывать настоящие бизнес-процессы кредитного отдела.

Я так понял это и есть цель автора "(Собственно, цель курсовой--спроектировать АИС для кредитования физических лиц) "



Я так понял это и есть цель автора "(Собственно, цель курсовой--спроектировать АИС для кредитования физических лиц) "

Для курсовой по it-специальности слишком амбициозная цель. :) Я же поэтому и начал с вопроса про специальность. То, что перечислено в ДВИ - это даже не вершина айсберга, а её отражение в маленьком (и отчасти кривеньком) зеркальце. Поэтому я думаю, что с большой вероятностью цель курсовой - проверка умения использовать нотации, а не знания предметной области банковского дела.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



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

Памятуя о том, что автоматизированная система = железо + ПО + люди, в рамки задачи "описания АИС" такие размышления укладываются идеально. Да и нотация вроде не сильно ограниченная.
Другое дело, что нужно быть махровым садистом, чтобы взрывать мозг студента объективной реальностью. Куда гуманнее всю АС при постановке задачи свести к одному только ПО (в простонародье - "Системе").



Куда гуманнее всю АС при постановке задачи свести к одному только ПО (в простонародье - "Системе").
И я о том же



Выскажите,пожалуйста, свое мнение по данной работе...



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

Еще, рекомендую не злоупотреблять направленными стрелочками. Это вполне конкретные виды связи в UML и если вы не умеете их пока использовать, лучше вообще откажитесь от них.
Примеры диаграмм и видов связей можно посмотреть вот тут: http://www.uml-diagrams.org/

PS: И в следующий раз, прикладывайте диаграмму как картинку к посту, так будет проще всем.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19