傳統結構化軟體系統分析與設計


    
         （資料來源：取材於http://www.dotspace.idv.tw/sofeeng/sofeeng_6.htm安德華科技股份有限公司技術長陳器中)

    

    系統發展(Development)

系統發展分為規劃(Planning)、設計(Design)和實施(Implementation)。須考慮未來資料量增加、企業的成長與擴充、科技的進步與系統整合性以便設計一個有彈性、可動態調整且易於維護的系統。

系統的三大基本要素：

1. 輸入(Input Data)
2. 處理與控制(Process Logic & Control)
3. 輸出(Output Information)

系統規劃通常採用由上而下的作業方式，其做法先從整體企業目標開始，探討企業營運特性，企業組織建立關係，資料處理應用邏輯，達到資訊系統架構建立完成檔案設計工作。而資訊管理的順序卻是與前相反由個別檔案資料的輸入一直到達成企業營運目標為止。

系統規劃(Planning)：

系統要做什麼(What)?

初步研究：
定義問題的範圍與建立系統可以解決問題、滿足需求、運用新科技、增加系統效能。

可行性研究：
定義問題需求範圍、蒐集資料、組織管理者與使用者需求。訂立階段計劃、訂立組織人力計劃、訂立推動計劃、訂立維護管理計劃、訂立教育訓練計劃、訂立文件製作計劃、訂立經費計劃、訂立其他配合措施。

系統分析(System Analysis)

系統分析，係利用系統方法或技術，建立系統觀念性架構，探討研究問題的特性，並提出具體和可行性方案的實際過程。廣義定義為一種有組織的方式來解決問題，達成目的。是一門研究如何建立系統來解決問題的科學。

系統分析的運作結果，是由資料的輸入，經過組合與處理，而輸出有意義的資訊，提供與輔助管理者進行決策。

良好系統具備的特性：整合性(Integertion)、使用者易操作性、管理能力強性、實用性、資料量處理需求、符合組織風格、達成最大成本效益、考量使用人員因素、結合外在科技、法規、經濟、社會等因素、彈性的組織變更及企業成長需求。

系統分析師(System Analyst)為運用各項分析工具，整理所獲得的資訊，找出一個最適合的方法解決問題的人員。須具備專業知識的能力，對系統的輸、出入與處理的軟、硬體與對資料庫的特性知識深入了解，也具有程式設計撰寫的能力，同時要具有系統企業領域知識(如財務、貿易、生產製造等)。

在規劃中由需求訪談，可以獲得管理者與使用者的各項企業行為需求與組織問題的特徵與本質，了解決策者訊息需求的關鍵性資訊及優先順序。由企業診斷可以獲知現行系統的作業程序與運作狀況，找出現行系統不足所在及未來需求的擴充性，了解問題發生的原因與理由，進行企業的改造(BPR)。再由需求訪談與企業診斷結果進行提出各種可行性分析與研究報告，提出改善現行系統方案與解決各項問題的處理方法。當然各種問題不一定完全可由電腦系統可以解決問題，某些部分需要靠組織變革、組織章程變更及流程改造來解決問題。

可行性分析

可行性分析報告要獲得高層管理人員支持，定義明確的問題描述與確認的目標方向，講求實事求是的效果，正確的評估所需資源，最佳生產品質，選擇適當的資訊科技與設備。在可行性目標上還要對系統中要求彈性與可維護性(Flexibility & Maintainability)，時程與成本(Schedule & Cost)，效率(Efficiency)，即時回應(Quick Response)，整合性(Integration)，安全性(Security)，可靠性(Reliability)，簡易性(Simplicity)，相容性(Compatibility)。

可行性研究建議案提出方式：

系統分析工具(一幅圖畫勝過千言萬語)。將系統所需處理步驟使用流程圖(Flowchart)表現。

