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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22、型是最佳選擇，結(jié)合了細(xì)部和設(shè)計(jì)階段，可以透過(guò)所設(shè)計(jì)的雛型驗(yàn)證不同方法較短的開(kāi)發(fā)時(shí)程(With a Short Time Schedule),最適合RAD方法論，RAD是為加速開(kāi)發(fā)而生，另外階梯式也相當(dāng)適合，時(shí)間延誤還可從開(kāi)發(fā)中的版本或雛型移除時(shí)程可見(jiàn)度(With Schedule Visibility)系統(tǒng)開(kāi)發(fā)最大的挑戰(zhàn)是是否準(zhǔn)時(shí)進(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階段的順序，藉由將問(wèn)題的分解聚集於能納入資料和程序的物件上，平衡程序與資料的重心根據(jù)UML的創(chuàng)造者表示，任何現(xiàn)代的物件導(dǎo)向方式開(kāi)發(fā)資訊系統(tǒng)，特點(diǎn)是使用案例導(dǎo)向以架構(gòu)為中心反覆性和漸進(jìn)性的,物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì)-使用案例導(dǎo)向(Use-case Driven),使用案例是定義系統(tǒng)行為的主要塑模工具，用來(lái)描述使用者如何與系統(tǒng)相互作用使用案例用來(lái)辨認(rèn)並且用以撰寫(xiě)系統(tǒng)之程式設(shè)計(jì)

24、師溝通系統(tǒng)的需求使用案例每次只專注一項(xiàng)活動(dòng)，因此發(fā)展模型簡(jiǎn)單許多,物件導(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)向支援至少三個(gè)獨(dú)立但彼此關(guān)聯(lián)的系統(tǒng)架構(gòu)觀點(diǎn):功能:從使用者觀點(diǎn)描述系統(tǒng)行為結(jié)構(gòu):屬性、方法、類(lèi)別、關(guān)係描述系統(tǒng)結(jié)構(gòu)動(dòng)態(tài)觀點(diǎn):物件間傳遞訊息及物件內(nèi)狀態(tài)改變描述系統(tǒng)的內(nèi)部行為,物件導(dǎo)向系統(tǒng)分析與設(shè)計(jì)-反覆性與漸

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

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

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

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

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

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

31、型，主要確保開(kāi)發(fā)人員與使用者明白問(wèn)題的根本而不過(guò)度分析，另外找出有用、可以再利用的類(lèi)別以建立類(lèi)別庫(kù)設(shè)計(jì)工作流(Design workflow)-將分析模型轉(zhuǎn)移成實(shí)作的設(shè)計(jì)模型，側(cè)重於發(fā)展一個(gè)在特定環(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)測(cè)試工作流(Testing workflow)-提

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

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

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

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

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

37、改進(jìn)之處及評(píng)估變更後的衝擊，使開(kāi)發(fā)人員排定變更時(shí)程及部屬未來(lái)的版本,統(tǒng)一塑模語(yǔ)言,CHAPTER 1.5,統(tǒng)一塑模語(yǔ)言(Unified Modeling Language),UML的目標(biāo)就是在物件導(dǎo)向上提供共通的語(yǔ)彙及圖示法，使系統(tǒng)開(kāi)發(fā)的每個(gè)階段均可建立模型UML2.0定義了一組14個(gè)製圖技巧來(lái)速模系統(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)一塑模語(yǔ)言-結(jié)構(gòu)圖(Structure diagrams),類(lèi)別-說(shuō)明類(lèi)別模型之間的關(guān)係物件-說(shuō)明物件模型之間的關(guān)係當(dāng)類(lèi)別的真正實(shí)例更有效傳達(dá)模型套件-將其他UML元素組成更高階結(jié)構(gòu)部屬-顯示系統(tǒng)實(shí)體架構(gòu)以及軟體元件如何部屬到實(shí)體架構(gòu)元件-說(shuō)明軟體元件間的實(shí)際關(guān)係合成結(jié)構(gòu)-說(shuō)明類(lèi)別的內(nèi)部結(jié)構(gòu)(各部分關(guān)係),統(tǒng)一塑模語(yǔ)言-行為圖(Behavior diagra

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

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