1. 系統理論
根據波爾丁氏(Kenneth E. Boulding)的通用系統理論：任何系統分為靜態結構系統、簡單動態系統、控制機構或自動操作系統、開放系統、原生社會系統、動物系統、人類系統、人類社會層級及超越系統層級由內而外共九種層級；每一層級均有其特殊功能而且外層系統包含有其內層系統，而且具有內層所沒有的特性。
根據系統特性可區分為封閉系統與開放系統兩大類；各類系統都由靜態系統與動態系統均衡的關系組成，現代信息系統的進步都是架構在這些理論基礎上建立。
軟件工程的研究與發展，從傳統的結構化系統分析設計方法建置系統，演變到對象導向分析設計建置系統。無疑的都是在嘗試與尋找，如何用最有系統與最有效率的方法，在復雜的計算機邏輯運算世界與捉摸不定的使用需求中，去建置一套應用系統。
然而從軟件公司所經驗的軟件開發過程中得知，軟件一直無法做到像硬件般，運用模塊化設計，能夠利用大量生產，帶來人力與時間成本降低。且軟件制作內容，仍然過于偏重個人的設計技巧與藝術，軟件人才的去留，深深影響著軟件的生命。
一個共同推論是，硬件的制程技術觀念可引用在軟件開發上，比照硬件零件組裝之軟件工廠概念已在技術的標準上，達到某種程度的成就。OMG組織所定義的CORBA軟件組件標準就是系統開發產出過程中零件與運作平臺的標準。引用零件的觀念，再用與組裝的技術才能實現出它的成效。零件本身可以經由外包或采購，達到半成品的再用。在市場機制運作下，您都可以用最實惠的價格取得市場上歷煉后最優秀的軟件組件植入您的系統。透過有效的軟件組件組裝制程技術，可以在最短的時間內開發出系統。且由于系統開發走向標準化，軟件人員的技術技巧，將大部份展現于軟件組件本身，系統結構本身則因標準化得以定型。爾后軟件的維護工作可能就如同修車般，只需更換零件或維修配件即可。
本文主要目的即在闡述傳統結構式系統分析與設計及組件式系統分析設計與開發進行開發應用系統過程中之標準與工作指引，使軟件組件在開發過程中有所依循，開發后得以在規則的模式下運作。組件標準與組件運作平臺采Microsoft DCOM標準，系統采多層式架構設計同Microsoft DNA(Distributed interNet Applications Architecture)架構。
2. 傳統結構化軟件系統分析與設計
2.1. 系統發展(Development)
系統發展分為規劃(Planning)、設計(Design)和實施(Implementation)。須考慮未來資料量增加、企業的成長與擴充、科技的進步與系統整合性以便設計一個有彈性、可動態調整且易于維護的系統。
系統的三大基本要素：
1. 輸入(Input Data)
2. 處理與控制(Process Logic & Control)
3. 輸出(Output Information)
系統規劃通常采用由上而下的作業方式，其做法先從整體企業目標開始，探討企業營運特性，企業組織建立關系，數據處理應用邏輯，達到信息系統架構建立完成檔案設計工作。而信息管理的順序卻是與前相反由個別檔案資料的輸入一直到達成企業營運目標為止。
2.1.1.系統規劃(Planning)：
系統要做什么(What)?
初步研究：定義問題的范圍與建立系統可以解決問題、滿足需求、運用新科技、增加系統效能。
可行性研究：定義問題需求范圍、搜集資料、組織管理者與使用者需求。訂立階段計劃、訂立組織人力計劃、訂立推動計劃、訂立維護管理計劃、訂立教育訓練計劃、訂立文件制作計劃、訂立經費計劃、訂立其它配合措施。
2.1.2.系統分析(System Analysis)
系統分析，系利用系統方法或技術，建立系統觀念性架構，探討研究問題的特性，并提出具體和可行性方案的實際過程。廣義定義為一種有組織的方式來解決問題，達成目的。是一門研究如何建立系統來解決問題的科學。
系統分析的運作結果，是由資料的輸入，經過組合與處理，而輸出有意義的信息，提供與輔助管理者進行決策。
良好系統具備的特性：整合性(Integertion)、使用者易操作性、管理能力強性、實用性、資料量處理需求、符合組織風格、達成最大成本效益、考量使用人員因素、結合外在科技、法規、經濟、社會等因素、彈性的組織變更及企業成長需求。
系統分析師(System Analyst)為運用各項分析工具，整理所獲得的信息，找出一個最適合的方法解決問題的人員。須具備專業知識的能力，對系統的輸、出入與處理的軟、硬件與對數據庫的特性知識深入了解，也具有程序設計撰寫的能力，同時要具有系統企業領域知識(如財務、貿易、生產制造等)。
在規劃中由需求訪談，可以獲得管理者與使用者的各項企業行為需求與組織問題的特征與本質，了解決策者訊息需求的關鍵性信息及優先級。由企業診斷可以獲知現行系統的作業程序與運作狀況，找出現行系統不足所在及未來需求的擴充性，了解問題發生的原因與理由，進行企業的改造(BPR)。再由需求訪談與企業診斷結果進行提出各種可行性分析與研究報告，提出改善現行系統方案與解決各項問題的處理方法。當然各種問題不一定完全可由計算機系統可以解決問題，某些部分需要靠組織變革、組織章程變更及流程改造來解決問題。
2.1.3.可行性分析
可行性分析報告要獲得高層管理人員支持，定義明確的問題描述與確認的目標方向，講求實事求是的效果，正確的評估所需資源，最佳生產品質，選擇適當的信息科技與設備。在可行性目標上還要對系統中要求彈性與可維護性(Flexibility & Maintainability)，時程與成本(Schedule & Cost)，效率(Efficiency)，實時響應(Quick Response)，整合性(Integration)，安全性(Security)，可靠性(Reliability)，簡易性(Simplicity)，兼容性(Compatibility)。
可行性研究建議案提出方式：
1. 提出最佳方案的二元建議方式(Binary recommendations)。
2. 提出多個方案進行假設不同與說明選擇的假設建議方式(Choose recommendations)。
3. 依據成本考量系統彈性反映速度維護容易等因素各與加權做量化分數的價值建議方式(Value recommendations)
系統分析工具(一幅圖畫勝過千言萬語)。將系統所需處理步驟使用流程圖(Flowchart)表現。
1. 流程圖(Flow Char)：以邏輯圖標處理過程，表示作業每一個步驟以足以表示特性的符號來代表。繪制原則：由上而下，由左而右；圖標明確，工作起始確定明白，每一個步驟動作描述清楚，排好各種工作順序，流程工作范圍清楚，分支要用連接符號表示，使用標準的流程圖符號。
2. 系統流程圖(System Flow Chart)：繪制系統整體工作流程者稱之為系統流程圖。
3. 功能流程圖(Functional Flow Diagrams)：繪制組織間各個作業間資料流動的關系。
4. 數據流程圖(Data Flow Diagrams)：繪制數據間數據的儲存、轉換、流程與輸出、入。
5. 文件流程圖(Paperwork Flow Chart)：繪制系統中各類文件或表格產生及紀錄其流動的情形。
6. 程序流程圖(Process Flow Chart)：繪制一個系統中各個工作的程序與步驟。
7. 甘特圖(Gantt Chart)：用以繪制表現工作排程進度，以時間做中心，一般用于項目的規劃及階段性排程。
8. 組織圖(Organization Diagram)：用以表現組織內各部門功能間的關系與各組織間從屬關系，包含組織的名稱與部門間關系與組織各成員信息。
9. 數據字典(Data Dictionary)：定義各種資料的說明，使得數據流程圖(DFD)更易于閱讀。
系統設計(System design)結合執行活動工作程序與設備資源來完成系統使用者所要求的目標，可以令系統達到最大、最佳、與滿足需求的功能�？紤]每一個獨立程序的隨機關系-與其它程序間產生互動的關系、循序關系-各程序間的前后順序關系和時間關系-各程序在不同時間期間所存在的關系。
2.2. 系統設計(Design)
如何完成這一個系統(How)?
系統大體設計：依據系統需求、系統功能來定義系統的輸入、輸出與處理程序。
系統細部設計：依據大體設計定義輸入規格輸出規格與處理程序規格。
進行程序撰寫與設計。
進行程序的測試與正確性。
2.2.1.結構化設計(Structure Design)
結構化設計(Structure Design)采用由上而下漸進且合乎邏輯思維的方式進行設計，建立起層次關系的結構，細分各層的問題逐一探討解決其問題的設計模式。
資料輸入方式的決定考量是采用批次性輸入(Batch Input)，還是采用實時性輸入(Online Input)，一般常態異動式日常作業大都采用實時性輸入方式，進行統計或結帳式作業可采用批次性輸入方式。
編碼設計：制定編碼原則，采用數字、文字、文數字或符號；主鍵(Prime Key)唯一鍵值的規劃設計，采用循序鍵或存取鍵，關聯鍵值的規劃設計，索引鍵值或復合索引鍵值(Index Key)的規劃設計，編碼長度，避免混淆字形，同音異字等。
資料輸出的設計，精確、時效與適切性，窗體的設計，考量用紙大小、份數、傳遞方式、顏色、字體大小、主標題說明、次標題說明、編號方式、分頁考量、頁首信息、頁尾信息、上下左右空間關系、復寫字段功能、打印機功能與格式。圖表的設計，圖形特性選擇、表現方式、顏色或條紋區隔、尺標刻度的計算、多維空間的建立、圖形標示及圖例說明。
成本效益評估：系統使用環境考量，網際網絡、局域網絡、企業網絡、單機使用等；使用硬設備的成本考量，服務器、終端計算機、個人計算機、備份設備、安全機制與管理；軟件工具的成本考量，工具軟件、應用軟件、數據庫軟件、操作系統；維護管理的成本考量，訓練使用、維護費用、管理人員薪資、更新版本費用等等。透過計劃需求書(RFP Request for Proposal)提出所需系統的軟硬件信息需求，具備有功能需求規格，評估程序與建議，各項軟硬件及廠商的介紹與說明�？剂坑布募嫒菪�、成本、可靠度、普遍性；軟件的適用性、成本、品質；廠商的經驗與規模、技術能力、人員素質、財務狀況、教育與訓練、服務滿意度等等。分析系統的顧問咨詢成本，期初建置成本，轉換成本，每期維護成本，后續發展成本，操作使用成本，教育訓練成本，初期評估成本等等。
2.3. 實施(Implementation)
系統安裝與使用訓練
系統實施
1. 系統環境安裝
2. 使用手冊
1. 系統簡介
2. 軟硬件配備要求。
3. 功能特色說明。
4. 功能畫面使用指引與說明。
5. 常見應用范例說明。
6. 常見問題回答。
3. 應用系統建置
循序式檔案(Sequential files)、索引循序式檔案(Index Sequential files)、直接存取式檔案(Random access files/Direct access files)和
分割式檔案(Partitioned files)。
4. 系統上線轉換
1. 直接轉換(Direct Conversion)或稱一次轉換：直接使用新系統。
2. 并行轉換(Parallel Conversion)：新舊系統并行一段時間后，再更換成新系統。
3. 模塊轉換(Modular Conversion)：依照模塊間關系逐個模塊進行替換成新系統。
4. 漸層轉換(Phase in)：和模塊轉換很像，但具有新舊轉換接口同時承接舊系統信息，對新系統而言增加許多負擔，但對于使用者確可不間斷及變動舊有所有作業。
3. 組件式軟件系統分析與設計
3.1. 組件分析方式
對象導向系統分析設計方法是一套以重復使用為基礎的系統分析、設計及程序制作一氣呵成的方法，
對象導向技術的觀點來看，我們認為所要模塑的真實世界是由對象所組成的，真實世界的運作是由個對象成員之間的互動而成，因此先天上用這樣方法去模塑真實世界將比用結構化方法來的穩定，而且在與客戶交談時也比較容易得到客戶的認同，因為我們所談的是客戶心中的真實世界，而抽象的方式就功能面來探討模塑系統。
現今各式各樣的對象導向分析(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版本使系統執行于廣域網絡；使用者可透過參數化的系統設定，讓系統容易維護、調整與使用；系統由組件組裝而成，易于與其它組件化系統整合；進行跨地域性的信息整合，并且縮短信息擷取時程，提升企業競爭力；資料維護方式，簡單易維護；報表查詢方式，迅速易調整；業務交易方式，彈性易擴增。組件再用，軟件量產。
3.3. 組件化應用系統架構
3.3.1.多層式組件化應用軟件開發平臺 (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中的應用作業如訂單作業循環、采購作業循環等由人工驅動改為流程驅動。由于是多層式組件化的應用系統架構，無需因為架設了工作流程引擎而重新設計應用程序。
3.3.3.領域分析
領域工程主要目的即在于可再用性，包含了軟件設計架構的再用、軟件開發流程的再用、文件的再用及領域知識的再用。
隨著軟件的應用與企業的經營越來越緊密，為了提身企業的競爭力，必須可實時反映政府的法規，提供市場的需求服務性，增加企業的安全性，提供實時的多樣化的分析，滿足企業集中式與多點多廠分布式的管理需求，彈性功能增加即最小變動達成功能的特性，隨插即用的技術成熟，以對象導向技術開發的軟件組件技術機制因此而生。
領域工程方法進行領域分析、制定領域架構規格、實做出領域組件、制定領域再用程序規格、維護及修正擴充領域組件。
對象導向設計(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)
3.3.4.應用系統架構(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. 取得查詢結果并顯示。
3.4. 組件開發系統程序
以組件方式開發系統，其程序仍不跳脫需求分析，系統分析與系統設計三大步驟，只是多引用了對象導向系統分析設計中之循環漸進(Spiral)觀念，隨時修正分析設計結果，并以各式模版原則組裝組件以規范組件運作。
項目之推行，建議先以開發共通組件，再以領域組件與使用接口平行開發方式進行，較能獲得較佳之人力與時間成本掌控。關于項目的分工，會較以往容易。當組件規格與組裝模版底定，組件的開發與使用接口的開發便可分頭并行，視適當時間會合組裝成系統。
項目基本成員，建議以項目經理，系統分析師，組件設計師，使用界面設計師與數據庫管理師搭配進行。
3.4.1.需求分析
領域分析
了解與熟悉所開發系統之應用范圍。
數據字典(DataDictionaryManager)專門用語建立：建立系統開發過程中之標準用詞，做為爾后系統開發與設計過程中之標準用語，此標準用語另可作為數據庫字段，作業畫面之標準用詞語。
領域模型
收集與了解領域資料。
記錄專門用語。
1.收集系統用詞。
2.統一用詞。
3.建立標準型別。
4.建立繼承字詞。
5.建立字詞，設定型別與繼承字詞。
6.建立字詞別名。
與使用者訪談，了解所開發系統與相關環境關聯。
繪制領域模型。
使用個案分析(Use Case)
收集與記錄使用者需求。根據使用者或客戶之需求描述，使用自然的語言來記錄使用者期望的狀況，進而了解與分析使用者的真正需求。
1. 使用者訪談。
2. 找出領域使用個案。
3. 找出系統使用個案。
4. 記錄領域使用個案。
5. 記錄系統使用個案。
6. 繪制使用個案圖。
作業畫面分析
規范最終使用接口之作業畫面，以做為與使用者確認最終產出之依據。
1. 依使用個案制作作業畫面初版。
2. 與使用者訪談，搭配使用個案，修訂作業畫面。
3. 與使用者確認作業畫面。
3.4.2.系統分析
數據庫分析(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. 擬出業務組件建構管理。
3.4.3.系統設計
共通服務組件(CSO Command Service Object)設計
設計共通服務組件服務界面(interface)，產出共通服務組件技術規格。
1. 依需求設計共通服務組件服務界面。
2. 撰寫共通服務組件技術規格。
業務組件(BSO，BPE)設計
設計業務服務組件與業務處理組件服務界面(interface)，產出業務服務組件技術規格，業務處理組件技術規格。
1. 設計業務服務組件與業務處理組件組件服務界面
2. 撰寫業務服務組件與業務處理組件組件技術規格
3.4.4.系統建置
共通函式建置
規范共通函式建構所在，規定引用路徑，以進行撰寫共通函式程序讓所有程序引用。產出共通函式建置規范，共通函式使用手冊。
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等檔案。
報表查詢作業模版建置
規范系統內所有查詢操作模式，以做為程序設計人員依循。產出查詢作業模版技術指引，分析查詢作業共通性質，使用共通服務組件開發模版窗口與程序叢集，撰寫查詢作業模版技術指引。
其它作業模版建置
視應用系統需要，規范系統內所需作業之操作模式，以做為程序設計人員依循。產出其它作業模版技術指引，分析其它作業共通性質，使用共通服務組件開發模版窗口與程序叢集，撰寫其它作業模版技術指引。
3.4.5.系統分發
將建置完成的系統，分發至使用者執行。
安裝程序：將所需分發的檔案包裝成安裝程序。
1. 測試數據庫是否連通
2. 設定系統參數Registry
3. 安裝軟件組件
4. 安裝系統主程序
使用手冊：
1. 系統簡介
2. 軟硬件配備要求。
3. 功能特色說明。
4. 功能畫面使用指引與說明。
5. 常見應用范例說明。
6. 常見問題回答。
|
