Software EngineeringA Practical Approach

Luba Tang2010/4/6

Outline

• 軟體工程的重要性• 實務上的進行方法

Luba Tang ( 唐文力 )Senior Engineer in CTO/CIT, MediaTek

HW/SW Co-Simulation, Embedded Compiler

SW is more costly than HW

In recent 5 years, software is 3 times costly than hardware

Software aspects of IC design can now account for 80% or more of embedded systems development cost

Embedded System Suffers from Design Gap

Challenges in Modern Embedded Software

Implement a large, various and variant embedded system Shrinking time-to-market for short life cycle of a product

• 10~15 months for releasing• 6~12 months for being on the shelf

Changing requirement• x2 new devices per 10 months

Coordinate with more than 6 teams coming from different backgrounds

Heavy workload• 250 K Line of code for self product• 1M Line of code in total system

High reliability

Everything about DESIGN becomes important

Esp. Software Engineering

我的軟體開發流程

對我而言是真實的 我不研究軟體工程 自己用過也教過，經過實驗與取捨

混合多種性質 不是最快的

曾有學弟改變流程，在更短時間內做完更多的事

軟體開發的過程

挑對手 – 在專案開始之前– 組織行為– 專案時間表– 人力配置

初手 – 規格與設計– 組織與工作規劃– 需求分析– 架構設計

中盤策略 – 撰碼與測試– Unit-test 的策略– Dependency Checking– Revision control

末盤策略 – 交貨拿錢– Software versioning– Release engineering

軟體開發機構的成長過程

渾然不知 (Oblivious)– 我們都不知道我們正尋着一個過程做事

變化無常 (Variable)– 我們全憑當時的感覺做事– 超級程式設計師的形象

照章行事 (Routine)– 我們凡事皆依造工作慣例，除非我們陷入

恐慌– 超級技術負責人的形象

把穩方向 (Steering)– 我們會選擇結果較好的工作慣例來行事– 有能力的經理

防範未然 (Anticipating)– 我們會參造過往的經驗制定出一套工作慣

例 全面關照 (Congruent)

– 人人時時刻刻都會參與改善工作問題的要求

客戶的要求

低低

高

高

P0

P1

P2

P3

P4

P5

模式一：變化無常型

仰賴超級程式設計師– 不同程式設計師的能力可達20:1 甚至更高的差別– 問題的複雜度往往呈現指數成長，就專案成功的機率而言，超級程式設計師並

非決定性的關鍵 模式

– 『告訴我們你想要的是什麼（而且不要改變你的心意）』– 『提供我們一些資源（而且只要開口，你就會不停地提供）』– 『不要再來煩我們（消除所有隨機事件發生的可能性）』

軟體開發系統

需求

隨機事件

資源

其它輸出

軟體

模式二：造章行事型

仰賴超級技術負責人– 問題複雜度過高，承認超級程式設計師並非決定性的關鍵– 控制者還無法直接取得開發系統內部狀態

模式– 『我將會使那些程式設計師，管他張三李四，皆能善盡責任』– 『我會僱用交大的學生，訓練他們變聰明』– 『我會開除清大的學生，讓其他人工作更賣力』

軟體開發系統

需求 （改變）

隨機事件

資源

其它輸出

軟體

控制者改變

模式三：把穩方向型

模型– 預期狀態的樣貌– 觀察實際的能力– 比較預期與實際差異的能力– 對系統採取行動，使得實際狀況更接近預期的能力

軟體開發系統

需求

隨機事件

資源

其它輸出

軟體

控制者改變

需求

挑選適合的開發模式

模式沒有對與錯– 就相同的問題而言，上述模

式的成功機率其實大同小異 針對客戶與問題的要求來

選擇模式，而非由資源來選擇模式

不計資源的話，永遠可以以集成法來進行

問題的要求

客戶的要求

低低

高

高

P0

P1

P2

P3

P4

P5

專案開發的時間表 (1/2)

需求 設計 撰碼 測試

總時間通常 10~12 個月必須第一次 release

個別時間

3/5~2/3 的時間6 個月

1/10~1/6 的時間1 個月

1/3~1/4 的時間2.5 個月

預留1/10 的時間1 個月

專案開發的時間表 (2/2)

總時間第二次 release 之後，每隔 N 週要 release 一次

• Linux kernel 中， N=8~12

個別時間

Release 1 Release 2 Release 3 Release 4

24hours

24hours

24hours

24hours

依專案慣性4~8週

專案開發的人力需求

總人力通常每 10K 需要 2~3 個人

個別人力

需求 設計

撰碼 測試

通常 1~3 人 依子專案個數約莫 3~5 人

依獨立元件個數從 5~30 人都可能

維護

和設計人數相仿

閒置人力 ?建立開發環境讀相關規格

