理解软件开发的特点- 软件质量保证的{dy}步- 李云- 51CTO技术博客企业库|免费b2b网站

与软件开发过程中产品从无到有的创造所带来的兴奋与有趣相比，软件质量保证更多地让人觉得沉闷和枯燥。相比之下，软件开发过程中的需求分析、设计和编码是一个相对容易做的事，因为在这些过程中如果出现差错，工程师都觉得有劲可使以进行弥补，这些过程中的错误更多地表现为“明枪”。软件质量保证则不然，往往很容易出现有劲使不出，乃至怎么也做不好，其更多地表现为“暗箭”。之所以会出现这种状况，是因为开发团队没有深刻地理解到软件质量保证是一个系统工程，高质量软件的获得并不是意味着只要做好软件开发过程中的某一个或几个关键环节就行了，而是需要xx软件生命周期内的所有环节，且很容易出现因为一个小小的细节没有做好却造成最终的软件质量大打折扣。正是因为对于质量保证的系统性认识不够，从而造成“暗箭难防”的局面。

《》探讨了软件质量的{dy}层含义，即用户层面来看高质量的软件具有更少的缺陷，也指出从技术层面保证软件质量的关键是提高软件设计质量。除此之外，软件质量还有其第二层含义，即尽可能在{dy}时间将事情做对，也就是减少返工，其表现是软件在被开发的过程中（并不是在用户手中）所出现的缺陷更少。需求捕获如果没有在需求分析阶段做好，那将造成很大的浪费，这一点众所周知，而这正是因为没有在{dy}时间将事情做对。另外，软件质量还应当涵盖高效地从事开发工作。同样是做对一件事，花{yt}与花半天时间将其做对，或许对于软件项目有着天壤之别。{zh1}，软件质量还包含它的第四层含义，这在《》也有所提及，那就是相关软件工程师的生活质量。高质量的软件应当包含软件工程师的生活质量并没有为之而“打折”，反之应当有助于提高软件工程师的生活质量。缺陷是软件用户可以看到的，而开发过程中的低返工率、开发效率和工程师的生活质量却是用户所看不到的，但对于开发团队来讲却及其重要和真切。不论是低返工率或是开发效率，其最终都反映在项目开发的经济性上。

另外，善变很可能是人的天性，由于大脑在处理事务时并不能xx保证其一致性。很有可能股票涨了的话一高兴就采用了这种处理方法，而心情不好时则采用了另一种处理方式。善变有它的好处，比如让我们更具创造性，也为我们的生活带来了更多的乐趣，使我们从无聊的事情中通过变通找到乐趣，但这对于软件质量的保证却未必是一件好事。减小善变所带来的负面影响，或许通过培养良好的工作习惯是一条不错的途径。

一个软件项目的阶段性完成并不意味着它不会带来后续的成本，因为不同的实现（实现不具{wy}性）所带来的软件稳定性和可维护性都将不同，而不良实现所带来的隐性成本往往在预算时无法合理地被考虑，这进一步又意味着什么呢？{dy}，它将导致对项目进行计划更困难。这是显然的，因为看不到隐性成本的存在，自然在计划时不会将其列入其中。第二则更为严重，由于隐性成本的不可见性，往往很容易造成被忽视，进而不能掌握软件开发的特点，对软件开发中的困难也表现得不理解。甚至一味地认为只要投入时间和人力就一定能开发出高质量的软件产品，孰不知很有可能因为更多的投入而造就更大的隐性成本。

软件开发过程中的一个很小的细节很容易被放大。对于一个模块在设计时所留下来的小窟窿，哪怕认为微不足道，但是这个“微不足道”{zh1}很有可能演变成项目组的沉重负担。对于大型项目，如果大家随意地包含头文件，{zh1}很有可能造成每一次项目编译都浪费不少时间去等待；修补一个缺陷时，由于觉得没有必要去除其中的一处冗余设计却有可能{zh1}落得难以维护；因为不小心将“==”错写成了“=”而造成一个严重的软件缺陷，等等。

一个表面上好的软件其设计未必就好，而设计不好则早晚会出问题，从而带来隐性成本。要真正地评估软件的质量需要通过评估其设计质量着手，而这很需专业的高水平。这里所说的专业水平不能简单地理解为评估人具有什么样的学历，或通过了什么样的认证，而是需要他对软件行业有深刻的理解和丰富的经验，以及拥有自己的软件设计思想。通常这类评估人也应当对于软件设计有着精神上的追求（否则他的水平也不会高到哪），很显然这种人是一种稀缺资源！

本文出自 “” 博客，请务必保留此出处