风险与质量管理

一、风险管理

1、风险管理的层次：
 （1）危机管理：  救火型，当问题严重时才会应对
 （2）事后补救：当风险发生后能够快速做出反应
 （3）风险缓解：通过预先计划的方式描述当风险发生时的解决方法，但并未试图排除风险
 （4）风险预防：把实施风险计划作为项目的一部分，识别风险并防患于未然
 （5)风险去除:  确认不排除可能造成风险的因素

 

2、风险数据库:
(1)技术或质量风险
 1.1使用未经验证的或复杂的技术
 1.2项目进行过程中变更技术路线
 1.3硬件、软件和网络功能划分不合理
 1.4在有用的产品生产出来之前，该技术过时
 1.5不现实的质量目标

（2）项目管理风险
 2.1不合理的进度
 2.2资源冲突
 2.3缺乏项目管理经验

（3）组织风险
 3.1对项目的重视程度不够
 3.2资金缺乏

（4）外部风险
 4.1客户变更
 4.2法律纠纷

（5）市场风险
 5.1产品或服务能推销出去吗？
 5.2用户会接受并采用这一产品或服务吗？
 5.3会不会被竞争对手赶在前面？

（6）财务风险
 6.1组织有能力承担这一项目吗？
 6.2项目干系人在财务预算时的信心如何？
 6.3项目会满足NPV、ROI和回报估计吗？
 6.4如果不能满足，公司还有能力继续进行该项目吗？
 6.5公司的现金流是否能够支撑该项目？
 
3、IT项目常见风险
（1）人力资源风险
 1.1人员的时间和精力不能满足
 1.2人员拒绝参加到项目组
 1.3项目组人员不稳定
 1.4没有合适的培训讲师

（2）软硬件咨询源和环境风险
 2.1缺少必要的软件
 2.2硬件设备不具备
 2.3办公环境落后
 2.4测试所需的软硬件资源不满足
 2.5测试环境的准备不充分

（3）客户需求风险
 3.1客户需求不明确
 3.2客户需求发生变更
 3.3客户需求发生重大变化

（4）技术风险
 4.1项目经理、项目人员的能力不足
 4.2项目组未正确理解客户需求
 4.3项目组设计的方案不能完全满足客户需求
 4.4没有合适的需求分析方法和建模工具
 4.5测试范围不合理，无法明确定义测试项
 4.6测试用例的选择缺乏代表性、不完备

（5）质量风险
 5.1需求报告发生质量问题
 5.2概要设计发生质量问题
 5.3详细设计发生质量问题
 5.4用户操作手册发生质量问题
 5.5代码质量不符合项目编码规范的要求
 5.6单元测试问题报告数量过多
 5.7各单元模块集成后，整个系统出现重大问题
 5.8系统的某些性能指标不能达到客户需求明确定义的验收指标
 5.9软件产品出现功能性错误
 5.10软件产品出现性能问题
 5.11软件产品未通过公司内部评审
 5.12软件复制过程中产生质量问题
 5.13不能完成软件产品安装
 5.14对已安装的软件产品的测试产生新的问题
 5.15试运行阶段发现软件产品存在错误

（6）客户关系风险
 6.1无法与用户对交付形式、交付时间和交付内容达成共识
 6.2用户对软件产品不认可，不在交付清单和试运行报告上签字
 6.3客户承诺
 6.4合同风险
 6.5收款风险

二、质量管理
1、定义
 软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种
 质量属性，从而提高软件的整体质量。它是一个系统、组件或过程符合客户或用户的要求或期望的程度。

2、商业目标决定质量目标。提高软件质量的最织目的是为了赢利，而不是创造完美无缺的产品。
 因此对于普通商业软件而言，并不是“质量越高越好”，而是恰好让广大用户满意，
 并且将提高质量所付出的代价控制在预算之内。

3、十大软件质量因素
（1）功能性质量因素：
 正确性：指软件按照需求正确执行任务的能力。
 健壮性：指在异常情况下，软件能够正常运行的能力。有两层含义：一是容错能力，
               二是恢复能力。
 可靠性：指在一定的环境下，在给定的时间内，系统不发生故障的概率。

（2）非功能性质量因素：
性能：指软件的“时间-空间”效率，而不仅是指软件的运行速度。
易用性：指用户使用软件的容易程度。
清晰性：指所有的工作成果易读、易理解，可以提高团队开发效率，易于维护。
安全性：指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
可扩展性：反映软件适应“变化”的能力，对于大项目，复杂项目，软件的可扩展性尤为重要，它是架构设计师要
              重点考虑的质量属性。
兼容性：指不同产品（或新老产品）相互交换信息的能力，兼容性的商业规则是弱者设法与强者兼容，否则无容身
            之地；强者应当避免被兼容，否则市场将被瓜分。 （例：WPS 与 Word）
可移植性：批软件不经修改或稍加修改就可以运行亍不同软硬件环境（CPU、OS和编译器） 的能力，主要体现为
               代码的可移植性。

4、消除软件缺陷的三种方式（参考郎中三兄弟看病故事）
 （1）在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，
 不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。（最优）
 （2）当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般
 都能学会。最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。（次之）
 （3）在软件交付之前，没有及时消除缺陷。当软件交付给用户后，系统出错后再来进行补救。（最差）。

5、软件评审
（1）评审（Review)
软件技术人员（包括管理人员、用户代表）以会议的形式对软件产品进行评论，识别存在的问题，并判断其是否
 满足预期的要求。

(2)同行评审(Peer review)
 在工作产品的开发过程中由同行们对该工作产品进行的评审，目的是识别要消除的缺陷。

（3)正式评审（Inspection）
 通常是由项目经理主持的正式评审会议形式的评审，3人以上（包括3人，3～7人为宜），
 一般在完成了一个工作产品后对其进行的评审。

（4）技术审查（Technical Reviews）
    或称内部评审，通常由技术负责人或项目经理召集，三人以上参加。

（5）走查（Walkthrough）
 非正式的评审，通常是小型讨论会，两三个人参加，由作者主持，主要是评估和提高工作产品的质量。一般是
 在工作产品的中期进行或完成了某部分独立的工作产品时进行。

6、同行评审的对象
 （1）用户需求说明书，产品需求规格说明书；
 （2)用户界面设计说明书；
 （3)概要（架构）设计、详细设计及模型；
 （4）源代码；
 （5）测试计划、测试用例；
 （6）项目计划，包括下属计划（进度计划，风险管理计划，开发计划、配置管理计划和质量保证计划等）。

7、改进质量的途径
   尽早消除缺陷，在总体注入缺陷相同的情况下，尽早地消除缺陷可以使交付产品的质量大大提高。
   
8、质量管理的规范化、量化和固化
（1）规范化就是建立一套适合软件企业的质量管理体制（例如ISO9001，CMMI）。
（2）量化就是要采用基于事实的决策方法，收集数据进行量化分析，实现质量管理的反馈控制。
（3）固化就是要建立一套行之有效的，真正可执行的过程，使得企业无论在什么地方、由什么人管理，都要按照
 统一的模式去实施。