軟體開發的過程

挑對手 – 在專案開始之前– 組織行為– 專案時間表– 人力配置

初手 – 規格與設計– 組織與工作規劃– 需求分析– 架構設計

中盤策略 – 撰碼與測試– Unit-test 的策略– Dependency Checking– Revision control

末盤策略 – 交貨拿錢– Software versioning– Release engineering

初手 – 撰寫規格書

不要產生沒必要的文件 如果溝通會耗掉某些人大部分的時間，就必須撰寫規格書

負責溝通的人，寫對應的章節

規格書中的章節1. Project Vision 2. Organization3. Requirement4. Basic Design5. Milestone Design

Project Vision

內容– 我們要做甚麼 ?– 為什麼要做這件事 ?– 投資報酬– 失敗風險

例子– 將 simulation instruction 相關資訊放入 SQL 資料庫中，以利下列操作1. 方便閱讀 simulation instruction 內容2. 自動生成 simulation instruction 的 header 與

implementation files3. 方便修改、新增 simulation instruction 的內容

人力組織 – Marlin Hills’ programming team

優點 : 結構完整、歷經二十多年考驗 缺點 : 人員流動風險高、人員幅度較大 可考慮以Mills Chief Programmer Team 為基礎，將多

個工作集中到少數人身上

Example

Pair Programming

優點– 降低溝通成本– 自然導入 unit test– 減少 trivial fault– 提升 programmer素質– 不需要額外的 peer review

執行方法– 每個人是 code owner ，同時也是他人的 code tester– 兩人為一組，每 1~2週輪換一次

在實驗室當中， pair programming 的效率比single programming 高

軟體開發的過程

挑對手 – 在專案開始之前– 組織行為– 專案時間表– 人力配置

初手 – 規格與設計– 組織與工作規劃– 需求分析– 架構設計

中盤策略 – 撰碼與測試– Unit-test 的策略– Dependency Checking– Revision control

末盤策略 – 交貨拿錢– Software versioning– Release engineering

需求分析

使用情境設定 (必要 )–畫圖，然後說故事

使用者與事件列表 ( 非必要 )–列出使用情境中的所有

• 主詞 => 物件• 動詞 => 函式或關係• 形容詞 /副詞 => 參數• 受詞 => 參數

UML Scenario

簡單的情境設定的例子 – 看圖說故事

學生

作業

報告

程式

勞動

作業

林教授

寫

出

可能是是

可能是

可能是

是

是

說故事的重點

優秀的工程師，就是懂得溝通的工程師 溝通系統中四大關係1. 生成2. 繼承3. 使用4. 毀滅

學生

作業

報告

程式

勞動

作業

林教授

寫

出

可能是是

可能是

可能是

是

是

Be 動詞繼承關係

一般動詞使用關係

需求分析重點就是在搞清楚四大關係

軟體開發的過程

挑對手 – 在專案開始之前– 組織行為– 專案時間表– 人力配置

初手 – 規格與設計– 組織與工作規劃– 需求分析– 架構設計

中盤策略 – 撰碼與測試– Unit-test 的策略– Dependency Checking– Revision control

末盤策略 – 交貨拿錢– Software versioning– Release engineering

專案的三大本質

單一進入點 (Single Entry) 相依於其它專案 (Dependency) 不可能遞迴相依 (Acyclic)

程式或 函式庫

stdlib

Qt math

Pthread

單一進入點

有相依性

不能遞迴相依

架構設計重點就是在搞清楚元件之間的相依性

架構設計的步驟

從最粗糙到最精細– Software Stack (必要 )– CRC ( 非必要 )– Work-Breakdown-Structure (必要 )– UML Object diagram (必要 )

Software Stack (必要 )

定義有哪些元件元件之間概念上的分層

基本須要先做的元件只需要基本測試

可以後做的元件需要比較多的測試

CRC - Class-Responsibility Card ( 非必要 )

目的– 確保生成關係的可行性

買空白名片卡，正面寫上物件名稱，背面寫上物件的用途 不同元件的設計者，持有不同的 CRC卡 找一天大家一起打個牌 玩法

1. 從main 開始， main 有用到的物件就疊在main 上面2. 如果物件 A 用到物件 B ，就將 B放到 A 上面，直到所有牌都放完3. 如果牌放完，而沒有缺牌，則確保架構是 Acyclic 的

mainQt math

stdlib

pthread

Work-Breakdown Structure (必要 )

顧名思義，將工作不斷分割，依相依性排好 在規劃初期，通常只會分割到第二階 實作階段，會分割到第三階，但是不是必要 不在 software stack 上的工作，記得也要列進來

Example

Level 2 dependency graph

Level 3 dependency graph

軟體開發的過程

