分、時、天

今天在研討會中聽到一個不錯的比喻。軟體工程度量在國內一直很難推動,這或許與國內對於工程量化的觀念比較不足有關係。這一點可以日常生活中的用語窺得一二,

西方人說『wait a minute』,以『分』為單位
台灣人稱火車慢了為『慢點』,以『小時』為單位
印度人則說『等天』,以『天』為單位

這讓我想起PSP (personal software process)方法要求以為單位來記錄工時,但對於我們的工程師的確是很大的壓力。以我們逢甲資訊處為例,工時的紀錄幾乎都是以小時為單位。這之間的關聯是否為巧合?有趣。

留言

  1. 採用何種時間單位,要看我們要度量什麼事務,我們常說:「等一會兒」,可以以秒、分、時甚至以天為單位,如果你是軟體工程師而想要延年益壽,千萬不要以秒、分或時為單位,以天甚至以週為單位可也,我曾在一家工程顧問公司服務多年,他們標工程是以「人時」為度量單位,所以他們很緊張。

    閒話少說,『軟體度量』(Software Metrics),對於推展軟體工業,不旦十分重要而且必要,可惜台灣的軟體工業界,似乎不怎麼在乎其重要性,因為要做軟體度量必須要蒐集軟體發展的種種數據,例如人時(或週、月、年),技術層次,軟體規模等等,而且要確定軟體種類,如Barry Boehm的COCOMO預測模式,是他蒐集六十幾種不同軟體的專案數據而成,不知台灣是否有人做類似的工作?沒有這些發展數據記錄,如何做發展預測,不能做預測,如何做管理?我曾經教過幾學期的軟體度量課程,重點放在「預測」上面,不過只是教教而已,並沒有機會實際「演練」。

    借這個意見箱,我只粗略提一提敏捷方法(如XP、Scrum等)常做的預測法,因為我覺得它有趣。敏捷方法一般並不以use cases做為顯示需求的工具,而是以user stories來表示需求,因此沒有像use cases那樣「大陣仗」,也不以完成百分幾做為進度,基本上是以story points為單位,所謂story point是說實作一story需要多少effort,有趣的是,story points的評量(scale)可以採用2的n次方,或Fibonacci Sequence,至於發展的進度是以velocity來計算,所謂velocity是一次反覆(iteration)可以完成多少story points,Story point不旦可以顯示「量」,也可以顯示軟體的複雜度。我提出這種「敏捷度量法」(可能沒有這種名詞),只覺淂它有趣而且敏捷,同時也希望能拋磚引玉,如有那位人士對此有研究,可否提供文章,讓軟工界受益。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

TCSE 2017

加油站與小鎮