軟體工程之版本控制 Tribute

今日主題 版本控制 ----- 中場休息 -------- 軟體工程系統架構簡述 ----- 中場休息 -------- 簡述 CMMI Overview

開始之前 問題一： 我為什麼要聽這一場 ?( 被 HaWay 騙來 ) 被課程名稱”騙”來 ( 吸引我來上這門課 ) 程式開發工作是不是遇到問題、瓶頸？ 程式開發工作是不是沒有什麼效率？想提升效率而

來？其他原因？ 想在現在的環境中突破 ( 留下來 / 離開 )

問題二： 聽完這場後，我希望我能從中獲得什麼？ 職場不是畜牧業，請不要用”飼料雞”的方式教育、

學習。 聽完這門課程後，我們可不可以了解”工具”的真正 用意 / 用途。 “ 軟體工程”是一條辛苦又漫長的道路。如何做到”

學習愉快”、”知識 / 經驗 /$$ 進袋”？ 導入”版本控制”後，請記得做持續執行評估、追蹤。

結束暖身 : 我們正式開始 我們以一個簡單的圖示來了解”傳統式”與”現在式” ( 指導入軟體工程流程 ) 的工作型態的比較 ( 見下圖 )

是不是一樣多呢 ? 排列整齊的那一邊比較好計算呢 ? 用上面的圖示來說明工作性質形態，我們很清楚的知

道排列整齊的那一邊比較好計算。 但是仍然有 80% 的人，他的工作形態是屬較雜亂、

不好計算的那一邊的。 為什麼要整理 ( 流程化 ) ？為什麼要管理？ 「記得有一本書提到說：整理的目的，是為了方便日

後的尋找，以避免日後事情急迫時，我們能從容的找尋、取得我們要的東西。而管理的目的，是為了讓所執行的過程、動作能更效率。」

80 ： 20 法則 ( 柏雷多法則原理 )

想想看，你是屬於那一類 80/20?

「艾森豪」法則 美國社懷特，艾森豪將軍指出，人們的精力，

往往被緊急但較不重要的事情所佔用，而並未完全或儘可能的將時間與精力用在重要的事。 「艾森豪」法則演繹啟示：留多一點時間給重要的

事情。

「艾森豪」法則規劃矩陣

60 ： 20 ： 20 彈性原則

協助瞭解：版本控制的意義 為什麼要做版本控制？ ( 效率提升…等 ) 與別人在同樣環境條件下一起競爭，你要怎麼比

別人更具競爭優勢？ ( 想要活著，就得先了解死亡 )

何時、何地 ( 環境條件 ) 要做版本控制？

Build any VersionBuild any Version

Configuration Builder working with Version Manager can build any version

io.cfoo.c test.c test.hfoo.h io.h

PROD

BETA

ALPHA

BASE

1.3

1.2

1.1

1.0

1.3

1.2

1.1

1.0

1.3

1.2

1.1

1.0

1.3

1.2

1.1

1.0

1.3

1.2

1.1

1.0

1.3

1.2

1.1

1.0

Organise: Version Management

RELEASE 1.0

RELEASE 1.5

RELEASE 2.0

C.I. 1

1.0

1.1

1.2

C.I. 2

1.0

C.I. 3

1.0

1.1

1.2

C.I. X

1.0

1.3

1.1

1.2

1.3

1.4

1.1

1.5

1.6

1.7

1.4

1.5

1.2

1.3

1.4

範例範例一： 「以 H 開頭 y結尾先生為例 (multi-girl friend process)

解釋單人多工版本控制」

範例二： 「以我的”遺書”為例 解釋版本控制與工作交接的關係」

休息一下

給予資訊：軟體工程系統架構 軟體工程系統架構組成的元件有那些 ? 80/20 ：每一個最小單位投入比，可達最佳的產能比。

如何針對每個 Project 去做適合的目標設定？ 提供”方法”而不是”答案”；提供”釣竿”

而不是”漁獲”。

SW 完整的建構管理解決方案

SW CM

版本管理Version

Management(Version Manager)

變更管理Issue

Management(Tracker)

建置管理Build

Management (Configuration Builder)

交付管理Release

Management(VM + CB)

SW CM Process Overview

Configuration Builder

(Build scripting tool)

Tracker(Issue management)

Version Manager(Version control, Release

management)

Oracle,Sybase, etc.

Tracker ReportTracker Report1

Trent reports describe changes in issue field values over time.

2

Distribution Reportsdescribe Categories of issues in termsof the percentagethey represent ofa specified group Of issues.

