SaaS模式中的质量管理-UML软件工程组织-火龙果软件

UML软件工程组织

SaaS模式中的质量管理

2007-11-29 作者：朱少民来源：csdn

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

随着互联网的迅猛发展，特别是Web2.0的兴起，将软件作为一种服务形式提供给客户的需求逐渐增加，软件产业正在发生越来越大的变化，其中最突出的就是形成软件即服务(Software as a Service，SaaS)模式。

SaaS模式就是以软件部署为基础，通过互联网直接为客户提供服务，而且客户还可以按需定制自己特定的服务。

这种新模式的出现正是顺应了这个需求，用软件服务代替传统的软件产品销售，不仅可以使软件免于盗版的困扰，而且可以降低软件消费企业购买、构建和维护基础设施和应用程序的成本和困难。SaaS模式已经给传统套装软件厂商带来了实实在在的压力，其自身的发展越来越快，许多著名调查或咨询公司所提供的数据进一步显示了这一趋势。

其中著名的代表有SalesForce、WebEx、oDesk、OpenAir、eProject等，而且像甲骨文、IBM、Microsoft和SAP等软件巨头开始关注这一模式，并投入巨资力图将传统的软件产品销售模式逐渐向软件服务迁移，例如，甲骨文相继收购了J.D. Edwards、PeopleSoft和Siebel CRM OnDemand，而IBM开始宣称自己一直是一家按需服务（On-demand service）公司，Microsoft开始力推其live.com的战略，而以百度、Google、eBay和Amazon等以消费者为中心的服务也从侧面证明了SaaS模式是可以进一步扩展的。

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

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

SaaS质量需求的焦点

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

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

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

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

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

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

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

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

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

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

一个安全相关的关键组件，需要保证其可靠，即使出现错误或故障，也要保证代码、数据被储存在安全的地方，而不能被不适当的使用和分析。

但软件的安全性和其性能、适用性会有些冲突，如加密算法越复杂，其性能可能会越低;或者对数据的访问设置种种保护措施，包括用户登录、口令保护、身份验证、所有操作全程跟踪记录等等，必然在一定程度上降低了系统的适用性。

适应SaaS质量需求的软件开发流程

SaaS通过互联网向用户提供服务，而这基础是软件系统的部署。这就要求在软件需求分析、设计和验证时，要充分考虑系统部署的需求，包括服务器集群、分布式网络、故障转移、系统在线扩充、数据备份和恢复等。所以系统的架构设计是非常重要的，需要投入足够的时间和资源。

另一方面，由于软件部署由软件服务商自己控制，且不会像渠道销售软件套装产品那样花费很长时间和制造成本，所以SaaS软件发布周期可以大大缩短，力求在软件开发过程中做到最简单和最有效，最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

对于SaaS软件开发，可以将敏捷方法和RUP过程方法结合起来，敏捷过程能够保持快速、稳定的开发速度，RUP过程可以保证系统的灵活架构、良好的扩充性和移植性，促进开发过程达到一个最佳的平衡状态，以获得很高的满意度。

软件服务模式的产品发布程序比一般软件产品的发布要复杂得多，要涉及到软件产品部署和实施的前期活动和后期活动，其中增加了“软件产品的部署（Deployment）规划、部署设计、部署设计的验证和实施、监控”等活动。

在开发中，要考虑到网站或数据的迁移、多种升级方式、多版本共存的运行环境等需求，对数据/系统的兼容性要进行充分的讨论和分析，保证用户升级过程中，所获得服务没有受到影响，数据受到保护，一切使用正常。

而且，要处理好客户之间的关系，对于功能变化较大的新版本升级，一般要事先得到用户的许可或同意。

对于软件服务模式，当产品发布到运行环境（服务器）中，在用户开始使用之前，还要进一步验证。所以，对软件服务模式的产品发布中最后实施阶段，其时间性非常强，一般放在周末或晚上时间（9:00pm～6:00am）。如果提供7x24不间断的软件服务，就需要采用DNS、服务器、目录等快速切换方式来实现无缝升级。

