軟體生命周期

出自 MBA智库百科(https://wiki.mbalib.com/)

軟體生命周期((Systems Development Life Cycle，SDLC)

　　軟體生命周期又稱為軟體生存周期或系統開發生命周期，是軟體的產生直到報廢的生命周期，周期內有問題定義、可行性分析、總體描述、系統設計、編碼、調試和測試、驗收與運行、維護升級到廢棄等階段，這種按時間分層的思想方法是軟體工程中的一種思想原則，即按部就班、逐步推進，每個階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟體的質量。但隨著新的面向對象的設計方法和技術的成熟，軟體生命周期設計方法的指導意義正在逐步減少。

　　生命周期的每一個周期都有確定的任務，並產生一定規格的文檔（資料），提交給下一個周期作為繼續工作的依據。按照軟體的生命周期，軟體的開發不再只單單強調“編碼”，而是概括了軟體開發的全過程。軟體工程要求每一周期工作的開始只能必須是建立在前一個周期結果“正確”前提上的延續；因此，每一周期都是按“活動 ── 結果 ── 審核 ── 再活動 ── 直至結果正確”迴圈往複進展的。

　　1、問題的定義及規劃

　　此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標及其可行性。

　　2、需求分析

　　在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟體開發項目的成功打下良好的基礎。"唯一不變的是變化本身。"，同樣需求也是在整個軟體開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。

　　3、軟體設計

　　此階段主要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計，資料庫設計等等。軟體設計一般分為總體設計和詳細設計。好的軟體設計將為軟體程式編寫打下良好的基礎。

　　4、程式編碼

　　此階段是將軟體設計的結果轉換成電腦可運行的程式代碼。在程式編碼中必須要制定統一，符合標準的編寫規範。以保證程式的可讀性，易維護性，提高程式的運行效率。

　　5、軟體測試

　　在軟體設計完成後要經過嚴密的測試，以發現軟體在整個設計過程中存在的問題並加以糾正。整個測試過程主要分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃並嚴格按照測試計劃進行測試，以減少測試的隨意性。

　　6、系統轉換

　　將作業由舊系統轉換新系統，也就是說運行系統的方法，轉換方法有平行、分批、分發、立即、試驗五種轉換方法。

　　7、運行維護

　　軟體維護是軟體生命周期中持續時間最長的階段。在軟體開發完成並投入使用後，由於多方面的原因，軟體不能繼續適應用戶的要求。要延續軟體的使用壽命，就必須對軟體進行維護。軟體的維護包括糾錯性維護和改進性維護兩個方面。

　　任何軟體都是從最模糊的概念開始的：為某個公司設計辦公的流程處理；設計一種商務信函列印系統並投放市場。這個概念是不清晰的，但卻是最高層的業務需求的原型。這個概念都會伴隨著一個目的，例如在一個“銀行押匯系統”的目的是提高工作的效率。這個目的將會成為系統的核心思想，系統成敗的評判標準。1999年政府部門上了大量的OA系統（辦公自動化系統），學過一點Lotus Notes（Lotus Notes是功能強大的多界面的Windows 軟體，它使人們能高效地協同工作。使用Notes 人們可以突破平臺技術組織和地理的限制，Lotus Notes非常好用，通常要由許多應用程式來完成的任務，用Notes一次即可完成。）的人都發了財（IBM更不用說了），但是更普遍的情況是，許多的政府部門原有的處理模式並沒有變化，反而又加上了自動化處理的一套流程。提高工作效率的初衷卻導致了完全不同的結果。這樣的軟體究竟是不是成功的呢？

　　從概念提出的那一刻開始，軟體產品就進入了軟體生命周期。在經歷需求、分析、設計、實現、部署後，軟體將被使用併進入維護階段，直到最後由於缺少維護費用而逐漸消亡。這樣的一個過程，稱為“生命周期模型”（Life Cycle Model）。

　　典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（Waterfall Model）首先由溫斯頓·羅伊斯（Winston Royce）提出。該模型由於酷似瀑布聞名。在該模型中，首先確定需求，並接受客戶和軟體質量保證（SQA）小組的驗證。然後擬定規格說明，同樣通過驗證後，進入計劃階段…可以看出，瀑布模型中至關重要的一點是只有當一個階段的文檔已經編製好並獲得軟體質量保證小組的認可才可以進入下一個階段。這樣，瀑布模型通過強制性的要求提供規約文檔來確保每個階段都能很好的完成任務。但是實際上往往難以辦到，因為整個的模型幾乎都是以文檔驅動的，這對於非專業的用戶來說是難以閱讀和理解的。想象一下，你去買衣服的時候，售貨員給你出示的是一本厚厚的服裝規格說明，你會有什麼樣的感觸。雖然瀑布模型有很多很好的思想可以借鑒，但是在過程能力上有天生的缺陷。

　　迭代式模型是RUP（Rational Unified Process，統一軟體開發過程，統一軟體過程)推薦的周期模型。在RUP中，迭代被定義為：迭代包括產生產品發佈（穩定、可執行的產品版本）的全部開發活動和要使用該發佈必需的所有其他外圍元素。所以，在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段（需求及其它）都可以細分為迭代。每一次的迭代都會產生一個可以發佈的產品，這個產品是最終產品的一個子集。迭代的思想如下圖所示。

　　迭代和瀑布的最大的差別就在於風險的暴露時間上。“任何項目都會涉及到一定的風險。如果能在生命周期中儘早確保避免了風險，那麼您的計劃自然會更趨精確。有許多風險直到已準備集成系統時才被髮現。不管開發團隊經驗如何，都絕不可能預知所有的風險。”（RUP）二者的區別如下圖所示：

　　由於瀑布模型的特點（文檔是主體），很多的問題在最後才會暴露出來，為瞭解決這些問題的風險是巨大的。“在迭代式生命周期中，您需要根據主要風險列表選擇要在迭代中開發的新的增量內容。每次迭代完成時都會生成一個經過測試的可執行文件，這樣就可以核實是否已經降低了目標風險。”

　　快速原型（Rapid Prototype）模型在功能上等價於產品的一個子集。註意，這裡說的是功能上。瀑布模型的缺點就在於不夠直觀，快速原型法就解決了這個問題。一般來說，根據客戶的需要在很短的時間內解決用戶最迫切需要，完成一個可以演示的產品。這個產品只是實現部分的功能（最重要的）。它最重要的目的是為了確定用戶的真正需求。在我的經驗中，這種方法非常的有效，原先對電腦沒有絲毫概念的用戶在你的原型面前往往口若懸河，有些觀點讓你都覺得非常的吃驚。在得到用戶的需求之後，原型將被拋棄。因為原型開發的速度很快，設計方面是幾乎沒有考慮的，如果保留原型的話，在隨後的開發中會為此付出極大的代價。至於保留原型方面，也是有一種叫做增量模型是這麼做的，但這種模型並不為大家所接受。

　　事實上，其實現在的軟體組織中很少說標準的採用那一種模型的。模型和實用還是有很大的區別。

　　軟體生命周期模型的發展實際上是體現了軟體工程理論的發展。在最早的時候，軟體的生命周期處於無序、混亂的情況。一些人為了能夠控制軟體的開發過程，就把軟體開發嚴格的區分為多個不同的階段，併在階段間加上嚴格的審查。這就是瀑布模型產生的起因。瀑布模型體現了人們對軟體過程的一個希望：嚴格控制、確保質量。可惜的是，現實往往是殘酷的。瀑布模型根本達不到這個過高的要求，因為軟體的過程往往難於預測。反而導致了其它的負面影響，例如大量的文檔、繁瑣的審批。因此人們就開始嘗試著用其它的方法來改進或替代瀑布方法。例如把過程細分來增加過程的可預測性。

　　一、軟體生命周期

　　任何事物都有產生、發展、成熟、消亡或更新幾個階段，電子商務網站也不例外。^[2]任何一個電子商務系統在使用過程中隨著其生存環境的變化，都需要不斷維護、修改，當它不再適應的時候就要被淘汰，就要由新系統代替舊系統，這種周期迴圈稱為生命周期。

　　根據軟體生命周期的原理，電子商務網站可以劃分為系統規劃、系統分析、系統設計、系統實施、系統測試、系統運行和維護等幾個階段。

　　二、B2C電子商務網站建設的一般過程

　　(一)系統規劃階段

　　系統規劃階段的任務是對企業的環境、目標、現行系統的狀況等進行初步調查，根據企業目標和發展戰略，確定信息系統的發展戰略，研究新系統的必要性和可能性。在這個階段給出備選方案，併進行可行性分析，寫出可行性分析報告。待可行性分析報告審議通過後，編製系統設計任務書。

　　1、需求分析

　　為了進行可行性研究分析，首先對電子商務系統的需求進行分析。通過對企業的需求進行調查，明確電子商務網站需要做什麼，做到什麼程度。在此，通過查閱資料、實地觀察、業務專題報告等方法將該電子商務網站的需求歸納為功能需求和性能需求。

　　功能需求：B2C電子商務網站就是Business To Consumer，也就是企業藉助於Internet建立網點進行交易的一個系統。流程上，店家發佈產品信息，消費者線上選購、線上支付，通過物流最後達成交易。所以從購買方看，需滿足消費者線上選購、線上支付等；從銷售方看，要能讓店家整理網上商品、管理訂單等。

　　性能需求：系統運行要穩定，在不同的系統中能正常運行，具有較強的適應性，可移植性。系統要有可擴展性，當出現新的需求時，能將其納入系統，而不必改變原有的基本結構。

　　2、可行性分析

　　在電子商務網站需求已確定的情況下，對系統的進行判定，決定有無必要、有誤可能完成系統的建設。在此，包括如下幾個方面：運行可行性分析：考查方案在企業中合適程度，避免一個可以工作的方案由於最終用戶和管理層的抵制而落選。

　　經濟可行性分析：建立電子商務網站需要經費支出，所以在建站前要評估該開發項目的收益，分析帶來的經濟效益是否超過所需要的成本。

　　技術可行性分析：ASP電子商務網站是動態網站技術的產物，以目前電腦硬體、軟體、網路，已經具備建立B2C電子商務網站的條件。

　　（二）系統分析階段

　　系統分析階段的任務是根據系統設計任務書確定的範圍，描述系統的業務流程，確定新系統的邏輯模型。系統分析階段的成果體現在系統說明書中。

　　1、業務功能分析

　　根據功能需求，B2C電子商務網站要由前臺系統和後臺系統兩部分構成的。前臺系統是供消費者使用的界面，在這裡可以提供註冊會員、查看商品、購買商品、網上支付等基本功能。後臺系統則是提供給銷售方，主要是進行管理商品信息、，同時要進行會員管理、配送商品、以及賬務管理、報表統計等其他功能。

　　2、數據流分析通過繪製數據流圖來幫助確定合理的數據項、確定合適的數據流向、確認合適的數據處理過程，為系統設計提供信息內容及處理依據。B2C電子商務網站的頂層流程圖如圖所示：

　　（三）系統設計階段

　　系統設計階段的任務就是根據系統說明書中的要求，設計新系統的物理模型，最終形成系統設計說明書。在這個階段主要完成系統劃分和資料庫設計的工作。

　　1、系統劃分

　　系統劃分的基本思想是按功能角度自頂向下地將系統劃分為若幹個子系統，子系統再劃分成模塊，層層劃分，逐步設計。在本項目中，B2C電子商務可以劃分成登錄帳戶模塊、瀏覽商品模塊、購物車模塊、訂單管理模塊、後臺管理模塊。

　　登錄帳戶模塊：通過該模塊確定用戶身份，以便為下一個購物車模塊提供必要的信息。同時，還可以結合客戶管理，收集用戶信息，如用戶的年齡、所屬地區、支付能力、購物偏好等。

　　瀏覽商品模塊：按各商品不同類別為客戶提供商品介紹。若客戶滿意，則點選進入購物車模塊。

　　購物車模塊：該模塊存放購買商品的信息、並計算商品的數量和價格等。用戶通過購物車，可以修改商品數目、退回商品。完成購物後，生成訂單，進入訂單管理模塊。

　　支付模塊：用戶購物後可通過多種方法完成支付功能，如網上銀行、第三方支付平臺、線下郵政匯款、貨到付款等方式。

　　訂單模塊：用戶完成購物後，生成訂單，在該模塊中可完成貨物發送前修改或者取消訂單、合併或拆分訂單、跟蹤訂單等功能。

　　後臺管理模塊：這是針對賣家，即網站管理員所設計的模塊。該模塊既可以根據需要統一修改網站界面，也可以根據企業需要，在網站中發佈新商品的信息，還能夠管理已註冊的用戶。

　　2、資料庫設計

　　資料庫的設計是系統設計的一個關鍵步驟。一個好的資料庫不僅能反映現實世界實體之間的聯繫、能滿足用戶需求，還要易於擴充和修改。在本系統中可以建立4個基表。

　　產品信息表（product）：該表主要用於記錄商品的信息，包括商品的編號、名稱、價格、類別、生產廠家、圖片、供貨商情況介紹等。

　　用戶表（user）：記錄會員的基本信息，如用戶編號、用戶名、密碼、真實姓名、身份證號碼、電子郵件、所在地區、郵政地址、郵編、年齡、性別、薪資、住址狀況、喜好等。

　　訂單表（order_list）：該表主要用於記錄訂單的信息，包括訂單編號、訂單產品編號，訂單用戶編號，訂單金額、訂單狀態，下單時間等。該表分別與產品信息表、訂單用戶信息表存在外鍵約束，即一個產品可以在多個訂單中，一個用戶可以下多個訂單。

　　管理員表（administrator）：存儲網站管理員的基本信息，如:ID號、密碼、姓名等等。

　　（四）系統實施階段

　　系統開發實施階段要在系統規劃的基礎上確定整個商務系統結構中各個組成部分的具體內容，完成應用軟體系統的編碼，最終將電子商務系統的應用軟體和各種平臺集成在一起，併購置、安裝和調試電腦設備，完成電子商務系統的上線運行準備。

　　1、編寫模塊：根據前面的系統設計說明書，確定需要用的技術來構築電子商務平臺，並完成應用軟體系統的編碼。

　　本網站主要採用ASP技術編寫所需模塊。^[3]ASP技術類似HTML、Script與CGI的結合體。它是位於伺服器端的腳本運行環境，通過這種環境，可以創建和運行動態的互動式Web伺服器應用程式。其擁有如下優點：可以和HTML或其他腳本語言（VBScript與JavaScript）互相嵌套；在Web伺服器端運行，因此，程式代碼完全保密；以對象為基礎，因此可以使用ActiveX控制項繼續擴充其功能；內置ADO組件，可以存取各種資料庫，大大縮短了程式開發時間。

　　在具體開發中，依據系統設計階段的劃分情況，完成各模塊頁面的代碼。

　　登錄帳戶模塊：用戶登錄頁面login.asp，買家通過用戶名、密碼登錄。新用戶註冊頁面reg.asp，由新用戶登錄並填寫相關信息，其中用戶名、密碼、真實姓名、郵政地址、郵編為必填內容。為了避免同一用戶多次重覆註冊，增加身份證ID和電子郵件審核，避免出現相同用戶名、ID、電子郵件。同時，在註冊頁面和登錄頁面都加入驗證碼，防止機器批量註冊和暴力破解。

　　瀏覽商品模塊：在網站中向買家展示各種商品的詳細信息。

　　用戶可根據類別、品牌瀏覽商品，並具體查看某一商品的詳細信息，也可以輸入所要查找的商品名稱或種類，即啟動查詢頁面seek.asp。

　　購物車模塊：添加商品到購物車。找到所要購買的商品後，點擊購買。啟動購物車模塊cart_add.asp，記錄所購商品的信息，如商品編碼、購買數量、單價等。點擊購物車，即啟動cart_show.asp，顯示商品信息，如商品名稱、單價、購買數量、應付總金額等。此時，若返回網站繼續購物或修改購買數量都會啟動cart_update.asp頁面，修改購物車中相關信息。

　　支付模塊：用戶購物結束後，可點擊收銀台，進入支付模塊。

　　多種支付方式可供選擇：網上銀行支付、第三方平臺支付、郵政匯款、貨到付款等。以近年來頗為流行的第三方支付平臺"支付寶"為例，傳遞參數到相關頁面即可完成線上支付。相關參數如下：支付介面gateway (https://www.alipay.com/cooperate/gateway.do?)、 服務參數service、合作商伙伴編號partner、時間out_trade_no、商品名稱subject、商品描述body、支付類型pay-ment_type、價格price、展示商品地址show_url、用戶帳號sell-er_email、安全校驗碼key、重定向地址return_url、數量quantity等。其中，合作商伙伴編號、安全校驗碼在註冊支付寶之後，可"我的商家服務"裡面可以獲取。

　　訂單模塊：啟動訂單模塊order_add.asp，根據購物車模塊的信息以及用戶信息，如用戶編號、姓名、郵政編號、郵政地址等信息生成訂單。若用戶未登錄，則會跳轉到登錄界面。訂單or-der_show.asp可顯示該訂單的相關狀態，如訂單未支付、訂單已支付、訂單發送中、訂單已完成，以及訂單中所選購商品的名稱、價格、數量、收貨人、收貨地址等信息。如果需要，可以通過or-der_update.asp更改訂單的收貨人、收貨地址等。

　　後臺管理模塊：商品管理子模塊，賣家對商品的管理，查看商品目錄、增加商品品種、清除淘汰商品和修改原有商品信息等。訂單管理子模塊，可以控制訂單的執行、跟蹤訂單的狀態。會員管理子模塊，管理用戶賬戶，包括查看審核會員資料、更新會員資料和刪除不合法會員等。

　　2、構建硬體平臺：根據各類技術標準，選擇合適的硬體構建網站運行的平臺，即其運行所需要的軟硬體環境。

　　機器硬體可以選用奔騰(R)雙核處理器E2220，2.4GHz、1000M網卡、記憶體1G、硬碟SATAII 160G。操作系統可以選用Windows2003，WindowsXP等。

　　本系統是基於WEB的採用ASP技術的B2C電子商務網站，首先，在本機安裝配置IIS，使之能讀取和運行腳本，並設置網站預設打開文件為index.asp。架站完成後，在IE瀏覽器地址欄輸入 http://localhost, 調試站點。

　　（五）系統測試和維護階段

　　系統測試階段的目的是為了發現系統中存在的問題，需要測試系統的功能是否滿足設計的需要，判定系統是否存在各種程度的錯誤或漏洞，測試的內容包括軟體整體測試、極限測試、可操作性測試等。對於電子商務而言，主要考慮系統整體性能的指標參數，例如系統可支持的最大的用戶數、系統的壓力與性能比、系統的安全性指標等。在系統測試之後形成系統測試分析報告。

　　1、系統測試

　　測試時，我們採用本地端架站的方式，通過在網路內部進行測試。把所有的設計文件全部完成並初步修正後，將完整的內容一起上傳到預定的空間，最後進行實際的聯機測試。

　　2、運行和維護

　　運行不僅僅是指電子商務網站投入運行使用，更為重要的是企業在一種新的商務模式下運轉，包括相應的維護、管理以及基於系統的市場、銷售、財務等基本商務環節的動作與組織。網站維護不僅包括對網站正常運行的維護、管理性工作，更主要的是對網站內容的更新、修改方面的網站建設。對於不能修改或難以修改的問題記錄在案，定期整理成新需求建議書，為下一周期的系統規劃做準備。

　　根據軟體開發過程中軟體生命周期原理的應用，通過對B2C電子商務網站建設的現狀及其特點的分析，不難看出：要開發一個成功的電子商務網站，必須利用軟體生命周期原理，分階段按步驟有條不紊的實施，才能在網站的開發中提高效率，提高其穩定性、可靠性、可維護性和用戶滿意度，取得事半功倍的效果。