終於完結了e一份project 了

so happy!

終於完結了e一份project 了

so happy!

Final Report Oral Presentation and Demonstration

Power point出爐時間:

1. 上午3-4時
2. 早上11時

建議準備流程:

1. 做Power point
2. 製作Test data/ Test file
3. 自己試行一次，有bug的路線要修改，直到沒有問題為止。
4. Present準備，寫重點，表達方法。
5. 準備常見問題，問及時便可快速解答。
6. 如果之前的試行路線不安全，現在可以試著修改你的程式，看看可否解決難題。改壞了用Subversion還原再來。Debugging所花的時間難以估計，你有可能花了一整個晚上還是徒勞無功，因此要放到最後才做，除非你已經想到修正方法(知道要修正那裡的程式碼)吧!

Presentation流程:

和上年的Project 3A一樣，先Setup，再Present，後Demo。

1. Setup:
   1. 以一個可執行的Folder，內有jar file和程式運行時所需的檔案。
   2. Present前先看看你的jar file是否能運行，如不能運行可能是JRE版本太舊，預先準備JRE安裝檔案以備不時之需。
   3. 檔案應同時放在USB記憶體和網路中，萬一USB有問題也可以連上網路下載。如果你的程式有修改，CD也要準備好，present後就要交了。
2. Present:
   1. 我們Present的位置在非一般的Lab - A310。
   2. 時限:20分鐘，頁數限制:20頁
   3. 內容跟上次的差不多，整個Powerpoint的內容: (暫定，有多餘或缺少的部份請告知)
      1. Project Objective -- Fai
      2. Background -- Fai
      3. Function -- All
      4. Class diagram -- charlie
      5. Data Design -- charlie
      6. System design -- charlie
      7. Testing strategy and result --David
      8. Project Schedule --David
      9. Result and conclusion --David
   4. 時間分配(暫定):
      1. 自己負責的部份，每一部份1.5分鐘。例如根據上表，不計All的部份，charlie的present時間有4.5分鐘，而David和Fai只有3分鐘，總時間10.5分鐘。
      2. Function: 2 分鐘
      3. Testing strategy and result: 2-4分鐘，視餘下時間而定。
      4. 總時間: 14.5 - 16.5分鐘，餘下的就是被問候的時間來了。
3. Demo:
   1. 自己做自己做過的Function，和在Mid-semester demo時相似，只是換了麗音(雙語廣播)而已。
   2. Demo前請先自已試行一次，確保過程中不會看到害蟲，也要確保你的行為不會被人發現你有迴避的企圖。
   3. 準備一個共用的Project File用作整合測試。
   4. 準備Test data列表，列出可以正常運作的Test data，可預先準備的檔案應先準備好。

Final Report 工作列表

Report地址:

http://choi-home.no-ip.info:10365/

Username: Project3

Password: pw32008

Report出爐時間:

1. 上午3時
2. 上午6時
3. 上午9時
4. 上午10時30分
5. 最終版，中午12時
6. 如果延遲，下午1時30分是最後了。

你們可以隨時給我Report，我會把合併了內容在上述時間放出來。

下面是Report的內容

