顯示包含「會議」標籤的文章。顯示所有文章
顯示包含「會議」標籤的文章。顯示所有文章

2008年5月9日星期五

Final report Planning

時間表:
  1. Implementation: 13-5-2008
  2. User guide and installation guide: 15-5-2008
  3. The requirements: 17-5-2008
  4. Results and conclusions:19-5-2008
  5. Documentation for detailed design:20-5-2008
  6. Documentation for problem analysis: 23-5-2008

Final Report是重質多於重量的

Implementation: Discuss on 10-5-2008

  1. 記錄自己做過甚麼，可以參考我的工作記錄
  2. Testing
    1. Black Box testing - Requirements Verification
  3. Changes to design(Provide reason) - Requirements Verification
Results and conclusions: Discuss on 16-5-2008
  1. Summary
  2. 全方位檢討(驗證)
    1. 由original problem formulation(簡潔陳述) was correct
      1. difficulties encountered
      2. delays/changes in project schedule
    2. 到how well the solution meets the specification
      1. limitations of the proposed system
    3. subsection suggesting further developments to be undertaken
User guide and installation guide: Discuss on 12-5-2008
  1. User Guide
    1. 寫自己的function
  2. Installation guide
    1. 把Software folder複製到儲存位置(USB記憶體也可以!!)。
    2. 按JAR file。
    3. 完成。
Documentation for detailed design
  1. 考慮多個可行方案，然後選擇最好的。
  2. 要把設計全部列出，不可以因為Project沒有做到而刪去。
  3. software/hardware architectural design (system design)
    1. Software architectural design
      1. 可行方案
        1. Client-Server
        2. Database-centric architecture
        3. Structured Systems Analysis and Design Method (SSADM)
      2. 正常情況下我們的程式只會在一部電腦上使用。
      3. 員工可以上網看時間表的話程式會在多部電腦上使用(Client: Staff, Server: Software)
    2. hardware architectural design
      1. 可行方案
        1. PC
        2. Pocket PC
      2. 在普通PC上運作，沒有特別的設計
  4. data design
    1. Project資料會以Object Oriented File儲存: 檔案裡全是Objects。
  5. user interface design.
The requirements
  1. analysed the problem
    1. 找出真正要解決的問題
  2. for evidence that you have investigated(調查) commercially available solutions
    1. 參考過市面上的軟體
    2. 決定最終的解決方案
      1. Scope of the proposed system
      2. description of functions provided
      3. data processed by the system
        1. User可以輸入甚麼，例如Task的資料
      4. other non-functional requirements
        1. 免安裝的特性應在此說明。
Documentation for problem analysis
  1. approach to problem solving
  2. choice of methods
  3. tools and techniques
  4. the quality of design
    1. data model
      1. class diagram
    2. functional model
      1. use cases
    3. dynamic model
      1. state transition diagram
      2. sequence diagram
    4. data dictionary
Referencess:
  1. http://en.wikipedia.org/wiki/Software_architecture
  2. http://en.wikipedia.org/wiki/Hardware_architecture
發佈者： 於 沒有留言:
標籤：

2007年9月11日星期二

Project work 3 第05次會議

與會者：Charlie, David,啟輝

地點：柴灣IVE

日期：11/9/2007

時間：下午2時正

會議目的：使我們可以開始撰寫Project Proposal

專案團隊議程：
· 開頭的簡短介紹。
· 議程審查。
  1. 瞭解Project Proposal的內容和各部份的撰寫方法

    1. Statement of problem to be solved:

    2. Background to the problem:

    3. Outline of proposed solution:

    4. Explanation of why proposed solution is appropriate:

    5. Main stages involved in the project, with estimated time to completion of each stage:
    6. Main Deliverables:
    7. The (tentative) responsibilities of each member:
    8. Projected Resource Requirements:

· 列出本次會議的行動項目（何人、何事、何時）。

· 為下次會議訂定議程與時間。

· 對於此次會議給予評價。


