1 SaaS模式下的质量管理

　　质量管理是从事SaaS事业的企业管理的重要课题，质量管理的职能是质量方针、质量目标和质量指标的制定和贯彻实施，中心目标是促进产品质量、提高客户满意度。

　　软件质量要素包含以下两个方面，从技术角度讲，对软件整体质量影响最大的那些质量属性才是质量要素;从商业角度讲，客户最关心的、能成为卖点的质量属性才是质量要素。

　　1.1 质量管理的目标

　　l 商业模式决定质量目标

　　提高软件产品质量的最终目的是为了赢利，而不是创造完美无缺的产品。因此对于普通商业软件而言，并不是“质量越高越好”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。

　　所以，为了提高产品质量并赢利，关键还是缩短产品开发进度，节约产品开发成本。

　　l 企业目标是为了获取尽可能多的利润

　　企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。如果企业销售出去的软件的质量比较差，轻则挨骂，重则被退货甚至被索赔，因此为了提高用户对产品的满意度，企业必须提高产品的质量。但是企业不可能为了追求完美的质量而不惜一切代价，当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不开发。

　　l 质量目标就是最大地提高客户满意度

　　质量是一组固有特性，满足要求的程度;产品是过程的结果。客户对于质量的看法或感知集中地体现在对于产品和与产品相关服务的满意度上，换言之客户对产品越满意度高，对该产品的质量与服务就越放心。企业要从客户身上取得最大的利润，首先必须最大地提高客户满意度。

　　l 企业必须权衡质量、效率和成本

　　企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。企业理想的质量目标不是“零缺陷”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。

　　1.2 软件质量管理模型

　　郎中治病的故事

　　在中国古代，有一家三兄弟全是郎中。其中老三是名医，人们问他：“您们兄弟三人谁的医术最高?”

　　他回答说：“我常用猛药给病危者医治，偶尔有些病危者被我救活，于是我的医术远近闻名并成了名医。我二哥通常在人们刚刚生病的时候马上就治愈他们，临近村庄的人说他是好郎中。我大哥不外出治病，他深知人们生病的原因，所以能够预防家里人生病，他的医术只有我们家里才知道。”

　　老大治病的方式最高明，如果人们能够预防生病的话，那么没病就用不着看医生了。

　　提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。

　　即使一个人严守养生之道，身体状况良好，但总是会意外地得病的，得了病就要去看医生。老二治病的方式就是医院的模式，病人越早看病，就越早治好，治病的代价就越低。

　　同理，在开发软件的时候，即使人们的技术水平很高，并且严格遵守规范，但是人非机器，总是会犯错误的，因此无法完全避免软件中的缺陷。

　　当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般都能学会。最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。

　　老三治病的方式代价最高，只能是不得已而为之。可在现实之中，大多数软件企业采用老三的方式来对付质量问题。典型现象是：在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。

　　借鉴老大、老二治病的方法，我们提炼出全面软件质量管理的模型，如下图4-9所示。项目中的所有人员几乎都参与了质量活动，只是介入的程度不同而已。

　　图1 软件质量管理的模型

　　角色职责

　　l 谁对软件质量负责?是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。所以人们不要把质量问题全部推出质量人员或测试人员。

　　l 谁对软件质量负最大的责任?谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个人并不对产品质量产生最大的影响，所以也不负最大的责任。

　　l 质量人员的主要职责：

　　(1)负责制定质量计划(很重要但是工作量比较少);

　　(2)负责过程检查(类似于CMM中的质量保证)，约占个人工作量的20%;

　　(3)参与技术评审，约占个人工作量的30%;

　　(4)参与软件测试，约占个人工作量的30%;

　　(5)参与软件过程改进(面向整个机构)，约占个人工作量的20%;

　　制定质量管理计划

　　l 质量管理计划就是为了实现质量目标的计划。而质量目标则是由商业目标决定的。开发软件产品的最终目的是为了赚钱，所以人们为提高软件质量所付出的代价是有上限的，项目负责人当然希望代价越低越好。质量管理计划是全面质量管理的行动纲领。

　　l 谁制定质量管理计划?由项目核心成员和质量人员共同协商制定，主要由质量人员起草，由项目经理审批即可。

　　l 质量管理计划的主要内容：

