物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì)

1、物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì),授課教師：夏則智 教授 碩資管1A A0M5002 唐知聖,認(rèn)識系統(tǒng)分析與設(shè)計(jì),CHAPTER 1,摘要,介紹系統(tǒng)生命週期(SDLC)系統(tǒng)開發(fā)方法論演進(jìn)概述物件導(dǎo)向系統(tǒng)分析統(tǒng)一流程(United Process)與其延伸專案開發(fā)小組所需成員及相關(guān)技能,系統(tǒng)開發(fā)生命週期,CHAPTER 1.1,系統(tǒng)開發(fā)生命週期(System Development Life

2、 Cycle),是一種程序，用來了解資訊系統(tǒng)透過設(shè)計(jì)、建構(gòu)、交付系統(tǒng)以支援企業(yè)需求關(guān)鍵人物(Key Person)是系統(tǒng)分析師(System Analyst),系統(tǒng)分析師,系統(tǒng)分析師能分析商業(yè)情況(Business Situation)、辨別機(jī)會(Identifies Opportunities)來改善、設(shè)計(jì)資訊系統(tǒng)的推行主要目標(biāo)並不是創(chuàng)造完美的系統(tǒng)，而是為組織創(chuàng)造價(jià)值,系統(tǒng)開發(fā)生命週期(System Development L

3、ife Cycle),擁有四個基本階段:規(guī)劃(Planning)、分析(Analysis)、設(shè)計(jì)(Design)與實(shí)作(Implementation)每個階段(Phase)由一系列的步驟(Step)撰寫，這些步驟與生產(chǎn)交付(Deliverable)的技術(shù)有關(guān)SDLC是逐步細(xì)緻化(Gradual Refinement)的過程,系統(tǒng)開發(fā)生命週期-規(guī)劃(Planning),了解資訊系統(tǒng)為何(Why)要建置以及專案小組要如何(How)建置

4、系統(tǒng)的過程共有專案起動(Project Initiation)以及專案管理(Project Management)兩個步驟,系統(tǒng)開發(fā)生命週期-規(guī)劃-專案起動(Project Initiation),Step 1.必須確認(rèn)系統(tǒng)對於組織的企業(yè)價(jià)值:如何降低成本或增加營收?其他非資訊系統(tǒng)部門的系統(tǒng)需求(System Request)?Step 2.和提出需求的部門或人合作進(jìn)行可行性分析(Feasibility Analysis):

5、由技術(shù)、經(jīng)濟(jì)、組織可行性檢視專案Step 3.提交資訊系統(tǒng)核準(zhǔn)委員會決定是否進(jìn)行,系統(tǒng)開發(fā)生命週期-規(guī)劃-專案管理(Project Management),資訊系統(tǒng)核準(zhǔn)委員會批準(zhǔn)後進(jìn)入專案管理階段專案經(jīng)理建立工作計(jì)畫訂定人事編制、技術(shù)就緒，以協(xié)助專案小組管制督導(dǎo)專案專案管制的交付成果是專案計(jì)畫,系統(tǒng)開發(fā)生命週期-分析(Analysis),回應(yīng)誰(Who)將使用系統(tǒng)、系統(tǒng)做什麼(What)、系統(tǒng)將使用於何處(Where)及何時

6、(When)等問題共有分析策略(Analysis Strategy)、需求蒐集(Requirements Gathering)及系統(tǒng)建議書(System Proposal) 三個步驟,系統(tǒng)開發(fā)生命週期-分析(Analysis),Step 1.分析策略-用以引導(dǎo)專案小組的工作Step 2.需求蒐集-透過訪談或問卷蒐集需求將蒐集的資訊分析、加上來自專案發(fā)起人和其他人概念發(fā)展出業(yè)務(wù)分析模型(Analysis model)Step 3

