2008/08/28

專題工作進度

距離上一篇進度記錄已經有半年之久,因為中間花了大半時間在研究 SOA 和轉 IDE。目前已經把最簡單的產能計算解決了,開始做排程管理的系統。小可負責 GUI、廖神負責 service 端的資料處理,而我則盡可能生出可用的排程測試資料。

這樣的工作分配有好有壞,因為現在大家除了自己的工作以外,就不會其他的東西了.... @@"



產能計算介面



排程管理介面


專題最難的地方,應該是屬於排程模擬。要讀取生產工單資料,並對照新的排程是否有不正確的地方,如:時間衝突、機器數量不足、產品出料量不足等等。

我到現在還是想不出來,排程的時間記錄到底要怎麼儲存,大二的資料結構都沒有碰過類似的東西。原本想用類似 Flash 的時間軸實作,不過有人說記憶體會掰掰......。模擬最常用的應該是搜尋在某個時間點,有哪些機器在運轉,時間軸沒辦法用就麻煩了。

12 則留言:

  1. 借問一下
    介面是用哪個軟體拉的@@
    最近我也要開始學界面Orz...

    回覆刪除
  2. 我們用的是 NetBeans,不過 NetBeans 的 Free Layout 物件一多很容易亂掉,建議先分成數個 Panel 在放物件進去

    回覆刪除
  3. 敏捷開發建議同一份code至少要有二個人寫
    好處是code會比較高效,而且好維護
    加上如果有人中途閃人也比較不會沒人接

    不過沒什麼人鳥我就是了XD

    回覆刪除
  4. 我覺得你現在最大的問題不是別人聽不懂你說什麼,而是你根本不知道別人的需求是什麼

    回覆刪除
  5. 噗哈哈,又被婊了XD

    回覆刪除
  6. 我也知道敏捷是開發啊,二個人一起 coding 是完全不可能的事

    回覆刪除
  7. 提供一下自己的經驗

    就我目前的專題是四個人一組,共同開發一個手機應用程式,對我而言,四個人是比較小的團隊,大家共同使用同一個專案配合svn,問題會解決不少,雖然每個人負責一部分,不過每個人都看的到code,有時間我會學習一下別人怎麼寫程式。

    敏捷軟體開發有提到pair programming,並且提到經常的交換夥伴。我當初有想過要不要用在我們組身上,後來發現,不要比較好,因為四個人已經夠少了,每個人各司其職,訂好溝通的方法,反正看的到對方的code,所以要調整或者是跟對方建議其實都沒有這麼的困難。

    我對於團隊的想法是,人可以學習去使用某些工具讓自己的工作更便利(在這一次之前,我從來沒有用過svn),但是我也不會過度的要求大家要會很多東西(到現在我還是不會用patterns解決問題,頂多用到Refactoring的基本而己),達成一個平衡,讓團隊讓好運作很重要。

    哈,不過這只是我的個人經驗,應該會有更好的方法,如果有錯誤,歡迎指正,因為我蠻想學習有關於團隊開發程式的種種。

    回覆刪除
  8. 我自己是覺得這種時候跟組員之間的配合度(我不知道要怎麼形容)有關,
    svn在某個八人作業時我們也有用到,但是實際上只有二個人在用,
    至於其他的軟工模型根本是嘴砲,因為連整份code是不是所有人都看得懂都是個問題。

    pair programming不是不可能,但是除了人力外,二個人如果有一方放爛就完全沒有意義。
    但是真的會有趣很多....XD

    回覆刪除
  9. 嗯嗯,我最近正要初學XD
    謝啦

    回覆刪除
  10. CA 你說的沒錯,很多東西一定要大家配合,當初軟工專題要用到 wiki 管理文件,一樣是一堆人沒做。

    但是我們現在專題重點是 SOA,暑假才知道要用 NetBeans,二個月要學會用 IDE 和一堆 API,而且要在開學前完成所有的實作,我們才不管什麼開發方法或是 Coding Convention,只要我們自己知道自己在做什麼,而且每個人寫的東西都可以互相溝通,最後能在大四下結束前發表就好。

    回覆刪除
  11. 我得說,我現在遇到很好的組員,組員配合度非常的高,我反而是常常被催寫程式碼的那一個XD

    軟工的模型,我從來沒用過,大部分考完我就忘了,不過我傾向邊開發邊決定要用怎麼樣的方式進行,哈。

    pair programming,有興趣的話,我想找個人試試,不過我目前東不成西不就,恐怕也寫不出什麼好程式了(笑)

    回覆刪除
  12. pair programming 跟 敏捷軟體開發 我都有聽過,也都知道,不過要套用到我們的專題身上,實在是不怎麼可能。
    但我們的專題套用到遞減式開發,好像還滿適合的XD

    回覆刪除