slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
軟體生命週期管理與實作 PowerPoint Presentation
Download Presentation
軟體生命週期管理與實作

Loading in 2 Seconds...

play fullscreen
1 / 61

軟體生命週期管理與實作 - PowerPoint PPT Presentation


  • 110 Views
  • Uploaded on

軟體生命週期管理與實作. 主講者 : 蘇中和 經歷 : 鼎升科技軟體工程處技術顧問兼專案經理 樹德科大資管系兼任講師 專業證照 : SCJP,SCWCD,MCSD.NET,MCDBA,Oracle 美國 PMP 專案管理師證照. 軟體生命週期. 軟體工程. 2.1 軟體生命週期模型. 軟體工程師或其小組必須混合包含過程、方法,及工具層次的開發策略。 軟體發展生命週期模型 (Software Development Life Cycle Model , SDLC) 軟體開發程序 (Software Develop Procedure)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '軟體生命週期管理與實作' - gallia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1
軟體生命週期管理與實作
  • 主講者:蘇中和
  • 經歷:鼎升科技軟體工程處技術顧問兼專案經理
  • 樹德科大資管系兼任講師
  • 專業證照:
    • SCJP,SCWCD,MCSD.NET,MCDBA,Oracle
    • 美國PMP專案管理師證照
slide3
2.1軟體生命週期模型
  • 軟體工程師或其小組必須混合包含過程、方法,及工具層次的開發策略。
    • 軟體發展生命週期模型(Software Development Life Cycle Model,SDLC)
    • 軟體開發程序(Software Develop Procedure)
    • 稱為軟體工程規範(software engineering paradigm)。
slide4
軟體發展生命週期模型
  • 軟體發展生命週期模型
    • 描述或定義軟體開發一系列的步驟或階段
    • 目的是提供開發者一個系統性的流程,以成功地開發使用者所需要的軟體。
slide7
2.2 軟體生命週期模型種類
  • 2.2.1 瀑布模型
  • 2.2.2 漸增模型
  • 2.2.3 快速雛形模型
  • 2.2.4 螺旋模型
2 2 1
2.2.1 瀑布模型
  • 瀑布模型(Waterfall Model,Royce(1970))有時稱為古典生命週期(classic life cycle)或線性序列模型。
  • 至少劃分3階段 (分析、設計、實施 ) 通常劃分5~7階段不等
slide10
瀑布模型
  • 需求分析階段(Requirements analysis phase) 需求搜集的過程是以軟體為特別的焦點。要了解所要建立程式的特性。
  • 規格階段(Specification Phase):一但客戶同意在需求階段的了解後,規格小組(Specification team)將畫出規格文件(Specification document)。
  • 設計階段(Design Phase) 設計過程將需求轉變為軟體的表示,以便在程式碼產生前了解其品質。
  • 建置階段(Implementation Phase)設計必須被轉變為機器可讀取的形式。這項工作即進行程式碼產生的步驟。
  • 測試階段(Testing Phase) 一旦程式碼產生後,即開始進行程式測試。。
  • 維護階段( Maintenances Phase) 軟體在交給客戶後,毫無疑問的一定會有改變的需求。
slide11
使用瀑布模型會碰到以下的問題
  • 很難依照模型的序列流程
  • 需求很難明確的表示
  • 客戶必須要有耐心
2 2 2
2.2.2 漸增模型
  • 強調需求可分成幾個部分 開發週期可重覆往返進行。
2 2 3
2.2.3 快速雛形模型
  • 開始於需求的搜集。開發者和客戶會面,定義整個軟體目標,確認需求是否已明確了解,並描繪更進一步的定義。
2 2 4
2.2.4 螺旋模型
  • 將瀑布模型的最終結果導回源頭,成為一個往復式的圓圈(Cycle),使整個流程具備回饋與檢驗機制,這就是螺旋模型(Spiral model,Boehm(1988))。
slide17
2.3 選用軟體生命週期模型
  • 該採用何種模型並沒有一定,必須取決於程式語言程序型或物件導向型、時程長短、成本大小、人力充足與否、組織型態..等各種因素,來選擇適合該軟體專案的過程模型。
slide18
2.4 軟體開發程序
  • 軟體開發程序(Software Develop Process)則是著重在於達成某一特定目標的一系列活動。
slide19
軟體程序
  • 軟體程序是一組的工具、方法、作法,用以製造軟體產品。
slide20
RUP
  • 軟體工程在近代最有名且使用在物件導向是Rational統一流程(Rational Unified sProcess, 簡稱RUP)