3

Modules Reportsdescribe which issues are related to which source files.

4

PVCS Metrics is an application shipped with PVCS Tracker which facilitates reporting data on the web.

Report AssistantReport Assistant 5This feature in administrator tool generates custom view of the database according to SQL Statement.

Workflow OverviewWorkflow Overview• Defects• Change Requests

Decision Making andProcess ImprovementReports

Discovery Investigation Resolution Verification

Submit by tester

(Submit SCR)

Notify Notify Notify

Review and Assignby Manager Solve by Developer

(Update SCR) (Update SCR) (Update SCR)

Verify by QA

Automate WorkflowKeep track of statusProduce report

軟體工程建構管理相關之問題版本管理問題：目前系統有那些項目？版本狀況？修改記錄？存取管制？同時修改？

系統版本管理問題：系統交付版本記錄？組成項目與版本狀況？

問題追蹤與管理問題：問題處理狀況追蹤與管制？相關人員主動通知？無法產生圖表了解產品品質狀況？無法追溯問題修改之程式及版本？

系統組態建置 (Build)問題：無法 Build正確的系統版本？

阿迪茲雙 S 職涯黃全規劃曲線 ( 見下圖 )

休息一下

簡述 CMMI Overview

軟體開發能力評鑑 CMM 與 CMMI 的一些差異 CMMI 是壓垮軟體工業的最後一根稻草嗎 ? CMMI 沒有人性，雞排工程師的哀歌

Outline

CMM brief Process is the focus 5 Maturity Levels Assessment

什麼是 CMM

CMM: 能力成熟度模型 (Capability Maturity Model) CMM vs. ISO 9000 Kinds of CMM

SW-CMM: for Software Organization SE-CMM: for System Engineering Organization IPD-CMM: for Integrated Product Development CMMI: Integration of SW/SE/IPPD P-CMM: for human asset in IT …

CMM 的演變 二十幾年來 , 美國很多政府機構和公司都發現很多買

來的軟體無法符合他們的需求而且無法掌握品質 1984 年 , CMU (Carnegie Mellon University) 在美國

國防部的支持下成立了 SEI (Software Engineering Institute)

1986 年 , SEI 開始制訂一套標準用來幫助軟體公司改善軟體流程 ; 1991 年 , SW-CMM v1.0 問世

1993 年 , SW-CMM v1.1 問世 , 成為世界上應用最廣泛的 CMM

2000 年 , SEI 將 SW-CMM, EIA 731 (from SE-CMM), IPD-CMM 整合為 CMMI

CMM 的用途 評價組織與流程的能力與成熟度所用的基準 提昇組織與流程的能力與成熟度所用的進程

5 Maturity Levels in CMMI

1. Initial

2. Managed

3. Defined

4. Quantitatively Managed

5. Optimizing

Process Improvement Focus

Optimizing

QuantitativelyManaged

Defined

Initial

ManagedBasic ProjectManagement

ProcessStandardization

QuantitativeManagement

ContinuouslyProcess

Improvement

Level 1 (Initial) 的特徵 沒有流程或是流程的穩定性很差，甚至是混亂組織雖然還是可以完成計畫，但通常會進度落

後，超出預算組織的成功完全仰賴某些成員的職能及英雄表

現，除非相同職能的人員存在，否則成功的計畫無法再次出現

因此在 Level 1 的組織中，所謂 Process Capability 只能用來評價每個人，而非組織

Level 2 (Managed) 的特徵建立起計畫管理的政策及實踐這些政策的程序組織已有了基本的計畫管理與控制 計畫的管理人員會追蹤的成本、時程與功能 Process Capability ： Disciplined; 因為計畫

的規劃與追蹤都是穩定的，計畫的進行是在有效的管控之下。成功的經驗可以不斷地重複，但是當異常狀況發生時，卻無法有效地反應

Level 3 (Defined) 的特徵 有一個團隊會專責制定組織的標準流程組織的標準流程會因計畫而修改成特定計畫使

用的流程 有一個教育訓練計畫來確保manager及技術

人員有正確的知識及技巧來滿足被指派的角色組織內的成員已瞭解流程中的權責劃分及作業 Process Capability ： Standard & Consistent;

工程及管理的作業均已標準化，組織也有足夠的能力因應突發狀況

Level 4 (Quantitatively Managed) 的特徵產品及流程均已設定了量化的品質目標 流程的所有相關作業都可透過量測的方式得到量化的生產力與品質指標，可供蒐集與分析

流程中任何導致例外狀況的變因，均可透過量測的數據辨識出來，加以去除

