Файл: Проектирование реализации операций бизнес-процесса «Управление денежными потоками» (Характеристика существующих бизнес – процессов).pdf
Добавлен: 26.06.2023
Просмотров: 51
Скачиваний: 2
СОДЕРЖАНИЕ
Выбор комплекса задач автоматизации
Характеристика существующих бизнес – процессов
Обоснование проектных решений по информационному обеспечению.
Обоснование проектных решений по программному обеспечению
2.1. Информационная модель и её описание
2.2. Характеристика нормативно-справочной, входной и оперативной информации
2.3. Характеристика результатной информации
2.4. Общие положения (дерево функций и сценарий диалога)
2.6. Структурная схема пакета (дерево вызова программных модулей)
2.5. Характеристика базы данных
- объем оперативного запоминающего устройства: 128 Мб;
- 750 Мб свободного места на жестком диске;
- CD-ROM;
- тип монитора: SVGA 800х600;
- клавиатура;
- мышь.
Программный продукт «Управление денежными потоками» разрабатывается в программе Microsoft Access 2013.
2 глава. Проектная часть
2.1. Информационная модель и её описание
Формирование информативных технологий рассматривается банком как неприменное ограничение для укрепления собственной конкурентоспособности на рынке предоставления передовых и современных вариантов кредитно-денежных услуг и снабжения безопасного функционирования.
Область информативных технологий банка занимает пространство существенно наибольшее по сопоставлению с инженерно-промышленной службой. Инновационная работа ИТ гарантирует взаимодействие многофункциональных установок системы, сформировывает бизнес-движения подразделений и дает ответ за подходящую реализацию операторной деловитости средством информативных порядков и многофункциональных прибавлений.
Осмотрим ход осуществления управления информативными ресурсами и технологиями в банке, который презентован в рисунке 2.
С1 – план развития ИТ Банка;
С2 – стандарты, регламенты в области ИТ;
С3 – нормативные документы ЦБ РФ;
С4 – инструкции;
I1 – информация о потребности определенной техники;
I2 – информация о поломке техники;
О1 – заявка на приобретение новой техники и программных средств;
О2 - ремонт техники;
М1 – системный администратор;
М2 – помощник системного администратора.
Управление информационными ресурсами и технологиями
Планирование обеспечения потребностей банка
Установка техники и программного обеспечения
Поддержание бесперебойной работы техники и ПО
Контроль работы и обслуживание
М1
I1
I2
О1
О2
С3
С1
I1
М1
С1
С2
О1
I1
I2
I1
I2
М1
М1
М1
О1
О2
О2
О1
С2
С4
С2
С4
Рисунок 2 - IDEF - диаграмма для отдела информационных технологий
С2
С3
М2
С3
М2
С4
С4
М2
М1
М3
2.2. Характеристика нормативно-справочной, входной и оперативной информации
Элементы системы управления денежными потоками, к ним следует отнести финансовые методы и инструменты, нормативно-правовое, информационное и программное обеспечения:
-среди финансовых методов, оказывающих непосредственное воздействие на организацию, динамику и государственными органами; кредитование; финансирование; фондообразование; инвестирование; страхование; налогообложение; факторинг и др.;
- финансовые инструменты объединяют деньги, кредиты, налоги, формы расчетов, инвестиции, цены, векселя и другие инструменты фондового рынка, нормы амортизации, дивиденды, депозиты и
прочие инструменты, состав которых определяется особенностями организации финансов в банке;
- нормативно-правовое обеспечение банка состоит из системы государственных законодательно-нормативных актов, установленных норм и нормативов, устава хозяйствующего субъекта, внутренних приказов и распоряжений, договорной базы.
2.3. Характеристика результатной информации
Процесс «Управление денежными потоками» прежде всего необходим для составления бюджета, хотя и опирается на бухгалтерские данные, включает в себя ряд плохо структурированных решений. Существует три подхода к его составлению: сверху вниз, снизу вверх и смешанный.
- Составление бюджета сверху вниз. При составлении бюджета сверху все начинается с того, что руководство высшего уровня, «разрезая общий пирог средств компании», определяет основные составляющие ее бюджета. Рациональным при этом следует считать, что распределение средств основывается на хорошем понимании руководством долгосрочных целей компании и той роли, которую играют различные ее подразделения в их достижении. Однако вполне резонно, что со стороны менеджеров, работающих на более низких уровнях управления, такой бюджет может показаться нереалистичным, навязанным людьми, далекими от каждодневных потребностей бизнеса.
- Составление бюджета снизу вверх. При составлении бюджета снизу вверх процесс начинается с нижних уровней управления организацией. Исходной посылкой здесь является суждение о том, что лучше всех потребности в ресурсах знают те, кто непосредственно с этими ресурсами работает. При этом высшее руководство нередко упрекает менеджеров низших уровней в нереалистично завышенных потребностях. Следует заметить, что часто так оно и бывает, поскольку менеджеры, зная, что их запросы будут безжалостно уменьшены руководством, искусственно их завышают на предварительной стадии.
- Cмешанный подход к составлению бюджета появился как следствие признания недостатков двух описанных выше подходов. В основу его положено участие в распределении средств всех заинтересованных в них подразделений и уровней управления. Центральную роль в процедурах согласования интересов играют менеджеры среднего уровня управления, интересы которых находятся между долгосрочными интересами высшего руководства и сиюминутными потребностями низких уровней управления.
Рисунок 3 - Контекстная диаграмма системы «Управление денежными потоками
Основным процессом является Электронный банкинг, т.к. вся деятельность системы направлена именно на это. Внешними сущностями являются Операционист и Клиент. Для регистрации в системе клиент вводит соответствующую информацию, после имеет возможность передавать операционисту электронные Документы и отправлять Запросы на отзыв документов, что отражено на диаграмме в виде информационных потоков. Получив документы заемщика, обработанные системой по формализованным правилам, операционист начинает их обработку по не формализованным правилам. Отправляет документы в РКЦ НБ, где решается вопрос об исполнении или неисполнении документа. Так же операционист может отказать в передаче последнего в РКЦ.
После создания контекстной диаграммы, я постаралась рассмотреть
функции системы более подробно и построить диаграмму детализации первого уровня.
В результате декомпозиции была получена диаграмма первого уровня.
Рисунок 4 - Диаграмма детализации первого уровня системы «Управление денежными потоками»
2.4. Общие положения (дерево функций и сценарий диалога)
Представим дерево функций диаграммой.
Рисунок 5 – Дерево функций процесса «Управление денежными потоками»
Use case diagram (диаграммы прецедентов) - позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.
Исходя из поиска ответов на следующие вопросы:
Кто взаимодействует с системой или использует систему?
Кто передает или принимает информацию в/из системы?
Кто является внешним по отношению к системе?
Я выявила следующих субъектов.
Рисунок 6 - Субъекты системы
Прецедент представляет собой целостный набор функций, имеющих определенную ценность для субъекта. Прецеденты можно вывести в результате определения задач для субъекта. Для этого следует задаться вопросом: «Каковы обязанности субъекта по отношению к системе и чего он ожидает от системы?»
Каждый вариант использования (прецедент) определяет набор действий, совершаемых системой при диалоге с актером. При этом ничего не говорится о том, как конкретно будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования.
Прецедент изображается в виде эллипса, внутри или ниже которого помещается имя прецедента.
Рисунок 7 - Прецеденты системы
Диаграмма прецедентов приписывает прецеденты к субъектам. Она также позволяет пользователю установить отношения между прецедентами, конечно, если такие отношения существуют.
Диаграмма прецедентов – это наглядное представление субъектов и прецедентов вместе с любыми дополнительными определениями и спецификациями. На данном виде диаграмм отображаются основные функции, которые выполняет система, лица, оказывающие влияния на систему – внешние сущности, а также связи между ними. Диаграмма прецедентов представляет собой не просто некую схему, а является полностью документированной моделью предполагаемого поведения системы.
Достоинства модели вариантов использования заключаются в том, что она:
- определяет пользователей и границы системы;
- определяет системный интерфейс;
- удобна для общения пользователей с разработчиками;
- используется для написания тестов;
- является основой для написания пользовательской документации;
- хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).
Рисунок 8.
Варианты использования и субъекты, выделенные для данной модели, можно представить в виде следующей диаграммы прецедентов:
Диаграмма прецедентов представляет собой не просто некую схему, а является полностью документированной моделью предполагаемого поведения системы. Это вид диаграмм особенно важен при организации и моделирования поведения системы. На них представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Актер – это роль, которую пользователь играет по отношению к системе.
Между субъектами и вариантами использования могут быть различные виды взаимодействия. Так, из построенной диаграммы видно, что Клиент банка инициирует различные варианты использования: Регистрация, Аутентификация, Получение выписки, Отзыв документа, Создание нового письма и так далее.. Операционист также может инициировать варианты использования, например, Проверка новых поступлений, Регистрация, Аутентификация, Обработка документа и т.д.
Рисунок 9 - Диаграмма прецедентов для субъекта Клиент банка
Остановлюсь подробнее на некоторых отношениях между вариантами использования.
Следует прокомментировать некоторые особенно «привлекательные» отношения между вариантами использования.
Так, смысл отношения «include» состоит в том, что Создание платежного документа включает в себя Создание платежного поручения и Создание платежного требования. Также, прецедент Подписать документ ЭЦП выполняется только в рамках Создания платежного документа, Создания нового письма или Отзыва документа.
Смысл же связи <<extend>> в том, что прецедент, например, Создание платежного документа «расширяется» вариантом использования Сохранение документа, которой в свою очередь расширяется прецедентом Проверка реквизитов документа. Я объясняю это тем, что сохранить документ можно только проверенный системой на наличие ошибок. Распечатка перечня документов за определенный период «расширяет» прецедент Получение выписки. Таким образом, связь <<extend>> говорит о выполнении того или иного прецедента в зависимости от определенных условий.
Рисунок 10 – Сценарий диалога
2.6. Структурная схема пакета (дерево вызова программных модулей)
Модели видов деятельности (Activity Diagram) строятся для описания общей последовательности действий для нескольких объектов и вариантов использования. На диаграммах этого типа представляются переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм относится к динамическим представлениям системы, и является наиболее полезным при моделировании ее функционирования, так как отражает передачу потока управления между объектами.