SlideShare a Scribd company logo
1 of 52
Download to read offline
Software Engineering
A Practical Approach
      Luba Tang
       2010/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
2012/05/23 AU Talk - 讓事情發生
我的軟體開發流程

 對我而言是真實的
  我不研究軟體工程
  自己用過也教過,經過實驗與取捨
 混合多種性質
 不是最快的
  曾有學弟改變流程,在更短時間內做完更多的事
軟體開發的過程

 挑對手 – 在專案開始之前
  – 組織行為
  – 專案時間表
  – 人力配置
 初手 – 規格與設計
  – 組織與工作規劃
  – 需求分析
  – 架構設計
 中盤策略 – 撰碼與測試
  – Unit-test 的策略
  – Dependency Checking
  – Revision control
 末盤策略 – 交貨拿錢
  – Software versioning
  – Release engineering
軟體開發機構的成長過程

   渾然不知 (Oblivious)
     –   我們都不知道我們正尋着一個過程做事    高                        P5
   變化無常 (Variable)                               P4
     –   我們全憑當時的感覺做事
     –   超級程式設計師的形象

   照章行事 (Routine)            客
     –   我們凡事皆依造工作慣例,除非我們陷入   戶              P3
         恐慌
     –   超級技術負責人的形象           的
                              要
   把穩方向 (Steering)           求
     –   我們會選擇結果較好的工作慣例來行事              P2
     –   有能力的經理

   防範未然 (Anticipating)
     –   我們會參造過往的經驗制定出一套工作慣
         例                             P1
   全面關照 (Congruent)
     –   人人時時刻刻都會參與改善工作       低   P0

                                  低                     高
                                              問題的要求
模式一:變化無常型

 仰賴超級程式設計師
  – 不同程式設計師的能力可達20:1 甚至更高的差別
  – 問題的複雜度往往呈現指數成長,就專案成功的機率而言,超級程式
    設計師並非決定性的關鍵
 模式
  – 『告訴我們你想要的是什麼(而且不要改變你的心意)』
  – 『提供我們一些資源(而且只要開口,你就會不停地提供)』
  – 『不要再來煩我們(消除所有隨機事件發生的可能性)』

                需求



       資源                    軟體
              軟體開發系統
  隨機事件                     其它輸出
模式二:造章行事型

 仰賴超級技術負責人
  – 問題複雜度過高,承認超級程式設計師並非決定性的關鍵
  – 控制者還無法直接取得開發系統內部狀態
 模式
  – 『我將會使那些程式設計師,管他張三李四,皆能善盡責任』
  – 『我會僱用交大的學生,訓練他們變聰明』
  – 『我會開除清大的學生,讓其他人工作更賣力』


                   控制者
       改變
              需求    (改變)
   資源                       軟體
              軟體開發系統
  隨機事件                     其它輸出
模式三:把穩方向型


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

              控制者
       改變
             需求
     資源                軟體
             軟體開發系統
  隨機事件                其它輸出
挑選適合的開發模式


 模式沒有對與錯         高                        P5
 – 就相同的問題而言,上述模
                                      P4
   式的成功機率其實大同小異
 針對客戶與問題的要求來     客
  選擇模式,而非由資源來     戶              P3

  選擇模式            的
                  要
 不計資源的話,永遠可以     求
                            P2
  以集成法來進行

                           P1

                  低   P0

                      低                     高
                                  問題的要求
專案開發的時間表 (1/2)

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

 個別時間

需求           設計   撰碼         測試



        3/5~2/3   1/10~1/6        1/3~1/4   預留
        的時間       的時間             的時間       1/10的時間
        6個月       1個月             2.5個月     1個月