挑對手 – 在專案開始之前– 組織行為– 專案時間表– 人力配置

初手 – 規格與設計– 組織與工作規劃– 需求分析– 架構設計

中盤策略 – 撰碼與測試– Dependency Checking– Revision control– Unit-test 的策略

末盤策略 – 交貨拿錢– Software versioning– Release engineering

必然會遇到的問題

只要程式有人用– 你就會繼續開發，讓他更好用– 客戶或許會更新程式，或許不會

客戶會面臨–版本太新–版本太舊

Too Old Problem

Host– 提供函式庫的專案

Dependant– 使用函式庫的程式

Too Old Problem– Host 提供的函式庫版本太舊

DependantHost

Version 2

需要 version 3

Too New Problem

Host 所提供的函式庫太新

DependantHostV3

需要 version 3

HostV6

HostV4

HostV5

改成 version 6 ，可能嗎 ?

解決方案

確認問題– 利用 Dependency Checker(如 ./configure script) ，在編譯之前檢查版本，以確保版本吻合

解決問題– 利用 Source Code Manager (如 SVN, CVS,

Perforce) ，返回到適合的版本

Dependency Checking

最常見 dependency checker 為 ./configure script Dependency checker 產生器有 Open Source 的

– Autoconf– Cmake

Dependency checker 會 Top-down 的檢查函式庫版本以及系統環境

程式或 函式庫

stdlib Qt math

Is v2?

Is v3?

Is v6?

Global Version

解決太舊的問題 將所有的 project 設定一個版次號碼 規定所有的 dependant 的版次必須要小於等於 host 的版次 最上層的 dependant 為 global version

MainV2

StdlibV6

QtV5

MathV3

PthreadV7

Global version

Local Version

解決太新的問題這是從少數客戶擴張到多數客戶的關鍵

DependantHostV3

需要 version 3

HostV6

HostV4

HostV5

HostV3-1

HostV3-2

開分支 (branch)

合併 (merge)

版次跳躍

Version Threads

2.3

2.4

2.5

2.6

2.7

2.3-1 2.3-2

2.4-1

2.6-1

Local Versions

Global Versions

軟體開發的過程

挑對手 – 在專案開始之前– 組織行為– 專案時間表– 人力配置

初手 – 規格與設計– 組織與工作規劃– 需求分析– 架構設計

中盤策略 – 撰碼與測試– Dependency Checking– Revision control– Unit-test 的策略

末盤策略 – 交貨拿錢– Software versioning– Release engineering

Software Versioning

功用– 對外做為看板，告知客戶目前專案的 stage of

life cycle– 對內做為進度管理，得知目前 release status

• Point release• Major release

Stage of Life Cycle

Pre-alpha0 developing

Alpha1 Internal testing

Beta2Customer testing

RC3Release Candidate

RTM4Release to Market

GA5Success in Market

In Market

In House

Release Status

Point release– 為了 bug-fix 經常且快速的 release

Major release– 為了 new feature 告知客戶應做更新

2.6

2.7

2.8 2.9

2.6.1 2.6.1

2.6.1

2.6.1 2.6.1major

point

Case Study 1 – DirectFB

Format– [Major].[Minor].[Micro].[IF_Age].[Bin_Age]

Major release– [Major].[Minor]

Point release– [Micro]

Release Status– [IF Age].[Bin Age]

Release 的規則不固定，隨喜好進版。 進版規則

– Existing interface changed => IF Age = 0– Binary interface changed => Bin Age = 0– Bug-fixed or new feature => Micro += 1

Case Study 2 – Linux Kernel 2.6.11+

Format– [Major].[Patch Level].[Minor].[Bug-fixed]

改進以往 release 方式 (2.odd/2.even) ，利用多個 source tree 來增加 patch 進入 mainline 的效率

Source tree Versioning Meaning

Mainline 2.6.X/2.6.X-rcY Developing source tree

Stable 2.6.X.Y For bug-fix

Legacy 2.6.X.Y-1 1 version old stable

Mm Integration tree, for new feature

Ck/Rt Improve performance

Linux kernel version threads

2.6.11

2.6.11.1stable

Mainline

2.6.12

2.6.13

2.6.14

2.6.15

2.6.11.2

2.6.12.1

2.6.14.1

MM

Proposed Release Engineering

3.1

3.1.1stable

Developing

3.1.2

3.2.1

3.4.1

StableRelease

3.2

3.3

3.4

3.5

軟體開發的過程

挑對手 – 在專案開始之前– 組織行為– 專案時間表– 人力配置

初手 – 規格與設計– 組織與工作規劃– 需求分析– 架構設計

中盤策略 – 撰碼與測試– Dependency Checking– Revision control– Unit-test 的策略

末盤策略 – 交貨拿錢– Software versioning– Release engineering