7、.透過上述分析、系統(tǒng)概念及模型組合成系統(tǒng)建議書,系統(tǒng)開發(fā)生命週期-設(shè)計(jì)(Design),決定系統(tǒng)將如何(How)運(yùn)作，從廣面的硬體、軟體、網(wǎng)路架構(gòu)至使用者介面、表單、報(bào)表、特定程式和資料庫等均為考慮範(fàn)圍共有設(shè)計(jì)策略(Design Strategy)、架構(gòu)設(shè)計(jì)和介面設(shè)計(jì)(Interface Design)、資料庫與檔案規(guī)格、程式設(shè)計(jì)(Program Design)四個步驟,系統(tǒng)開發(fā)生命週期-設(shè)計(jì)(Design),Step 1.設(shè)計(jì)策

8、略-釐清系統(tǒng)的開發(fā)者Step 2.架構(gòu)系統(tǒng)、介面設(shè)計(jì)-描述要使用的軟硬體架構(gòu)後設(shè)計(jì)使用者系統(tǒng)Step 3.資料庫與檔案規(guī)則-明確定義資料儲存地點(diǎn)和如何儲存Step 4.程式設(shè)計(jì)-定義要撰寫程式及功能,系統(tǒng)開發(fā)生命週期-實(shí)作(Implementation),系統(tǒng)實(shí)際的建置起來，是開發(fā)過程時間最長且最昂貴的一環(huán)共有系統(tǒng)建置(Construction)、安裝(Installation)、支援計(jì)畫(Training Plan)三個步驟

9、,系統(tǒng)開發(fā)生命週期-實(shí)作(Implementation),Step 1.系統(tǒng)建構(gòu)-經(jīng)由測試確保功能如設(shè)計(jì)Step 2.安裝-新舊系統(tǒng)轉(zhuǎn)換過程，並發(fā)起訓(xùn)練計(jì)畫教導(dǎo)使用者Step 3.支援計(jì)畫-正式或非正式的實(shí)作來審查辨識系統(tǒng)所需的主次要變更,系統(tǒng)的開發(fā)方法,CHAPTER 1.2,系統(tǒng)的開發(fā)方法,方法論(Methodology)是實(shí)作SDLC的形式化方法方法論有不同分類方法依定義區(qū)分為程序?yàn)橹?Process-centered

10、)-強(qiáng)調(diào)程序模型式系統(tǒng)概念的核心資料為主(Data-centered)-強(qiáng)調(diào)資料模型視系統(tǒng)概念的核心 物件導(dǎo)向方法論-平衡程序和資料為重心,系統(tǒng)的開發(fā)方法,依類型區(qū)分為結(jié)構(gòu)化設(shè)計(jì)(Structured Design)-1980年代的優(yōu)勢，取代先前毫無紀(jì)律的方法快速應(yīng)用程式開發(fā)(Rapid Application Development)-1990年代，改善結(jié)構(gòu)化交件慢的弱點(diǎn)敏捷開發(fā)(Agile Development) –新類