專案開發的時間表 (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週
專案開發的人力需求

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

 個別人力
建立開發環境
    閒置人力?
讀相關規格
                     撰碼       測試

         設計                            維護
需求



通常1~3人      依子專案個數        依獨立元件個數      和設計人數相仿
            約莫3~5人        從 5~30人都可能
軟體開發的過程

 挑對手 – 在專案開始之前
  – 組織行為
  – 專案時間表
  – 人力配置
 初手 – 規格與設計
  – 組織與工作規劃
  – 需求分析
  – 架構設計
 中盤策略 – 撰碼與測試
  – Unit-test 的策略
  – Dependency Checking
  – Revision control
 末盤策略 – 交貨拿錢
  – Software versioning
  – Release engineering
初手 – 撰寫規格書

 不要產生沒必要的文件
 如果溝通會耗掉某些人大部分的時間,就必須撰寫規
  格書
 負責溝通的人,寫對應的章節

 規格書中的章節
 1.   Project Vision
 2.   Organization
 3.   Requirement
 4.   Basic Design
 5.   Milestone Design
Project Vision

 內容
 –   我們要做甚麼?
 –   為什麼要做這件事?
 –   投資報酬
 –   失敗風險
 例子
 – 將simulation instruction相關資訊放入SQL資料庫中
   ,以利下列操作
     1.    方便閱讀simulation instruction內容
     2.    自動生成simulation instruction的header與implementation
           files
     3.    方便修改、新增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)
                         單一進入點


   有相依性         程式或
                函式庫



                 Qt        math

    stdlib
                             不能遞迴相依
               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的




                             main
                        Qt      math
              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提供的函式庫版本太舊


                     需要 version 3     Host
         Dependant
                                    Version 2
Too New Problem


Host所提供的函式庫太新

需要 version 3
                   Host
Dependant
                    V3


                      Host   Host   Host
                       V4     V5     V6

       改成 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 的檢查函式庫
  版本以及系統環境

                              程式或
            Is v2?            函式庫   Is v6?

                     Is v3?

        stdlib                Qt       math
Global Version

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


      Global version     Main
                          V2


                         Qt      Math
                         V5       V3
       Stdlib
        V6
                       Pthread
                         V7
Local Version


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

                開分支 (branch)
需要 version 3
                   Host        Host     Host
Dependant
                    V3         V3-1     V3-2
                                               合併 (merge)


        版次跳躍
                       Host      Host    Host
                        V4        V5      V6
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
軟體開發的過程

 挑對手 – 在專案開始之前
  – 組織行為
  – 專案時間表
  – 人力配置
 初手 – 規格與設計
  – 組織與工作規劃
  – 需求分析
  – 架構設計
 中盤策略 – 撰碼與測試
  – 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




                   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
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
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.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
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
軟體開發的過程

 挑對手 – 在專案開始之前
  – 組織行為
  – 專案時間表
  – 人力配置
 初手 – 規格與設計
  – 組織與工作規劃
  – 需求分析
  – 架構設計
 中盤策略 – 撰碼與測試
  – Dependency Checking
  – Revision control
  – Unit-test 的策略
 末盤策略 – 交貨拿錢
  – Software versioning
  – Release engineering

More Related Content

What's hot

软件工程 第七章
软件工程 第七章软件工程 第七章
软件工程 第七章浒 刘
 
七天基于风险测试—Chinatest
七天基于风险测试—Chinatest七天基于风险测试—Chinatest
七天基于风险测试—Chinatestdrewz lin
 
1 spmc introduction
1 spmc introduction1 spmc introduction
1 spmc introductionhuanglab
 
Zhongxing practice-suchunshan-qcon
Zhongxing practice-suchunshan-qconZhongxing practice-suchunshan-qcon
Zhongxing practice-suchunshan-qconYiwei Ma
 
软件工程 第一章
软件工程 第一章软件工程 第一章
软件工程 第一章浒 刘
 
高绩效项目团队漫谈
高绩效项目团队漫谈高绩效项目团队漫谈
高绩效项目团队漫谈Lu Ming
 
SRE CH33/CH34 - Lessons Learned from Other Industries/Conclusion
SRE CH33/CH34 - Lessons Learned from Other Industries/ConclusionSRE CH33/CH34 - Lessons Learned from Other Industries/Conclusion
SRE CH33/CH34 - Lessons Learned from Other Industries/ConclusionRick Hwang
 
2.ie培訓教材
2.ie培訓教材2.ie培訓教材
2.ie培訓教材營松 林
 
從緊急事件 談 SRE 應變能力的培養 - DevOpsDays Taipei 2018
從緊急事件  談 SRE 應變能力的培養 - DevOpsDays Taipei 2018從緊急事件  談 SRE 應變能力的培養 - DevOpsDays Taipei 2018
從緊急事件 談 SRE 應變能力的培養 - DevOpsDays Taipei 2018Rick Hwang
 

