CMU MSE Studio Project 總結 (2)
10 views
Skip to first unread message
Mac-Mangobear
Aug 24, 2008, 11:05:56 PM8/24/08
to CSZone 程式設計樂園
春天的工作包括了繼續敲定需求細節，以及決定軟體架構。我們利用architecture-centered process，由核心需求入手，建立最
簡單的架構，並且藉由幾次paper prototype，與客戶逐步討論需求的細節。由於客戶的要求，而且我們team上剛好有一位之前在IBM
Rational做過事情，對於Eclipse平台熟悉，另一位在IBM做過事情，對Java EE平台熟悉，所以我們選擇以這兩者為基礎。在學期中的
時候，我們已經大概擬定軟體的架構，但是仍有很多技術（特別是Eclipse Modeling Framework、Graphical
Editing Framework，與Graphical Modeling Framework）是我們不熟悉的，所以需要進行實驗。經過幾次不同
的實驗，我們對於架構有一定的信心，對困難度比較有概念，才開始針對各個功能需要的時間預估。套用學長遺留下來的時間分配表，估計的結果是無法在暑假內
完成，只好與客戶商量砍掉部分的功能。我在這個學期的角色是chief architect，重點利用基礎架構與客戶溝通，緊盯Software
Architecture Document的進度。
關於品質計畫，因為我受到Dr.Paulk課堂，以及Team Software Process書的影響，做了一個自己覺得還不錯的報告，同學們也都
覺得很有意思，只是沒辦法在我們的studio project上實行，這也是可惜的地方。
大部分其他組別的品質計畫書，都會說：我們的目標是移交出去的產品，每一千行程式碼有五個錯誤以下；或者說我們的目標是移交出去的產品，沒有任何嚴重等
級的錯誤。接下來就跳到我們打算花多少時間做code review，花多少時間做integration testing之類的。
我的想法是：目標與作法之間，缺乏連結，所以這樣的計畫沒有邏輯性。連結是甚麼呢？就是defect injection/removal
model。我們如果知道軟體開發過程中每道工序會如何添加或移除錯誤，就可以依據這個model來規劃流程與投入的資源，以期達到設定的品質目標。
比方說，我們根據經驗，發現軟體工程師寫程式每小時會加入1個錯誤，但是code review每小時大概可以抓掉4個錯誤，我們就可以知道大概每五小
時的工作量，搭配一小時的code review，可能程式裡還有（估計）一個錯誤。如果我們的品質目標可以容忍這一個（可能的）錯誤，目前的資源分配
就是合理的。
建構，並且維護這樣的模型，應該是相當複雜的，也很難準確（我不曉得把或然率加進來會不會有幫助，但是可能會先嚇跑一堆人），但是至少提供了一個連結，
也反映出各種品質管制手段的效率。或許有人會覺得這樣管理實在是太可怕了，但是如果公司裡有品質管制部門，這些工作正是工業工程的看家本領。
簡單的架構，並且藉由幾次paper prototype，與客戶逐步討論需求的細節。由於客戶的要求，而且我們team上剛好有一位之前在IBM
Rational做過事情，對於Eclipse平台熟悉，另一位在IBM做過事情，對Java EE平台熟悉，所以我們選擇以這兩者為基礎。在學期中的
時候，我們已經大概擬定軟體的架構，但是仍有很多技術（特別是Eclipse Modeling Framework、Graphical
Editing Framework，與Graphical Modeling Framework）是我們不熟悉的，所以需要進行實驗。經過幾次不同
的實驗，我們對於架構有一定的信心，對困難度比較有概念，才開始針對各個功能需要的時間預估。套用學長遺留下來的時間分配表，估計的結果是無法在暑假內
完成，只好與客戶商量砍掉部分的功能。我在這個學期的角色是chief architect，重點利用基礎架構與客戶溝通，緊盯Software
Architecture Document的進度。
關於品質計畫，因為我受到Dr.Paulk課堂，以及Team Software Process書的影響，做了一個自己覺得還不錯的報告，同學們也都
覺得很有意思，只是沒辦法在我們的studio project上實行，這也是可惜的地方。
大部分其他組別的品質計畫書，都會說：我們的目標是移交出去的產品，每一千行程式碼有五個錯誤以下；或者說我們的目標是移交出去的產品，沒有任何嚴重等
級的錯誤。接下來就跳到我們打算花多少時間做code review，花多少時間做integration testing之類的。
我的想法是：目標與作法之間，缺乏連結，所以這樣的計畫沒有邏輯性。連結是甚麼呢？就是defect injection/removal
model。我們如果知道軟體開發過程中每道工序會如何添加或移除錯誤，就可以依據這個model來規劃流程與投入的資源，以期達到設定的品質目標。
比方說，我們根據經驗，發現軟體工程師寫程式每小時會加入1個錯誤，但是code review每小時大概可以抓掉4個錯誤，我們就可以知道大概每五小
時的工作量，搭配一小時的code review，可能程式裡還有（估計）一個錯誤。如果我們的品質目標可以容忍這一個（可能的）錯誤，目前的資源分配
就是合理的。
建構，並且維護這樣的模型，應該是相當複雜的，也很難準確（我不曉得把或然率加進來會不會有幫助，但是可能會先嚇跑一堆人），但是至少提供了一個連結，
也反映出各種品質管制手段的效率。或許有人會覺得這樣管理實在是太可怕了，但是如果公司裡有品質管制部門，這些工作正是工業工程的看家本領。
Philosopher
Aug 29, 2008, 10:01:00 PM8/29/08
to CSZone 程式設計樂園
On 8月25日, 上午11時05分, Mac-Mangobear <LiangYun.W...@gmail.com> wrote:
> Editing Framework，與Graphical Modeling Framework）是我們不熟悉的，所以需要進行實驗。經過幾次不同
> 的實驗，我們對於架構有一定的信心，對困難度比較有概念，才開始針對各個功能需要的時間預估。套用學長遺留下來的時間分配表，估計的結果是無法在暑假內
> 完成，只好與客戶商量砍掉部分的功能。我在這個學期的角色是chief architect，重點利用基礎架構與客戶溝通，緊盯Software
> Architecture Document的進度。
不曉得「學長遺留下來的時間分配表」精細得什麼樣的程度？可以參考一下嗎？e.g. share 在Google Docs？
> Editing Framework，與Graphical Modeling Framework）是我們不熟悉的，所以需要進行實驗。經過幾次不同
> 的實驗，我們對於架構有一定的信心，對困難度比較有概念，才開始針對各個功能需要的時間預估。套用學長遺留下來的時間分配表，估計的結果是無法在暑假內
> 完成，只好與客戶商量砍掉部分的功能。我在這個學期的角色是chief architect，重點利用基礎架構與客戶溝通，緊盯Software
> Architecture Document的進度。
我也一直在嘗試建構出一個template，使得可以利用過去的資料，預測新的project要花多久、多少resource進行。
> 關於品質計畫，因為我受到Dr.Paulk課堂，以及Team Software Process書的影響，做了一個自己覺得還不錯的報告，同學們也都
> 覺得很有意思，只是沒辦法在我們的studio project上實行，這也是可惜的地方。
Team Software Process是你們的text book嗎？需要先做到Personal Software Process嗎？還是可
以直接跳到Team Software Process？
Mac-Mangobear
Aug 30, 2008, 3:34:29 PM8/30/08
to CSZone 程式設計樂園
先說 TSP 吧，不是我們的 text book，是我在 seminar for software process 的期末報告用的書。
TSP 是以 PSP 為基礎的，但是先看 TSP 或許可以了解 PSP 為什麼要這麼追求數字。
TSP 是以 PSP 為基礎的，但是先看 TSP 或許可以了解 PSP 為什麼要這麼追求數字。
Mac
Sep 2, 2008, 10:27:27 PM9/2/08
to CSZone 程式設計樂園
學長留下來的時間分配表，跟我upload 上去的 EOSP 投影片裡的類似囉（在另外一篇）
至於 QA 計畫的投影片，我也放上 google doc 了
http://docs.google.com/Presentation?id=dcm8cm56_177g5mgzbcc
我覺得比較有趣的只有 slide 9 啦，供你參考囉～
很糟的是因為技術面的問題實在太多了，我們很早就放棄了 QA plan 中，對於 latent defect 的追蹤，不過 daily
smoke test 有在做
mac
On 8月29日, 下午10時01分, Philosopher <murphyc...@gmail.com> wrote:
> On 8月25日, 上午11時05分, Mac-Mangobear <LiangYun.W...@gmail.com> wrote:
> 不曉得「學長遺留下來的時間分配表」精細得什麼樣的程度？可以參考一下嗎？e.g. share 在Google Docs？
>
至於 QA 計畫的投影片，我也放上 google doc 了
http://docs.google.com/Presentation?id=dcm8cm56_177g5mgzbcc
我覺得比較有趣的只有 slide 9 啦，供你參考囉～
很糟的是因為技術面的問題實在太多了，我們很早就放棄了 QA plan 中，對於 latent defect 的追蹤，不過 daily
smoke test 有在做
mac
On 8月29日, 下午10時01分, Philosopher <murphyc...@gmail.com> wrote:
> On 8月25日, 上午11時05分, Mac-Mangobear <LiangYun.W...@gmail.com> wrote:
> 不曉得「學長遺留下來的時間分配表」精細得什麼樣的程度？可以參考一下嗎？e.g. share 在Google Docs？
>
Reply all
Reply to author
Forward
0 new messages