主题：【原创】如果软件商要承担赔偿责任 -- 冰与火

这应该算软件工程科学中接近哲学方面的内容吧，所以发到科学探索这里。

这段时间研究理论研究的多了，偶尔会想些类似哲学问题的东西。

今天想说的，是软件开发的责任和义务的问题。

先给大家看我正在写的文章中的一段，是关于目前最热的可信计算（trusted computing）领域的。

-----------------------引用分割线------------------------------------------------------------------------------

软件的测试工作是一个工作量投入非常巨大的系统，据统计，国外软件开发机构40\%的工作量是花

在软件测试上，软件开发费用近1/2用户软件测试，对于一些要求高可靠、高安全的软件，测试费用可

能相当于软件工程所有其他费用总和的3-5倍。这也就是说，如果我们使用现有的测试方法来开发可信

软件，并要求其各项功能都达到高可靠、高安全的程度，则软件开发费用将可能达到现在平均费用的2

-3倍。

实际上，一个软件中的大多数功能往往并不被用户所使用。软件工程中有著名的80/20规则，即一个

软件中80\%的用户仅使用其中20\%的功能，而现代的一些大型软件，如Excel等，则实际上遵循95/5规

则，即95\%的用户仅使用其中5\%的功能\supercite{Paul04}。一般而言，软件所有功能中一个比较小

的子集即可以满足较低限度的使用需求。

-----------------------引用分割线------------------------------------------------------------------------------

造成这一现象的直接原因，大概在于软件开发中功能添加部分和核心开发部分相比，工作量的不成

比例，以及软件复制的零成本。但深层次想一想，这一现象的背后，软件开发商和发行商对所提供功能

的责任和义务的缺失是否也是个重要的原因呢？

现在，软件开发商和发行商发行软件，一般都是只提供功能，不提供服务义务，不担负安全责任。在这样

的环境下，可信计算似乎有点奢谈。

如果我们规定，软件开发商每提供一个功能，都要保证其安全性和可靠性达到相当高的水平，那么，现有软件的开发成本就一下提高了2-3倍。但如果我们要求开发商在提供软件时，确定哪些功能是收费的，哪些功能是免费提供的，对开发商免费提供的功能提出较低的安全性和可靠性的要求，仅仅要求收费功能的高安全性和可靠性，又会如何呢？

这样，对一个小安全功能集合的严格测试，其费用对开发商来说，是可以接受的。而使用者如果仅在这一安全功能集合中使用该软件，那么该软件Bug导致系统崩溃所造成的损失，开发商负有赔偿责任。当然，我们可以通过保险、根据软件安全性等级限定赔偿上限等方式将赔偿风险限定在一个可以接受的范围内。也就是说，软件开发商对任何一个功能收费的同时，就同时承担了该功能安全使用的责任；而使用者为软件功能缴纳费用后，这些功能所处理的数据财产本身也受到了一定程度的保障。

现有系统和软件当然是作不到这点的，有许多技术问题，但这些问题在可信计算技术下，都是可以解决的。以后有机会，我会详细讲解。

这样的软件,可以叫"绿色软件"或者"环保软件",因为它不浪费.,并且,这对软件的开发方式,使用方式甚至盈利方式都有重大影响.

那么,这些影响是正面的,还是负面的?请大家谈谈看法.

您的帖子提到的问题，似乎是一个软件质量管理的问题，这个如果仅仅归因于测试，似乎失之过窄......

我理解软件的赔偿责任，是一个质量成本的问题。产品的价格取决于业界平均的生产力水平，质量也是如此。在一定的价格下取得一定的质量水平的产品。如果对软件质量有特别的要求，比如MTTF、MTBF什么的，需要付出平均水平以上的劳动，是为质量成本，价格自然水涨船高。一分钱一分货而已。

回到质量和测试的关系。测试所花的时间取决于你愿意付出的代价，但是，不存在一个代价水平，能够保证仅通过测试的手段来达到你所期望的安全性和可靠性。一个需求理解错误，设计拙劣的软件，要达到期望的质量水平，其最小代价是推倒重来，而不是永无止境的测试。软件开发的质量管理贯穿了整个开发过程，从需求、分析、设计到代码、测试。在每一方面都要为质量作出相当大的投入。

所以，对有质量管理的软件开发组织来说，在测试方面为质量做出的努力只占整个软件的质量管理工作的一小部分。如果仅对一个小安全功能集合进行严格测试，并不能从整体上降低质量成本。具体对某一个项目而言，也许可以仅对一个小安全功能集合的需求、设计、编码、测试等等进行严格的质量管理，但是对施行全面质量管理的组织而言，这样做其实省不了多少钱。相反，为了区分不同功能集合的质量等级，反而要付出额外的管理成本。

