理解软件开发的特色 - 软件质量保证的第一步

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

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

     软件质量保证是一个比较沉重的话题，由于在其后更关系到软件工程师的生活质量，而不仅是表面上的产品质量那么简单。对于质量保证这一系统工程，它不能被简单地理解为“就是测试”。在进一步探讨这一话题以前，须要先了解软件开发的特色。软件开发具备如下几个特色，有些特色之间也表现为相互影响，且这些特色最终致使软件质量控制并非那么的直观和容易。

脑力密集型

     软件开发是脑力密集型工做，其中的很多活动由于只存在于软件工程师的大脑中，于是具备不可见性，天然也就没法指出工程师在作开发时哪一步思考将有可能形成质量问题，进而没法经过运用流程的方法将这些潜在的质量问题彻底消除，这与流水线生产下的质量保证方法彻底不一样。

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

实现不具惟一性

     一个软件功能，尽管从使用者的角度来看都同样，但却能够有多种不一样的实现方法，且不一样的开发团队或者不一样能力的人所作出来的设计颇有可能彻底不一样。若是软件实现具备惟一性，那其质量就更好被评估，也更容易找到改善点，但软件开发不属于这一列。

     正由于软件的实现不具惟一性，这使得很难从林林总总的实现中找到哪种更好，或者要找到这个“更好”所须要的成本（包括时间、金钱和能力）却更高。

隐性成本高

     只要是产品开发则老是存在开发成本的概念，也须要对项目进行预算，这一点软件产品的开发也不例外。与其它产品开发不一样的是，软件开发的隐性成本很高。所谓的隐性成本，是指在项目预算时并无将其考虑在内，但它确实在未来的开发活动中会致使额外的成本开销。

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

     隐性成本的存在每每很容易致使工程师由于工做而影响生活，而进一步带来更大的隐性成本。试想一想，有没有某个项目在预算时将工程师的生活质量真正地考虑在内呢？若是有，这种考虑是考虑到了点子上吗？仍是只是表面？

细节很容易被放大

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

     在软件行业，彷佛存在这种必然，只要某种事情有可能变坏那就必定会变坏（莫非定律），用“如履薄冰”来形容软件开发一点都不夸张。软件行业能很好地体现“蝴蝶效应”，也就是说一个细节最终对项目所形成的负面影响并不是是按它应有的比例，而是远远大于这一比例。

     能够说软件开发无小事，可能一开始认为很小的事，到最后明白其重要性时却已让团队背上了沉重的负担，进而可能压跨团队。对于“小事”的把握，须要对软件行业有较为全面和深入的认识，以及丰富的经验和良好的洞察力。

质量评估很需专业的高水平

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

    设计质量评估所需的专业性也正是由于实现不具惟一性这一特色所形成的，合格质量评估者的缺少使得质量评估变得更加困难。一个开发团队，若是不具有胜任的质量评估者，则颇有可能整个团队在开发过程当中不知道软件质量的真实情况，而只是停留在关注被发现的缺陷之上，进而没法涉及质量问题的核心 —— 不良设计。

    真正高水平软件工程师的缺少也加重了软件行业的困难，因为缺少这些“领头羊”，项目组在开发过程当中没法有目的地朝着高质量设计的方向前进，而只能是以完成工做为目标。结果颇有多是项目组多走弯路，以及项目面临更高的隐性成本。