1. Testing
2. User Guide
1. 一步步教人如何使用
2. 如果有難用的地方，要解釋這個東西(例如選單、輸入欄位)
3. Installation Guide
1. 在不同OS下的安裝方法。(如果你沒有那OS，用文字說明即可)
4. Result and conclusion: Critical evaluation of the work
1. Result: 這個Product好用嗎?簡述好用和不好用的地方。可以參考Future Extension(Project Work檢討會議記錄)
2. Conclusion: 拿你的製成品，從Requiremnt到Final Product，有甚麼做得好和不好的地方(例如Requirement是否正確定義、之後的設計到最終製成品是否合乎當初定立的要求)，不需要提出有甚麼困難。除了Final product的Function外，說明改善方法。
3. Problem/Difficulties encountered: 可以參考Problem / Difficulties(Project Work檢討會議記錄)
1. 從分析階段到製作階段遇到的問題。
2. 多提及技術性的問題，例如:多Bugs, UI design的限制等等。
3. 可以提及少量時間安排的因素，但是不要把其成為主要的原因。
4. Limitaion of current system:
5. Future Extension and Future Development: Final product的Function可以如何改進。可以參考Future Extension(Project Work檢討會議記錄)
5. Inline code comment
6. Introduction: 因Report內容有不同，必須修改。這是給老師留下第一印象的地方，一定要做到最好。
1. 把Function每一部份的重點表達出來。
2. 頁數不應多於2頁
7. Requirement spec修正
1. Function應提供更詳細的資料，例如User可以在這個Function幹什麼，不知道可以參考你的製成品。
8. Design Spec
1. Data Dictionary
2. Use case修正
3. Sequence Diagram修正
9. Acknowledgement: 討好奉承的地方，(對Project貢獻的人太多，我們沒法盡錄)，可說要多謝那些人，給我們甚麼教導等 。可有可無，但要取同情分的話這不可少。

 

這份Report的分數將會平均地分佈，即是做得愈多，全組人就愈高分。所以不要計較付出，可以做的盡做吧!

Problem / Difficulties(Project Work檢討會議記錄)

1. Implementation
1. schedule change
2. Requirement Change/ Inconsistent
3. USB11(Unidentified Small Bugs), duplicate add staff
2. Techial Problem
1. Design is not good, but there are no perfect software design.
2. 4 in 1.
3. Code duplicate
4. Programming style, our program have different version of code(但看到有進步是好事來的)
5. Not compartable when an object class is updated.
6. Duplicate Library: Filewriter.
3. Test-Driven
1. Because of time, only a few classes have been implemented.
2. Balance of Quality and quantity.
3. It is impossible to have faster development with fewer bugs occur.
4. Design Pettern
1. Command Pattern: easy to debug
2. Skeleton Pettern
3. Adapter Pettern
5. MVC: Command Pattern can fully implemented.

Future Extension(Project Work檢討會議記錄)

Create Project

1. Project End Date can be calculated by latest task's end date.
2. Project Type can be a seletion box.
3. Project Leader can be search and added though Database.

 

Maintain Staff

1. Add Staff
1. Staff data are got from database.
2. Staff and project are separated, so no need open project before maintain staff.
3. Skill can be shown by click on a button.
4. Department can be selected.
5. Post can be search and selected.
6. Skills can be maintained, search and added.
2. Delete Staff
1. Alert if staff have task in charge.
3. Edit Staff
1. Add cancel button.
4. Table will adjust when window size is changed.
5. Staff have e-mail address.

 

Maintain Task

1. Undo/Redo
2. Create Task
1. Duration: when focus is lost, adjust task end date.
2. Adjust start date when dependent task is choosen.
3. Can depen on sub tasks.
4. When start date is changed, change the end date or duration.
3. Edit Task
1. Cannot be edited after task is completed.
2. In popup menu, complete task will not be shown if task have not started.
3. In popup menu, start task will not be shown if task have started.
4. Add staff: staff can be search and selected( more than one)
5. If project status is not in planning mode, Real start date can not be selected by user, only task is started the real start date is recored.

 

Save Project

1. "Save" button should be "Save project"

 

Generate PERT Chart

1. Export file: user can choose file format.
2. Change font size, color of the title and description.
3. Change color of normal path and critial path.
4. Title can be customized.
5. Node can be draged by user.

 

Generate Gantt chart

1. Export file: user can choose file format.
2. Change font size, color of the title and description.
3. Gantt chart bar can show task information such as progress, start date and end date.
4. Title can be customized.
5. Can preview real project.
6. Open the generated file after generation.
7. Show task dependency.
8. Re-generate when the project change.
9. Task information can be edited and Gantt chart bar can be adjusted. Then reverse to project data.

 