　　(1)质量要素分析

　　(2)质量目标

　　(3)人员与职责

　　(4)过程检查计划

　　(5)技术评审计划

　　(6)软件测试计划

　　(7)缺陷跟踪工具

　　(8)审批意见

　　技术评审

　　l 技术评审(Technical Review，TR)的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。

　　l 技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。

　　l 技术评审的主要好处有：

　　l 通过消除工作成果的缺陷而提高产品的质量;

　　l 技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本;

　　l 开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。

　　l 技术评审有两种基本类型：

　　l 正式技术评审(FTR)。FTR比较严格，需要举行评审会议，参加评审会议的人员比较多。

　　l 非正式技术评审(ITR)。ITR的形式比较灵活，通常在同伴之间开展，不必举行评审会议，评审人员比较少。

　　软件测试

　　l 技术评审和软件测试的目的都是为了消除软件的缺陷，两者的主要区别是：

　　l 前者无需运行软件，评审人员和作者把工作成果摆放在桌面上讨论;

　　l 而后者一定要运行软件来查找缺陷。技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。

　　l 相比而言，软件测试的工作量通常比技术评审的大，发现的缺陷也更多。

　　l 在制定质量计划的时候，已经确定了本项目的主要测试活动、时间和负责人，之后再考虑软件测试的详细计划和测试用例。

　　l 如果机构没有专职的软件测试人员的话，那么开发人员可以兼职做测试工作。当项目开发到后期，过程检查和技术评审都已经没有多少意义了，开发小组急需有人帮助他们测试软件，如果质量人员参与软件测试，对开发小组而言简直就是“雪中送炭”。

　　l 强调：质量人员一定要参与软件测试(大约占其工作量的30%左右)，只有这样他才能深入地了解软件的质量问题，而且给予开发小组强有力地帮助。

　　过程检查

　　l CMM和ISO9001所述的软件质量保证，实质就是过程检查，即检查软件项目的“工作过程和工作成果”是否符合既定的规范。

　　l “过程检查”这个词虽然没有质量保证那么动听，但是其含义直接明了，不会让人误解。为了避免人们误以为“质量保证”能够“保证质量”，我提议用“过程检查”取代质量保证这个术语。

　　l 虽然本章批判了“质量保证”的浮夸，但是并没有全盘否定质量保证的好处。过程检查对提高软件质量是有帮助的，只是它的好处没有象质量保证鼓吹的那么好而已。

　　l 符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。例如版本控制检查。再例如，机构制定了重要工作成果的文档模板(例如需求规格说明书、设计报告等)，要求开发人员写的文档尽可能符合模板。如果质量人员发现开发人员写的文档与机构的模板差异非常大，那么就要搞清楚究竟是模板不合适?还是开发人员偷工减料?

　　l 过程检查的要点是：找出明显不符合规范的工作过程和工作成果，及时指导开发人员纠正问题，切勿吹毛求疵或者在无关痛痒的地方查来查去。不少机构的质量人员并没有真正理解过程检查的意义，老是对照规范，查找错别字、标点符号、排版格式等问题，迷失了方向，这样只有疲劳没有功劳，而且让开发人员很厌烦。对于中小型项目而言，过程检查工作由质量人员一个人负责就够了，约占其20%的工作量，让质量人员抽出更多的时间从事技术评审和软件测试工作。

　　1.3 研发管理流程改进

　　l 所谓流程就是工作的步骤和制度(规范)，流程规定了“谁”“在什么时候”“怎么做事情”“产生什么成果”。流程一般有6个要素：目的和适用范围、角色职责、工作步骤和流程图、输入和输出、成果模板、度量和评价。

　　l 流程改进是指分析企业的强项和弱项，改正缺点、发挥优点，制定更合理的流程，使广大员工依据流程开展工作。

　　l 超过百人的研发队伍，公司应该设立专门的流程改进机构，不断发现企业自身的研发管理问题，并在公司层面进行持续改进，为各业务部门提供有效的研发管理方法论和工具支持。

　　l 流程改进的一般方法如下图所示：

　　图2 研发流程

　　l 软件质量管理是充满争论的话题。被人们奉为软件质量管理圣经的CMM和ISO9001似乎并不奏效，现实和理想之间的差距太大。