系統設計(System design)結合執行活動工作程序與設備資源來完成系統使用者所要求的目標，可以令系統達到最大、最佳、與滿足需求的功能。考慮每一個獨立程序的隨機關係-與其他程序間產生互動的關係、循序關係-各程序間的前後順序關係和時間關係-各程序在不同時間期間所存在的關係。

系統設計(Design)

如何完成這一個系統(How)?

結構化設計(Structure Design)

結構化設計(Structure Design)採用由上而下漸進且合乎邏輯思維的方式進行設計，建立起層次關係的結構，細分各層的問題逐一探討解決其問題的設計模式。

資料輸入方式的決定考量是採用批次性輸入(Batch Input)，還是採用即時性輸入(Online Input)，一般常態異動式日常作業大都採用即時性輸入方式，進行統計或結帳式作業可採用批次性輸入方式。

編碼設計：制定編碼原則，採用數字、文字、文數字或符號；主鍵(Prime Key)唯一鍵值的規劃設計，採用循序鍵或存取鍵，關聯鍵值的規劃設計：索引鍵值或複合索引鍵值(Index Key)的規劃設計，編碼長度，避免混淆字形，同音異字等。資料輸出的設計，精確、時效與適切性，表單的設計，考量用紙大小、份數、傳遞方式、顏色、字體大小、主標題說明、次標題說明、編號方式、分頁考量、頁首資訊、頁尾資訊、上下左右空間關係、複寫欄位功能、印表機功能與格式。圖表的設計，圖形特性選擇、表現方式、顏色或條紋區隔、尺標刻度的計算、多維空間的建立、圖形標示及圖例說明。

成本效益評估：系統使用環境考量，網際網路、區域網路、企業網路、單機使用等；使用硬體設備的成本考量，伺服器、終端電腦、個人電腦、備份設備、安全機制與管理；軟體工具的成本考量，工具軟體、應用軟體、資料庫軟體、作業系統；維護管理的成本考量，訓練使用、維護費用、管理人員薪資、更新版本費用等等。透過計劃需求書(RFP Request for Proposal)提出所需系統的軟硬體資訊需求，具備有功能需求規格，評估程序與建議，各項軟硬體及廠商的介紹與說明。考量硬體的相容性、成本、可靠度、普遍性；軟體的適用性、成本、品質；廠商的經驗與規模、技術能力、人員素質、財務狀況、教育與訓練、服務滿意度等等。分析系統的顧問諮詢成本，期初建置成本，轉換成本，每期維護成本，後續發展成本，操作使用成本，教育訓練成本，初期評估成本等等。

實施(Implementation)

系統安裝與使用訓練
系統實施

元件式軟體系統分析與設計
元件分析方式
物件導向系統分析設計方法是一套以重複使用為基礎的系統分析、設計及程式製作一氣呵成的方法。

物件導向技術的觀點來看，我們認為所要模塑的真實世界是由物件所組成的，真實世界的運作是由個物件成員之間的互動而成，因此先天上用這樣方法去模塑真實世界將比用結構化方法來的穩定，而且在與客戶交談時也比較容易得到客戶的認同，因為我們所談的是客戶心中的真實世界，而抽象的方式就功能面來探討模塑系統。

現今各式各樣的物件導向分析(OOA)，目前較著名的方法理有Object Modeling、Technique、Booch Method、Function/Mellor Method及Use Case等等。這些方法除了Use Case以外，其他的方法大體上都是物件模型（Object Modeling）為主，再輔以動態模型（Dynamic Model）及功能模型。其中物件模型是用來述真實世界的靜態關係，所談的內容是物件．物件及物件之間的關係，如組成關係、繼丞關係或其他各式關係。

動態模型通常是描述系統動態行為，所談的內容通常先用腳本（Scenario）描述物作對外界刺激的反應及各物件之間的動關係,並用事件追蹤圖(Event Trace Diagram)追縱各個物件之間的動態行為，或用態圖描述單一物件對外界刺激的反應。功能模型則用功能觀點來看系統，與傳統的結構化方法的DFD相同。