Find out Workload

1. Contribution in one project/task.
2. Can be displayed in "add staff to task" function in Maintain Task.

 

Reminder

1. Remind all reminder at once.
2. Can set reminded or remind again when reminding.
3. Send reminder to staff by e-mail.(If staff have e-mail address)

 

Generate Progress Rerport

1. Add preview function.
2. UI will be consistent to other report generation function.
3. Add "Select All" button.
4. Report to Project manager everyday by e-mail.
5. Report can print to printer.

 

Staff Analyze Report

1. More criteria of status such as staff who miss deadline or staff who never miss deadline.
2. More than one staffs can be selected.
3. Criteria of status can be multi-selected.
4. Report can print to printer.
5. Report can be saved to other places.

 

Cost Report

1. Project are sorted by total cost
2. "Type" can be deleted.
3. Report can print to printer.
4. Report can be saved to other places.

 

Project Analyze Report

1. Table can be sorted
2. Report can print to printer.
3. Report can be saved to other places.

 

Timetable

1. Web server can solve multi connection.
2. User can use existing web server to display time table.
3. Can view by several day, week and month.

 

Main GUI

1. Task bar, help file
2. After opne project, main area should display task information and Gantt chart, both of them can be modified by user.

義和團式的專案計劃

http://www.wretch.cc/blog/phopicking/2851110

老實說，很多人在進行軟體專案規劃的時候，都會有義和團上身的現象。無論外在環境多麼險惡，只要我擁有教主保佑，就有神功護體，可以刀槍不入，攻無不克，戰無不勝。所以兄弟們，不管實際上到底案子看起來有多困難，大家放心，一定沒問題。
吉娜：這個案子要做多久？
義和團團長：三個月。
布魯斯吃驚的說：三個月？這樣有任何的buffer嗎？你有抓任何risk factor嗎？我怎麼覺得少說也要六個月！
義和團團長模仿了一下李小龍：啊剎！啊剎！相信我，只要三個月。我一定把他做完。Risk factor？六個月？(模仿李小龍伸出食指左右搖晃後，往地上吐了一口口水。)這是沒有練過武功，對自己能力沒有自信的東亞病夫，才估的出來這種可恥的schedule。
......

本田：我覺得你們一定可以在3個月之內做完的。
布魯斯：怎麼可能！我們從沒做過銀行的案子。
本田：我知道你們一定可以的，你們技術能力這麼強，一定沒問題的。
布魯斯：話不是這樣講，3個月，又是不一樣的domain。還不要提，光使用者訪談最少就要一個月了。
本田：我知道你們一定可以的，你們技術能力這麼強，一定沒問題的。
布魯斯：話不是這樣講，這個案子的測試環境特別複雜。光是架這個測試的環境，就要花掉很多時間了。
本田：我知道你們一定可以的，你們技術能力這麼強，一定沒問題的。
布魯斯：我們再強也是有極限呀。這樣做的risk太高了啦。
本田：我知道你們一定可以的，你們技術能力這麼強，一定沒問題的。

......

也有人認為，如果立了一個完全不合理的deadline，反倒可以激起大家的士氣，願意努力加班達成不可能的任務。

......

所以當下一次有人請你對一個專案進行預估時，在你高喊：『神功護體，刀槍不入』前，請先想一想，你的金剛不壞護體神功，真的練到了第九層嗎？自己進行自我催眠，告訴自己一切都沒問題，這樣真的比較好嗎？

這是一篇我在上年暑假看到的文章，雖然我很早已經知道不要編排一個不可能的任務，但是在開發過程中才發現其速度沒有想像中般快，而在老師又以為我們有神功護體，總是以為會做得完，怎知道臨近期限才發覺不可能。我又再一次當義和團定下不可能的時間表了!

當軟體專案計劃趕不上變化時

http://www.lifeparty.idv.tw/blog/archives/279(部份轉載)

