* 帖子主题 * 例释权利和义务 你是第 79 位浏览者 citizen 军衔: PMU初级一星 财产: 经验: 魅力: 来自: 北京市 鉴定: 本功能已经被关闭 发帖: 158篇 注册: 2001-11-26 -------------------------------------------------------------------------------- 作者:citizen 软件客户的权利和义务例释 1) 权利书一/三/四 山东某玻璃机械集团需要对其生产的啤酒瓶的质量进行控制,他们了解到北京某大学电子系的某个教研组在图像识别方面处于国内领先地位。1999年10月,该公司副总经理蔡先生率领其研发班子来到北京考察。以下是蔡先生和电子系苏教授的对话: “我们要开发一套关于啤酒瓶缺陷检测的在线监控系统”蔡先生说,“我们希望这套系统对于我们的啤酒瓶的质量带来一个飞跃。” “那么这套系统的主要检测对象应该什么?”苏教授很关心系统的真实需要。 “当然,我们需要对于流水线上的啤酒瓶进行监控,找到他们的缺陷,然后在适当的时候将这些有缺陷的瓶子剔除掉。” “很好,我们有很好图象模式识别的基础,我想我们可以通过摄像机将啤酒瓶拍摄下来,然后从图片中识别出缺陷,这个对于我们来说一点都没有问题。” “太好了,我们调查了国内很多研究机构,听说你们研究室在这方面是国内最好的,所以我们相信你们一定能帮我们完成这套系统的研究。” 蔡先生和苏教授非常兴奋,他们就该系统的前景和经费进行友好深入的讨论,最后在一次聚餐之后签订了开发合同,合同开发期限为6个月。 4个月过去了。苏教授收到蔡先生寄来的缺陷啤酒瓶样品,并接到蔡先生的电话。 “我们想看看系统的样子,开发的时间不多了,我们的样品识别率怎么样?” “系统一切正常,我们识别出3#是缺陷瓶!”苏教授对自己的工作很满意。 “什么?我们的样品只有1#是好瓶,2#到8#的缺陷分别是小炸口、瓶口大破损、瓶壁暗纹、封锁环裂纹、磨缝线裂损、瓶口小气泡和大炸口。”蔡先生对这样的结果非常吃惊。 “什么乱七八糟的东西,怎么前面都没有和我说过啊。” …… 一段沉默以后,苏教授终于说,“蔡先生,我们是不是应该讨论一下什么是缺陷,再来谈这个项目了。” “好吧,也只有这样了。”蔡先生无奈的说。 分析: 权利一:【要求分析人员使用符合客户语言习惯的表达】。双方并不是在讨论同一个问题。蔡先生和苏教授对于缺陷的概念完全不同。在签合同之前,蔡先生就有权利要求苏教授知道所谓的缺陷就是包括小炸口、瓶口大破损、瓶壁暗纹、封锁环小裂纹、磨缝线裂损、瓶口小气泡和大炸口在内7种破损。 权利三:【要求分析人员组织需求获取期间所介绍的信息,并编写软件需求规格说明】。在合同签署直到开发到合同期限的2/3,双方都没有一份完整的需求规格说明书。测试用例也没有一个完整的准确的说明。以至于整个项目不知道在做些什么。 权利四:【要求开发人员对需求过程中所产生的工作结果进行解释说明】。可以认为仅仅是在聚餐磋商的时候属于本项目的需求过程,更不用说对需求过程中所产生的工作结果进行解释说明了。 2) 义务书五/六/八 苏教授和蔡先生在迫不得已的情况下举行了一次会谈,他们就有关概念和术语做了相互交流。蔡先生向苏教授提供了国家标准关于啤酒瓶B瓶的标准文件,文件描述了可以投入生产的啤酒瓶的缺陷最大容许参数。因为有了一个参照的标准,苏教授组织他的开发人员们做了一次成本估算,结果发现当前条件下完成该项目的预算将要超过原定项目经费的3倍。这样的预算蔡先生当然不能接受,双方作出了各自认为的最大的让步之后,签署了变更合同,开发期限延长半年,项目经费增加一半。 又是4个月过去,苏教授领导的开发已经能够很好地识别出2#到8#的缺陷了,于是决定派遣研发小组长Apou带着开发出的检测系统奔赴山东在线调试。 检测系统在一个微型流水线上进行测试,以下是Apou在山东的工作日志: X月8日,星期六:到达山东X市X区,单位热情接待,参观了厂房。X月9日,星期日:他们准备流水线的运行调试,周边环境的整饬,我们参观同地区 一个同类产品(德国进口)的运行。X月10日,星期一:上午帮助流水线正常运行,下午安装电脑系统,发现操作系统不 能正常运行,下午解决。X月11日,星期二:同行人员citizen负责算法调试,我安装硬件卡,准备光源。 他们给出了将近100个待检测的啤酒瓶。X月12日,星期三:算法调试继续。软件系统可以运行,但是界面不符合单位要求, 要求修改成独占模式。试图实现,未完成。X月13日,星期四:算法调试继续。界面修改成独占模式完毕,系统老是出现bug, 每次出现问题都必须重新启动计算机,单位领导觉得不妥,重新 改为原定界面。X月14日,星期五:算法模拟测试,特殊条件下缺陷检出率>50%,好瓶误检率>20%。 单位技术处张处长提出坏瓶率应该>95%,好瓶误检率<1%。差距 太大,调试中止。原定一个瓶子三个摄像头拍摄的方案被否决。X月15日,星期六:回北京。 …… 项目并没有结束,Apou等人在张处长、蔡先生、苏教授的不断磨合下最终在2002年的一月给出了当前技术能力下的开发结果: 1、 原定3台摄像机扩展为12台。 2、 原定一套系统扩展为三套系统并行。 3、 对裂纹检测只限于瓶口横裂纹(封锁环裂纹的一种形式)、瓶口大缺损。 4、 缺陷瓶检出率>90%,好瓶误检率<5%。 双方对于结果都不满意,蔡先生认为本次开发项目没有完成原定合同目标,后续的研发经费均克扣未发;苏教授苦于在项目初期没有制定严格的范围文档和可行性分析,所有的预付研发费用都花在了硬件配置上,可谓入不敷出,参与人员的基本工资都无法发放。 总的来说,这个项目是失败了,我们回头看这个项目后期的进展,可以发现只要双方在权利义务上有较好的共识,就能够很好地避免这些问题。 分析: 义务五:【要尊重开发人员的成本估算和对需求的可行性分析】。蔡先生仅仅根据初期本单位地开发预算,不顾苏教授的成本估算和可行性分析,死扣开发经费,给整个研发带来了很多障碍,开发方抠着指头算钱才支撑到了最后。而在可行性方面,直到最终项目完毕,张处长提出的要求也不能和国家标准要求的相符,直接导致了双方的不欢而散。 义务六:【对单项需求、系统特性或使用实例划分优先级】。在开发人员看来,算法研制的优先级往往是最高的,而在山东公司看来,该系统首先是一个商业系统,关心的优先级是正常流水线运行、用户界面、识别率。在整个项目过程中,没有明确的项目视图和范围,使用实例仅仅是100来个缺陷瓶子,任何的业务优先级和使用实例优先级都没有明确区分。一会儿做横裂纹,一会儿要瓶口缺损,一会儿又要磨缝线,开发人员完全不着头绪。 义务八:【一旦知道要对项目需求进行变更,要马上与开发人员联系】。项目需求一变再变,开发人员的在线测试就相当于一次新的项目需求的更改,这是直接导致本项目失败的原因。 -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- [ 本文发表于 2002年3月6日 11:50:02 ] hoytoma 军衔: 三等兵 财产: 经验: 魅力: 来自: 不告诉你 :) 鉴定: 本功能已经被关闭 发帖: 35篇 注册: 2002-2-24 -------------------------------------------------------------------------------- 很好!有启示的意义! -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- [ 本文发表于 2002年3月6日 13:27:00 ] citizen 军衔: PMU初级一星 财产: 经验: 魅力: 来自: 北京市 鉴定: 本功能已经被关闭 发帖: 158篇 注册: 2001-11-26 -------------------------------------------------------------------------------- :) 这是一个实际的项目,结果差不多是失败了。当然主要的原因不仅仅在于这几点权利义务上的问题,但是软件需求上的问题也占非常重要的一部分。 现在我们进行开发的是另外一个项目。应该归类为与政府机关合作的项目。 有机会的话,我们可以一起探讨。 -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- [ 本文发表于 2002年3月6日 14:41:09 ]
|