技术开发 频道

浅谈质量和风险管理

    质量因素和风险

    我们已经讨论了质量,接下来的问题就是软件质量,或程序的质量,在软件开发项目中要讨论的风险因素。在《软件风险的评估和控制》一书中,Jones描述了他在软件开发中的评估经验。运用软件生产力研究(SPR,Software Productivity Research)和软件工程技术(SEI,Software Engineering Institute)方法来回顾几百个企业的项目,这些项目产生的软件可以分为六类:

    * 管理信息系统:财务和管理系统;

    * 象操作系统、通讯软件或其他物理设备控制软件等系统软件;

    * 商务开发项目,如给最终用户出租/出售产品等;

    * 军事软件项目;

    * 合同/采购软件项目(民间),一些零散的用于职员和雇主的客户端软件;

    * 最终用户软件项目,即一些给特定的用户开发的软件。

    这些程序中有超过100多个的风险因素。少数项目有超过15个风险因素,但大多数是6个因素影响。分析这些项目中的风险模式,结论是它们不都是所有软件中的共同因素。这儿列出了几个在样本程序中出现最多的风险因素。

    MIS:

    * 缓慢的用户需求分析(80%)

    * 过大的时间进度压力(65%)

    * 低质量(60%)

    * 严重超成本(55%)

    * 不充分的配置控制(50%)

    低质量的软件被定义为根本不工作,或是重复出现操作失败的现象。Jones定义低质量的软件是,用户报告中每日历年、每个功能点出现超过0.5个错误。MIS系统低质量表现在两个方面:(1)不确定的错误出现,如偶然或非专业的使用检查或运行测试时出现错误;(2)不充分的错误预防,如使用象联合应用设计(JAD)或信息工程(IE)的标准技术失败,一些错误可以产生项目的说明。

    系统软件风险:

    * 长期的计划(70%)

    * 不充分的成本估计(65%)

    * 过多的文档工作(60%)

    * 错误的模块(50%)

    * 项目取消(35%)

    过多的文档工作并没有严格的规律,但是可以从以下几点来判断是否是“过多”:(1)超过50种分散类型的文档;(2)文档费用接近或超过了整个项目费用的50%;(3)每个功能点有超过2000词的描述。系统软件的文档在数量级上仅次于军事软件,太多的文档对工作来讲是多余的。(注意,过多的文档会引起额外的问题,目前,还没有出版相关的作品说明怎样数量、卷、结构或什么样的文档风格对于软件项目来讲是合适的。)

    商业软件风险

    * 不充分的用户文档(70%)

    * 低用户满意度(55%)

    * 太多的市场营销时间(50%)

    * 有害的竞争活动(45%)

    * 诉讼费用(40%)

    不充分的用户文档定义为不完整的、不清楚的、错误的或理解有困难的用户信息。用户信息包括在线帮助和出版材料,这在商业软件世界里是广泛存在的问题。这个问题可以有一下因素来描述:

    * 技术描述缺乏相当的技巧

    * 用户文档不充分:

    n 新的软件包发布的文档每次都很困难;

    n 一些厂商不愿使用有能力的作者;

    n 用户文档的陈述还是很原始的方法;

    低的用户满意度意味着用户对以下一点或多个因素不满意(在1993年,一半多商业软件存在这些问题):

    * 低质量;

    * 不完整的功能;

    * 复杂的不可思议的命令结构;

    * 很难学习;

    * 麻烦的安装过程;

    * 用户服务和支持力量不足;

    * 过多的占用磁盘空间或其他硬件资源;

    军用软件

    据用软件有相当严格的项目连续性,同时也有其相应的代价高昂的问题和风险。

    * 过多的文档(90%)

    * 低产率(85%)

    * 长周期(75%)

    * 缓慢的用户需求(70%)

    * 不用或不能用的软件(45%)

    合同/采购软件项目风险

    * 高维护费用(60%)

    * 委托人和承包人间的摩擦(50%)

    * 缓慢的用户需求(45%)

    * 不可预料的认可标准(30%)

    * 交付的软件法律所有权(20%)

    维护费用是指每年一次的修复错误或按照显著高于U.S标准的项目维护费用,一个人能够维护的目前软件总数显著的低于U.S标准。

    不可预料的标准认可定义为有时存在项目委托人和承包人之间的对于产品交付条件、付款、超出最初的合同或协议的条件方面的问题。例如一个典型的问题就是过高的质量要求、对软件性能目标的过高要求,或者软件的特殊需要或文档。这种情况最终会使认可失败,或导致用户感到工作不满意。这会对项目造成伤害,影响客户关系,极端的情况会引起法律诉讼。

    最终用户软件风险

    * 不可转让的应用(80%)

    * 隐藏的错误(65%)

    * 不可维护的软件(60%)

    * 多余的应用(50%)

    * 交付的物品和软件的法律关系(版权)(20%)

    应藏错误定义为隐藏在最终用户系统中不为开发者或任何其他人知道的逻辑或程序错误。在没有最后回顾、检查、测试、审核和质量分析活动的情况下更容易出现。

    不可维护的软件。一旦软件开发者离开了公司之后,谁来维护软件呢?一些应用软件机构化很差、注释不全,以至于一旦开发者离开了公司,就没有谁能够维护该软件了。

0
相关文章