此外，仅对一个小安全功能集合的严格测试，也要考虑各功能集合之间的相互关系。你提到：

而没有提到使用者如果使用安全功能集合外的免费功能模块，而导致安全功能集合中的模块不可用又该如何？比如说，你的软件有一个后台自动更新的免费功能模块，可是这个模块消耗了大部分的CPU时间和内存，导致安全功能集合内的模块无法正常使用，或者，这个模块崩溃以后，导致整个系统的不稳定，等等等等。由于免费功能模块没有经过严格的测试或者质量管理，你如何保证不会出现这样的情况？

我在文中也提到了对当前软件,技术上是不可行的.但如果真要实行这种方式的话,也许操作系统,应用的开发模式和现在都会不一样了.

我的研究方向是操作系统安全和可信计算,软件测试方面了解不多,由于涉及到软件可信性的确定问题,现在我正在学习了解中,特别对其中的公理化体系很感兴趣,下面求文就是为了了解这方面的内容.

至于可信计算,你可以先查trusted computing,以及TCG组织关于可信计算体系结构的specification.

网站是www.trustedcomputinggroup.com.,不过我基本不赞同他们的方法,只认同他们提出的可信就是软件行为的可预测性这句话,并且认为他们的规范并没有真正体现这一想法.

如果你对这方面也有研究,我有关于可信计算形式化模型的论文可以交流.

在这里使用可信计算技术的目的是提供安全功能集合的确认和详细描述,以及保证在软件使用过程中出现数据财产损失后,对责任的无争议认定以及系统正常运行过程中,对这些信息审计时的隐私保护等内容.

提出安全功能集合的目的就是把需要测试的内容降低到一个可以接受的范围.安全功能集合只是一个目标的改变,具体达到这一要求还需要软件设计和操作系统功能上的配合.

至于你提到的使用者如果使用安全功能集合外的免费功能模块，而导致安全功能集合中的模块不可用又该如何？我的想法是,当用户使用了安全功能集合外的免费功能模块时,除非开发商允许,否则他就自动放弃了只使用安全功能模块所获得的数据财产索赔权利.

安全功能集合的基本想法很简单:

假设把软件看作一个具有大量状态,随着不同输入而变化状态的自动状态机,其中的一个子状态集合和输入集合构成了一个闭包,就是如果系统初始状态在这个子状态集合中,任意一个属于该输入集合的输入执行后,系统的下一个状态仍在这个子状态集合中,那么只要我们确定了该闭包是可信的,那么只要保证初态属于该子状态集合,输入属于该输入集合,则软件在运行过程中总是可信的,即使软件其他地方满是Bug.

至于如何确保初态和输入符合要求,那就是可信计算所研究的内容了,不过,是"我的可信计算"所研究的内容,不是TCG的.

净室软件工程号称可以生产出“零缺陷”的软件，也许能满足您的要求？

这都是您自己想出来的？那可真了不起！

我觉得这个思路并不困难啊,总觉得不应该只有我想到这些内容.倒是我对可信系统安全理论的研究,已经接近拓扑的领域了,估计别人应该还没想到.

净室软件工程以前没有了解过,有相关的论文吗?

另外,您能帮我找到下面我提到的那篇软件测试公理化的文章吗?

google上搜了一下,下了一篇文章正在阅读中.

网上书店看到一本专著,但处于缺货状态

想找关于净室软件工程理论基础方面的的文章,希望能给推荐一两篇比较全面的.

净室主要实践为：统计质量控制下的增量开发,基于功能的规范,开发及认证,以及基于使用模型的统计测试

看来大家的思路真的差不多.

净室软件工程的文章不多。网上书店那个其实就是SEI的净室软件工程参考模型技术报告。您可以按照：

Technical Report

CMU/SEI-96-TR-022

ESC-TR-96-022

Cleanroom Software Engineering

Reference Model

Version 1.0

Richard C. Linger

Carmen J. Trammell

November 1996

查找一下。查不到的话，我可以给您一份pdf，希望能对您的工作有所帮助。

不知道您提到的“那篇”软件测试公理化的文章是哪篇，这方面我不熟，平时没什么积累。

谢谢你提供的信息.

我要找的文章是Axiomatizing software test data accuracy，发表于IEEE trans on software engineering 86年,国内IEEE电子图书馆刚好缺了86年的IEEE trans on software engineering.

如果不能的话,你也不要指望软件商承担所有责任.如果一定要的话,跟行医保险一样,责任的事让保险公司来干.这样的话几个后果,医生付不起保费被迫中止行医,或者政府规定医疗事故赔偿cap。有一个后果是永远不会出现的，就是医生患者都满意。

你这个问题，可以参考美国行医保险的现状。