雖然「計劃趕不上變化，變化比不上老闆一句話」，但趕不上或比不上並不代表要放棄計劃，否則專案的成功也只是聽天由命的偶然罷了。同人認為，軟體專案要成功，關鍵不在於如何照計劃進行，而是要「計劃」當計劃趕不上變化時該怎麼辦。換句話說，當軟體專案管理者把計劃當成死的名詞時，他將不會成為稱職的專案管理者；稱職的專案管理者會把計劃當動詞，用以採取適當行動，才會讓專案走向成功。

實際上，根據同人在軟體專案開發的實務經驗，期待專案問題藉由收尾巴的過程而得到解決的想法，往往是要付出很慘痛的代價的，但許多人總是無法從這些慘痛教訓中得到啟示。在專案後期所發現的問題、或產生變動，其所花費的成本與消耗的開發人員的青春，與產出軟體的功能與品質相比往往是划不來的。於是，歷史不斷地重演，軟體開發的痛苦經驗也一再地被經歷。

問題並不在於軟體功能無法說加就加、說改就改，而是在收尾巴的過程中自廢武功。不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計怎麼會有足夠的空間來容納新功能？就好像想在堆滿東西的房間中，還要硬塞一些東西進去，這樣的結果當然很容易會讓我們在這房間中跌倒。

......

理論上，專案管理中的專案收尾過程（project closeout）本來就不是用來讓開發者增加功能、修改缺陷的，而是吸取專案的經驗及教訓（Lessons Learned），以利後續專案當作規劃參考。因此，期待在專案收尾巴才來修改軟體的想法，事實上，正代表著專案在規劃、執行及控制的過程中有所遺漏。然而，一廂情願地認為收尾巴可以彌補這些在專案過程中的遺漏，這種想法實在是太過樂觀了呀。

所以，現在其實是反省的時候，開發的時間已經過去了，硬著頭皮去修改將會付出很慘痛的代價的。你想修改的等Further Development時再改吧!

Java , COBOL 以及版本控制

Java , COBOL 以及版本控制

2.Third party程式庫的版本及相容性問題
這個問題一樣，也不是一個可以一體適用的問題。可以不換，我們當然就可以撐住不換。可是有時候，是某個版本有重大的defect爆出來不得不換，有時候，是客戶一定要你換。這個世界上雖然也有升級狂的存在，可是也還是有不想升級卻是不得不升級的倒楣鬼。qing比較好命的地方在於他對於要使用的環境與 library有很高的控制權。不過這種事並非放諸四海都皆準的。
其實不要講別的，像我家的diggirl，有附一個軟體給大家下載，最近一堆買了新電腦的朋友，就跟我抱怨說，我的vista不能裝girl digger。
我當然可以說，靠盃呀，我連vista都沒有，誰叫你裝這麼吃resource的OS？可是這些朋友又會告訴我，現在notebook出廠就是vista，你沒別的可以選。
生意能夠不做嗎？我可以不support vista嗎？
這實在是個很傷感情的問題呀。^^
也有的朋友說，我們做的某些網站的網頁，IE7看了會爛掉。
我也很想高聲大罵，靠盃呀，我已經測了IE6跟firefox，哪有性命再去測其他版本的browser？可是我們還是要保持專業的形象，流露出淺淺的微笑，答應客戶我們會想辦法。
老實說，我還不知道該怎麼辦，就只好先鋸箭一下。

軟體測試真是不容易啊!

Java會步上 COBOL 的後塵嗎?

http://mmdays.com/2008/01/02/java_future/

最近這個禮拜，許多網站都在寫所謂的「年終回顧」，而向來報導資訊科技產業為主的InfoWorld卻列出了「2007最被低估〈未被大力報導〉的科技新聞」，而排名第一的就是這篇文章：「JAVA正步上COBOL的後塵！」