分析階段描述系統要做什麼，設計階段考慮如何才能滿足客戶的需求。

第一階段是需求收集階段：我們利用使用個案進行需求蒐集工具。

第二階段是系統分析階段：依據第一階段的使用個案依據原則找出可能的類別，再用一套篩選原則找出適合的原則，利用物件圖進行系統的領域模型及應用程式塑模工作，以使用狀態圖來描素系統的動態行為。

第三階段是系統架構設計：考慮整個架構設計，如何分割系統，使用整體運作能夠顧慮到結構性、執行效率與擴充性等，此時可產出商業物件(Business Object)、應用程式物件與技術物件等。

第四階段為設計階段：考慮如何設計系統介面，如何將物件圖對應到資料庫上，如何設計所需的演算法，如何選用可再用的物件等等。

第五階段：可依據第一階段的使用個案進行程式測試個案製作。

第六階段：將使用個案的測試結果結合系統架構設計可以編製成使用手冊，符合再用的需求。

運用CASE工具UML(Unify Modeling Language)，結合了Use Case，OMT和Booch Method三者的精華成為設計分析更好的方法。

使用元件再用模版之優點

提供多樣化的用戶端選擇，如Internet BUI(Browser User Interface)或是Windows GUI(Graphics User Interface)。可透過Internet由遠端使用系統，使用彈性度大，不受空間與時間限制；充份運用Internet降低連線成本；軟體元件同時提供ActiveX使系統執行於區域網路，與DCOM版本使系統執行於廣域網路；使用者可透過參數化的系統設定，讓系統容易維護、調整與使用；系統由元件組裝而成，易於與其他元件化系統整合；進行跨地域性的資訊整合，並且縮短資訊擷取時程，提昇企業競爭力；資料維護方式，簡單易維護；報表查詢方式，迅速易調整；業務交易方式，彈性易擴增。元件再用，軟體量產。

元件化應用系統架構

多層式元件化應用軟體開發平台 (eMAX Framework)建構
應用系統架構：為支援組織特定功能之資訊系統(OrgManager)，而應用系統架構則為協助提供組織所需資訊之應用系統模式，他顯示了應用系統、資料與其相互關係，依據業務作業模式界定出組織未來電腦作業之功能與範圍，以作為設定系統發展優先順序之基礎。應分析現行資訊系統之功能與資料檔案，考慮應用系統架構的可行性，以免重複開發應用系統而浪費人力與物力。

應用系統建構要求：

1.系統是屬於多層式軟體架構(Muti-Tier)，將軟體予以切割成展現層(View Layer)、網路層(Net Layer)、處理層(Control Layer)、分封層(Encapsulation Layer)與資料層(Data Layer)。

2.系統可運作於多層次(Muti-Tier)的硬體環境中，建置多形網路結構如：展示層、控制層、資料層透過區域網路連結。展示層透過網際網路與控制層、資料層連結。展示層、控制層透過網際網路與資料層連結。

3.系統可於網際網路(Internet)下運作。

4.系統是由軟體元件組裝而成。

5.系統是開放性架構(Open System)提供業務元件隨插即用，視窗圖形使用者介面(Graphic User Interface)與瀏覽器介面(Browser)。View Manager是視窗畫面的編輯器，它內建的元件綱要資訊(Meta Information)能力，可以讓所有產生的作業畫面在不經過編譯(Compile)的情形下，隨編即用。

6.Web Manager是網頁畫面編輯器，則是透過資料庫的資料綱要機制，以最快速的方式自動產生ASP、XML、XSL等檔案，讓網頁可以很容易的連結到應用邏輯層中的作業元件。

7.其支援多國、多點、多公司、多語言、多單位、多幣別及多網域、多伺服器等應用系統在架構面及使用面的複雜需求，同時也支援網際網路B2B、B2C電子商務交易、非同步資料更新遠端資料存取及工作流程(Work Flow)管理等應用面的延伸需求，而在客戶導向的e世代裡如何面對快速變遷的使用者需求，eMAX Framework提供了動態企業塑型(DEM Dynamic Enterprise Modeling)能力，讓使用者可以很容易的動態調整或產生報表、企業邏輯、操作畫面及程序，甚至可以完全不必透過軟體商廠，即完成客製化的目的。