部署的规划、设计和验证

软件部署(Deployment) 是SaaS一个必不可少的、关键的环节。软件部署是通过整合的、虚拟化的或逻辑化的资源和进程的集中管理，对所要运行的程序提供技术和环境的支撑，从而保证软件系统被部署到合适的运行环境中能具有最优的、最可靠的性能表现，并能对用户和系统的各种数据进行有效的存储、备份和恢复等。

在软件部署的技术分析上，就是以业务目标为出发点，将这些要求转化为可用来设计部署体系结构的技术规范。而在部署设计中，必须考虑多种质量因素。

逻辑体系结构它能决定服务分配的最佳方式和系统扩充性、维护性等。

服务质量要求必须满足服务质量 (QoS) 要求，建立在逻辑体系结构和QoS要求的映射关系，从而达到性能、可用性、可伸缩性、可维护性等软件服务的质量目标。

用量分析有助于通过系统负载的使用模式来隔离性能瓶颈，开发出满足 QoS 要求的策略，用于部署设计中。

用量分析因素主要有:用户数量及类型、活动和非活动用户、管理用户、使用模式、用户增长、用户事务和用户/历史数据等。

使用案例尽管使用案例已包含在用量分析中，但评估部署设计时，应参考使用案例，确保任何案例中所揭示的问题在设计中得到处理或解决。

根据性能指标，对一些关键的使用案例进行研究，以确定在系统层次如何保证该要求得到实现的结构、技术或方式。

服务级别协议指定了最低性能要求以及未能满足此要求时必须提供的客户支持级别和程度，相当于设计的底线(Bottom Line)。

成本有必要设计2-3个软件部署方案，通过分析、比较，对资源优化，采用平衡策略，能够在业务约束范围内达到业务要求，并获得成本最优化。

业务目标是软件部署的最终目标，包括这些目标实现的业务要求或约束。软件部署设计的质量好坏，最终取决于对满足业务目标的能力的评估。

除此之外，下面还要着重讨论可用性、可伸缩性和安全性的影响因素和规划策略，保证部署设计成功。对可用性、可伸缩性和安全性等的验证，也是至关重要的。

可用性的规划策略

当可用性的要求达99.99%或99.999%，通常要求系统必须是一个容错系统。容错系统必须能够在硬件或软件出现故障时继续运行，其实现手段是为提供关键服务的硬件（如 CPU、内存和网络设备）及软件配置冗余组件。

可用性设计将考虑到可用性降低或组件丢失时所发生的情况，其中要考虑连接的用户是否必须重新启动会话和一个区域内的故障对系统的其他区域的影响程度。QoS 要求应考虑这些方案并指定部署如何对这些情况作出反应。

单一故障点（Single-point failure）是指没有备用的冗余组件的硬件或软件组件，而这些组件是重要路径的组成部分，即该组件出现故障会使系统无法继续提供服务。设计容错系统时，必须确定并消除潜在的单一故障点。

其常用的可用性策略有:

负载平衡使用冗余硬件（如服务器集群-Server Cluster）和软件组件来分流处理负载。

负载平衡器（如NetScaler LoadBalance）把对某个服务的任意请求引导至该服务的服务器集群中当前负载最小的某个服务器上。如果任一实例发生故障，其他实例可以承担更大的负载。

故障转移涉及对冗余硬件和软件的管理，在任何组件发生故障时提供对服务的不间断访问并保证关键数据的安全。如Sun Cluster 软件为后端组件管理的关键数据提供了故障转移解决方案。

复制或备份服务为同一数据的访问提供多个源，如目录服务器为LDAP目录访问提供多个复制和同步策略。

可伸缩系统的规划

可伸缩性是指增加系统容量的能力，而且要求在增加系统资源时不改变部署的体系结构。

