汽车金融风险控制系统分析.docVIP

汽车金融服务风险控制系统 一、开发项目的风险背景 伴随着软件开发技术的不断更新、软件数量的增多、软件复杂程度不断加大、客户对产品的要求也在不断的提高，随之而来的是软件开发项目给软件开发企业和需求企业带来的巨大风险。软件开发项目的成功与否会直接影响到公司的生存。这对软件开发企业来讲应该是更大的难题。一方面是业务需求更加复杂。人们对软件质量和用途的期望大幅度提高，对业务系统的要求也越来越挑剔。另一方面是开发成本不断缩减。在此形势下，风险管理与控制已成为软件开发项目成败的关键。 软件开发项目由于其具有连续性、复杂性、少参照性，无标准规范等特点，其风险程度较高。目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识，缺少进行系统、有效的度量和评价的手段。据有调查数据显示，有15—35%的软件项目中途被取消，剩下的项目不是超期就是超出预算或是无法达到预期目标。另外，软件项目因风险控制和管理原因失败的约占90% ，可见，软件风险控制与管理在目前的软件开发项目中的重要性。 交易数据系统交易数据系统存储了银行进行的所有交易。它已经配置为在纽约的交易关闭时间（下午5 点）生成一个XML 输出文件。输出包括银行进行的每一次交易的以下信息：??交易ID；??日期；??当前的美元交易价格；??交易对手ID。 参考数据系统参考数据系统维护了银行需要的所有参考数据。这包括了交易对手的信息，每一个都代表一个个体、一家银行等。它也生成XML 输出文件，包括了每个交易对手的基本信息。一个新的全组织参考数据系统将在未来3 个月内完工，而当前的系统最终将停用。 功能需求以下是新的风险系统的高层次功能需求：(1) 从交易数据系统导入交易数据；(2) 从参考数据系统导入交易对手数据；(3) 合并两个数据集，用交易对手的信息丰富交易数据；(4) 对每个交易对手计算银行面临的风险；(5) 生成一个可以导入微软Excel 的报表，包含银行所有已知的交易对手的风险指数；(6) 在新加坡的下一个交易日开始（上午9 点）之前将报表分发给业务用户；(7) 为业务用户子集提供一种配置和维护风险计算使用的外部参数的方法。非功能需求以下是新的风险系统的非功能需求。 性能??新加坡在每个业务日的当地时间上午9 点开市，风险报表必须在此前生成。 可伸缩性??系统必须有能力处理未来5 年的交易量。??交易数据系统的导出文件包括大约5000 次交易，预计现在每天将有10 次额外的交易。??参考数据系统的交易对手导出文件包括大约2 万个交易对手，增长可以忽略不计。??全世界有40~50 个业务用户需要访问报表。 可用性??风险报表应该随时对用户可用，但少量的停机（每天不超过30 分钟）是可以忍受的。 故障转移?人工故障转移对所有的系统组件都足够了，能够满足可用性目标。 安全性??这个系统必须遵循仅限认证和授权用户访问的银行政策。 ??报表必须只分发给授权用户。??只允许授权用户的子集修改风险计算使用的参数。??尽管也不错，但没有单点登录的需求（比如，与ActiveDirectory、LDAP 等的整合）。??所有对系统和报表的访问都将在银行的全球网络范围内。 审计??以下事件必须记录在系统审计日志中：????生成报表；????修改风险计算参数。??用于风险计算的输入数据必须是可理解的。 容错和恢复??如果可能，系统应采取适当的步骤从错误中恢复，但所有的错误都应被记录。??影响完成交易对手风险计算的错误都应被记录，流程应继续。 国际化和本地化??所有用户界面都将只用英语呈现。??所有报表都将只用英语呈现。??所有交易价格和风险指数都将只用美元呈现。 监测和管理??如遇下列情况，简单网络管理协议（SNMP）陷阱应被发送至银行的中心监测服务：????系统组件的致命错误；????新加坡时间上午9 点前未能生成报表。 数据保存和归档??风险计算过程使用的输入文件必须保留1 年。互操作性??现有数据系统的接口应该遵守并使用现有的数据格式。 二、 软件开发项目的风险来源及对项目成败的影响 软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题，以及由这些问题而产生的对软件项目的影响。软件项目风险经常会涉及许多方面，如：缺乏用户的参与，缺少高级管理层的支持，含糊的要求，没有计划和管理等，总体概括下来应该由五大方面。 1、 产品规模风险 项目的风险是与产品的规模成正比的。与软件规模相关的常见风险因素有：(1)估算产品规模的方法(包括：代码行，文件数，功能点等)，(2)产品规模估算的信任度，(3)产品规模与以前产品规模平均值的偏差，(4)产品的用户数