3.3.2. eMAX Framework的驅動引擎：

eMAX Framework目前提供了三個可以同時並存的驅動引擎：
1. AcroFrame：
負責上述多層式元件化應用系統架構的建置及運作，應用系統的啟動程式是eMAX.exe。
2. AcroBrowser：
是一個可以從瀏覽器下載並自動安裝的元件，它取代了AcroFrame中的啟動程式eMAX.exe。使用者可以直接透過瀏覽器執行在AcroFrame中設計好的應用系統，無需再安裝任何其他客戶端程式。
3. AcroWorkFlow：
是一個工作流程引擎，包括Server Agent、Worklist Agent、Instance Agent，可以將AcroFrame中的應用作業如訂單作業循環、採購作業循環等由人工驅動改為流程驅動。由於是多層式元件化的應用系統架構，無需因為架設了工作流程引擎而重新設計應用程式。

領域分析

領域工程主要目的即在於可再用性，包含了軟體設計架構的再用、軟體發展流程的再用、文件的再用及領域知識的再用。

隨著軟體的應用與企業的經營越來越緊密，為了提身企業的競爭力，必須可即時反映政府的法規，提供市場的需求服務性，增加企業的安全性，提供即時的多樣化的分析，滿足企業集中式與多點多廠分散式的管理需求，彈性功能增加即最小變動達成功能的特性，隨插即用的技術成熟，以物件導向技術開發的軟體元件技術機制因此而生。

領域工程方法進行領域分析、制定領域架構規格、實做出領域元件、制定領域再用程序規格、維護及修正擴充領域元件。
物件導向設計(OOP)的目的其實就是將物件導向分析出來的物件與物件間的互動方式，用程式設計出來，最重要的是將物件的類別(Class)撰寫出來，然後將個體間互動方式利用物件及其方法撰寫出來，如此即可完成一個應用系統。

eMAX領域範圍包含企業資源規劃系統(eERP)、電子商店系統(eStore)、電子商城系統(eMall)以及電子聯盟系統(eAlliance)等。eERP的應用範圍包含配銷、生產、財務管理及企業決策等領域，其可滿足多組織企業內庫存、採購(包含進口)、銷售(包含出口)、生產、物料需求、產能規劃、財務、會計以及主管決策等管理領域的需求。eStore和eMall則為B2C最佳解決方案。至於eAlliance則可滿足企業B2B的需求。

依據業務需求進行可行性分析

1. 技術可行性(Technical Feasibility)
2. 經濟可行性(Economic Feasibility)
3. 推動可行性(Motivational Feasibility)
4. 時程可行性(Schedule Feasibility)
5. 操作可行性(Operation Feasibility)

應用分析項目

1. 回應時間
2. 危機時間(可容忍時間)
3. 使用率
4. 使用者數
5. 複雜度
6. 一致性

資料實體分析項目

1. 時效性
2. 分割性
3. 必要性
4. 變動性
5. 共用性
6. 安全性(AuthorityManager)

應用系統架構(Application Architecture)

為了讓元件得以在一定的規則下運作，特針對資訊管理系統三大應用範圍將元件運作架構加以定義:
(1)基本資料維護類:統歸一般性基本資料如員工，公司，部門等資料之基本資料之新增，刪除，修改，查詢，停用，復用功能均規於此類。系統可開發DM(DataMaintenance)元件統籌基本資料維護工作，其中搭配Table Manager及DataDictionaryManager元件工具負責掌握資料欄位，型態，欄寬與多語言控制;搭配TM(TransactionManager)元件負責將SQL指令執行於指定的資料庫。資料維護邏輯：