What's hot (20)

Ch09
Ch09Ch09
Ch09
 
Ch13
Ch13Ch13
Ch13
 
Ch01
Ch01Ch01
Ch01
 
Ch03
Ch03Ch03
Ch03
 
Ch18
Ch18Ch18
Ch18
 
Ch15
Ch15Ch15
Ch15
 
Ch04
Ch04Ch04
Ch04
 
Ch14
Ch14Ch14
Ch14
 
Ch08
Ch08Ch08
Ch08
 
Ch11
Ch11Ch11
Ch11
 
软件工程 第七章
软件工程 第七章软件工程 第七章
软件工程 第七章
 
七天基于风险测试—Chinatest
七天基于风险测试—Chinatest七天基于风险测试—Chinatest
七天基于风险测试—Chinatest
 
1 spmc introduction
1 spmc introduction1 spmc introduction
1 spmc introduction
 
Ch02
Ch02Ch02
Ch02
 
Zhongxing practice-suchunshan-qcon
Zhongxing practice-suchunshan-qconZhongxing practice-suchunshan-qcon
Zhongxing practice-suchunshan-qcon
 
软件工程 第一章
软件工程 第一章软件工程 第一章
软件工程 第一章
 
高绩效项目团队漫谈
高绩效项目团队漫谈高绩效项目团队漫谈
高绩效项目团队漫谈
 
SRE CH33/CH34 - Lessons Learned from Other Industries/Conclusion
SRE CH33/CH34 - Lessons Learned from Other Industries/ConclusionSRE CH33/CH34 - Lessons Learned from Other Industries/Conclusion
SRE CH33/CH34 - Lessons Learned from Other Industries/Conclusion
 
2.ie培訓教材
2.ie培訓教材2.ie培訓教材
2.ie培訓教材
 
從緊急事件 談 SRE 應變能力的培養 - DevOpsDays Taipei 2018
從緊急事件  談 SRE 應變能力的培養 - DevOpsDays Taipei 2018從緊急事件  談 SRE 應變能力的培養 - DevOpsDays Taipei 2018
從緊急事件 談 SRE 應變能力的培養 - DevOpsDays Taipei 2018
 

Viewers also liked

AAME ARM Techcon2013 005v02 System Startup
AAME ARM Techcon2013 005v02 System StartupAAME ARM Techcon2013 005v02 System Startup
AAME ARM Techcon2013 005v02 System StartupAnh Dung NGUYEN
 
AAME ARM Techcon2013 004v02 Debug and Optimization
AAME ARM Techcon2013 004v02 Debug and OptimizationAAME ARM Techcon2013 004v02 Debug and Optimization
AAME ARM Techcon2013 004v02 Debug and OptimizationAnh Dung NGUYEN
 
AAME ARM Techcon2013 003v02 Software Development
AAME ARM Techcon2013 003v02  Software DevelopmentAAME ARM Techcon2013 003v02  Software Development
AAME ARM Techcon2013 003v02 Software DevelopmentAnh Dung NGUYEN
 
AAME ARM Techcon2013 006v02 Implementation Diversity
AAME ARM Techcon2013 006v02 Implementation DiversityAAME ARM Techcon2013 006v02 Implementation Diversity
AAME ARM Techcon2013 006v02 Implementation DiversityAnh Dung NGUYEN
 
ARM AAE - Intrustion Sets
ARM AAE - Intrustion SetsARM AAE - Intrustion Sets
ARM AAE - Intrustion SetsAnh Dung NGUYEN
 
ARM AAE - Developing Code for ARM
ARM AAE - Developing Code for ARMARM AAE - Developing Code for ARM
ARM AAE - Developing Code for ARMAnh Dung NGUYEN
 
Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.
Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.
Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.Atollic
 
ARM AAE - Memory Systems
ARM AAE - Memory SystemsARM AAE - Memory Systems
ARM AAE - Memory SystemsAnh Dung NGUYEN
 
Q4.11: ARM Architecture
Q4.11: ARM ArchitectureQ4.11: ARM Architecture
Q4.11: ARM ArchitectureLinaro
 

Viewers also liked (14)