11、型的系統(tǒng)開發(fā)方法論，通常搭配物件導(dǎo)向方法論使用,系統(tǒng)的開發(fā)方法-結(jié)構(gòu)化設(shè)計(jì)(Structured Design),為第一類系統(tǒng)開發(fā)方法論，採按部就班形式，以邏輯順序依階級進(jìn)入下階段許多以程序或資料為主的方法論，都遵循以下兩種結(jié)構(gòu)化設(shè)計(jì)的方法瀑布式開發(fā)(Waterfall Development)平行式開發(fā)(Parallel Development),系統(tǒng)的開發(fā)方法-結(jié)構(gòu)化設(shè)計(jì)-瀑布式開發(fā) (Waterfall Developm

12、ent),系統(tǒng)的開發(fā)方法-結(jié)構(gòu)化設(shè)計(jì)-瀑布式開發(fā) (Waterfall Development),為最早的結(jié)構(gòu)化設(shè)計(jì)方法論由一階完成後結(jié)束才至下階，但倒退困難重重優(yōu)點(diǎn):在程式開始後可以確認(rèn)系統(tǒng)需求專案進(jìn)行期間，需求變更次數(shù)降到最低缺點(diǎn):設(shè)計(jì)要在程式設(shè)計(jì)開始前明定完成分析階段的系統(tǒng)建議書至系統(tǒng)交付期間長若企業(yè)環(huán)境改變，需要大量重施工(Rework),系統(tǒng)的開發(fā)方法-結(jié)構(gòu)化設(shè)計(jì)-平行式開發(fā) (Parallel Develop

13、ment),系統(tǒng)的開發(fā)方法-結(jié)構(gòu)化設(shè)計(jì)-平行式開發(fā) (Parallel Development),嘗試解決分析至系統(tǒng)交付之間冗長的時間延遲將專案細(xì)分為範(fàn)疇分明的子專案，子專案的設(shè)計(jì)與實(shí)作可平行進(jìn)行，完成後再進(jìn)行整合優(yōu)點(diǎn):減少系統(tǒng)交付時程並且較少機(jī)會重施工缺點(diǎn):子專案並非獨(dú)立，若其一進(jìn)行設(shè)計(jì)決策，有可能會影響另一個子專案,系統(tǒng)的開發(fā)方法-快速應(yīng)用程式開發(fā)(Rapid Application Development),嘗試解決結(jié)構(gòu)

14、化設(shè)計(jì)方法論弱點(diǎn)調(diào)整SDLC階段並快速開發(fā)系統(tǒng)某部分且儘快交給使用者，使使用者更快提出建議程序、資料以及物件導(dǎo)向方法論都遵循以下三種結(jié)構(gòu)化設(shè)計(jì)的方法階段式開發(fā)(Phased Development)雛型式開發(fā)(Prototyping Development)可拋棄雛形開發(fā)(Throwaway Development),系統(tǒng)的開發(fā)方法-快速應(yīng)用程式開發(fā)-階段式開發(fā)(Phased Development),系統(tǒng)的開發(fā)方法-快速應(yīng)用