1. 取得資料欄位，型態，欄寬等綱要資訊。
2. 顯示編輯視窗。
3. 使用者由編輯視窗輸入資料，或以泛查輸入。
4. 系統檢視輸入資料。
5. 依作業動作取得SQL指令公式，並鎖定資料。
6. 結合SQL指令公式與輸入之資料取得完整SQL作業指令。
7. 執行SQL作業指令。

(2)業務交易類:統歸以填具單據進行資料庫異動交易者歸於此類。業務交易邏輯架構經分析後可得，交易單據單頭與單身之資料欄位，型態，欄寬。使用者輸入單據資料。.將輸入單據資料包裝成一單據參數封包。依作業動作取得相關子系統BSO元件。依事務交易代碼，呼叫相關BPE元件群，依序處理單據參數封包以完成事務交易。撰寫BPE訂定交易規則流程：

1.取得單據單頭與單身之資料欄位，型態，欄寬等綱要資料。
2.顯示編輯視窗。
3.使用者輸入單據資料。
4.系統檢視輸入單據資料。
5.依作業動作處理單據參數以完成業務交易。

(3)報表查詢類:統歸以查詢條件取得資料庫資料以進行資料瀏覽，報表列印或轉檔者均歸為此類。系統可開發QM(QueryManager)元件統籌資料查詢工作，其中搭配ReportManager元件工具進行報表查詢邏輯架構。設定報表查詢SQL：

1.取得查詢項目之查詢條件資料欄位，型態，欄寬等綱要資料。
2.使用者輸入查詢條件資料。
3.系統檢視查詢條件資料。
4.依查詢條件資料進行查詢。
5.取得查詢結果並顯示。

元件開發系統程序
以元件方式開發系統，其程序仍不跳脫需求分析，系統分析與系統設計三大步驟，只是多引用了物件導向系統分析設計中之循環漸進(Spiral)觀念，隨時修正分析設計結果，並以各式模版原則組裝元件以規範元件運作。

專案之推行，建議先以開發共通元件，再以領域元件與使用介面平行開發方式進行，較能獲得較佳之人力與時間成本掌控。關於專案的分工，會較以往容易。當元件規格與組裝模版底定，元件的開發與使用介面的開發便可分頭並行，視適當時間會合組裝成系統。

專案基本成員，建議以專案經理，系統分析師，元件設計師，使用界面設計師與資料庫管理師搭配進行。

需求分析

領域分析：

瞭解與熟悉所開發系統之應用範圍。

資料字典(DataDictionaryManager)專門用語建立：建立系統開發過程中之標準用詞，做為爾後系統開發與設計過程中之標準用語，此標準用語另可作為資料庫欄位，作業畫面之標準用詞語。

領域模型：

收集與瞭解領域資料。

記錄專門用語。

1.收集系統用詞。
2.統一用詞。
3.建立標準型別。
4.建立繼承字詞。
5.建立字詞，設定型別與繼承字詞。
6.建立字詞別名。

與使用者訪談，瞭解所開發系統與相關環境關聯。

繪製領域模型：

使用個案分析(Use Case)

收集與記錄使用者需求。根據使用者或客戶之需求描述，使用自然的語言來記錄使用者期望的狀況，進而瞭解與分析使用者的真正需求。

1.使用者訪談。
2.找出領域使用個案。
3.找出系統使用個案。
4.記錄領域使用個案。
5.記錄系統使用個案。
6.繪製使用個案圖。

作業畫面分析：

規範最終使用介面之作業畫面，以做為與使用者確認最終產出之依據。

1.依使用個案製作作業畫面初版。
2.與使用者訪談，搭配使用個案，修訂作業畫面。
3.與使用者確認作業畫面。

系統分析

資料庫分析(Database)：
建立系統資料庫，儲存系統資料。產出資料庫關聯圖，資料庫，表格。

1.分析資料表格與資料表格關聯。
2.建立實體資料庫。
3.建立實體表格，定義欄位。
4.設定資料庫使用者，表格使用權限。