AAME ARM Techcon2013 005v02 System Startup
AAME ARM Techcon2013 005v02 System StartupAAME ARM Techcon2013 005v02 System Startup
AAME ARM Techcon2013 005v02 System Startup
 
AAME ARM Techcon2013 004v02 Debug and Optimization
AAME ARM Techcon2013 004v02 Debug and OptimizationAAME ARM Techcon2013 004v02 Debug and Optimization
AAME ARM Techcon2013 004v02 Debug and Optimization
 
ARM AAE - Introduction
ARM AAE - IntroductionARM AAE - Introduction
ARM AAE - Introduction
 
AAME ARM Techcon2013 003v02 Software Development
AAME ARM Techcon2013 003v02  Software DevelopmentAAME ARM Techcon2013 003v02  Software Development
AAME ARM Techcon2013 003v02 Software Development
 
ARM AAE - System Issues
ARM AAE - System IssuesARM AAE - System Issues
ARM AAE - System Issues
 
AAME ARM Techcon2013 006v02 Implementation Diversity
AAME ARM Techcon2013 006v02 Implementation DiversityAAME ARM Techcon2013 006v02 Implementation Diversity
AAME ARM Techcon2013 006v02 Implementation Diversity
 
ARM AAE - Intrustion Sets
ARM AAE - Intrustion SetsARM AAE - Intrustion Sets
ARM AAE - Intrustion Sets
 
Tokens_C
Tokens_CTokens_C
Tokens_C
 
ARM AAE - Developing Code for ARM
ARM AAE - Developing Code for ARMARM AAE - Developing Code for ARM
ARM AAE - Developing Code for ARM
 
C AND DATASTRUCTURES PREPARED BY M V B REDDY
C AND DATASTRUCTURES PREPARED BY M V B REDDYC AND DATASTRUCTURES PREPARED BY M V B REDDY
C AND DATASTRUCTURES PREPARED BY M V B REDDY
 
Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.
Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.
Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.
 
ARM AAE - Architecture
ARM AAE - ArchitectureARM AAE - Architecture
ARM AAE - Architecture
 
ARM AAE - Memory Systems
ARM AAE - Memory SystemsARM AAE - Memory Systems
ARM AAE - Memory Systems
 
Q4.11: ARM Architecture
Q4.11: ARM ArchitectureQ4.11: ARM Architecture
Q4.11: ARM Architecture
 

Similar to 2012/05/23 AU Talk - 讓事情發生

專案管理理論基礎
專案管理理論基礎專案管理理論基礎
專案管理理論基礎黑狗 大
 
ΝΕΚΡΟΦΑΝΕΙΑ ΚΑΙ ΑΠΟΤΕΦΡΩΣΗ
ΝΕΚΡΟΦΑΝΕΙΑ  ΚΑΙ  ΑΠΟΤΕΦΡΩΣΗ ΝΕΚΡΟΦΑΝΕΙΑ  ΚΑΙ  ΑΠΟΤΕΦΡΩΣΗ
ΝΕΚΡΟΦΑΝΕΙΑ ΚΑΙ ΑΠΟΤΕΦΡΩΣΗ csdtesting
 
從理想、到現實的距離,開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)
從理想、到現實的距離,開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)從理想、到現實的距離,開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)
從理想、到現實的距離,開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)Rick Hwang
 
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)LetAgileFly
 
Pair Programming (结对编程)
Pair Programming (结对编程)Pair Programming (结对编程)
Pair Programming (结对编程)Josh Chen
 
TDD (Test-driven development, 測試驅動開發) 基本教學
TDD (Test-driven development, 測試驅動開發) 基本教學TDD (Test-driven development, 測試驅動開發) 基本教學
TDD (Test-driven development, 測試驅動開發) 基本教學潘 冠辰
 
(宇宏)生產履歷 建議方案 20100901 v2
(宇宏)生產履歷 建議方案 20100901 v2(宇宏)生產履歷 建議方案 20100901 v2
(宇宏)生產履歷 建議方案 20100901 v2Sonny Chen
 
敏捷開發分享
敏捷開發分享敏捷開發分享
敏捷開發分享東城 楊
 
Scrum过程介绍
Scrum过程介绍Scrum过程介绍
Scrum过程介绍ben
 