在系统需求分析、设计阶段，系统容量的预测往往只是估计值，可能与部署系统的实际情况存在较大差异，所以部署具体设计时，应考虑到必然存在的偏差，引入系统部署可伸缩性的策略，使部署后的系统具备足够的灵活性，具有足够的处理合理时间内（如系统运行后 6～12 个月）增加负载的潜在容量，以便在出现异常峰值负载时能够从容应对。

可伸缩系统的规划，一般有以下3个策略，可从中选择一个或多个组合策略。

高性能设计策略在性能要求的确定阶段加入潜在容量，以处理可能会随时间推移而增长的负载，并在预算控制内尽可能提高系统的可用性。这一策略可使系统具有一定的缓冲时间来应付增长的负载，所以可以相对从容地制订更大的系统扩展方案。

渐增式部署基于负载的要求以及评估，事先明确系统扩展的条件以及条件可能达到的时间，对每一个重大的系统扩展特定日期/时间有一个估计和安排，从而建立部署的整个日程表。

大范围性能监视对性能进行监视有助于确定向部署中增加资源的时机。监视性能的要求可为负责维护和升级的操作员和管理员提供指导。

安全性的规划

安全性是一个复杂的主题，涉及到部署系统的各个级别，主要包括以下内容:

物理安全物理安全是对路由器、服务器、服务器机房、数据中心及基础结构中其他部分的物理访问。如果未经授权的人可以进入服务器机房然后拔掉路由器电源，则其他安全措施将毫无意义。

网络安全网络安全是通过防火墙、安全访问区、访问控制列表和端口访问对网络进行访问。应开发针对未授权访问、篡改和拒绝服务攻击的策略。

应用程序和应用程序数据安全包括通过验证和授权过程及策略访问用户帐户、公司数据和企业应用程序，包括口令、加密、认证、访问权限和控制等策略。

个人安全惯例组织范围的安全策略，定义工作环境和所有用户必须遵守的惯例，以确保其他安全措施按设计实行。

通常的做法是编印安全手册并对用户进行培训。要实现有效的总体安全策略，可靠的安全惯例必须成为企业文化的组成部分。

SaaS软件系统的维护质量

首先确保系统的可维护性，其次制定一系列系统维护的操作规则和变更控制流程，切实保证系统能得到及时、有效的维护。

可维护性是指对部署系统进行维护的容易程度，包括系统监视、系统出现故障的修复、系统功能的增强、系统数据的更新和备份、系统软硬件的升级等任务执行的难易程度，其影响的因素还包括使用模式、停机时间计划和相应的流程等。可维护性和可用性存在一定的依赖性，良好的可维护性才可能保证系统运行的高可用性。

软件部署维护，首先必须由专业的、独立的维护团队，其成员的技术构成应比较完备，包括硬件工程师、网络设计工程师、安全认证工程师、（操作）系统工程师、数据库管理员(DBA)和应用系统的技术人员等。

其次要有完整的操作流程和规范，告诉每个维护人员，如何进行操作，哪些操作是允许的，哪些操作是不允许的。对于出现的紧急事件，制定相应的应急方案。除此之外，通过下列措施，进一步提高软件部署维护的质量。

安装有运行环境的监控程序，随时监控运行环境的情况，任何问题的先兆可以及时通知维护人员，形成预警机制;保证7×24任何时间内有人值班或保持被呼叫（on-call）状态;有一套系统（如Remedy Ticket System），报告系统问题，并能及时得到响应和处理;除了故障转移机制之外，有冗余的设备或冗余的系统运行能力;做好软件部署的维护记录。

SaaS模式的特定要求

(1)软件开发方法和流程要敏捷，其实施要具有简单性。

(2)允许客户自我定制，对系统架构的灵活性、兼容性和扩充性等有更高的要求。

(3)通过部署系统来实现软件服务，对系统部署、操作、技术支持和维护要求高。

(4)要求高可用性（7x24不间断运行），以及性能稳定、可靠性，包括系统故障转移。