　　l 经典软件工程教科书以及CMM和ISO9001总是抛开商业目标谈质量管理，本末倒置，纸上谈兵，误导了大量读者，所以质量管理才变得那么艰辛。世界上还没有万能的软件质量管理圣经，我们不要迷信CMM和ISO9000。

　　l 企业研发管理的指导思想是：关注结果，重视过程。

　　l “关注结果”是指：以最终产品获得的经济效益来衡量研发业绩，追求利益最大化。

　　l “重视过程”是指：将期望的成果分解到每个过程域(即工作环节)去实现，努力把每项工作做好，从而得到好的成果。

　　l 衡量研发工作优劣的三个关键指标是：质量、生产率和成本。

　　l 企业研发管理的基本目标：让所有人员有条不紊地开展工作，在预定的时间和成本之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。

　　l 企业研发管理的奋斗目标：调动一切积极因素，努力提高产品质量、提高工作效率并且降低成本，使企业和个人获得比预定目标更多的利益。

　　l 企业里大部分工作是成熟的，有现成的模式可以套用，这类工作应当靠流程制度来管理，可比喻为“法治”。企业中还有一部分工作可能是独特的，并不适宜套用流程制度(也可能没有流程制度可以套用)，相关人员要当机立断、高效地处理问题，可比喻为“人治”。

　　l 一般地，企业既需要大量的“法治”管理方式，又需要小量的“人治”管理方式。通常前者约占60-80%，而后者约占20-40%。“法治”和“人治”结合使用是企业管理的重要手段。企业领导要关注两点：一是建立合适的流程制度(实现良好的法治);二是使用合适的人(实现良好的人治)。

　　l 国内大部分IT企业的研发管理现状是：“法治”太少，混乱的“人治”太多。阻碍国内IT企业发展的瓶颈问题通常不是技术问题，而是杂乱无章的管理。

　　开发正确的产品

　　l 所谓“开发正确的产品”是指“开发能够赚取利润的产品”。对于企业而言，评判产品“对错”的标准就是“能否赚钱”。

　　l 政府每年给大学科研机构投资很多钱，允许人们去研发不赚钱的东西，例如很多自然科学基金项目的考核目标是学术水平而不是经济效益。但是企业的职能和大学科研机构的完全不同。企业只能开发“能够赚取利润”的产品，赔钱的产品不能开发。

　　l 对于普通的中小企业而言，它们只能干些力所能及的事情。如果采用成熟的技术就能够做出能赚钱的产品，那就没有必要自己研究新技术，尽可能地降低风险。

　　l 判断一个设想中的产品是否能给企业带来利润，这绝对不是一件轻松的事情，千万不能依赖于少数领导人拍脑袋的决策方式。“开发正确的产品”这种决策过程叫“立项管理”。

　　正确地开发产品

　　l 基本要求：项目团队在预定的时间和成本之内，开发完成合格的产品;

　　l 努力方向：项目团队尽最大努力把产品做得好、做得快并且少花钱。

　　l “质量、效率、成本”通常是衡量产品开发过程优劣的三个关键指标。一般说来，质量、效率、成本之间存在对抗关系。俗话说“一分钱一分货”，人们买东西的时候大多认可“质量越好价格就越高”。再如俗话“慢工出细活”，言下之意是提高质量将使生产率降低。根据常识可知，要想同时提高产品质量、效率并且降低开发成本是非常不容易的。

　　过程改进

　　l 过程改进(Process Improvement)是指：根据企业的现实情况和发展需求，优化流程制度，努力提升人们在过程中的工作能力，从而“提升产品质量、提升生产率并降低成本”。(注：这是作者对过程改进的定义)

　　l “过程改进”本身就是一件消耗时间、精力和成本的事情，那么企业为什么要做“过程改进”?答案是：过程改进是企业谋求进步的需要。

　　l 企业谋求进步离不开以下两点：

　　l (1)企业人士要不断学习新技术，开发新产品，开拓新业务领域。

　　l (2)企业人士要不断反省自己，总结经验教训，改正缺点、发挥优点。

　　l 过程改进体现了“自我反省、自我改进”的精神，不论对人生还是对企业而言，都是极为重要的。

　　引进CMMI