過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱
過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱
過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱TIM WANG
 
從研發團隊管理及產品發展的角度看 DevOps
從研發團隊管理及產品發展的角度看 DevOps從研發團隊管理及產品發展的角度看 DevOps
從研發團隊管理及產品發展的角度看 DevOpsTIM WANG
 
Agile changes in liba
Agile changes in libaAgile changes in liba
Agile changes in libatopgeek
 
專案進度追蹤
專案進度追蹤專案進度追蹤
專案進度追蹤黑狗 大
 
Djt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comDjt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comdrewz lin
 
Djt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comDjt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comdrewz lin
 
软件设计原则、模式与应用
软件设计原则、模式与应用软件设计原则、模式与应用
软件设计原则、模式与应用yiditushe
 
Software Project Risk Management
Software Project Risk ManagementSoftware Project Risk Management
Software Project Risk ManagementAndy Liu
 

Similar to 2012/05/23 AU Talk - 讓事情發生 (20)

專案管理理論基礎
專案管理理論基礎專案管理理論基礎
專案管理理論基礎
 
ΝΕΚΡΟΦΑΝΕΙΑ ΚΑΙ ΑΠΟΤΕΦΡΩΣΗ
ΝΕΚΡΟΦΑΝΕΙΑ  ΚΑΙ  ΑΠΟΤΕΦΡΩΣΗ ΝΕΚΡΟΦΑΝΕΙΑ  ΚΑΙ  ΑΠΟΤΕΦΡΩΣΗ
ΝΕΚΡΟΦΑΝΕΙΑ ΚΑΙ ΑΠΟΤΕΦΡΩΣΗ
 
從理想、到現實的距離,開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)
從理想、到現實的距離,開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)從理想、到現實的距離,開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)
從理想、到現實的距離,開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)
 
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
Scrum gathering 2012 shanghai 产品管理及用户体验 分会场:敏捷的hard模式 产品经理视角(窦涵之)
 
Pair Programming (结对编程)
Pair Programming (结对编程)Pair Programming (结对编程)
Pair Programming (结对编程)
 
TDD (Test-driven development, 測試驅動開發) 基本教學
TDD (Test-driven development, 測試驅動開發) 基本教學TDD (Test-driven development, 測試驅動開發) 基本教學
TDD (Test-driven development, 測試驅動開發) 基本教學
 
(宇宏)生產履歷 建議方案 20100901 v2
(宇宏)生產履歷 建議方案 20100901 v2(宇宏)生產履歷 建議方案 20100901 v2
(宇宏)生產履歷 建議方案 20100901 v2
 
敏捷開發分享
敏捷開發分享敏捷開發分享
敏捷開發分享
 
Scrum过程介绍
Scrum过程介绍Scrum过程介绍
Scrum过程介绍
 
SCRUM
SCRUMSCRUM
SCRUM
 
软件工程2010
软件工程2010软件工程2010
软件工程2010
 
過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱
過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱
過來人經驗 - 在企業中推行 DevOps 前該具備的認知與工具箱
 
從研發團隊管理及產品發展的角度看 DevOps
從研發團隊管理及產品發展的角度看 DevOps從研發團隊管理及產品發展的角度看 DevOps
從研發團隊管理及產品發展的角度看 DevOps
 
Agile changes in liba
Agile changes in libaAgile changes in liba
Agile changes in liba
 
專案進度追蹤
專案進度追蹤專案進度追蹤
專案進度追蹤
 
Djt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comDjt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.com
 
Djt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comDjt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.com
 
20150206 aic machine learning
20150206 aic machine learning20150206 aic machine learning
20150206 aic machine learning
 
软件设计原则、模式与应用
软件设计原则、模式与应用软件设计原则、模式与应用
软件设计原则、模式与应用
 
Software Project Risk Management
Software Project Risk ManagementSoftware Project Risk Management
Software Project Risk Management
 

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為基礎,將多個 工作集中到尐數人身上
  • 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. 需求分析 使用情境設定 (必要) – 畫圖,然後說故事 使用者與事件列表(非必要) – 列出使用情境中的所有 • 主詞 => 物件 • 動詞 => 函式或關係 • 形容詞/副詞 => 參數 • 受詞 => 參數
  • 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