15、程式開發(fā)-階段式開發(fā)(Phased Development),將系統(tǒng)分解為一系列版本，各版本循序開發(fā)；分階段確認(rèn)系統(tǒng)概念，再由專案小組、使用者及系統(tǒng)發(fā)起人將需求分類為一系列版本，而最重要也最基本的需求放置第一版本主要優(yōu)點(diǎn)有快速將有用的系統(tǒng)交給使用者主要缺點(diǎn)為使用者開始操作系統(tǒng)不完善,系統(tǒng)的開發(fā)方法-快速應(yīng)用程式開發(fā)-雛型式開發(fā)(Prototyping Development),系統(tǒng)的開發(fā)方法-快速應(yīng)用程式開發(fā)-雛型式開發(fā)(Proto

16、typing Development),同時進(jìn)行分析、設(shè)計(jì)與實(shí)作在同個循環(huán)內(nèi)重複進(jìn)行直到系統(tǒng)完成，藉由這些方法進(jìn)行分析和設(shè)計(jì)的基礎(chǔ)工作，產(chǎn)生一個系統(tǒng)雛型(具有部分功能的速成(Quick & Dirty)程式主要優(yōu)點(diǎn)為快速提供可以讓使用者互動的系統(tǒng)主要缺點(diǎn)為快節(jié)奏釋出對分析挑戰(zhàn)極大,系統(tǒng)的開發(fā)方法-快速應(yīng)用程式開發(fā)-可拋棄雛形開發(fā)(Throwaway Development),使用者產(chǎn)生的技術(shù)問題透過分析設(shè)計(jì)建立雛型檢視，確認(rèn)

17、重要的問題已經(jīng)被解決而降低系統(tǒng)風(fēng)險(xiǎn)至最低，在建置真正系統(tǒng)後，設(shè)計(jì)雛型就會被丟棄，專案邁向設(shè)計(jì)與實(shí)作階段主要優(yōu)點(diǎn)為產(chǎn)生較為穩(wěn)定可靠的系統(tǒng)主要缺點(diǎn)為花費(fèi)更長時間才能交付最後的系統(tǒng),系統(tǒng)的開發(fā)方法-快速應(yīng)用程式開發(fā)-可拋棄雛形開發(fā)(Throwaway Development),使用者產(chǎn)生的技術(shù)問題透過分析設(shè)計(jì)建立雛型檢視，確認(rèn)重要的問題已經(jīng)被解決而降低系統(tǒng)風(fēng)險(xiǎn)至最低，在建置真正系統(tǒng)後，設(shè)計(jì)雛型就會被丟棄，專案邁向設(shè)計(jì)與實(shí)作階段主要優(yōu)點(diǎn)為

18、產(chǎn)生較為穩(wěn)定可靠的系統(tǒng)主要缺點(diǎn)為花費(fèi)更長時間才能交付最後的系統(tǒng),系統(tǒng)的開發(fā)方法-敏捷開發(fā)(Agile Development),以程式設(shè)計(jì)為中心，沒有很多成規(guī)且易於遵循，排除了模型塑造及文件製作的工作負(fù)荷及時間，強(qiáng)調(diào)簡單、反覆的應(yīng)用發(fā)展敏捷開發(fā)的方法包括極致程式設(shè)計(jì)法(Extreme Programming)並列爭球法(Serum)動態(tài)系統(tǒng)開發(fā)法(Dynamic Systems Development , DSDM),系統(tǒng)的

19、開發(fā)方法-敏捷開發(fā)-極致程式設(shè)計(jì)(Extreme Programming),系統(tǒng)的開發(fā)方法-敏捷開發(fā)-極致程式設(shè)計(jì)(Extreme Programming),建立在溝通、簡明、回饋、勇氣四核心價(jià)值上，測試與有效率的撰寫程式碼是XP的核心，非常依賴重構(gòu)(Refactoring)建立成功系統(tǒng)的三原則是持續(xù)不斷的測試開發(fā)人員雙人一組撰寫簡明的程式及密切的與末端使用者互動,系統(tǒng)的開發(fā)方法-敏捷開發(fā)-極致程式設(shè)計(jì)(Extreme P

20、rogramming),主要優(yōu)點(diǎn)為交付成果比RAD還快，很少陷入系統(tǒng)需求蒐集中主要缺點(diǎn)為只適合小組，所需紀(jì)律性強(qiáng)，需要現(xiàn)場使用者投入，使許多業(yè)務(wù)單位無法接受,系統(tǒng)的開發(fā)方法-選擇適當(dāng)?shù)拈_發(fā)方法論,分析師要面臨的第一個挑戰(zhàn)-選擇哪一種方法沒有最好最全面的方法，只有最適合的方法以下幾種是選擇方法論的重要準(zhǔn)則釐清使用者需求(With Unclear User Requirements )使用者若對需求不清楚，最好選擇雛型式和可拋棄

21、雛型式，有助於早期和SDLC互動,陌生的技術(shù)(With Unfamiliar Technology)當(dāng)系統(tǒng)要使用不熟悉的新技術(shù)，可拋棄雛型式和階梯式適合技術(shù)的不熟悉中學(xué)習(xí)機(jī)會複雜的系統(tǒng)(That Are Complex)複雜的系統(tǒng)需要審慎的分析設(shè)計(jì)，可拋棄式雛型特別適合細(xì)部分析和設(shè)計(jì)，雛型式則相當(dāng)不適合，複雜的系統(tǒng)無法再開發(fā)早期給予使用者可靠的系統(tǒng)(That Are Reliable)當(dāng)系統(tǒng)的可靠度被列為最高優(yōu)先時，可拋棄式雛

