軟件生命週期的模型
任何軟件都是從最模糊的概念開始的：爲某個公司設計辦公的流程處理；設計一種商務信函打印系統並投放市場。這個概念是不清晰的，但卻是最高層的業務需求的原型。這個概念都會伴隨着一個目的，例如在一個“銀行押匯系統”的目的是提高工作的效率。這個目的將會成爲系統的核心思想，系統成敗的評判標準。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）模型在功能上等價於產品的一個子集。注意，這裏說的是功能上。瀑布模型的缺點就在於不夠直觀，快速原型法就解決了這個問題。一般來說，根據客戶的需要在很短的時間內解決用戶最迫切需要，完成一個可以演示的產品。這個產品只是實現部分的功能（最重要的）。它最重要的目的是爲了確定用戶的真正需求。在我的經驗中，這種方法非常的有效，原先對計算機沒有絲毫概念的用戶在你的原型面前往往口若懸河，有些觀點讓你都覺得非常的吃驚。在得到用戶的需求之後，原型將被拋棄。因爲原型開發的速度很快，設計方面是幾乎沒有考慮的，如果保留原型的話，在隨後的開發中會爲此付出極大的代價。至於保留原型方面，也是有一種叫做增量模型是這麼做的，但這種模型並不爲大家所接受。
事實上，其實現在的軟件組織中很少說標準的採用那一種模型的。模型和實用還是有很大的區別。
軟件生命週期模型的發展實際上是體現了軟件工程理論的發展。在最早的時候，軟件的生命週期處於無序、混亂的情況。一些人爲了能夠控制軟件的開發過程，就把軟件開發嚴格的區分爲多個不同的階段，並在階段間加上嚴格的審查。這就是瀑布模型產生的起因。瀑布模型體現了人們對軟件過程的一個希望：嚴格控制、確保質量。可惜的是，現實往往是殘酷的。瀑布模型根本達不到這個過高的要求，因爲軟件的過程往往難於預測。反而導致了其它的負面影響，例如大量的文檔、繁瑣的審批。因此人們就開始嘗試着用其它的方法來改進或替代瀑布方法。例如把過程細分來增加過程的可預測性。
案例一:利用軟件生命週期創建B2C電子商務網站[1]
一、軟件生命週期
任何事物都有產生、發展、成熟、消亡或更新幾個階段，電子商務網站也不例外。[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電子商務網站建設的現狀及其特點的分析，不難看出：要開發一個成功的電子商務網站，必須利用軟件生命週期原理，分階段按步驟有條不紊的實施，才能在網站的開發中提高效率，提高其穩定性、可靠性、可維護性和用戶滿意度，取得事半功倍的效果。