　　l 提高软件过程能力的实践通称为软件过程改进(Software Process Improvement)。软件过程改进的目的是：提高软件质量、提高生产率并且降低开发成本。从二十世纪九十年代至今，软件过程改进成为软件工程学科的一个主流研究方向，其中CMM/CMMI是该领域举世瞩目的重大成果。CMM/CMMI是世界范围内用于衡量软件过程能力的标准。

　　l 人们往往搞不清楚“软件过程改进”和“CMMI等级评估”之间的关系，经常混为一谈。这里作个比喻来解释：

　　l 把“软件过程改进”比喻为“学英语，提高英语能力”，那么“CMMI等级评估”就好比是“英语等级考试”。一般情况下，英语等级考试的成绩反映了英语能力。但是，在特别擅长应试的中国，英语考试成绩很好并不见得英语能力很好，甚至差到“哑巴英语”的程度。这种“特性”传染到软件领域，不少企业虽然通过了高级别的CMMI等级评估，但是其实际的软件过程能力却非常底下。

　　l 如何应用CMMI

　　l 应当根据企业的实际情况，既要裁剪CMMI过程域和实践，又要补充CMMI没有涉及的过程域和实践。企业领导和软件过程改进工作者必须明白：企业需要吻合商业目标、容易执行的软件过程规范。

　　l 裁剪不是指用剪刀把CMMI厚厚的书剪成薄薄的书，裁剪是要动脑筋的：要分析企业的业务特征，根据自身的人力和财力，选取CMMI文本中一些重要的东西，舍弃其它不重要的东西。至于什么是“重要的东西”，则要根据它对企业的贡献多少来衡量。

　　基于CMMI的集成化软件研发流程

　　图3 集成化软件研发流程

　　这些也无疑是对软件质量管理的新挑战，我们有必要找出相应的对策来保障高品质的软件服务。

　　SaaS模式有很多特定要求包括对软件开发方法和流程、对系统架构的灵活性、兼容性和扩充性等有更高的要求、对系统部署、操作、技术支持和维护要求等等。这些也无疑是对软件质量管理的新挑战，我们有必要找出相应的对策来保障高品质的软件服务。

　　1.4 SaaS质量需求的焦点

　　质量高的软件应同时满足用户的需求和软件企业自身的需求。满足用户的需求，就是要满足用户在功能上、界面易用性、可用性、可靠性和安全性等方面的要求。

　　满足软件企业自身的需求，就是要降低软件系统的复杂性，具有可扩充性、移植性等，使系统更容易维护。对于SaaS，软件质量需求的焦点在于系统的有效性、可靠性、安全性和可维护性等。

　　产品或服务对于客户的是否能保持有效，即在预定的启动时间中，系统真正可用并且完全运行时间所占的百分比，可以用“系统平均无故障时间(MTTF，Mean Time To Failure)除以总的运行时间(MTTF与故障修复时间之和)”来计算系统的有效性。

　　例如，网上银行系统需要高有效性(如>99.99%)才能满足质量要求。

　　一个有效性需求可以这样说明：“工作日期间，在当地时间早上6点到午夜，系统的有效性至少达到99.5%，在下午4点到6点，系统的有效性至少要达到99.95%”。

　　系统的健壮性和有效性有时可看成是可靠性的一部分。

　　衡量软件可靠性的方法，包括正确执行操作所占的比例、在发现新缺陷之前系统运行的时间长度和缺陷出现的密度。软件系统的可靠性和性能是相互关联的，更确切地说是相互影响的，高可靠性可能降低性能，比如数据的复制备份、重复计算等可以提高软件系统的可靠性，但在一定程度上降低了系统的性能。

　　又比如，一些协同工作的关键流程要求快速处理，达到高性能，而这些关键流程可能是单点失效设计，其可靠性是不够的。

　　对于SaaS，还必须认真地考虑安全性、扩充性和可维护性等。安全性，除了数据存储、备份等要求之外，还需要设定系统合理的、可靠的系统和数据的访问权限，防止一些不速之客的闯入和黑客的攻击，以避免数据泄密和系统瘫痪。

　　软件系统的安全性和可靠性，一般是一致的，安全性高的软件，其可靠性也要求相对高，因为任何一个失效，可能造成数据的不安全。

　　2质量与监督