22、型是最佳選擇，結(jié)合了細(xì)部和設(shè)計(jì)階段，可以透過所設(shè)計(jì)的雛型驗(yàn)證不同方法較短的開發(fā)時程(With a Short Time Schedule),最適合RAD方法論，RAD是為加速開發(fā)而生，另外階梯式也相當(dāng)適合，時間延誤還可從開發(fā)中的版本或雛型移除時程可見度(With Schedule Visibility)系統(tǒng)開發(fā)最大的挑戰(zhàn)是是否準(zhǔn)時進(jìn)行，RAD方法論可以較早進(jìn)行專案的關(guān)鍵設(shè)計(jì)決策,物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì),CHAPTER 1.3,物件

23、導(dǎo)向系統(tǒng)分析與設(shè)計(jì)(OOSAD),使用RAD為主的SDLC階段的順序，藉由將問題的分解聚集於能納入資料和程序的物件上，平衡程序與資料的重心根據(jù)UML的創(chuàng)造者表示，任何現(xiàn)代的物件導(dǎo)向方式開發(fā)資訊系統(tǒng)，特點(diǎn)是使用案例導(dǎo)向以架構(gòu)為中心反覆性和漸進(jìn)性的,物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì)-使用案例導(dǎo)向(Use-case Driven),使用案例是定義系統(tǒng)行為的主要塑模工具，用來描述使用者如何與系統(tǒng)相互作用使用案例用來辨認(rèn)並且用以撰寫系統(tǒng)之程式設(shè)計(jì)

24、師溝通系統(tǒng)的需求使用案例每次只專注一項(xiàng)活動，因此發(fā)展模型簡單許多,物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì)-以架構(gòu)為中心(Architecture Centric),逐步成型的系統(tǒng)規(guī)格之基礎(chǔ)軟體架構(gòu)導(dǎo)向系統(tǒng)的規(guī)格、建設(shè)和文件編制現(xiàn)代的物件導(dǎo)向支援至少三個獨(dú)立但彼此關(guān)聯(lián)的系統(tǒng)架構(gòu)觀點(diǎn):功能:從使用者觀點(diǎn)描述系統(tǒng)行為結(jié)構(gòu):屬性、方法、類別、關(guān)係描述系統(tǒng)結(jié)構(gòu)動態(tài)觀點(diǎn):物件間傳遞訊息及物件內(nèi)狀態(tài)改變描述系統(tǒng)的內(nèi)部行為,物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì)-反覆性與漸

25、進(jìn)性(Iterative & Incremental),在專案開發(fā)生命週期間，持續(xù)進(jìn)行測試與細(xì)部調(diào)整工作分析師與使用者正在研擬系統(tǒng)的架構(gòu)觀點(diǎn)時，分析師會往返檢視各個觀點(diǎn)，當(dāng)對結(jié)構(gòu)和行為觀點(diǎn)有更好的了解時，會發(fā)現(xiàn)有遺漏的需求或功能觀點(diǎn)，對被扭曲的事實(shí)進(jìn)行修正,物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì)-物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì)的優(yōu)點(diǎn),物件導(dǎo)向方法讓分析師能夠分解複雜的系統(tǒng)，使其變成規(guī)模更小、易於管理的模組，而開發(fā)模組時，很容易將模組拼湊構(gòu)成完整資訊系

26、統(tǒng)以物件觀念來溝通，有助於改進(jìn)使用者和分析師或開發(fā)人員之間的互動,統(tǒng)一流程,CHAPTER 1.4,統(tǒng)一流程(The Unified Process),統(tǒng)一流程是一種特定的方法論，定義何時和如何使用不同的UML技術(shù)對應(yīng)到物件導(dǎo)向的分析和設(shè)計(jì)上統(tǒng)一流程是一種由階段及工作流交織而成的二維性系統(tǒng)開發(fā)流程。階段包括初始、詳述、建構(gòu)與轉(zhuǎn)移工作流包括企業(yè)塑模、需求、分析、設(shè)計(jì)、實(shí)作、測試、部屬、專案管理、型態(tài)與變更管理以及環(huán)境,統(tǒng)一流程-

