资源描述
按一下以編輯母片標題樣式,按一下以編輯母片,第二層,第三層,第四層,第五層,*,按一下以編輯母片標題樣式,按一下以編輯母片,第二層,第三層,第四層,第五層,*,物件導向系統分析與設計,授課教師：夏則智,教授,碩資管,1A,A0M5002,唐知聖,物件導向系統分析與設計授課教師：夏則智 教授,認識系統分析與設計,CHAPTER,1,認識系統分析與設計CHAPTER 1,摘要,介紹系統生命週期,(SDLC),系統開發方法論演進,概述物件導向系統分析,統一流程,(United Process),與其延伸,專案開發小組所需成員及相關技能,摘要介紹系統生命週期(SDLC),系統開發生命週期,CHAPTER,1.1,系統開發生命週期CHAPTER 1.1,系統開發生命週期,(System,Development,Life,Cycle),是一種程序，用來了解資訊系統透過,設計,、,建構,、,交付系統,以支援企業需求,關鍵人物,(Key,Person),是,系統分析師,(System,Analyst),系統開發生命週期(System Development L,系統分析師,系統分析師能分析,商業情況,(Business Situation),、,辨別機會,(Identifies,Opportunities),來改善、設計資訊系統的推行,主要目標並不是創造完美的系統，而是為組織,創造價值,系統分析師系統分析師能分析商業情況(Business Sit,系統開發生命週期,(System,Development,Life,Cycle),擁有四個基本階段,:,規劃,(Planning),、,分析,(Analysis),、,設計,(Design),與,實作,(Implementation),每個,階段,(Phase),由一系列的,步驟,(Step),撰寫，這些步驟與,生產交付,(Deliverable),的技術有關,SDLC,是,逐步細緻化,(Gradual Refinement),的過程,系統開發生命週期(System Development L,系統開發生命週期,-,規劃,(Planning),了解資訊系統,為何,(Why),要建置以及專案小組要,如何,(How),建置系統的過程,共有,專案起動,(Project Initiation),以及,專案管理,(Project Management),兩個步驟,系統開發生命週期-規劃(Planning)了解資訊系統為何,系統開發生命週期,-,規劃,-,專案起動,(Project Initiation),Step 1.,必須確認系統對於組織的,企業價值,:,如何降低成本或增加營收,?,其他非資訊系統部門的,系統需求,(System,Request)?,Step 2.,和提出需求的部門或人合作進行,可行性分析,(Feasibility,Analysis),:,由技術、經濟、組織可行性檢視專案,Step,3.,提交,資訊系統核准委員會,決定是否進行,系統開發生命週期-規劃-專案起動(Project Init,系統開發生命週期,-,規劃,-,專案管理,(Project Management),資訊系統核准委員會批准後進入專案管理階段,專案經理建立工作計畫,訂定,人事編制,、,技術就緒,，以協助專案小組管制督導專案,專案管制的交付成果是,專案計畫,系統開發生命週期-規劃-專案管理(Project Manag,系統開發生命週期,-,分析,(Analysis),回應,誰,(Who),將使用系統、系統,做什麼,(What),、系統將使用於,何處,(Where),及,何時,(When),等問題,共有,分析策略,(Analysis,Strategy),、,需求蒐集,(Requirements,Gathering),及,系統建議書,(System,Proposal),三個步驟,系統開發生命週期-分析(Analysis)回應誰(Who),系統開發生命週期,-,分析,(Analysis),Step,1.,分析策略,-,用以,引導專案小組,的工作,Step,2.,需求蒐集,-,透過,訪談,或,問卷蒐集,需求,將蒐集的資訊分析、加上來自專案發起人和其他人概念發展出業務分析模型,(Analysis,model),Step,3.,透過上述分析、系統概念及模型組合成系統建議書,系統開發生命週期-分析(Analysis)Step 1.分,系統開發生命週期,-,設計,(Design),決定系統將,如何,(How),運作，從廣面的硬體、軟體、網路架構至使用者介面、表單、報表、特定程式和資料庫等均為考慮範圍,共有,設計策略,(Design Strategy),、,架構設計,和,介面設計,(Interface Design),、,資料庫與檔案規格,、,程式設計,(Program Design),四個步驟,系統開發生命週期-設計(Design)決定系統將如何(Ho,系統開發生命週期,-,設計,(Design),Step,1.,設計策略,-,釐清系統的開發者,Step,2.,架構系統、介面設計,-,描述要使用的軟硬體架構後設計使用者系統,Step,3.,資料庫與檔案規則,-,明確定義資料儲存地點和如何儲存,Step,4.,程式設計,-,定義要撰寫程式及功能,系統開發生命週期-設計(Design)Step 1.設計策,系統開發生命週期,-,實作,(Implementation),系統,實際的建置,起來，是開發過程時間最長且最昂貴的一環,共有,系統建置,(Construction),、,安裝,(Installation),、,支援計畫,(Training,Plan),三個步驟,系統開發生命週期-實作(Implementation)系統,系統開發生命週期,-,實作,(Implementation),Step,1.,系統建構,-,經由測試確保功能如設計,Step,2.,安裝,-,新舊系統轉換過程，並發起訓練計畫教導使用者,Step,3.,支援計畫,-,正式或非正式的實作來審查辨識系統所需的主次要變更,系統開發生命週期-實作(Implementation)St,系統的開發方法,CHAPTER,1.2,系統的開發方法CHAPTER 1.2,系統的開發方法,方法論,(Methodology),是實作,SDLC,的形式化方法,方法論有不同分類方法,依定義區分為,程序為主,(Process-centered),-,強調程序模型式系統概念的核心,資料為主,(Data-centered),-,強調資料模型視系統概念的核心,物件導向方法論,-,平衡程序和資料為重心,系統的開發方法方法論(Methodology)是實作SDLC,系統的開發方法,依類型,區分為,結構化設計,(Structured,Design),-1980,年代的優勢，取代先前毫無紀律的方法,快速應用程式開發,(Rapid,Application,Development)-,1990,年代，改善結構化交件慢的弱點,敏捷開發,(Agile Development),新類型的系統開發方法論，通常搭配物件導向方法論使用,系統的開發方法依類型區分為,系統的開發方法,-,結構化設計,(Structured,Design),為第一類系統開發方法論，採,按部就班,形式，以邏輯順序依階級進入下階段,許多以程序或資料為主的方法論，都遵循以下兩種結構化設計的方法,瀑布式開發,(Waterfall,Development),平行式開發,(Parallel,Development),系統的開發方法-結構化設計(Structured Desi,系統的開發方法,-,結構化設計,-,瀑布式開發,(Waterfall,Development),系統的開發方法-結構化設計-瀑布式開發 (Waterfal,系統的開發方法,-,結構化設計,-,瀑布式開發,(Waterfall,Development),為最早的結構化設計方法論,由一階完成後結束才至下階，但倒退困難重重,優點,:,在程式開始後可以,確認系統需求,專案進行期間，,需求變更次數降到最低,缺點,:,設計要在,程式設計開始前,明定,完成分析階段的系統建議書至,系統交付期間長,若企業環境改變，需要大量,重施工,(Rework),系統的開發方法-結構化設計-瀑布式開發 (Waterfal,系統的開發方法,-,結構化設計,-,平行式開發,(Parallel,Development),系統的開發方法-結構化設計-平行式開發 (Parallel,系統的開發方法,-,結構化設計,-,平行式開發,(Parallel,Development),嘗試解決分析至系統交付之間,冗長的時間延遲,將專案細分為範疇分明的,子專案,，子專案的設計與實作可平行進行，完成後再進行整合,優點,:,減少系統交付時程並且較少機會重施工,缺點,:,子專案並非獨立，若其一進行設計決策，有可能會影響另一個子專案,系統的開發方法-結構化設計-平行式開發 (Parallel,系統的開發方法,-,快速應用程式開發,(Rapid,Application,Development),嘗試解決結構化設計方法論弱點,調整,SDLC,階段並,快速開發,系統某部分且儘快交給使用者，使使用者更快,提出建議,程序、資料以及物件導向方法論都遵循以下三種結構化設計的方法,階段式開發,(Phased,Development),雛型式開發,(Prototyping,Development),可拋棄雛形開發,(Throwaway,Development),系統的開發方法-快速應用程式開發(Rapid Applic,系統的開發方法,-,快速應用程式開發,-,階段式開發,(Phased,Development),系統的開發方法-快速應用程式開發-階段式開發(Phased,系統的開發方法,-,快速應用程式開發,-,階段式開發,(Phased,Development),將系統分解為一系列版本，各版本循序開發；分階段確認系統概念，再由專案小組、使用者及系統發起人將需求分類為一系列版本，而最重要也最基本的需求放置第一版本,主要優點有,快速將有用的系統交給使用者,主要缺點為,使用者開始操作系統不完善,系統的開發方法-快速應用程式開發-階段式開發(Phased,系統的開發方法,-,快速應用程式開發,-,雛型式開發,(Prototyping,Development),系統的開發方法-快速應用程式開發-雛型式開發(Prototy,系統的開發方法,-,快速應用程式開發,-,雛型式開發,(Prototyping,Development),同時進行分析、設計與實作在同個循環內重複進行直到系統完成，藉由這些方法進行分析和設計的基礎工作，產生一個系統雛型,(,具有部分功能的速成,(Quick,&,Dirty),程式,主要優點為,快速提供可以讓使用者互動,的系統,主要缺點為快節奏釋出對,分析挑戰極大,系統的開發方法-快速應用程式開發-雛型式開發(Prototy,系統的開發方法,-,快速應用程式開發,-,可拋棄雛形開發,(Throwaway,Development),使用者產生的技術問題透過分析設計建立雛型檢視，確認重要的問題已經被解決而降低系統風險至最低，在建置真正系統後，設計雛型就會被丟棄，專案邁向設計與實作階段,主要優點為產生較為,穩定可靠的系統,主要缺點為,花費更長時間,才能交付最後的系統,系統的開發方法-快速應用程式開發-可拋棄雛形開發(Throw,系統的開發方法,-,快速應用程式開發,-,可拋棄雛形開發,(Throwaway,Development),使用者產生的技術問題透過,分析設計,建立雛型檢視，確認,重要的問題,已經被解決而降低系統風險至最低，在建置真正系統後，設計雛型就會被丟棄，專案邁向設計與實作階段,主要優點為產生較為,穩定可靠的系統,主要缺點為,花費更長時間,才能交付最後的系統,系統的開發方法-快速應用程式開發-可拋棄雛形開發(Throw,系統的開發方法,-,敏捷開發,(Agile Development),以程式設計為中心，沒有很多成規且易於遵循，排除了模型塑造及文件製作的工作負荷及時間，強調簡單、反覆的應用發展,敏捷開發的方法包括,極致程式設計法,(Extreme Programming),並列爭球法,(Serum),動態系統開發法,(Dynamic,Systems,Development , DSDM),系統的開發方法-敏捷開發(Agile Developmen,系統的開發方法,-,敏捷開發,-,極致程式設計,(Extreme Programming),系統的開發方法-敏捷開發-極致程式設計(Extreme P,系統的開發方法,-,敏捷開發,-,極致程式設計,(Extreme Programming),建立在溝通、簡明、回饋、勇氣四核心價值上，測試與有效率的撰寫程式碼是,XP,的核心，非常依賴,重構,(Refactoring),建立成功系統的三原則是,持續不斷的測試,開發人員雙人一組,撰寫簡明的程式及密切的與末端使用者互動,系統的開發方法-敏捷開發-極致程式設計(Extreme P,系統的開發方法,-,敏捷開發,-,極致程式設計,(Extreme Programming),主要優點為,交付成果比,RAD,還快,，,很少陷入系統需求蒐集中,主要缺點為,只適合小組,，,所需紀律性強,，,需要現場使用者投入，使許多業務單位無法接受,系統的開發方法-敏捷開發-極致程式設計(Extreme P,系統的開發方法,-,選擇適當的開發方法論,分析師要面臨的第一個挑戰,-,選擇哪一種方法,沒有最好最全面的方法，只有最適合的方法,以下幾種是選擇方法論的重要準則,釐清使用者需求,(With,Unclear,User Requirements,),使用者若對需求不清楚，最好選擇雛型式和可拋棄雛型式，有助於早期和,SDLC,互動,系統的開發方法-選擇適當的開發方法論分析師要面臨的第一個挑,陌生的技術,(With Unfamiliar Technology),當系統要使用不熟悉的新技術，可拋棄雛型式和階梯式適合技術的不熟悉中學習機會,複雜的系統,(That Are Complex),複雜的系統需要審慎的分析設計，可拋棄式雛型特別適合細部分析和設計，雛型式則相當不適合，複雜的系統無法再開發早期給予使用者,可靠的系統,(That Are Reliable),當系統的可靠度被列為最高優先時，可拋棄式雛型是最佳選擇，結合了細部和設計階段，可以透過所設計的雛型驗證不同方法,較短的開發時程,(With,a,Short,Time,Schedule),陌生的技術(With Unfamiliar Technolo,最適合,RAD,方法論，,RAD,是為加速開發而生，另外階梯式也相當適合，時間延誤還可從開發中的版本或雛型移除,時程可見度,(With,Schedule,Visibility),系統開發最大的挑戰是是否準時進行，,RAD,方法論可以較早進行專案的關鍵設計決策,釐清使用者需求,陌生的技術,複雜的系統,可靠的系統,較短的開發時程,時程可見度,系統開發的能力,瀑布式,平行式,階段式,雛型式,可拋棄雛型式,最適合RAD方法論，RAD是為加速開發而生，另外階梯式也相當,物件導向系統分析與設計,CHAPTER,1.3,物件導向系統分析與設計CHAPTER 1.3,物件導向系統分析與設計,(OOSAD),使用,RAD,為主的,SDLC,階段的順序，藉由將,問題的分解,聚集於,能納入資料,和程,序的物件,上，平衡,程序,與,資料,的重心,根據,UML,的創造者表示，任何現代的物件導向方式開發資訊系統，特點是,使用案例導向,以架構為中心,反覆性和漸進性的,物件導向系統分析與設計(OOSAD)使用RAD為主的SDLC,物件導向系統分析與設計,-,使用案例導向,(Use-case,Driven),使用案例是定義系統行為的主要塑模工具，用來描述,使用者如何與系統相互作用,使用案例用來,辨認,並且用以,撰寫系統,之程式設計師溝通系統的需求,使用案例每次,只專注一項活動,，因此發展模型簡單許多,物件導向系統分析與設計-使用案例導向(Use-case Dr,物件導向系統分析與設計,-,以架構為中心,(Architecture Centric),逐步成型的系統規格之基礎軟體架構導向系統的,規格,、,建設,和,文件編制,現代的物件導向支援至少三個獨立但彼此關聯的系統架構觀點,:,功能,:,從,使用者觀點,描述系統行為,結構,:,屬性,、,方法,、,類別,、,關係,描述系統結構,動態觀點,:,物件間,傳遞訊息,及物件內,狀態改變,描述系統的內部行為,物件導向系統分析與設計-以架構為中心(Architectur,物件導向系統分析與設計,-,反覆性與漸進性,(Iterative,&,Incremental),在專案開發生命週期間，持續進行,測試與細部調整,工作,分析師與使用者正在研擬系統的架構觀點時，分析師會往返檢視各個觀點，當對結構和行為觀點有更好的了解時，會發現有遺漏的需求或功能觀點，對被扭曲的事實進行修正,物件導向系統分析與設計-反覆性與漸進性(Iterative,物件導向系統分析與設計,-,物件導向系統分析與設計的優點,物件導向方法讓分析師能夠分解複雜的系統，使其變成規模更小、易於管理的模組，而開發模組時，很容易將模組拼湊構成完整資訊系統,以物件觀念來溝通，有助於改進使用者和分析師或開發人員之間的互動,物件導向系統分析與設計-物件導向系統分析與設計的優點物件導向,統一流程,CHAPTER,1.4,統一流程CHAPTER 1.4,統一流程,(The,Unified,Process),統一流程是一種特定的方法論，定義何時和如何使用不同的,UML,技術對應到物件導向的分析和設計上,統一流程是一種由,階段,及,工作流,交織而成的二維性系統開發流程。,階段包括,初始、詳述、建構與轉移,工作流包括,企業塑模、需求、分析、設計、實作、測試、部屬、專案管理、型態與變更管理以及環境,統一流程(The Unified Process)統一流程,統一流程,-,階段,(Phase),統一流程階段協助分析師以,反覆性與漸進性,的方式開發資訊系統,每個階段包含若干次的,反覆,，每次反覆均使用不同的,工作流,，為演進中的資訊系統建立一個,漸進性的版本,統一流程-階段(Phase)統一流程階段協助分析師以反覆性,統一流程,-,階段,-,初始階段,(Inception),類似傳統,SDLC,的,規劃階段,為了回答可行性分析，開發小組進行,企業塑模,、,需求和分析,等工作流相關文件,主要交付文件有,願景文件,系統開發所採用的環境,統一流程-階段-初始階段(Inception)類似傳統SD,統一流程,-,階段,-,詳述階段,(Elaboration),分析與設計工作流,是這階段的主要焦點,此階段面對的有蒐集,演進中的系統架構,開發人員會,涉足所有工作流,，,除了部屬工作流,外,主要交付成果有,UML,結構與行為圖,基準版本的可執行系統,統一流程-階段-詳述階段(Elaboration)分析與設,統一流程,-,階段,-,建構階段,(Construction),焦點放在,資訊系統程式撰寫,，主要焦點在實作工作流；需求工作流、分析與設計等工作流也有關,版本控制著活動，所以型態與變更管理工作流極其重要,主要的交付成果是,實作好的系統,，可供作,beta,測試與驗收測試之用,統一流程-階段-建構階段(Construction)焦點放,統一流程,-,階段,-,轉移階段,(Transition),與,SDLC,的實作有關，主要焦點在於,測試與部屬工作流,主要的交付成果是,實際可運轉,的資訊系統,其他交付成果包括,使用手冊,、,使用者的支援計畫,，以及,未來資訊系統的升級計畫,等,統一流程-階段-轉移階段(Transition)與SDLC,統一流程,-,工作流,(Workflow),工作流是開發人員在資訊系統的演進過程中，所要執行的任務或活動,工作流分成兩大類,工程性,(Engineering),支援性,(Supporting),統一流程-工作流(Workflow)工作流是開發人員在資訊,統一流程,-,工作流,-,工程性工作流,(Engineering),工程性工作流是,製作技術性成品,的活動,包括,企業塑模,、,需求,、,分析,、,設計,、,實作,、,測試,與,部屬,等工作流,企業塑模工作流,(Business,modeling,workflow)-,使用者組織中,揭露問題,並,發掘潛在專案,，有助於管理階層理解專案範圍，改進使用者組織效率與效用,統一流程-工作流-工程性工作流(Engineering)工程,需求工作流,(Requirements workflow)-,篩選出,功能,與,非功能性,需求，需求工作流在,初始,及,詳述,階段使用最多,分析工作流,(Analysis workflow)-,建立問題領域,的分析模型，主要確保開發人員與使用者,明白問題的根本,而,不過度分析,，另外找出有用、可以再利用的類別以建立類別庫,設計工作流,(Design workflow)-,將分析模型,轉移成實作,的設計模型，側重於發展一個在,特定環境中執行,的解決方案，與統一流程的,詳述,和,建構,有密切關聯,需求工作流(Requirements workflow)-篩,實作工作流,(Implementation workflow)-,根據設計模型建立,可執行的解決方案,(,程式設計,),，主要與,詳述,及,建構,階段有關聯,測試工作流,(Testing workflow)-,提升系統開發品質,，包括所有實作系統及模組間的整合測試、驗收測試及軟體測試等，主要在,建構,及一定程度的,轉移,階段進行,部署工作流,(Deployment workflow)-,為軟體包裝、散發、安裝及,beta,測試等，與,轉移,階段最密切,實作工作流(Implementation workflow),統一流程,-,工作流,-,支援性工作流,(Supporting),支援性工作流著重資訊系統開發的,管理,包括,專案管理,、,型態與變更管理,、,環境,工作流,專案管理工作流,(Project Management,workflow)-,專案管理是,跨階段,的工作流，開發支援,漸進性,和,反覆性,開發，,隨時間成長,或,演進,，每次反覆結束後，新的漸進版本便已經就緒,統一流程-工作流-支援性工作流(Supporting)支援性,型態與變更管理工作流,(Configuration,and,Change,Management,workflow)-,主要,追蹤,系統演進狀態，對於,工件等存取,(,防止偷竊或破壞,),，以及,定期維護,等控制，大部分與,建構,及,轉移,有關,環境工作流,(Environment workflow)-,獲取,和安裝開發小組,使用的工具,和,程序,，在統一流程的各階段均有使用，主要還是於,初始,階段,型態與變更管理工作流(Configuration and C,統一流程,-,統一流程的擴充,(Extensions),統一流程的弱點有,統一流程並不解決,人事,、,預算,、,契約管理,等議題,也不解決,產品交付後,的,維護,、,操作,或,支援,等議題,統一流程,不探討跨專案,或,專案間,的問題,統一流程-統一流程的擴充(Extensions)統一流程的,Ambler,及,Constantine,兩位建議增加,生產階段,和,操作與支援工作流,、,基礎架構管理工作流,，並修改,測試,、,部屬與環境工作流,，將,專案管理,及,型態與變更管理工作流,擴充至,生產階段,生產階段,(Production,phase)-,注重軟體產品,部署成功,後的相關問題，著重於軟體更新、維護及操作等部份,操作與支援性工作流,(Operation,and,Support,workflow)-,著重,支援目前版本,的軟體與日常操作此軟體等問題,Ambler及Constantine兩位建議增加生產階段和操,基礎架構管理工作流,(Infrastructure Management,workflow)-,主要支援,基礎架構的開發,以發展物件導向系統，以及,跨專案活動,改進軟體開發流程,(,統一流程並不考慮跨專案進行,),對現有的工作流也進行修正及擴充並延伸到生產階段,測試工作流,-,測試,每個,交付成果，也包括初始階段建立的文件,部屬工作流,-,轉換,舊有資料庫,與新系統互動，並對轉換詳加規劃，從,初階而不是向統一流程建構進入尾聲執行,基礎架構管理工作流(Infrastructure Manag,環境工作流,-,設定,與,開發,環境有關的工作，必須修改納入與,操作,和,生產環境,有關的活動,專案管理工作流,-,擴充專案管理，使其包括專案的,人事,、,客戶,與,業者間,的,合約管理,及,專案的預算管理,，並額外出現於,生產階段,以解決教育訓練、人事管理與客戶關係管理等問題,型態與變更管理,-,被擴充到新的生產機段，包括辨認出操作系統,待改進之,處及,評估變更後的衝擊,，使開發人員排定變更時程及部屬未來的版本,環境工作流-設定與開發環境有關的工作，必須修改納入與操作和生,統一塑模語言,CHAPTER,1.5,統一塑模語言CHAPTER 1.5,統一塑模語言,(Unified,Modeling,Language),UML,的目標就是在,物件導向,上提供共通的,語彙,及,圖示法,，使系統開發的每個階段均可建立模型,UML2.0,定義了一組,14,個製圖技巧,來速模系統，分成結構圖及行為圖,結構圖,(Structure,diagrams)-,提供一種方式代表資訊系統的資料和靜態關係,行為圖,(Behavior,diagrams)-,幫助分析師塑模演進資訊系統的功能需求,統一塑模語言(Unified Modeling Langua,統一塑模語言,-,結構圖,(Structure,diagrams),類別,-,說明,類別模型,之間的關係,物件,-,說明,物件模型,之間的關係,當類別的真正實例更有效傳達模型,套件,-,將其他,UML,元素,組成,更高階結構,部屬,-,顯示,系統實體架構,以及,軟體元件,如何,部屬,到實體架構,元件,-,說明,軟體元件間,的實際關係,合成結構,-,說明類別的,內部結構,(,各部分關係,),統一塑模語言-結構圖(Structure diagrams,統一塑模語言,-,行為圖,(Behavior,diagrams),活動,-,說明,企業流程,、,使用案例中的活動流程,、或,方法的細部設計,循序,-,建立使用案例中物件行為的模型，著重於,活動的時序,溝通,-,建立使用案例中物件行為的模型，著重於,活動的合作物件之間的溝通,互動概觀,-,說明一個程序的,控制流程,統一塑模語言-行為圖(Behavior diagrams),統一塑模語言,-,行為圖,(Behavior,diagrams),時序,-,說明,物件間,所發生的,互動,以及,沿著時間軸,所經歷的,狀態改變,行為狀態機,-,檢視一個,類別的行為,協定狀態機,-,說明,類別不同,，,介面間的依存關係,使用案例,-,捕捉,系統的企業需求,，並說明,系統與環境間,的互動關係,統一塑模語言-行為圖(Behavior diagrams),專案小組的角色與技能,CHAPTER,1.6,專案小組的角色與技能CHAPTER 1.6,專案小組的角色與技能,在,SDLC,期間，各種階段和步驟的逐漸明朗使得專案小組需要各式各樣的技能,專案小組的角色基本構成有企業分析師、系統分析師、基礎架構分析師、變更管理分析師、專案經理，其他成員有程式設計師、技術撰寫人等,專案小組的角色與技能在SDLC期間，各種階段和步驟的逐漸明朗,專案小組的角色與技能,-,角色職責,(Role,Responsibilities),企業分析師,(Business,analyst)-,分析系統的主要企業面向,、,確認系統將如何提供企業價值,、,設計新的企業流程和政策,系統分析師,(Systems,analyst)-,確認技術如何改進企業流程,、,設計新的企業流程,、,設計資訊系統,、,確定系統遵照資訊系統的標準,基礎架構分析師,(Infrastructure,analyst)-,確定系統遵照基礎架構標準,、,確認變更基礎架構以支援系統,專案小組的角色與技能-角色職責(Role Responsib,專案小組的角色與技能,-,角色職責,(Role,Responsibilities),變更管理分析師,(Change,management,analyst)-,發展並執行變更管理計畫、發展並執行使用者的訓練計劃,專案經理,(Project,manager)-,管理分析師、程式設計師、技術撰寫人及其他專員所組成團隊；發展並督導專案計畫、分配資源、充當專案的第一線聯絡人,程式設計師,(Programmer)-,實際撰寫程式,技術撰寫人,(Technical writer)-,準備畫面和使用手冊、系統手冊等文件,專案小組的角色與技能-角色職責(Role Responsib,
展开阅读全文