你們要預備:

  1. 要做一個系統首先要對這個系統有願景，即你期望這樣神兵利器可以幫你做些甚麼，幫你解決甚麼問題。不論怎樣，這份報告就是要寫出計劃軟體的三個步驟，你可以根據你喜愛的順序來思考(即是如果原本的順序想不出甚麼來，便換個順序來想)：
    1. 現在有甚麼不妥(我全身都不舒服，醫生，有何解救呢?)
    2. 本軟體提供甚麼解決方案(這個時候，你要用我們最新研發的產品，它可以舒緩身體不適，還可延年益壽，好東西耶！)
    3. 為什麼解決方案是正確的(我們的產品使用全天然中草藥煉製而成，絕無副作用，不論是寒底還是熱底，只要一劑就見效。不用打針)
  2. 以下的資料可以幫你一把：
    姑且不論你是否有預知未來，呼風喚雨的能力。每個人在想要規劃一套軟體系統的時候，內心總會有所期待。拿到企業界來說，軟體可以幫你做的事情，不外乎下列幾項：
    •節省成本
    •縮短作業時間
    •精確地收集整理資料
    •提供情報或是對於未來提供更好的預測
    •改善溝通效率
    •增加曝光機會
    •帶來新的生意
    •被客戶或是廠商逼迫
    •老闆指名了要做

    如果你想要生一個案子出來，卻沒什麼概念時，就往上面提示的方向去想一想，把分權改成集權，把沒有用的冗員給砍掉，這就可以省錢，省錢就可以節省成本，嗯，大概就差不多可以找出一個方向了。當你有了一個想法，想要實行，這就叫做vision啦。
  3. 看看各式各樣的Project management tools有甚麼Feature(上官方網站看，或者去其他網站看看軟體評論)，可以解決甚麼問題。
發佈者： 於 沒有留言:
標籤：

2007年8月19日星期日

Project work 2B 好的方面的補充


　　之前在會議中我想不到在Project Work 2B的後期做得好的原因，今晚看完一擲千金後終於記起了，原來都是個很動人的故事來的。當時，佔該科目總分的一半的製成品已經完成了，在最後一分鐘光碟已經繳交了，但是之後發現很多功能都用不到，在這時候多美好的期待都沒有了，就像一擲千金裡由三百萬跌至只有數萬，但我們不是甚麼都沒有，還有presentation和其他文件可以追回分數，但是分數最多只有１５分(其他文件佔10分)，我還記得在演說前一晚有組員在MSN問我做project先還是做ISP(其他科目的家課)先，我回答說：「做project先。」在演說中大家都很用心的介紹自己所做過的，還有組員擔心時間不足調節速度呢！接著在寫文件中組員們都很用心的去測試製成品，那怕製成品有甚麼缺憾，還忙著為到自己所做的功能提供詳細的說明，到了最後繳交時連同Project Work 2A所寫的文件，合共超過五百頁(Project Work 2A估算佔了總數一半，有錯請提示)。回想起這段情景，就像一擲千金裡的玩家要從幾個寶箱中爭取最大銀碼，即使無法回到有數十萬的時候，相信這是團隊合作最燦爛的一刻來吧！
　　看回MSN的記錄，當時不只Project Work，還有其他科目也是忙著做的，當時其實可以放棄Project Work去做別的科目，用更多時間去爭取其他科目的分數不好麼？但是我們沒有放棄，只知道Project Work不合格的後果是不敢想像的，就是有這份堅持，這一科最後都合格，而且分數也不錯呢！
　　如果當時我在MSN回答的時候不是這樣說，是回答做ISP先的話，我想沒有人會繼續為那些少分數而努力，也沒有這個出人意表成績。跌倒了，要懂得站起來，這樣的團隊才能經歷風浪，為自己，為朋友，留下美好的回憶。
發佈者： 於 沒有留言:
標籤： ,

2007年7月26日星期四

Project Work 3的第一次會議

我們會在7月28日(星期六)舉行這個專案的第一次會議。 由於我們彼此沒有深入的認識，因此我希望可以藉今次的會議使大家有深入的認識，從而取得互相的信任、使大家有相同的目標和得到自己真正愛做的項目。
日期:7月28日(星期六)
時間:下午2時
地點:小西灣(藍彎半島)
如果你想更新時間和地點，可以和我們商議。

為了達到使大家有深入的認識的目的，在會議開始前請你們為這次會議準備好要分享的內容，詳情請看這個文件。
http://docs.google.com/Doc?id=dct4np4m_30dfff35&invite=gjfxp9g
發佈者： 於 沒有留言:
標籤：
訂閱： 文章 (Atom)