2 4 1 rational
2.4.1 Rational統一流程
  • Rational統一流程(Rational Unified Process,簡稱RUP註:因為是Rational 公司強力發展,現已被IBM公司併購。
  • 共有三大特點、四個階段和九個核心流程。
slide22
RUP最重要的它有三大特點
  • 軟體開發是一個疊代(Iteration,註:有人翻譯程重覆往返)過程。
  • 軟體開發是由Use Case驅動的。
  • 軟體開發是以構架設計(Architectural Design)為中心的。
slide23
四個階段
  • 1. 起始階段(Initial phase):進行可行性研究,定義出專案大小及涵蓋範圍,評估專案所需的能力、時程與經費,以及資訊系統預期達到之效益· 了解商業模型及需求。
  • 2. 精細規劃階段(Elaboration phase):擬定專案計畫、系統特性與架構·確認商業模型及需求·進行系統分析與設計。
  • 3. 建構階段(Construction phase):建構產品並進行單元測試、整合測試。
  • 4. 移轉階段(Transition phase):將產品分批交付給客戶進行驗收測試,並進行使用者訓練。
core workflows
九個核心工作流程(Core Workflows)
  • 1.  商業塑模(Business Modeling)
  • 2.  需求(Requirements)
  • 3.  分析和設計(Analysis & Design)
  • 4.  實作(Implementation)
  • 5.  測試(Test)
  • 6.  部署(Deployment)
  • 7.  配置和變更管理(Configuration & Change Management) 。
  • 8.  專案管理(Project Management) 。
  • 9.  環境(Environment) 。
slide25
RUP優點
  • (1)該程序方法論結合了許多來自眾多的成功方法論,提供完整的軟體開發流程。
  • (2)結合採用反覆式(Iterative)開發流程失敗,可降低開發的風險。
  • (3)UML作為其視覺化軟體分析與設計語言,使軟體開發人員之間的溝通與資訊的交換無礙。
  • (4)以UML中的使用者案例(Use-Case)作為整個Rational Unified Process的核心。
  • (5)受到工具的支援:程序經過良好的支援,且受到好的工具支援。例如:Rational Rose。
  • (6)對於軟體開發各階段中所參與之角色皆定義每一個角色所應有之責任與活動。
slide26
RUP缺點
  • 學習困難: 為了無所不包,相對使得該程序變的非常巨大,不論是學習或管理都很困難。
  • 花費很多時間: 各專案使用該方法論,會花上許多的時間。
  • 工具受限: 支援工具相對受限於Rational自己的產品。

(註:Rational公司是該幾位物件導向大師所設立的公司。)

2 5 1 cmmi
2.5.1 CMMI的由來
  • CMMI(Capacity Mature Model Integration,能力成熟度模式整合)便是軟體工程具體化的最佳例子,並非是一種軟體生命週期模型,而是一個軟體生產標準流程,無關於開發軟體使用何種軟體生命週期模型。
  • 2000年底卡內基-梅隆大學軟體工程研究所 (SEI)發表了能力成熟度模式整合(CMMI)
slide32
公司引進CMMI後成長實例
  • l  生產力約有10%到20%的提昇。
  • l  產品錯誤率約降低一個數量級。
  • l  對專案的預估與控制能力約提昇40%到50%。
  • l  依據 SEI 的研究資料顯示,成功公司軟體產品的瑕疵,比不成功的公司少了1/3以上,客戶滿意度也因而較高。
  • l  軟體成熟度每提昇一級,約可降低5%到10%的開發成本。
  • l 洛克希德公司在連續五年改善軟體開發流程後,軟體瑕疵數降低90%,上市時間增快40%,開發成本則降低75%。
2 5 2 cmmi
2.5.2 CMMI的模型和層級
  • 分成五個等級(Level )
    • CMMI-Level 1初始層(Initial)
    • CMMI-Level 2重覆層(Repeatable)
    • CMMI-Level 3定義層(Defined)
    • CMMI-Level 4管理層(Managed)
    • CMMI-Level 5最佳層(Optimized)
cmmi level 1 initial
CMMI-Level 1初始層(Initial)
  • 軟體程序漫無章法,程序未被定義。
cmmi level 2 repeatable
CMMI-Level 2重覆層Repeatable)
  • 已建立基本的管理程序,對成本、時程、和職務權責能加以追蹤、查詢。已有作業程序所須具有的紀律,所以有能力重覆使用相類似的專案成功的案例與經驗。
cmmi level 3 defined
CMMI-Level 3定義層(Defined)
  • 屬於管理和工程的活動都已設計、定義好,並且文件化,完整地整合成組織內的標準作業程序。
cmmi level 4 managed
CMMI-Level 4管理層(Managed)
  • 組織可收集詳細的軟體程序以及軟體產品的量測資料。
cmmi level 5 optimized
CMMI-Level 5最佳層Optimized)
  • 評估革新性的新技術,做反省與提升,有規則地依序導入採用,以持續不斷地改進程序。
2 5 3 cmmi key process area kpa
2.5.3 CMMI的關鍵流程領域(Key Process Area,KPA)
  • 每個成熟度層級內部各包含了數目不等的關鍵流程領域(Key Process Areas,KPAs)
