隨著互聯網的迅猛發展，特別是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個軟件部署方案，通過分析、比較，對資源優化，采用平衡策略，能夠在業務約束范圍內達到業務要求，并獲得成本最優化。
業務目標 是軟件部署的最終目標，包括這些目標實現的業務要求或約束。軟件部署設計的質量好壞，最終取決于對滿足業務目標的能力的評估。
除此之外，下面還要著重討論可用性、可伸縮性和安全性的影響因素和規劃策略，保證部署設計成功。對可用性、可伸縮性和安全性等的驗證，也是至關重要的。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/