　　您与客户达成的SLA将您应满足的运营标准加以量化。SLA是具有法律约束力的合同，如果不能满足协议要求，就意味着将损失大量收入，对您的商誉造成影响。监督应用架构，防范其出问题，这是在问题导致严重停机或降低性能之前查出并修复故障的重要途径。

　　² 可用性监控

　　确保系统的高度可用性是所有SaaS开发商的重中之重。停机不仅影响一台服务器或数据中心，还会导致大部分客户数据丢失，降低工作效率，甚至影响到所有用户!有些ISV从传统的台式机或客户端—服务器软件开发向SaaS模式转型，对他们来说，确保以网络为中心的应用模型的可用性，将是全新的、从未遇到过的挑战。我们建议您在应用中建立中心监控(heartbeat monitoring)与告警机制等基本方法的支持，并特别关注潜在的薄弱连接，如不在您控制之下的到数据库的远程连接。

　　当然，告警等技术机制只是确保高度可用性的一部分，如果发出告警却没有任何反应，那么也根本不能起作用。要确保您的运营中心制定具体到位的行动措施和标准，在系统发生故障时能发挥实效。

　　² 性能监控

　　客户希望您提供的应用达到可接受的性能水平。从一定意义上说，SLA作为您与客户达成合同的一部分，对这种性能要求提出了明确规定。不过，除了SLA的明文规定外，如果客户感觉您的应用速度慢，反应迟钝，那么他们也很可能终止合同，或拒绝继续作为付费用户。牢骚满腹的用户会在网站上大发不满或在行业出版物上抱怨连连，从而使您的应用声名狼藉。相反，快速高效的应用不仅能满足用户需求，还能使他们开心。如果客户从反应较慢的传统软件套件转而采用您的软件的话，您还会使他们更容易接受整个SaaS模式。

　　为了确保高级性能，只要有可能，就应直接在应用设计中构建相应的性能支持。要对CPU占用和应用响应时间等性能指标设定标准，如果出现管理问题，要马上通知相关人员解决。

　　确定性能底线通常是最重要的工作。性能底线将便于我们在不正常情况发生时及时察觉问题的症结所在。

　　3 SaaS的实施与应用

　　通过一整套过程管理规范，确保SaaS应用成功的实施方法主要在如下几个方面：

　　1)规范化咨询：在系统实施开始时，了解与辨认整个实施行动的基本概念，采用先进的管理工具，开展管理咨询与服务。

　　2)标准化培训：人的能力可定义为“知识”与“经验”的结合，系统的实施成功要靠有能力的管理者来实现，而管理者的能力中，“知识”要靠教育、“经验”则靠训练。因此，我们通过“原理解说”的过程充分了解系统的工作原理，并通过对系统“操作技巧”的训练，使使用者充分掌握系统的“信息流程”。使标准化的培训起到事半功倍的效果。

　　3)系统化设计：在观念正确，知识与技巧也具备的基础上，对系统进行系统化规划与设计。依据系统原理，系统地分析与设计SaaS平台的实现模式、应用模式和商务模式以及实施的“行动目标”，设计总体方案，并进行分步实施。

　　4)典型化应用：项目启动之初，我们选择了浏阳生物医药园、湘潭市生产力促进中心、等技术先进、管理规范的工业园区一起参加系统的分析、设计和构建SaaS平台和应用的开发与实施。使项目与用户紧密结合在一起，并通过系统的典型化应用不断完善。

　　5)现代化管理：SaaS平台开发及应用课题的实施是一个非常复杂的项目管理过程，我们建立了一套项目管理标准和控制模板，采用先进的项目管理软件工具对项目的范围、进度、成本、质量、人力资源、采购、协作等因素进行全面、科学的管理和严密、有效的控制，确保项目实施的成效。

　　4小结

　　SaaS模式中质量管理是个很重要的问题，本章主要从SaaS模式的质量管理入手，重点介绍了SaaS模式的质量管理及实施与应用。

　　软件的质量好坏是决定系统成败的关键，重视软件质量，制订SaaS模式下的软件的质量标准，;通过SaaS模式的质量管理的分析，把我们的质量管理浸透到开发与服务的每个环节，让质量管理无所不在，只有这样才能开发出客户最大满意度的产品，企业才能真正获取最大的利益。