共通服務元件(CSO)分析：
找出系統會使用到的共通服務，並歸納出相關負責元件。產出共通服務元件清單，共通服務元件建構管理。

1.根據系統使用個案，找出共通服務需求。
2.根據共通服務需求，依現行架構找出共通服務元件。
3.擬出共通服務元件清單。
4.擬出共通服務元件建構管理。

業務元件分析(BSO Business Service Object，BPE Business Process Edit)：
找出系統會使用到的業務服務，並歸納出相關負責元件。服務介面由業務服務元件(Business Service Component)負責， 服務項目由業務處理元件(Business Process Component)提供。產出業務元件清單，業務元件建構管理。

1.依作業畫面找出所有業務服務需求。
2.依子系統區分，定義業務服務元件(BSO)。
3.依業務服務需求定義業務處理元件(BPE)。
4.擬出業務元件清單。
5.擬出業務元件建構管理。

系統設計

共通服務元件(CSO Command Service Object)設計：
設計共通服務元件服務界面(interface)，產出共通服務元件技術規格。

1.依需求設計共通服務元件服務界面。
2.撰寫共通服務元件技術規格。

業務元件(BSO，BPE)設計：
設計業務服務元件與業務處理元件服務界面(interface)，產出業務服務元件技術規格，業務處理元件技術規格。

1.設計業務服務元件與業務處理元件元件服務界面。
2.撰寫業務服務元件與業務處理元件元件技術規格。

系統建置

共通函式建置：
規範共通函式建構所在，規定引用路徑，以進行撰寫共通函式程式讓所有程式引用。產出共通函式建置規範，共通函式使用手冊。

1.規定共通函式建構所在路徑。
2.規定引用原則與引用設定程序。
3.傳寫與發佈共通函式建置規範。
4.撰寫共通函式程式。
5.共通函式測試。
6.撰寫共通函式使用手冊。

共通服務元件(CSO)建置：
規範共通服務元件設計程序，命名原則以完成共通服務元件。產出共通服務元件發佈規範。根據共通服務元件清單，建置規範與設計規格進行建置，發佈共通服務元件。

業務元件(BSO，BPE) 建置：
規範業務服務元件與業務處理元件設計程序，命名原則以完成業務服務元件與業務處理元件。產出業務服務元件與業務處理元件發佈規範。根據業務服務元件與業務處理元件元件清單，建置規範與設計規格進行建置。發佈業務服務元件與業務處理元件元件。

定義業務作業(BPA-Business Process Action)是由那些業務處理元件(BPO- Business Process Object)的方法(Method)組合而成。自動產生編譯式業務處理元件的主體程式碼，並支援直接於作業編輯器上用不同語言撰寫解譯式業務處理元件程式碼。

協力廠商元件安裝(3rd Party Component)：
規範管理所有外購元件，讓系統所有程式引用。產出外購元件安裝規定，外購元件之合法使用文件，規定外購元件建構路徑，規定外購元件安裝引用程序，保存外購元件合法使用文件。

主畫面模版建置(System Manager & View Manager)：
規範系統主畫面功能佈置與子視窗啟動原則，以做為程式設計人員依循。主畫面模版技術指引，決定主畫面運作模式，決定主畫面畫面佈置，決定子視窗啟動方式，使用共通服務元件開發模版視窗與程式叢集，撰寫主畫面模版技術指引。

GUI模版建置：
規範系統內所有基本資料之操作模式，所有交易操作模式，以做為程式設計人員依循。產出基本資料維護作業模版技術指引，分析基本資料維護作業共通性質，使用共通服務元件開發模版視窗與程式叢集，撰寫基本資料維護作業模版技術指引。業務交易作業模版技術指引，分析業務交易作業共通性質，使用共通服務元件開發模版視窗與程式叢集，撰寫業務交易作業模版技術指引。