27、階段(Phase),統(tǒng)一流程階段協(xié)助分析師以反覆性與漸進(jìn)性的方式開發(fā)資訊系統(tǒng)每個階段包含若干次的反覆，每次反覆均使用不同的工作流，為演進(jìn)中的資訊系統(tǒng)建立一個漸進(jìn)性的版本,統(tǒng)一流程-階段-初始階段(Inception),類似傳統(tǒng)SDLC的規(guī)劃階段為了回答可行性分析，開發(fā)小組進(jìn)行企業(yè)塑模、需求和分析等工作流相關(guān)文件主要交付文件有願景文件系統(tǒng)開發(fā)所採用的環(huán)境,統(tǒng)一流程-階段-詳述階段(Elaboration),分析與設(shè)計(jì)工作流

28、是這階段的主要焦點(diǎn)此階段面對的有蒐集演進(jìn)中的系統(tǒng)架構(gòu)開發(fā)人員會涉足所有工作流，除了部屬工作流外主要交付成果有UML結(jié)構(gòu)與行為圖基準(zhǔn)版本的可執(zhí)行系統(tǒng),統(tǒng)一流程-階段-建構(gòu)階段(Construction),焦點(diǎn)放在資訊系統(tǒng)程式撰寫，主要焦點(diǎn)在實(shí)作工作流；需求工作流、分析與設(shè)計(jì)等工作流也有關(guān)版本控制著活動，所以型態(tài)與變更管理工作流極其重要主要的交付成果是實(shí)作好的系統(tǒng)，可供作beta測試與驗(yàn)收測試之用,統(tǒng)一流程-階段-轉(zhuǎn)移階段

29、(Transition),與SDLC的實(shí)作有關(guān)，主要焦點(diǎn)在於測試與部屬工作流主要的交付成果是實(shí)際可運(yùn)轉(zhuǎn)的資訊系統(tǒng)其他交付成果包括使用手冊、使用者的支援計(jì)畫，以及未來資訊系統(tǒng)的升級計(jì)畫等,統(tǒng)一流程-工作流(Workflow),工作流是開發(fā)人員在資訊系統(tǒng)的演進(jìn)過程中，所要執(zhí)行的任務(wù)或活動工作流分成兩大類工程性(Engineering)支援性(Supporting),統(tǒng)一流程-工作流-工程性工作流(Engineering),工程性

30、工作流是製作技術(shù)性成品的活動包括企業(yè)塑模、需求、分析、設(shè)計(jì)、實(shí)作、測試與部屬等工作流企業(yè)塑模工作流(Business modeling workflow)-使用者組織中揭露問題並發(fā)掘潛在專案，有助於管理階層理解專案範(fàn)圍，改進(jìn)使用者組織效率與效用,需求工作流(Requirements workflow)-篩選出功能與非功能性需求，需求工作流在初始及詳述階段使用最多分析工作流(Analysis workflow)-建立問題領(lǐng)域的分析模

31、型，主要確保開發(fā)人員與使用者明白問題的根本而不過度分析，另外找出有用、可以再利用的類別以建立類別庫設(shè)計(jì)工作流(Design workflow)-將分析模型轉(zhuǎn)移成實(shí)作的設(shè)計(jì)模型，側(cè)重於發(fā)展一個在特定環(huán)境中執(zhí)行的解決方案，與統(tǒng)一流程的詳述和建構(gòu)有密切關(guān)聯(lián),實(shí)作工作流(Implementation workflow)-根據(jù)設(shè)計(jì)模型建立可執(zhí)行的解決方案(程式設(shè)計(jì))，主要與詳述及建構(gòu)階段有關(guān)聯(lián)測試工作流(Testing workflow)-提

