去年本论坛层展开了一场UML大讨论，也就是那时我才开始注意这方面的资料。
乱七八糟看了些书，觉得UML虽然能够从用例开始，逐步构建系统模型，但也只解决了系统建模问题。至于系统的正确性和可靠性则没有提供合适的方法给予保障。
最近看了净室软件工程技术，感觉该理论提供了基于数学模型的一系列步骤，确保系统分析的正确性和系统设计的合理性。感觉应该是一种更为有效的软件工程理论和工具。
不知是否有对此熟悉的朋友愿意在此一叙？
------解决方案--------------------------------------------------------
我记得以前这里也讨论过净室软件工程技术,感觉在军工项目,或者用户需求变化很小,可靠度要求很高的项目比较合适,但是,对于一般的软件,是否合适,我不是特别清楚.
因为在现在的中国企业,问题最大的还不是系统设计的正确性和可靠性,而是需求的正确性和可靠性.这恐怕不是净室软件工程技术主要解决的方面.同时,净室软件工程技术的开发速度好象比较慢,只是个人感觉,没有数据支持,请知道的朋友指点.
------解决方案--------------------------------------------------------
静室软件工程,对每个地方都要用数学证明是正确的肯定很慢,它是用在高可靠性方面的.
问题是,如何保证你的证明是正确的,做数学题也会出错啊,如果不能保证证明过程是正确的又怎么能保证证明出来的结果,也就是程序是正确的?一直没想明白.
当然,证明的东西,现在人工智能已经能做一定程度了,用电脑证明应该可以比较正确,赫赫.
------解决方案--------------------------------------------------------
用自已现有的技术手段可以实现的去设计每一个可进的方案步聚，都设计完了，
检查一下工程图纸没有什么缺的，就照图施工这是不是静室软件呢？
我想是的话可以有这样的的结论，
静室工程对人的要求是把所有的可能的问题事先都想透了再动手，
技术是非关键因素，没有高级的技术一样可以做出好的软件来，
那怕只是用汇编，我个人认为多数人在工作一两年后就可以去做一些静室软件工程了，
当然是很小的工程而且是自已有经验的工程。
净室软件工程很省成本，但设计文档到谁手里能看懂是个问题，UML好像不是每个人都可以很清楚的。如果产业化来个编程专业，设计专业，软件的分工更清楚，来之能战，战之能胜，倒是个不错的产业结构，只可惜这行业变得太快了，不稳定的结构才合适现状，也苦了新人类了。唉~~~
------解决方案--------------------------------------------------------
cleanroom approach对于开发人员的水平要求太高了，在项目组中至少要有一个专家小组从事方法保证，设计及规约的评审，以及使用模型和基于markov模型的测试以及质量评价工具的设计。一般的项目小组无法负担如此高昂的资源。所以ibm也只有很少的项目使用此方法开发，爱立信好像也是此方法的行家。
------解决方案--------------------------------------------------------
对核心模块应该可以应用。
------解决方案--------------------------------------------------------
看了一遍，感觉这里没有人认真地研究过净室！
净室过程（CRM）是基于数学和统计学的可从重复的软件方法。他就好像是中世纪的重骑兵一样，远比轻骑兵昂贵。但是更可靠，更有战斗力。
CRM是昂贵的软件过程，他具备相当高的灵活性，即使需求一般性更改，对于软件的设计通常影响通常不会太大，这要好于基于RUP的方法。
对于实际应用来说，CRM通常过于昂贵，因此并不适合不要求特别可靠的小型软件开发（小于10000行有效代码）也不适合附加价值小的，相对简单的软件开发，比如MIS,ERP之类。更不适合复用性要求小而且对可靠性要求不高的应用。对于CRM我认为，在电信，军用，工控，航空航天等方面具有无以伦比的优越性。遗憾的是国内的资料太少，而且由于昂贵，国外的资料也很少，这确实限制了CRM的应用，也更加容易走火入魔。
------解决方案--------------------------------------------------------
to quicmous(快鼠)
如果不熟悉CRM就用，就会出现开发效率下降，产品质量提升有限的问题。我不推荐局部测试的方法，如果采用就要认真重新组织开发团队，组建正规的净室小组。还要求对软件重用有一个全面的认识。而且这样还不够，通常还需要一个评估小组，对这个净室小组所作的工作做出评估。CRM的复杂程度远远高于RUP。他又有很好的灵活性，而且精确，但是缺点却足以致命，因为这个方法过于昂贵
------解决方案--------------------------------------------------------
to smilemac()
你在CRM中用测试来找bug?这样做，那就是一种自定义的软件工程模型了，我觉得这与CRM相悖，因此最好不要称为净室。净室过程讲求的是开发是基于无错的，因此测试只是用来验证无措，如果发现错误，就要检讨净室过程的实施。我认为自定义的软件工程模型可能更加适合现实的软件开发，这需要深思熟虑和对软件工程的渊博知识。在这点上，我十分欠缺.因此在软件开发的实践中，我是按照ibm的CRM来走的，不敢有所不同。
------解决方案--------------------------------------------------------
To redpower(常宁):
不过似乎现在静室软件工程有一些新发展，与85年IBM创立的这一（可能是唯一的）系统化的形式化软件工程相比，已有比较大的不同，其一个特点是出现了一些非形式化的折衷，比如我前面提到的将覆盖测试引入测试过程就是其中之一。
我比较喜欢cleanroom提出的很多方法和思想，尤其是他的基于markov模型的统计测试方法。分析和设计的形式化方法有很多，但对测试而言，统计测试似乎是到目前为止唯一的形式化方法（也许是我孤陋寡闻，请知道的指正一下），可以很好地解决测试过程难以管理以及软件质量黑盒评估的问题。
很高兴与你讨论，毕竟，讨论静室的人太少了，顺便问一下，你是在美国还是中国，IBM现在还在发展这种方法吗？在IBM内，它的使用普遍吗？
谢谢！
------解决方案--------------------------------------------------------
to smilemac()
我在国内，据我所知IBM的部分实验室在使用这个方法，这是IBM确保软件质量的基本手段之一。我不是IBM公司员工，所以不敢说CRM在IBM内使用是否普遍。不过按照IBM的一贯作风以及他的软件研发体系而言，我认为CRM在IBM的所有软件实验室和部分其他实验室应该被广泛使用。
对于CRM的测试我从来都是用来验证软件开发过程的无错，而不用来找bug,如果出现错误，要回过头来检讨开发的过程，并且在过程中改进，然后再测试，直到符合概率为准。也就是说，通常在测试中发现一个错误，通过检讨开发过程，将会找到更多的问题，并解决掉。这样要好于通常的(通过测试找错误的)方法的效率。