所有網頁 圖片 影片 地圖 新聞 網誌搜尋 Gmail 更多 »
最近造訪的群組 | 說明 | 登入
Google 網上論壇首頁
CMU MSE Studio Project 總結 (2)
目前本群組有太多主題設為優先顯示。要優先顯示這個主題,請將其他主題的這個選項取消。
在處理您的要求時發生錯誤。請再試一次。
標幟
  4 個訊息 - 全部摺疊  -  將全文翻譯為 已翻譯 (查看所有原文)
您要留言的群組是 Usenet 群組。在此群組留言,網際網路上的任何使用者將可以看到您的電郵地址。
您的回覆郵件尚未寄出。
您已成功留言
 
寄件人:
收件人:
副本:
後續追蹤對象:
新增副本 | 新增後續追蹤對象 | 編輯主旨
主旨:
驗證:
為了確認,請輸入您在以下圖片中看到的字元,或輸入您按下存取圖示時所聽到的號碼。 注意聽並輸入您聽到的號碼
 
Mac-Mangobear  
檢視個人資料  
 更多選項 2008年8月25日, 上午11時05分
寄件人: Mac-Mangobear <LiangYun.W...@gmail.com>
日期: Sun, 24 Aug 2008 20:05:56 -0700 (PDT)
當地時間: 2008年8月25日(星期一) 上午11時05分
主旨: CMU MSE Studio Project 總結 (2)
春天的工作包括了繼續敲定需求細節,以及決定軟體架構。我們利用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,可能程式裡還有(估計)一個錯誤。如果我們的品質目標可以容忍這一個(可能的)錯誤,目前的資源分配
就是合理的。

建構,並且維護這樣的模型,應該是相當複雜的,也很難準確(我不曉得把或然率加進來會不會有幫助,但是可能會先嚇跑一堆人),但是至少提供了一個連結,
也反映出各種品質管制手段的效率。或許有人會覺得這樣管理實在是太可怕了,但是如果公司裡有品質管制部門,這些工作正是工業工程的看家本領。


    回覆作者    轉寄  
您必須先登入才能張貼訊息。
若要張貼訊息,您必須先加入此群組
請在留言之前更新您訂閱設定網頁上的暱稱。
您沒有留言所需的權限。
Philosopher  
檢視個人資料  
 更多選項 2008年8月30日, 上午10時01分
寄件人: Philosopher <murphyc...@gmail.com>
日期: Fri, 29 Aug 2008 19:01:00 -0700 (PDT)
主旨: Re: CMU MSE Studio Project 總結 (2)
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?
我也一直在嘗試建構出一個template,使得可以利用過去的資料,預測新的project要花多久、多少resource進行。

> 關於品質計畫,因為我受到Dr.Paulk課堂,以及Team Software Process書的影響,做了一個自己覺得還不錯的報告,同學們也都
> 覺得很有意思,只是沒辦法在我們的studio project上實行,這也是可惜的地方。

也想瞧瞧你這份報告。 :)

Team Software Process是你們的text book嗎?需要先做到Personal Software Process嗎?還是可
以直接跳到Team Software Process?


    回覆作者    轉寄  
您必須先登入才能張貼訊息。
若要張貼訊息,您必須先加入此群組
請在留言之前更新您訂閱設定網頁上的暱稱。
您沒有留言所需的權限。
Mac-Mangobear  
檢視個人資料  
 更多選項 2008年8月31日, 上午3時34分
寄件人: Mac-Mangobear <LiangYun.W...@gmail.com>
日期: Sat, 30 Aug 2008 12:34:29 -0700 (PDT)
當地時間: 2008年8月31日(星期日) 上午3時34分
主旨: Re: CMU MSE Studio Project 總結 (2)
先說 TSP 吧,不是我們的 text book,是我在 seminar for software process 的期末報告用的書。
TSP 是以 PSP 為基礎的,但是先看 TSP 或許可以了解 PSP 為什麼要這麼追求數字。

    回覆作者    轉寄  
您必須先登入才能張貼訊息。
若要張貼訊息,您必須先加入此群組
請在留言之前更新您訂閱設定網頁上的暱稱。
您沒有留言所需的權限。
Mac  
檢視個人資料  
 更多選項 2008年9月3日, 上午10時27分
寄件人: Mac <LiangYun.W...@gmail.com>
日期: Tue, 2 Sep 2008 19:27:27 -0700 (PDT)
當地時間: 2008年9月3日(星期三) 上午10時27分
主旨: Re: CMU MSE Studio Project 總結 (2)
學長留下來的時間分配表,跟我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:


    回覆作者    轉寄  
您必須先登入才能張貼訊息。
若要張貼訊息,您必須先加入此群組
請在留言之前更新您訂閱設定網頁上的暱稱。
您沒有留言所需的權限。
無其他留言
« 返回討論主題 « 較新的主題     較舊的主題 »

建立群組 - Google 網上論壇 - Google 首頁 - 服務條款 - 隱私權政策
©2009 Google