32、升系統(tǒng)開發(fā)品質(zhì)，包括所有實(shí)作系統(tǒng)及模組間的整合測試、驗(yàn)收測試及軟體測試等，主要在建構(gòu)及一定程度的轉(zhuǎn)移階段進(jìn)行部署工作流(Deployment workflow)-為軟體包裝、散發(fā)、安裝及beta測試等，與轉(zhuǎn)移階段最密切,統(tǒng)一流程-工作流-支援性工作流(Supporting),支援性工作流著重資訊系統(tǒng)開發(fā)的管理包括專案管理、型態(tài)與變更管理、環(huán)境工作流專案管理工作流(Project Management workflow)-專案管理是

33、跨階段的工作流，開發(fā)支援漸進(jìn)性和反覆性開發(fā)，隨時間成長或演進(jìn)，每次反覆結(jié)束後，新的漸進(jìn)版本便已經(jīng)就緒,型態(tài)與變更管理工作流(Configuration and Change Management workflow)-主要追蹤系統(tǒng)演進(jìn)狀態(tài)，對於工件等存取 (防止偷竊或破壞)，以及定期維護(hù)等控制，大部分與建構(gòu)及轉(zhuǎn)移有關(guān)環(huán)境工作流(Environment workflow)-獲取和安裝開發(fā)小組使用的工具和程序，在統(tǒng)一流程的各階段均有使用，主

34、要還是於初始階段,統(tǒng)一流程-統(tǒng)一流程的擴(kuò)充(Extensions),統(tǒng)一流程的弱點(diǎn)有統(tǒng)一流程並不解決人事、預(yù)算、契約管理等議題也不解決產(chǎn)品交付後的維護(hù)、操作或支援等議題統(tǒng)一流程不探討跨專案或?qū)０搁g的問題,Ambler及Constantine兩位建議增加生產(chǎn)階段和操作與支援工作流、基礎(chǔ)架構(gòu)管理工作流，並修改測試、部屬與環(huán)境工作流，將專案管理及型態(tài)與變更管理工作流擴(kuò)充至生產(chǎn)階段生產(chǎn)階段(Production phase)-注重軟體

35、產(chǎn)品部署成功後的相關(guān)問題，著重於軟體更新、維護(hù)及操作等部份操作與支援性工作流(Operation and Support workflow)-著重支援目前版本的軟體與日常操作此軟體等問題,基礎(chǔ)架構(gòu)管理工作流(Infrastructure Management workflow)-主要支援基礎(chǔ)架構(gòu)的開發(fā)以發(fā)展物件導(dǎo)向系統(tǒng)，以及跨專案活動改進(jìn)軟體開發(fā)流程(統(tǒng)一流程並不考慮跨專案進(jìn)行)對現(xiàn)有的工作流也進(jìn)行修正及擴(kuò)充並延伸到生產(chǎn)階段測試工

36、作流-測試每個交付成果，也包括初始階段建立的文件部屬工作流-轉(zhuǎn)換舊有資料庫與新系統(tǒng)互動，並對轉(zhuǎn)換詳加規(guī)劃，從初階而不是向統(tǒng)一流程建構(gòu)進(jìn)入尾聲執(zhí)行,環(huán)境工作流-設(shè)定與開發(fā)環(huán)境有關(guān)的工作，必須修改納入與操作和生產(chǎn)環(huán)境有關(guān)的活動專案管理工作流-擴(kuò)充專案管理，使其包括專案的人事、客戶與業(yè)者間的合約管理及專案的預(yù)算管理，並額外出現(xiàn)於生產(chǎn)階段以解決教育訓(xùn)練、人事管理與客戶關(guān)係管理等問題型態(tài)與變更管理-被擴(kuò)充到新的生產(chǎn)機(jī)段，包括辨認(rèn)出操作系統(tǒng)待