Process Capability ： Being Quantifiable & Predictable; 因為整個流程都可被量測，組織能夠預測出可能發生的異常狀況

Level 5 (Optimizing) 的特徵 整個組織把重點放在持續地改善流程 為了防止 Defect 的產生，組織可以找出流程

的缺點並加以改良藉由加強現有流程與技術或採用新流程與技術使流程不斷地改進

Process Capability ： Continuously Improving; 整個組織都在不斷地努力改進流程，以避免異常狀況的發生，也因此改進了流程的效能

Toward High Maturity Level

Increase the predictability of cost, effort, schedule and quality

Decrease the average of cost, effort and schedule

Process Area(PA)

在 Level 2~5, 每一個 Level都有若干個 PAs做為組織流程改善的重點

PAs in Level 2 (Managed)

1. Requirement Management• 管理產品與產品元件的需求規格，確保需求規格、

計畫規劃與計畫產出的一致性2. Project Planning

• 為計畫中工程部分與管理部分的活動做出規劃3. Project Monitoring and Control

• 提高計畫進度的透明度以便成效不彰時採取措施4. Supplier Agreement Management

• 選擇並管理合適的供應商

PAs in Level 2 (Managed)

5. Measurement and Analysis• 因應管理階層的需求，而提供與維護數據

的量測與相關分析6. Process and Product Quality Assurance

• 為運作中的流程及產品提供足夠的透明度以便品質的掌控

7. Configuration Management• 在產品的生命週期內，建立並維護產品的

整體性與一致性

PAs in Level 3 (Defined)

1. Requirement Development• 建立與分析客戶對產品及產品元件的需求

2. Technical Solution• 發展、設計、實作出滿足需求的產品

3. Product Integration• 將各個產品的元件組合成正常運作的產品

4. Verification• 驗證所做的產品是否符合所制訂的需求

PAs in Level 3 (Defined)

5. Validation• 確認產品滿足客戶所設想的使用方式、功

能與環境6. Organization Process Focus

• 建立組織中各項流程在各單位的權責與作業項目

7. Organization Process Definition• 發展並維護組織所有的流程

PAs in Level 3 (Defined)

8. Organization Training

提供教育訓練使所有的成員均有足夠的知識與技能完成所負責的作業項目

9. Integrated Project Management• 針對 IPPD 的計畫，建立共同的計畫規劃與掌控

10. Risk Management• 鑑別出潛在的問題，並規劃因應的措施

PAs in Level 3 (Defined)

9. Decision Analysis and Resolution• 採用系統化的步驟來分析各項決策

10. Organization Environment for Integration• 針對 IPPD 的計畫，提供負責的人員與組織

11. Integrated Teaming• 整合各個部門的流程，形成一個相互合作

的團隊

PAs in Level 4 (Quantitatively Managed)

1. Organizational Process Performance• 建立並維護組織流程效能的量化指標

2. Quantitative Project Management• 建立量化的方式來作計畫的規劃與掌控

PAs in Level 5 (Optimizing)

1. Organizational Innovation and Deployment• 選擇並實施新的技術 ( 工具，方法或流程 )

以改進組織流程2. Causal Analysis and Resolution

• 找出瑕疵或問題出現的原因，並採取行動來避免

Assessment

Assessment is not the focus, but Improvement is Assessment 的成本 :

約為期兩週 約數百萬台幣的費用

Assessment 的方式： Assessment team 的組成： Assessors + Assessed team

members 形式：文件審閱與面談

文件審閱的目的在瞭解有哪些流程已被定義面談的目的在瞭解流程執行的情況

CMMI vs. ISO 9000

ISO 9000關注的是： 是否有足夠的流程 是否已將流程定義清楚

CMMI還關心：流程是否有被確實地執行雖然 ISO 9000 所制訂的流程包含了大部分

CMMI L2~3 的 PAs ，但實際上通過 ISO 9000 認證的公司能通過 CMMI L2 或 3 的情況還是很少 (Roselyn: 2/27)

Conclusion

The major problems of SW/SE/IPPD projects are managerial not technical

CMMI is a short cut to high quality CMMI makes “Software Factories” possible!!

CMMI Ref. Info

Version Control & Process tracker tool1. IBM Rational ClearCase2. Merant PVCS VM & Tracker3. Open Source Subversion 、 CVS 、 CVS SVK…..

Ref. Linkhttp://www.sei.cmu.edu/cmmi/http://www.csqa.org.tw

/portal/modules/news/ CMMI QBQ

Q & A