係統後期運行階段，包括係統安裝投入使用後對係統的使用和評審，還包括為完善係統所進行的係統修改。用戶和技術人員將在新係統投入運行後對係統進行跟蹤審查，以確定新係統是否達到原定目標，是否還需進行修訂和更改。係統調試完畢之後，可能還需進行一些糾錯、改善處理效率等維護工作。經過一段時間後，係統可能需要進行更多的維護才能保持有效地工作並滿足用戶目標，直到係統有效生命周期的結束。一旦係統生命周期走向結束，則會要求一個全新的係統來替代老係統，一個新的周期可能再次開始。
③生命周期法的局限性。係統生命周期法適用於大型事務處理係統和高度結構化且完全可定義的管理信息係統的開發。它對複雜的技術性係統，像航天發射、航空指揮和煉油管理等也較為適用。這些應用都需要有嚴格且規範的需求分析，預先可確定的說明書，以及對整個係統建立過程嚴密地控製。然而係統生命周期法存在著嚴重的局限性，它不能很好地適用於90年代以來成為主流的小型台式機係統。它有以下一些特點：
第一，生命周期法需要大量的資源。用生命周期法進行係統開發需要花費大量時間搜集信息並準備長篇的說明書。在一個係統被最後安裝之前，它可能要花費幾年時間。如果花費時間太長，信息係統運行之前信息需求就可能發生變化，這樣花費多年和大量資金開發的係統，在還處於設計過程中就可能過時了。
第二，生命周期法缺乏靈活性，不適合需求的多變。當然為確保需求得到滿足，生命周期法也允許對係統進行修改。當需求不正確或遇到錯誤時，就需要按照生命周期活動的順序反複進行。除產生必要的附加文檔外，事實上還增加了開發時間和成本。因此這一方法更加適合開發過程一開始需求就完全確定的係統，一旦用戶同意了說明書內容，則它就基本確定不變了。但用戶不可能單憑說明書去想象一個最終的係統。實際上，用戶可能需要親眼見到並實際操作一個係統，才能確定係統是否滿足他們的需要。而用生命周期法要做到這一點幾乎是不可能的。所以用戶對說明書尚未完全理解就簽字通過，到編程測試階段才發現其不完整或不符合需求的現象時有發生。
第三，生命周期法不適合麵向決策的應用。因為決策問題可能是高度非結構化和不固定的，需求經常變化。另外決策應用往往缺乏很好的可定義模型及過程，決策者對自己的信息需求常常無法預先確定，他們可能需要借助一個實際係統來進行試驗。規範化的需求說明可能會影響係統開發者探索和發現問題，所以對這些高度不確定性問題不適合用生命周期法進行解決。當然，這些問題中的一部分可用後麵介紹的幾種信息係統開發戰略來解決。
(2)快速原型開發法
原型法是美國學者JamesMartin在20世紀80年代初提出來的，它是針對生命周期法在係統開發過程中存在的缺陷而誕生的一種係統開發方法。
①基本思想。生命周期法雖然有嚴密的理論基礎，嚴格的階段劃分，詳細的工作步驟和規範的文檔要求，但它對係統的用戶和開發者的要求是相當高的。在六、七十年代，由於信息係統的應用範圍比較狹窄，如財務、倉庫、設備等管理方麵，使用環境相對穩定。在係統開發之前，用戶的需求可以預先定義且高度結構化。開發者對整個係統的目標、功能等有一個全麵、深刻的了解，並製訂詳細的開發計劃。這些係統一經完成，往往不需要有很大的變動。這種方法與當時的計算機發展和企業管理水平相適應，成功地開發了大量實用的係統，成為當時普遍采用的方法。
②原型法的步驟。原型法的四個步驟，它包括：
第一步：確定用戶基本需求。係統設計者(通常是信息係統專業人員)和用戶一起工作一段時間，以便獲得用戶的基本信息需求。
第二步：建立一個係統的初步原型。係統設計者快速建立一個工作模型，最好采用第四代軟件工具實現快速開發。該原型可能隻完成係統的主要功能。
第三步：試用原型，精練用戶需求。為了確定原型是否滿足用戶需求並提出改進原型的建議，應鼓勵用戶使用係統進行工作。
第四步：修改並提高原型。係統開發者記下所有用戶提出的修改意見，並對原型做相應地精練。當原型被修改完畢後，再返回到第三步，重複第三步和第四步，直到用戶達到滿意為止。
當上述循環過程結束時，則原型被認可，成為一個可使用的係統，並給出最終的應用說明書。實踐證明原型法比係統生命周期法更快捷、重複性好且更靈活、實用。
③原型法的優、缺點。對有些類型的信息係統而言，用原型法開發比用生命周期法更有效。特別是當需求不能完全確定時，原型法顯得更為實用。有些項目可能難以事先確定需求，事實上在係統實現過程中需求也可能是經常變化的。特別是那些麵向決策的應用，信息需求往往不十分明確。管理者們可能覺得好信息固然需要，但必需哪些信息卻無法肯定。例如，一個大型證券公司可能需要用一些綜合信息來分析經營績效，那麼績效用什麼來衡量呢?所需信息能全部從人事係統中獲得嗎?還是必須把委托人單據的數據也收集起來?報表中哪些項目該做比較?是否包括對某些統計進行分析的中間處理過程?對許多決策支持的應用來說，很難在開發初期就把全部需求統統確定下來，因為管理者們無法預見係統是怎樣工作的，他們也不可能清楚地想象出最終的係統是什麼樣子。
原型法對信息係統最終用戶界麵的設計尤其有用。因為用戶的需求與行為無法完全預知，它們對環境有很強的依賴性，原型法能夠確保用戶對將使用的係統中的某些問題立即作出響應。
另有一種情況，係統開發者對最終用戶需求可能十分清楚，但對設計方案的某一技術特點沒把握，例如一個大型超市連鎖店打算改進它的庫存控製係統，允許從不同地點方便地聯機訪問它的主文件。這一應用可能需要大量聯機數據輸入和主要信息輸出的屏幕顯示格式。但係統開發小組對屏幕格式應如何從一個聯機屏幕轉到另一屏，以及該如何調整屏幕格式沒把握。因此開發小組決定采用能夠建立人機對話界麵的實用工具來開發多個屏幕格式原型。這些屏幕格式能很快地被開發出來，並展示給用戶。
原型法鼓勵用戶參與到整個係統開發過程中去。由於用戶從開發設計過程一開始就與係統打交道，在對原型進行評價和精練的過程中，用戶自始至終都積極地參與設計工作，因此原型法開發的係統更容易滿足用戶需求。特別是當原型法被用於決策應用開發時，有可能避免開發成本超支，並減少由於需求不能被一次滿足而產生的設計錯誤。經過很短時間用戶就能得到一個實際的工作係統，盡管它可能是初步的，但用戶的滿意程度會逐步提高。
然而，原型法也有其應用局限性。它不可能取代細致的需求分析、結構化的設計方法以及詳盡的文檔資料，也不可能完全取代傳統的開發方法和工具。另外目前能用於進行原型法開發的方法和工具還十分有限。
那些簡單的數據操作和記錄管理的應用係統比較適合用原型法開發；而對那些批處理或大量計算和有著複雜過程邏輯的係統一般不適合用原型法處理。原型法更適合較小的應用開發，對大型係統就須分成幾部分，一部分一部分地分別建立原型。如果缺乏用傳統方法進行透徹的需求分析，就無法對大型係統進行劃分，因為一開始很難分辨係統各部分之間存在哪些相互的影響。
快速原型開發法的不足是它可能會掩蓋係統開發中的一些基本步驟，基本的係統分析和需求分析被削弱。快速開發原型的需求可能會導致開發小組在尚未捕獲起碼需要的情況下，單純為工作原型而倉促行動。在大型係統開發中這一問題尤為明顯。若原型法不以全麵、徹底的需求分析為先導，那麼就不能明確如何建立一個係統原型，將原型轉換成一個完善係統的最後步驟也就無法進行了。一旦原型建立起來，往往就成了最終的應用係統。如果原型工作很理想，那麼管理者們可能就會認為無需再重新編程和設計了。但這些草率建立起來的係統，在規範的生產環境中進行維護和支持可能都十分困難。因為原型沒有通過細致地建立過程，它們的技術性能可能是低效的。所以在一個生產環境中，它們可能無法適應大量數據或大量用戶處理需求。另外，原型法開發的係統仍需建立詳細的文檔並進行測試，但通常這些步驟有所簡化。因為構造原型十分容易，所以管理者們就覺得測試工作可由用戶自己完成，測試中的任何疏漏也都能被隨後糾正。正由於係統非常易於更改，所以文檔內容很難做到與係統更新同步。