《商业银行新产品开发的风险点及其控制.docx》由会员分享，可在线阅读，更多相关《商业银行新产品开发的风险点及其控制.docx（9页珍藏版）》请在三一办公上搜索。
1、 商业银行新产品开发的风险点及其控制新产品开发的风险主要有项目风险、技术风险、商业风险等。其中项目风险是指在预算、进度、人员和组织、资源、需求等方面存在的潜在问题可能给项目开发带来的风险，如项目复杂性、规模和结构等都可构成风险因素。技术风险指在设计、实现、接口、检验和维护方面存在的潜在问题可能给项目带来的风险，也包括规格说明的多义性、技术上的不确定性、技术陈旧、新技术的不成熟所带来的风险。技术风险之所以出现是由于问题的解决比所预想的要复杂。而商业风险包括以下五种：（1）开发的程序虽然很优秀但并非市场所需（市场风险）；（2）开发的产品不适合整个软件产品原意图；（3）市场推广部门不知如何推广该新产
2、品；（4）上级部门不再支持该项目的开发；（5）预算或相关人员不再支持项目的开发（预算风险）。 新产品开发风险分布在新产品开发过程中从新产品开发可行性论证阶段、产品设计和需求分析阶段、需求设计阶段、程序编写阶段、程序测试验收阶段、试点推广阶段到产品运行维护阶段的各个阶段，控制新产品开发风险的最好办法就是在产品开发的初期就将风险控制要求考虑进去，并在开发过程每一阶段对可能存在的风险点进行控制，并在每一阶段的终点，设置检查点进行检查。 成下面就分阶段对风险点进行分析并制订相应的控制措施。 一、可行性论证阶段 可行性论证阶段主要是对产品开发项目从市场、技术、管理和经济效益等诸方面进行可行性论证，并给出
3、系统的总体功能、性能、可靠性以及接口方面的初步要求，对可利用的资源、成本、可取得的效益、开发进度做出估计，编写可行性论证报告，并提交有关部门通过。 （一）风险点分析 可行性论证阶段主要的风险点有： 1、在论证中对影响新产品开发的各种因素考虑不够周全； 2、在论证中虽然对影响新产品开发的各种因素作了全面考虑，但在对其中的某些因素作可行性分析时忽略了某些重要方面，或者作了错误的分析； 3、市场调研工作做得不够细致，或根本未做市场调研工作，或对调研中存在的市场风险作了错误的分析，对市场趋势作了错误的推定； 4、设计的产品功能在技术上无法实现； 5、论证过程有人为干预，使得论证过程不够科学和客观。 （
4、二）风险控制 1、建立科学合理的新产品开发论证管理制度： （1）任何新产品开发项目必须经过严格的可行性论证才能上马； （2）新产品开发项目必须经过四个阶段：调查研究阶段；部室内部讨论阶段；相关部门业务骨干论证阶段；开发委会议讨论阶段。重大开发项目尚须经由行外专家组讨论。任何项目未经委员会会议讨论通过，不得上马。 （3）项目论证书的内容必须包括以下八个方面内容：市场可行性论证；技术可行性论证；竞争对手同类产品开发情况分析；产品设计思想；产品功能设计；风险控制；成本效益分析；开发计划（开发周期及费用预估）。 （4）市场调研应建有标准化档案，对重大课题的市场调研时间应在一个月以上。 （5）新产品项目
5、可行性论证内部质询制度。即在部门讨论阶段，相关部门业务骨干论证阶段和开发委会议论证阶段应有30分钟1小时的时间，由与会人员向项目论证小组成员轮流提问。 2、人员条件 （1）项目论证小组至少在两人以上。其中重大开发项目论证小组人数应在5人以上，并建立内部正反论证小组，正方主要从正面进行论证，反方主要从反面进行论证，正方和反方的意见都必须提交创新委员会讨论。 （2）相关部室业务骨干论证会必须有五个以上的部门的业务骨干参加，其中法律事务部和风险部的业务骨干必须参加，并由与会三分之二以上的业务骨干通过。 （3）参加论证会的委员会成员不得少于委员全体成员的三分之二。 二、产品设计和需求分析阶段 根据产品
6、开发可行性论证阶段提出的各类需求，深入描述待开发产品的功能和性能、操作流程等，确定产品设计的限制，定义系统的其它有效性需求，在此基础上编写出完备的产品设计方案和系统需求设计书（或系统功能设计书）并提交有关部门通过。 （一）风险点分析 1、对市场需求的提炼有偏差，相应的功能需求不适合市场需要； 2、设计的产品流程在业务管理方面有漏洞，操作流程中存在较大的风险隐患； 3、对产品运营后的后续管理功能在产品设计时考虑不多或根本未予考虑； 4、没有合理吸收各方的正确意见； 5、对产品需求的分析不够全面。 （二）风险控制 1、建立新产品设计和需求分析三级咨询制度。 （1）新产品设计和需求分析方案必须经过基
7、层网点咨询、业务部门咨询、委员会咨询三个层面的咨询，才能进入下一阶段的开发。 （2）各咨询部门或网点必须在接到新产品设计和需求分析方案五个工作日内向项目小组提出书面意见，对所涉及的新产品作出总体评价并指出其中尚需改进之处。 （3）上述咨询意见经项目小组合理吸引后交风险部存档保管，以新产品开发出来后投入运行的实际效果确定奖惩。 2、新产品需求分析的内容必须包括： （1）功能需求； （2）性能需求，即对产品开发的技术性指标； （3）环境需求，即对开发出的产品运行环境的需求； （4）可靠性需求，应对重要运行部件提出可靠性要求； （5）安全保密需求； （6）用户界面需求； （7）资源使用需求，是指开发
8、产品运行时所需数据、软件、内层空间等各项资源； （8）软件成本消耗与开发进度需求； （9）预估系统以后可能达到的目标。 3、成立专门的项目开发小组对产品进行设计，项目小组成员应由产品开发部门、科技部和各相关业务部门人员组成，其中新产品开发牵头部门应为相应对口业务管理部门。 4、产品的设计和需求分析必须包括风险控制和后期管理的内容。 5、审计部门派专人负责对设计出的产品功能与可行性论证报告中的市场功能需求作一致性检查。若两者不一致，要求项目小组说明原因。若项目小组所提交原因审计部门认为不够充分，审计部门应将此点提交委员会讨论。 6、产品开发人员在进行产品需求分析时必须做到：（1）必须能够表达和理
9、解问题的数据域和功能域。（2）必须按自顶向下、逐层分解的方式对问题进行分解和不断细化。（3）要给出系统的逻辑视图和物理视图。 三、需求设计阶段 此为新产品开发的关键阶段，因为在需求设计阶段，开发人员将已确定的各项需求转换为一个相应的体系结构。结构中的每一组成部份都是意义明确的模块，每个模块都和某些需求相对应，并进而对每一个模块要完成的工作进行具体的描述，为源程序编写打下基础。所有设计中的考虑都应以设计说明书的形式加以描述，以供后续开发需求并提交评审。 （一）风险点分析 1、部份模块没有得到清晰的定义； 2、模块之间的关系处理不当； 3、并不是所有的需求都能找到与之对应的模块； 4、对每一模块中
10、工作任务的具体描述与系统需求说明书中的功能需求间在内容上存在不一致之处。 5、在需求设计中对业务操作关系作了错误的界定。 （二）风险控制 1、建立需求设计内部评审制度，相关业务部门应对需求设计书写出书面意见交风险部存档保管，视新产品推出后的实现运行效果确定奖惩； 2、由审计部门专门成立需求设计的审计小组，对需求设计与需求分析的一致性进行检验，在检验中应注意以下五个方面： （1）全部模块定义是否清晰； （2）全部业务操作关系是否正确； （3）模块之间的关系处理是否得当； （4）模块与需求设计书上的功能是否存在正确的对应关系； （5）每一模块对相应工作任务是否作了与需求设计书上一致的描述。 3、项
11、目开发小组在人员配备上应避免一人单独作战，应至少由两人以上在一起合作进行需求设计以尽量减少可能出现的错误。 4、程序分析人员在进行需求设计时应与产品设计人员或用户进行充分的交流，其定稿的需求设计书得到产品设计人员或用户的书面认可。否则，不得进行程序编写阶段。 四、程序编写阶段 程序设计即将需求设计转换成计算要可以接受的程序代码，即写成以某一种特定程序设计语言表示的源程序清单。 （一）风险点分析 1、编写出的程序与需求设计不一致； 2、程序中BUG较多； 3、程序内在结构不易识别 4、外包项目开发出后不能使用或无法进行独立的维护。 （二）风险控制 1、建立程序编写的分步文档说明制度，要求编程者严
12、格按照编程步骤展开工作，并将每一步骤以标准文档形式附加说明交档案部门存档管理。 2、制订严格的程序编写进度计划，分阶段对程序编写情况进行检查和局部测试。 3、在组织较为复杂的大型程序编写工作时，应将程序按功能模块进行分解，每一模块由一编写小组负责，并由项目负责人在各编写小组之间进行协调。模块编写好后，先对单个的小模块进行测试，待所有小模块测试通过后，再对整个系统进行测试。4、定期举行项目状态会议。在会上由每一位程序编写人员报告他的进展和所遇到的问题。 5、项目负责人和的新产品开发人员应经常与开发人员进行交流，以得到他们对开发进展和刚冒头问题的客观评价。 6、人员配备 （1）应用“软件人员成熟度
13、模型”对软件开发人员进行定级和合理分工。 （2）编写中小型程序时，程序开发小组应采用主程序员制小组形式。即小组的核心由1位主程序员（必须严格挑选），15位技术员，1位后援工程师组成。主程序员负责小组全部技术活动的计划、协调与审查工作，还负责设计和实现项目中的关键部份。技术员负责项目的具体分析与开发，以及文档资料的编写工作。后援工程师协助和支持主程序员的工作，为主程序员提供咨询，也做部份分析、设计和实现工作，并在必要时代替主程序员工作，以使项目进行下去。 编写大型程序时应采用层次式小组，组内人员分为三级：项目负责人（1人）负责工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。他直接领
14、导23名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。 7、若项目外包，应经委员会同意，公开举行项目软件开发招标活动找到正式外包单位，并应与其签订开发任务明确，检验标准统一的开发协议。 在外包单位开发过程中，科技部门应派开发人员与外包单位人员合作开发，以便外包单位能充分理解开发项目和商业银行内部电脑系统特点，并为项目开发好后的后续维护工作打下基础。 8、建立双阶梯提升制度：即软件开发人员的提升应分别按技术职务和管理职务进行，不能混在一起。 五、程序测试验收阶段 程序测试本身是控制项目开发风险和保障软件质量的重要手段，其主要方式是在设计测试用例的基础上检验软件的各个部份。首先是进行单
15、元测试，查找各模块在功能和结构上存在的问题并加以纠正；其次是进行组装测试，将已测试过的柜块按一定顺序组装起来；最后按规定的各项需求，逐渐进行有效性测试，决定已开发软件是否合适，能否交付使用。 （一）风险点分析 1、测试未能发现程序中的重大错误，给安全运行留下隐患。 2、埋有的逻辑炸弹未能发现。 3、测试未能按严格的步骤走完。 4、测试中出现的问题未引起足够重视。 5、测试受到个别人意志的左右。 （二）风险控制 1、坚持若干测试原则：尽早地和不断地进行测试；程序员应避免检查自己的程序；在设计测试用例时，应当包括合理的输入条件和不合理的输入条件；充分注意测试中的群集现象；对每一个测试结果作全面检查
16、。 2、严格按测试内容和步骤操作： （1）单元测试，测试内容应包括：模块接口、局部数据结构、独立路径、错误处理和边界条件，以消除程序模块内部在逻辑上和功能上的错误和缺陷； （2）集成（组装）测试，主要检测以下内容： 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； 一个模块的功能是否会对另一个模块的功能产生不利影响； 各个子功能组合起来，能否达到预期要求的父功能； 全局数据结构是否有问题； 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度； 排除子系统（或系统）结构上的错误。 （3）确认测试。确认测试阶段首先要进行有效性测试以及软件配置复审，然后进行验收测试和安装测试，在通
17、过专家鉴定后，才能将软件交付使用。该测试主要确定软件的功能和性能与需求是否有差距。 （4）系统测试。即从系统整体出发，看系统是否满足要求。 3、运用黑盒测试，以证明每个实现了的功能是否符合要求；运用白盒测试，以证明每种内部操作是否符合设计规格要求，所有内部成份是否已经过检查 4、整个测试过程必须建立完整的文档和测试评价制度。 六、试点推广阶段 试点推广是指新产品测试通过后，先作局部试点，然后将新产品全面推向市场。 （一）风险点分析 1、新产品未经过严格的测试，匆忙上马。 2、培训工作没有跟上，业务人员在使用产品中发生失误。 3、操作规程、管理办法以及合同、协议等法律文书等有漏洞。 4、同一产品
18、的各种文书材料对产品的功能或操作界定不一。 5、在试点中发现的问题未引起市场推广人员和产品开发人员的注意。 6、在新产品推广过程中发生失误，给新产品的形象带来影响。 7、新产品开发或推广半途而废。 （二）风险控制 1、新产品未经严格的测试并经委员会同意，不得随意上马。 2、对新产品操作人员必须进行专门的培训，培训后应举行笔试和上机操作考试，凡考试未通过者，不得上岗操作新产品。对大的产品项目的培训时间必须达到30小时以上，并且上机教学时间不得少于8小时。 3、有关新产品的各种操作规程、管理办法以及合同、协议在使用前应统一由法律事务部和风险管理部进行审查。 4、建立新产品试点推广中的推广责任人制度
19、。责任人必须经常与试点推广网点保持联系，在第一时间发现新产品在试点推广中出现的问题，小问题立即予以解决，重大问题必须向所在部门领导汇报。由所在部门领导确定该问题是否送委员会会议讨论。 5、若新产品在试点推广过程中发生失误，有关部门和业务操作部门应在第一时间将失误纠正过来，力求减少失误给新产品形象带来的不良影响，并就此事件进行分析总结，以免重蹈覆辙。 6、凡经委员会通过的新产品开发项目，停止开发或推广必须报委员会批准。 七、运行维护阶段 运行维护是交付使用的产品投入正式使用后，由于各种原因，需要对其进行维护和修改。 （一）风险点分析 1、运行中发现了产品的错误或设计缺陷需要修正而未引起有关方面足
20、够重视，造成不良后果。 2、产品市场环境或程序运行数据环境发生了变化而未对产品或程序进行合理修正。 3、产品功能已显落后而未修改，造成在竞争中处于劣势甚至丧失市场。 4、新产品运营后无人对其改进负责。 （二）风险控制 1、建立改正性维护、适应性维护、完善性维护、预防性维护的完整产品维护体系。 2、对处于运行过程中的新产品，必须由市场开发人员和科技部门人员共同对新产品运行的性能、功能、可靠性等每半年进行一次评估。 3、对于软件产品的维护，需建立内部分工合理的、附属于科技部门的产品维护机构。产品维护机构中至少要有下列五种人：修改负责人、维护管理员、配置管理员、系统监督员、维护人员，以明确各自的责任所在：维护申请提交给一个维护管理员，他把申请交给某个系统监督员去评价。系统监督员作出评价后，由修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。 4、在产品维护中建立明确的产品质量目标和优先级。因为尽管可维护性要求产品的每一质量特性都要得到满足，但它们相对的重要程度却随产品用途及环境的不同而不同。 5、在产品开发中必须选择可维护的程序语言。因而应尽量使用第三代和第四代语言。 6、实施软件再造工程。 7、业务管理部门应对新产品的改进负责。