WEB模版建置：
規範系統內網頁之操作模式，透過Web Manager是做網頁畫面編輯器，透過資料庫的資料綱要機制，自動產生ASP、XML、XSL等檔案。

報表查詢作業模版建置：
規範系統內所有查詢操作模式，以做為程式設計人員依循。產出查詢作業模版技術指引，分析查詢作業共通性質，使用共通服務元件開發模版視窗與程式叢集，撰寫查詢作業模版技術指引。

其他作業模版建置：
視應用系統需要，規範系統內所需作業之操作模式，以做為程式設計人員依循。產出其他作業模版技術指引，分析其他作業共通性質，使用共通服務元件開發模版視窗與程式叢集，撰寫其他作業模版技術指引。

系統分發
將建置完成的系統，分發至使用者執行。

安裝程式：將所需分發的檔案包裝成安裝程式。

1.測試資料庫是否連通
2.設定系統參數Registry
3.安裝軟體元件
4.安裝系統主程式

使用手冊：

1. 系統簡介
2. 軟硬體配備要求。
3. 功能特色說明。
4. 功能畫面使用指引與說明。
5. 常見應用範例說明。
6. 常見問題回答。
（資料來源：取材於http://www.dotspace.idv.tw/sofeeng/sofeeng_6.htm安德華科技股份有限公司技術長陳器中)

                    http://sunchaoyi.xxking.com/ 電子豬腦

軟體發展之作業程序
（資料來源：取材於 http://www.gss.com.tw/eis/19/any.htm作者：楊清萍 【叡揚資訊金融資訊服務部經理】）

        
前置作業
由各機構業務人員合作參與之各項準備工作，而業務性質分為共通性業務系統：
由本中心邀集各館(所)資深且具專業經驗之業務人員成立電腦化專案小組，訂定系統需求書。其所從事之工作內容為：
訂定業務電腦化的需求範圍。
現行作業程序及表單、表格之搜集。
制定業務電腦化的統一表單、表格與作業程序。
提供業務電腦化所需之行政業務的專業知識，以期與資訊專業人員配合。

專門性業務系統：

由本中心軟體專業人員與該單位富經驗之業務人員洽談、協商、訂定系統需求書，及原始表單。、表格之蒐集。

系統分析

本階段主要是在確定系統之目標、範圍和需求，再依據系統需求，發展出系統在軟體、硬體及人工作業三方面之規格。本階段主要工作包括分析現行系統、確定
業務需求、擬訂輸出入表單規格、確定資料流量及使用、製作資料流程圖(dfd)、系統架構圖(sfd) 及資料字典(dd)，並填具系統開發傳票，展開下一階段作業
系統設計
本階段係將上一階段所訂定的各種規格，考慮將來處在實際環境下運作的情況，一步一步地設計其細部標準。其主要工作有實體資料庫之設計（file layont）
、輸出入螢幕格式之設計（I/O screen layont）、 輸出表格之設計（output   report layont）、 製作資料與檔案關係表、及程式細部流程之設計（program
 spec.）。

程式撰寫

本階段根據系統設計所訂定之規格編寫程式，並完成除錯與模組測試，使每一程式均能執行無誤。本階段工作完成後將產生程式清單及印製程式原始碼等文件。
　
系統測試

此階段是對上一階段所撰寫之程式，作功能測試與整合測試，其主要工作為準備測試資料，進行各種測試，檢討並修改不合要求之部份，以求系統確實符合原訂
標準。

平行作業

  在確定系統能夠運作無誤後，必須再經過一段人工與電腦平行作業的期間，此一階段將對業務人員進行系統操作訓練，使其逐漸熟悉電腦作業情形，並可測試系
統在處理實際業務時，是否有疏漏不周之處。此階段並將整理系統文件與操作手冊，以備系統正式移交時供操作人員參考。

正式移轉(驗收)

   此階段乃將完成之系統正式移交業務單位使用，協助其展開獨立作業。本階段將填具系統開發完結單，並由本中心系統管制人員填具開發成果評估報告表。