37、改進(jìn)之處及評估變更後的衝擊，使開發(fā)人員排定變更時程及部屬未來的版本,統(tǒng)一塑模語言,CHAPTER 1.5,統(tǒng)一塑模語言(Unified Modeling Language),UML的目標(biāo)就是在物件導(dǎo)向上提供共通的語彙及圖示法，使系統(tǒng)開發(fā)的每個階段均可建立模型UML2.0定義了一組14個製圖技巧來速模系統(tǒng)，分成結(jié)構(gòu)圖及行為圖結(jié)構(gòu)圖(Structure diagrams)-提供一種方式代表資訊系統(tǒng)的資料和靜態(tài)關(guān)係行為圖(Behavio

38、r diagrams)-幫助分析師塑模演進(jìn)資訊系統(tǒng)的功能需求,統(tǒng)一塑模語言-結(jié)構(gòu)圖(Structure diagrams),類別-說明類別模型之間的關(guān)係物件-說明物件模型之間的關(guān)係當(dāng)類別的真正實(shí)例更有效傳達(dá)模型套件-將其他UML元素組成更高階結(jié)構(gòu)部屬-顯示系統(tǒng)實(shí)體架構(gòu)以及軟體元件如何部屬到實(shí)體架構(gòu)元件-說明軟體元件間的實(shí)際關(guān)係合成結(jié)構(gòu)-說明類別的內(nèi)部結(jié)構(gòu)(各部分關(guān)係),統(tǒng)一塑模語言-行為圖(Behavior diagra

39、ms),活動-說明企業(yè)流程、使用案例中的活動流程、或方法的細(xì)部設(shè)計(jì)循序-建立使用案例中物件行為的模型，著重於活動的時序溝通-建立使用案例中物件行為的模型，著重於活動的合作物件之間的溝通互動概觀-說明一個程序的控制流程,統(tǒng)一塑模語言-行為圖(Behavior diagrams),時序-說明物件間所發(fā)生的互動以及沿著時間軸所經(jīng)歷的狀態(tài)改變行為狀態(tài)機(jī)-檢視一個類別的行為協(xié)定狀態(tài)機(jī)-說明類別不同，介面間的依存關(guān)係使用案例-捕捉系統(tǒng)

40、的企業(yè)需求，並說明系統(tǒng)與環(huán)境間的互動關(guān)係,專案小組的角色與技能,CHAPTER 1.6,專案小組的角色與技能,在SDLC期間，各種階段和步驟的逐漸明朗使得專案小組需要各式各樣的技能專案小組的角色基本構(gòu)成有企業(yè)分析師、系統(tǒng)分析師、基礎(chǔ)架構(gòu)分析師、變更管理分析師、專案經(jīng)理，其他成員有程式設(shè)計(jì)師、技術(shù)撰寫人等,專案小組的角色與技能-角色職責(zé)(Role Responsibilities),企業(yè)分析師(Business analyst)-分析系

41、統(tǒng)的主要企業(yè)面向、確認(rèn)系統(tǒng)將如何提供企業(yè)價(jià)值、設(shè)計(jì)新的企業(yè)流程和政策系統(tǒng)分析師(Systems analyst)-確認(rèn)技術(shù)如何改進(jìn)企業(yè)流程、設(shè)計(jì)新的企業(yè)流程、設(shè)計(jì)資訊系統(tǒng)、確定系統(tǒng)遵照資訊系統(tǒng)的標(biāo)準(zhǔn)基礎(chǔ)架構(gòu)分析師(Infrastructure analyst)-確定系統(tǒng)遵照基礎(chǔ)架構(gòu)標(biāo)準(zhǔn)、確認(rèn)變更基礎(chǔ)架構(gòu)以支援系統(tǒng),專案小組的角色與技能-角色職責(zé)(Role Responsibilities),變更管理分析師(Change manage