key process area kpa
關鍵流程領域(Key Process Area,KPA)
  • 每一個關鍵流程領域則認定了一群相關的活動,以作為完成該關鍵流程領域的目標,目標中所描述的是關於該關鍵流程領域的關鍵技巧(Key Practices,KPs)的總體,可由此目來判定組織或專案是否有效地實施此關鍵流程領域。
  • 第一層是毫無章法的管理,所以沒有任何KPA,而第二層到第五層,每一成熟度階層都由一些KPA所組成。
goals
目標(Goals)
  • 每個KPA都設定有一組目標,標示出KPA的範圍、界限與企圖。
key practice kp
關鍵技巧(Key Practice,KP)
  • 每一個KPA是由幾個KP來描述,而KP是描述將KPA有效地的實現和制度化所需的重要活動與基礎建設(infrastructure)。
common feature
共同特徵(Common feature)
  • 共同特徵是屬性的表徵,經由它們可以來判定KPA的實施與制度化上是否具有效性、可否重複使用執行、以及是否可持續下去。
2 5 5 cmmi cba
2.5.5 CMMI鑑定(CBA)
  • CMMI鑑定工作須由SEI授權之主導評審員負責依SEI之方法及資料執行,並將執行結果回報給SEI。
2 5 6 cmmi
2.5.6 CMMI國內現況
  • 目前是由軟體自由協會成立軟體工業生產力提升計畫辦公室來輔導企業進行相關認証,而資策會技術處則取得政府補助,負責導入相關相關技術,以培養人力。
  • 國內的軟體廠商大部份爭取的是CMMI的Level II認證,目前國內已有多家取得CMMI認證,工研院電通所、碩網資訊、三商電腦、英特連..等。台積電的軟體部門也要透過印度Tata consulting來取得level 3認証。
2 6 iso 9000
2.6 ISO 9000
  • ISO9000本質上是一個品質管理系統標準,在品質系統建置的過程中,對品質系統架構面提供了一個良好的指導,可以幫助組織建立一個完整且能持續改善的品質系統。
2 6 1 iso 9000 3
2.6.1 ISO 9000-3
  • 軟體業也能夠採用ISO 9001標準,ISO公佈了ISO 9000-3的指導方針來因應具有開發製造,供給維護流程的軟體產業。
2 6 2 iso 9000
2.6.2 ISO 9000品質系統的建置
  • 流程導向的品質管理系統,是為了更切合客戶的需要
    • 新的標準在概念及結構上,被“流程方式”所取代,新的流程化架構和計劃-實施-檢查-執行(Plan-Do-Check-Action)改善循環程序一致。
2 6 3 iso 9000
2.6.3 ISO-9000與軟體工程
  • 軟體工程重點項目:
  • 1.            合約與需求管理
  • 2.            軟體開發流程與標準
  • 3.            建構管理之實施
  • 4.            軟體審查與驗證
  • 5.            軟體測試
  • 6.            專案管理
  • 7.            系統維護管理
  • 8.            量測與統計
2 6 4 iso 9000 cmmi
2.6.4 ISO 9000與CMMI
  • ISO 9000是以架構整體品質系統為優先,再透過持續改善的過程,加強每一流程到理想的程序。
  • 而CMMI模式則對每一關鍵流程的導入有著較嚴格的要求,但以分批逐步導入的方式架構整個品質系統。
  • 雖然導入的邏輯不同,但如果能確實的建置、實施、與持續改善品質系統,兩者都可以為軟體業建置出一個能有效提昇企業競爭力與品質的品質系統。
2 6 5 iso 9000
2.6.5 ISO 9000國內現況
  • 國內目前也已經有四十家以上之資訊軟體公司取得ISO-9000認證。
  • 國內軟體公司卻常常迫於績效或市場需要,而期望在六個月以內通過ISO-9000認證,通過後亦不積極於進行持續改善。
2 7 case tool
2.7 CASE Tool
  • CASE Tool (Computer-Aided Software Engineering Tool,電腦輔助軟體工程工具) 是一種電腦工具,是用以將資訊系統的開發與維護的流程自動化的利器。
  • Rational的Rose 作為業界普遍公認的標準,Sybase PowerDesigner也符合此一標準。
slide59
採用RUP的精神
  • 可先將飯店管理系統,如圖2-13是其功能架構圖,先拆成房間管理系統、訂房處理系統、會員管理系統、財務報表系統和系統設定系統等。再將訂房處理系統再拆成若干子系統,例如: 訂房子系統、取消訂房子系統、Check-in系統、Check-out子系統等。
  • 每次重覆循環只發展一個重要的子系統,依照開發系統流程從需求、分析、設計、實作和測試等,完成每一個子系統並且釋出一個可執行的版本
slide61
總結
  • 必須依據該軟體專案的各種特性,例如程式語言程序型或物件導向型、時程長短、成本大小、人力充足與否、組織型態。等各種因素,來選擇適合該軟體專案的生命週期模型。