SaaS模式中的质量管理
导读:
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,还必须认真地考虑安全性、扩充性和可维护性等。安全性,除了数据存储、备份等要求之外,还需要设定系统合理的、可靠的系统和数据的访问权限,防止一些不速之客的闯入和黑客的攻击,以避免数据泄密和系统瘫痪。
软件系统的安全性和可靠性,一般是一致的,安全性高的软件,其可靠性也要求相对高,因为任何一个失效,可能造成数据的不安全。[page]
一个安全相关的关键组件,需要保证其可靠,即使出现错误或故障,也要保证代码、数据被储存在安全的地方,而不能被不适当的使用和分析。
但软件的安全性和其性能、适用性会有些冲突,如加密算法越复杂,其性能可能会越低;或者对数据的访问设置种种保护措施,包括用户登录、口令保护、身份验证、所有操作全程跟踪记录等等,必然在一定程度上降低了系统的适用性。
适应SaaS质量需求的软件开发流程
SaaS通过互联网向用户提供服务,而这基础是软件系统的部署。这就要求在软件需求分析、设计和验证时,要充分考虑系统部署的需求,包括服务器集群、分布式网络、故障转移、系统在线扩充、数据备份和恢复等。所以系统的架构设计是非常重要的,需要投入足够的时间和资源。
另一方面,由于软件部署由软件服务商自己控制,且不会像渠道销售软件套装产品那样花费很长时间和制造成本,所以SaaS软件发布周期可以大大缩短,力求在软件开发过程中做到最简单和最有效,最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
对于SaaS软件开发,可以将敏捷方法和RUP过程方法结合起来,敏捷过程能够保持快速、稳定的开发速度,RUP过程可以保证系统的灵活架构、良好的扩充性和移植性,促进开发过程达到一个最佳的平衡状态,以获得很高的满意度。
软件服务模式的产品发布程序比一般软件产品的发布要复杂得多,要涉及到软件产品部署和实施的前期活动和后期活动,其中增加了“软件产品的部署(Deployment)规划、部署设计、部署设计的验证和实施、监控”等活动。
在开发中,要考虑到网站或数据的迁移、多种升级方式、多版本共存的运行环境等需求,对数据/系统的兼容性要进行充分的讨论和分析,保证用户升级过程中,所获得服务没有受到影响,数据受到保护,一切使用正常。
而且,要处理好客户之间的关系,对于功能变化较大的新版本升级,一般要事先得到用户的许可或同意。
对于软件服务模式,当产品发布到运行环境(服务器)中,在用户开始使用之前,还要进一步验证。所以,对软件服务模式的产品发布中最后实施阶段,其时间性非常强,一般放在周末或晚上时洌?:00pm~6:00am)。如果提供7x24不间断的软件服务,就需要采用DNS、服务器、目录等快速切换方式来实现无缝升级。
[本文共有 3 页,当前是第 1 页] <<上一页 下一页>>
声明:该作品系作者结合法律法规,政府官网及互联网相关知识整合,如若内容错误请通过【投诉】功能联系删除.
相关知识推荐
Deming第一原则:要有一个坚定不移的目标许多公司趋向于解决当前的问题而忽略将来的目标。根据Deming的原则:“对于一个公司,在没有一个针对未来的计划的前提
定义:为了能够在最经济的水平上并考虑到充分满足顾客要求的条件下进行市场研究、设计、制造和售后服务,把企业内各部门的研制质量、维持质量和提高质量的活动构成为一体的
我们常说“百年大计,质量第一”,而如何才能真正地把项目质量管理好,是我们经常思考的问题,文中对如何抓好项目质量管理提出了相应的建议,值得大家借鉴。摘要:“靠质量
工程先开工后签合同一般不合法,属于倒签合同的法律行为。倒签合同与企业风险防范的目标相悖,不符合企业管理制度的要求,同时存在较大的法律风险和经营管理风险,在实践中
没有资质挂靠拖欠工程款挂靠施工人可以自己名义起诉要求发包人支付工程款。承包人应当积极向发包人主张工程款,实际施工人有足够证据证明承包人未积极向发包人主张工程款的
建筑工程纠纷行使先履行抗辩权如下:负有先履行义务的一方不如约履行的,另一方可以行使先履行抗辩权、拒绝其相应的履行请求。先履行抗辩权基本上适用于先履行一方违约的场
个人名义签订了建筑工程承包合同无效。承包建筑工程的主体必须具有企业法人资格、持有工商行政管理机关核发的营业执照和建设行政主管部门颁发的资质证书,在核准的资质等级
施工企业与包工头之间的法律关系是劳务合同关系,双方建立承揽业务后包工头受施工企业管理。建筑企业与施工企业之间是建设工程承包(加工承揽)关系,包工头与农民工之间是
承包工程需要签合同,签订时需要注意对工程的真实性、可靠性及发包人的资信情况进行了解,写明单项承包工程名称和范围、施工准备、施工组织设计和工期、工程质量和检验、价