光看這標題實在太嚇人。從大學時候開始算起，Java我碰了少說也有快七年以上，雖然比起眾高手不敢說多麼精通，但是說Java說要像COBOL一樣被市場淘汰，會不會太早了點？如果真的有朝一日醒來，Java全面性的被新語言替換，那所有寫Java長大的程式設計師豈不是立刻失業？

好，先別急，先把原文內容看完再說。InfoWorld在這篇文章所持的幾個重要論點如下：

1. 在網頁設計師界，擁抱Ruby on Rails、PHP、AJAX的人越來越多，而M$ .Net也正逐步把Java趕出企業應用市場。
2. Java最被人傳頌的好處是可以跨平台，然而根據Twiki.net CEO的說法，Java的版本越來越多，還時常要去下載各種不同的Library檔案，因此他們開發網站後來都改用ROR，解決版本複雜性的問題。
3. Java吃記憶體太兇、在UI上表現不佳，不利於手機版本J2ME的發展。
4. 根據InfoWorld一份訪問超過1,850家企業的問卷結果顯示，各企業比較偏好用.Net，勝過用Java。

好，我知道這樣的文章一定爭議滿天飛。我對當中的許多論點也不甚認同，但話說回來，它也的確點出一些問題。首先談談我不認同的點：

• 少來了，AJAX什麼時候變成獨立的程式語言，還可以取代Java來著？
• Ruby on Rails細節我不熟，但只因為這個語言近兩年開始起飛，開發網站套用模版用現成Framework開發速度很快，就可以取代Java了嗎？ROR之所以速度會快，是因為Rails已經寫好很多的模版可以套用是因為它的Framework可以讓你節省很多從頭開始的功夫，而寫Java的大部分人卻還習慣著從頭到尾一頁一頁慢慢刻。如果現在Wicket這些 Java Web Framework發展得好，也綁進Eclipse裡面，那未來JSP是不是也可以喊出取代ROR的口號了呢？

不過，我也必須承認，寫Java到現在，有很多地方是我認為值得討論的。

• 版本控制：Java一直在推出新的版本，而且最近出的速度超快，一轉眼已經要出Java SE 7了，Java EE 6也預定2008年問世，速度快到其他家廠商都追不太上〈企業級伺服器WebLogic都到了2007年中出新版才能支援Java EE 5，而WebSphere、JBoss、Oracle等大廠都還在苦苦追趕中。〉
• 除了SDK外，Java還有許多由Open Source界開發的Library。雖然這些軟體免費又好用，但是伴隨而來的版本與相容性問題也相對複雜。程式老跳訊息告訴你這個jar檔版本太舊不是他要的，怎麼辦？
• 記憶體吃得兇：這顯然是跨平台的代價。我個人只遇過幾個純粹用Java寫的GUI程式，分別是JBuilder、Eclipse，以及NetBeans。而這幾個都是吃記憶體的超級怪物。就算我現在電腦有2G的ram，我也不敢同時開前面任兩個程式起來。
• 程式架構越來越複雜：曾經我以為只要會寫繼承、MVC，看過Design Pattern就算是會寫Java了，但是我大錯特錯，Java還有很多Framework，而且到最後某些Framework已經複雜到有點變本加厲了。這當中首推EJB。EJB現在已經被認為是失敗的概念，因為它實在是超級複雜…我曾經在課堂上寫過Agent，要讓同一隻程式能「跨越不同的JVM執行」，天啊，從頭寫一隻出來大概要走我半條命。果不其然，現在POJO〈Plain Old Java Object〉的口號越來越響亮，呼籲大家把Java程式設計得越簡單越好，尤其是不要照EJB 2.x的模樣來寫。

但話說回來，縱使Java的確有許多缺點，這仍然離標題所預測：「JAVA正步上COBOL的後塵！」差之甚遠。與其他新進語言相比，Java因為平台眾多，又有大批open source人士寫了很多的Library，以致讓新手光看到版本就眼花撩亂，但這些並不是會影響Java是否能持續存活下去的關鍵因素；關鍵應該要從整個軟體產業的角度下手。在原文後面的回應中，有一位署名systemanalyst的人寫得相當精闢：〈以下節錄〉

