![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](https://image.slidesharecdn.com/softwareengineering-120524014818-phpapp01/85/2012-05-23-AU-Talk-48-320.jpg)
![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](https://image.slidesharecdn.com/softwareengineering-120524014818-phpapp01/85/2012-05-23-AU-Talk-49-320.jpg)
More Related Content
What's hot (20)
Viewers also liked (14)
Similar to 2012/05/23 AU Talk - 讓事情發生 (20)
2012/05/23 AU Talk - 讓事情發生
- 1. Software Engineering A Practical Approach Luba Tang 2010/4/6
- 2. Outline ? 軟體工程的重要性 ? 實務上的進行方法 Luba Tang (唐文力) Senior Engineer in CTO/CIT, MediaTek HW/SW Co-Simulation, Embedded Compiler
- 3. 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
- 4. Embedded System Suffers from Design Gap
- 5. 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
- 7. 我的軟體開發流程 ? 對我而言是真實的 ? 我不研究軟體工程 ? 自己用過也教過，經過實驗與取捨 ? 混合多種性質 ? 不是最快的 ? 曾有學弟改變流程，在更短時間內做完更多的事
- 8. 軟體開發的過程 ? 挑對手 – 在專案開始之前 – 組織行為 – 專案時間表 – 人力配置 ? 初手 – 規格與設計 – 組織與工作規劃 – 需求分析 – 架構設計 ? 中盤策略 – 撰碼與測試 – Unit-test 的策略 – Dependency Checking – Revision control ? 末盤策略 – 交貨拿錢 – Software versioning – Release engineering
- 9. 軟體開發機構的成長過程 ? 渾然不知 (Oblivious) – 我們都不知道我們正尋着一個過程做事 高 P5 ? 變化無常 (Variable) P4 – 我們全憑當時的感覺做事 – 超級程式設計師的形象 ? 照章行事 (Routine) 客 – 我們凡事皆依造工作慣例，除非我們陷入 戶 P3 恐慌 – 超級技術負責人的形象 的 要 ? 把穩方向 (Steering) 求 – 我們會選擇結果較好的工作慣例來行事 P2 – 有能力的經理 ? 防範未然 (Anticipating) – 我們會參造過往的經驗制定出一套工作慣 例 P1 ? 全面關照 (Congruent) – 人人時時刻刻都會參與改善工作 低 P0 低 高 問題的要求
- 10. 模式一：變化無常型 ? 仰賴超級程式設計師 – 不同程式設計師的能力可達20:1 甚至更高的差別 – 問題的複雜度往往呈現指數成長，就專案成功的機率而言，超級程式 設計師並非決定性的關鍵 ? 模式 – 『告訴我們你想要的是什麼（而且不要改變你的心意）』 – 『提供我們一些資源（而且只要開口，你就會不停地提供）』 – 『不要再來煩我們（消除所有隨機事件發生的可能性）』 需求 資源 軟體 軟體開發系統 隨機事件 其它輸出
- 11. 模式二：造章行事型 ? 仰賴超級技術負責人 – 問題複雜度過高，承認超級程式設計師並非決定性的關鍵 – 控制者還無法直接取得開發系統內部狀態 ? 模式 – 『我將會使那些程式設計師，管他張三李四，皆能善盡責任』 – 『我會僱用交大的學生，訓練他們變聰明』 – 『我會開除清大的學生，讓其他人工作更賣力』 控制者 改變 需求 （改變） 資源 軟體 軟體開發系統 隨機事件 其它輸出
- 12. 模式三：把穩方向型 ? 模型 – 預期狀態的樣貌 – 觀察實際的能力 – 比較預期與實際差異的能力 – 對系統採取行動，使得實際狀況更接近預期的能力 需求 控制者 改變 需求 資源 軟體 軟體開發系統 隨機事件 其它輸出
- 13. 挑選適合的開發模式 ? 模式沒有對與錯 高 P5 – 就相同的問題而言，上述模 P4 式的成功機率其實大同小異 ? 針對客戶與問題的要求來 客 選擇模式，而非由資源來 戶 P3 選擇模式 的 要 ? 不計資源的話，永遠可以 求 P2 以集成法來進行 P1 低 P0 低 高 問題的要求
- 14. 專案開發的時間表 (1/2) ? 總時間 ? 通常 10~12個月必須第一次release ? 個別時間 需求 設計 撰碼 測試 3/5~2/3 1/10~1/6 1/3~1/4 預留 的時間 的時間 的時間 1/10的時間 6個月 1個月 2.5個月 1個月
- 15. 專案開發的時間表 (2/2) ? 總時間 ? 第二次release之後，每隔N週要release一次 ? Linux kernel中，N=8~12 ? 個別時間 24 24 24 24 hours hours hours hours Release 1 Release 2 Release 3 Release 4 依專案慣性 4~8週
- 16. 專案開發的人力需求 ? 總人力 ? 通常每10K需要2~3個人 ? 個別人力 建立開發環境 閒置人力? 讀相關規格 撰碼 測試 設計 維護 需求 通常1~3人 依子專案個數 依獨立元件個數 和設計人數相仿 約莫3~5人 從 5~30人都可能
- 17. 軟體開發的過程 ? 挑對手 – 在專案開始之前 – 組織行為 – 專案時間表 – 人力配置 ? 初手 – 規格與設計 – 組織與工作規劃 – 需求分析 – 架構設計 ? 中盤策略 – 撰碼與測試 – Unit-test 的策略 – Dependency Checking – Revision control ? 末盤策略 – 交貨拿錢 – Software versioning – Release engineering
- 18. 初手 – 撰寫規格書 ? 不要產生沒必要的文件 ? 如果溝通會耗掉某些人大部分的時間，就必須撰寫規 格書 ? 負責溝通的人，寫對應的章節 ? 規格書中的章節 1. Project Vision 2. Organization 3. Requirement 4. Basic Design 5. Milestone Design
- 19. Project Vision ? 內容 – 我們要做甚麼? – 為什麼要做這件事? – 投資報酬 – 失敗風險 ? 例子 – 將simulation instruction相關資訊放入SQL資料庫中 ，以利下列操作 1. 方便閱讀simulation instruction內容 2. 自動生成simulation instruction的header與implementation files 3. 方便修改、新增simulation instruction的內容
- 20. 人力組織 – Marlin Hills’ programming team ? 優點: 結構完整、歷經二十多年考驗 ? 缺點: 人員流動風險高、人員幅度較大 ? 可考慮以Mills Chief Programmer Team為基礎，將多個 工作集中到尐數人身上
- 21. Example
- 22. Pair Programming ? 優點 – 降低溝通成本 – 自然導入unit test – 減尐trivial fault – 提升programmer素質 – 不需要額外的peer review ? 執行方法 – 每個人是code owner，同時也是他人的code tester – 兩人為一組，每1~2週輪換一次 ? 在實驗室當中，pair programming的效率比single programming高
- 23. 軟體開發的過程 ? 挑對手 – 在專案開始之前 – 組織行為 – 專案時間表 – 人力配置 ? 初手 – 規格與設計 – 組織與工作規劃 – 需求分析 – 架構設計 ? 中盤策略 – 撰碼與測試 – Unit-test 的策略 – Dependency Checking – Revision control ? 末盤策略 – 交貨拿錢 – Software versioning – Release engineering
- 24. 需求分析 ?使用情境設定 (必要) – 畫圖，然後說故事 ?使用者與事件列表(非必要) – 列出使用情境中的所有 ? 主詞 => 物件 ? 動詞 => 函式或關係 ? 形容詞/副詞 => 參數 ? 受詞 => 參數
- 25. UML Scenario
- 26. 簡單的情境設定的例子 – 看圖說故事 學生 報告 寫 是 可能是 作業 是 程式 可能是 作業 是 出 可能是 勞動 林教授
- 27. 說故事的重點 ? 優秀的工程師，就是懂得溝通的工程師 ? 溝通系統中四大關係 1. 生成 2. 繼承 學 報 寫 是 告 生 3. 使用 可能是 作 一般動詞 4. 毀滅 業 是 使用關係 程 可能是 式 作 是 業 出 可能是 Be 動詞 勞 繼承關係 動 林教授
- 28. 軟體開發的過程 ? 挑對手 – 在專案開始之前 – 組織行為 – 專案時間表 – 人力配置 ? 初手 – 規格與設計 – 組織與工作規劃 – 需求分析 – 架構設計 ? 中盤策略 – 撰碼與測試 – Unit-test 的策略 – Dependency Checking – Revision control ? 末盤策略 – 交貨拿錢 – Software versioning – Release engineering
- 29. 專案的三大本質 ? 單一進入點 (Single Entry) ? 相依於其它專案 (Dependency) ? 不可能遞迴相依 (Acyclic) 單一進入點 有相依性 程式或 函式庫 Qt math stdlib 不能遞迴相依 Pthread
- 30. 架構設計的步驟 ?從最粗糙到最精細 – Software Stack (必要) – CRC (非必要) – Work-Breakdown-Structure (必要) – UML Object diagram (必要)
- 31. Software Stack (必要) ?定義有哪些元件 ?元件之間概念上的分層 可以後做的元件 需要比較多的測試 基本 須要先做的元件 只需要基本測試
- 32. CRC - Class-Responsibility Card (非必要) ? 目的 – 確保生成關係的可行性 ? 買空白名片卡，正面寫上物件名稱，背面寫上物件的用途 ? 不同元件的設計者，持有不同的CRC卡 ? 找一天大家一起打個牌 ? 玩法 1. 從main開始，main有用到的物件就疊在main上面 2. 如果物件A用到物件B，就將B放到A上面，直到所有牌都放完 3. 如果牌放完，而沒有缺牌，則確保架構是 Acyclic的 main Qt math pthread
- 33. Work-Breakdown Structure (必要) ? 顧名思義，將工作不斷分割，依相依性排好 ? 在規劃初期，通常只會分割到第二階 ? 實作階段，會分割到第三階，但是不是必要 ? 不在software stack上的工作，記得也要列進來
- 34. Example Level 2 dependency graph Level 3 dependency graph
- 35. 軟體開發的過程 ? 挑對手 – 在專案開始之前 – 組織行為 – 專案時間表 – 人力配置 ? 初手 – 規格與設計 – 組織與工作規劃 – 需求分析 – 架構設計 ? 中盤策略 – 撰碼與測試 – Dependency Checking – Revision control – Unit-test 的策略 ? 末盤策略 – 交貨拿錢 – Software versioning – Release engineering
- 36. 必然會遇到的問題 ?只要程式有人用 – 你就會繼續開發，讓他更好用 – 客戶或許會更新程式，或許不會 ?客戶會面臨 – 版本太新 – 版本太舊
- 37. Too Old Problem ? Host – 提供函式庫的專案 ? Dependant – 使用函式庫的程式 ? Too Old Problem – Host提供的函式庫版本太舊 需要 version 3 Host Dependant Version 2
- 38. Too New Problem ?Host所提供的函式庫太新 需要 version 3 Host Dependant V3 Host Host Host V4 V5 V6 改成 version 6，可能嗎?
- 39. 解決方案 ? 確認問題 – 利用Dependency Checker(如 ./configure script)，在 編譯之前檢查版本，以確保版本吻合 ? 解決問題 – 利用 Source Code Manager (如 SVN, CVS, Perforce)，返回到適合的版本
- 40. Dependency Checking ? 最常見 dependency checker 為 ./configure script ? Dependency checker 產生器有 Open Source 的 – Autoconf – Cmake ? Dependency checker 會 Top-down 的檢查函式庫 版本以及系統環境 程式或 Is v2? 函式庫 Is v6? Is v3? stdlib Qt math
- 41. Global Version ? 解決太舊的問題 ? 將所有的project設定一個版次號碼 ? 規定所有的 dependant的版次必須要小於等於host的版次 ? 最上層的dependant為global version Global version Main V2 Qt Math V5 V3 Stdlib V6 Pthread V7
- 42. Local Version ? 解決太新的問題 ? 這是從尐數客戶擴張到多數客戶的關鍵 開分支 (branch) 需要 version 3 Host Host Host Dependant V3 V3-1 V3-2 合併 (merge) 版次跳躍 Host Host Host V4 V5 V6
- 43. Version Threads 2.3-1 2.3-2 Local Versions 2.3 2.4-1 2.4 2.5 2.6-1 2.6 2.7 Global Versions
- 44. 軟體開發的過程 ? 挑對手 – 在專案開始之前 – 組織行為 – 專案時間表 – 人力配置 ? 初手 – 規格與設計 – 組織與工作規劃 – 需求分析 – 架構設計 ? 中盤策略 – 撰碼與測試 – Dependency Checking – Revision control – Unit-test 的策略 ? 末盤策略 – 交貨拿錢 – Software versioning – Release engineering
- 45. Software Versioning ?功用 – 對外做為看板，告知客戶目前專案的stage of life cycle – 對內做為進度管理，得知目前release status ? Point release ? Major release
- 46. Stage of Life Cycle 2 In House Beta 5 Customer testing GA 1 Alpha Success in Market 4 Internal testing RTM 0 Pre-alpha Release to Market 3 developing RC Release Candidate In Market
- 47. Release Status ? Point release – 為了bug-fix經常且快速的release ? Major release – 為了new feature告知客戶應做更新 2.6 2.6.1 2.6.1 2.7 2.6.1 major 2.8 2.6.1 2.6.1 2.9 point
- 48. 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
- 49. 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
- 50. Linux kernel version threads 2.6.11.1 2.6.11.2 stable 2.6.11 2.6.12.1 2.6.12 2.6.13 2.6.14.1 2.6.14 2.6.15 MM Mainline
- 51. Proposed Release Engineering 3.1.1 3.1.2 stable 3.1 3.2.1 3.2 3.3 3.4.1 3.4 3.5 Release Stable Developing
- 52. 軟體開發的過程 ? 挑對手 – 在專案開始之前 – 組織行為 – 專案時間表 – 人力配置 ? 初手 – 規格與設計 – 組織與工作規劃 – 需求分析 – 架構設計 ? 中盤策略 – 撰碼與測試 – Dependency Checking – Revision control – Unit-test 的策略 ? 末盤策略 – 交貨拿錢 – Software versioning – Release engineering