拉回企業的角度來看，許多公司內的mainframe程式是用IMS、CICS搭配上JMS(Java Message Service的縮寫) Connector來寫的，PHP跟ROR在這一點是要怎麼取代Java？

當你的網站流量很大時，用Windws TCP/IP會癱瘓，你確定敢用Windows當作重要的前端系統平台嗎？

我不是說Java沒有問題，但相較於其他平台，如果我自己開公司，我一定會選擇Java平台。為何？因為我可能會選擇 POS平台用AIX〈IBM的Unix作業系統〉，線上購物平台用Linux，開發環境用Windows，而後端的資料倉儲系統架在z/OS上。為了省下管理不同異質平台的錢，我會用Java，因為它是唯一能在所有平台上通用的程式語言。

當我們在談論一個程式語言時，我們必須要從整個軟體工程的角度來看。Java不只是一個語言。當你看著Java時，你必須包含整個平台來看。看看這些為Java創造出來的架構與伺服器，它們的scalability是無限的！比起來.NET可就完全沒辦法比。如果你只是要講語言的syntax，是的C#跟Java沒什麼差別。但是如果你要評判Java能帶給你的價值，你必須從頭到尾、從上到下，完整的評估，而不只是”getThis()” 或 “setThat()”這些語法。

說到企業用途，或許Java還有另外一項好處，那就是Java Solution的平台提供者眾多，包括IBM、BEA、Sun、Oracle都有出Java專屬的應用伺服器，但.NET的平台似乎只有 Microsoft一家比較知名。不管M$的名聲如何，選擇Java平台的公司至少在短期內比較不用擔心被同一家廠商壟斷的問題。即使Sun這一兩年來的股票跌到連水餃股都不如，各家企業至少還有IBM、BEA這幾家可以選擇，而選擇.NET的公司，可能就只好期望M$能夠活得長長久久，永保安康了。

講到這裡，各位看倌，你們的看法又是如何呢？

熱門程度: 53%

 

 

看了這篇文章後，有沒有後悔當初要選JAVA呢?

延伸閱讀:

版本控制，版本升級是不是個問題？

Critical evaluation of the work

Critical evaluation of the work - for a critical discussion of all aspects of the project, from whether the original problem formulation was correct, to how well the solution meets the specification.

批判性評價的工作 - 為一個專案的各方面的關鍵討論，從原來的問題有否正確制訂，到解決方案如何符合規格。

Results and conclusions: a summary and a critical discussion of the results, conclusions, any problems/difficulties encountered, any delays/changes in project schedule, limitations of the proposed system, and in some cases a subsection suggesting further developments to be undertaken.

結果與結論：一個總結和一個批判的討論結果、結論、任何問題/遇到的困難、在專案進度上的任何延誤/變化、系統的限制和在某些情況下制訂的進一步發展建議。

今次の約定:

我們會一步一步的把你回到專案剛剛啟動的情況。

1. 看看現在的程式，找出可以改善的地方，為整體的系統評價。
2. 看看工作記錄，回憶系統製作過程的苦與樂。
3. 檢視我們的設計規格(Design Specification)。
4. 檢視我們的需求規格(Design Specification)

 

我們這個製成品都可以算是完成了吧!雖然有可用功能，但是還有很多值得改善的地方。

即將到達: 試用階段

1. 詳見會議記錄
2. 製成品有沒有符合使用者要求。

即將到達: 製作階段

1. 製作過程遇到的技術困難。
   1. 太多Bug?從設計的角度看，為何會出現太多Bug?
   2. 有甚麼方法減少?
2. 時間表上的變更。(盡量以其他問題取代家課壓力，例如花太多時間找出解決某某問題，不想說謊就不如不要說，不要以為坦白就會從寬，坦白告訴人只會令人們以為我們沒有用心於這個專案。)
   1. 7個Iteration，為何我們沒有實行?
   2. Release 2 的Function為何延期?
   3. 製成品延誤完成的原因
   4. 如果給你再來，你會如何安排？
3. 有甚麼新技術研究出來?此技術如何幫助你解決困難?
   1. Design Pettern
      1. Open Close Principle
      2. Factory Pattern
      3. Comand Pattern
   2. MVC
   3. 重構有沒有給你一些新的想法?
   4. 過程中甚麼Tools幫助我們度過難關?
4. 不用討論平日我們的工作流程，這些人們不會看的。(雖然如此，我們日後仍會抽空檢討)

即將到達: 設計階段

1. 與現有的系統相比，有甚麼不同?為什麼?
   1. 記憶中有甚麼Function是和Design中有很大分別，抽一兩個最大變更的Function說明之
   2. 參考Class diagram、Use Case Diagram，不要看Sequence Diagram，太長了
2. 系統架構符合預期嗎?
1. Web base/ Local use / One project per program
3. 如果比你再做，你會怎樣設計系統架構?
4. 如果比你再做，你還會選用這種程式語言嗎?
1. Java / C# / C++ / PHP / J2EE / ASP.NET/ Oracle Designer
5. 有沒有後悔當初選用物件導向編程?為什麼?

即將到達: 分析階段

1. 我們收集足夠的意見嗎?
1. 其實不足，取得意見的階段意見較少，實作時才知道出入較多。
2. 這些要求是否使用者真正需要的呢?
3. 有沒新加的需求?有沒有要求可以放寬?
4. 當初選用的開發方式有沒有貫徹實行呢?
1. 開發方式:Extreme Programming
2. 少量釋出
3. 測試先行
5. 我們的系統設計是否滿足使用者的要求?
6. 當初的要求和現在的要求有多少出入?為什麼？
   1. 怎樣才可減少需求變更的出現?

Project Work Final Product檢視會議

希望通過回顧會達到目標: 找出這次專案產品的不足，以便將來改善。

交付物: Final Report的Results and conclusions:

 

1. 各組員演示自己所做的Function，為了能模擬一個Project manager使用本產品的情況，演示次序如下:
   1. Project Planning (從無到有)
      1. Create Project
      2. Matintain Staff
      3. Maintain Task
      4. Save Project
      5. Close Project
      6. Open Project
      7. Generate PERT Chart
      8. Generate Gantt hart
   2. Project Monitoring(從專案開始到結束)
      1. Find out workload
      2. Maintain Reminder
      3. Monitor Project
   3. Reporting
      1. Generate Project Progress Report
      2. Generate Cost Report
      3. Generate Staff Analyze Report
      4. Generate Project Analyze Report
2. 每演示完一個Function，各組員可以對這個Function給予意見，例如:
   1. User Friendly
      1. Easy to use
      2. Efficent to use
   2. Error Handling
   3. 符合當初定下的要求
   4. 發展空間
   5. 開發過程遇到的困難，例如開發工具的限制、自身的技能不足(千萬不可以告訴人們因為你無能所以做不到，會給人鄙視的)。
   6. 如果可以給你從頭再來，你會怎樣做得更好?
3. 期間必須有人記下所有意見以作寫Report之用，有需要的話更可以錄音。
1. 可以接受其他意見，例如轉用另一程式語言，改變軟體架構。但不要過份離題。
4. 自己的事自己最清楚，所以會議完畢後組員依自己負責的Function寫Report。

 

提示:

每演示完一個Function，各組員可以對這個Function給予意見，例如:

1. 使用方便嗎?可不可以快速做到你想要的function?
2. 有沒有令你煩躁的地方?
3. 如果你是Project Manager，你會希望這個Function會長得怎樣?
4. 為什麼做不到?是程式語言做不到?想不到算法?找不到Library?
5. 這個Function可以給你任意改造的話，你會怎樣改?(在不改變其程式語言的情況下)

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