1.開發時間預估編程
PSP2.1函數 |
Personal Software Process Stages性能 |
Time學習 |
Planning測試 |
計劃優化 |
|
· Estimate編碼 |
· 估計這個任務須要多少時間spa |
2day設計 |
Development3d |
開發 |
|
· Analysis |
· 需求分析 (包括學習新技術) |
8h |
· Design Spec |
· 生成設計文檔 |
4h |
· Design Review |
· 設計複審 (和同事審覈設計文檔) |
3h |
· Coding Standard |
· 代碼規範 (爲目前的開發制定合適的規範) |
2h |
· Design |
· 具體設計 |
8h |
· Coding |
· 具體編碼 |
8h |
· Code Review |
· 代碼複審 |
3h |
· Test |
· 測試(自我測試,修改代碼,提交修改) |
4h |
Reporting |
報告 |
|
· Test Report |
· 測試報告 |
3h |
· Size Measurement |
· 計算工做量 |
2h |
· Postmortem & Process Improvement Plan |
· 過後總結, 並提出過程改進計劃 |
3h |
合計 |
48h |
2.實際開發時間
PSP2.1 |
Personal Software Process Stages |
Time |
Planning |
計劃 |
|
· Estimate |
· 估計這個任務須要多少時間 |
2day |
Development |
開發 |
|
· Analysis |
· 需求分析 (包括學習新技術) |
12h |
· Design Spec |
· 生成設計文檔 |
3h |
· Design Review |
· 設計複審 (和同事審覈設計文檔) |
2h |
· Coding Standard |
· 代碼規範 (爲目前的開發制定合適的規範) |
2h |
· Design |
· 具體設計 |
12h |
· Coding |
· 具體編碼 |
12h |
· Code Review |
· 代碼複審 |
2h |
· Test |
· 測試(自我測試,修改代碼,提交修改) |
3h |
Reporting |
報告 |
|
· Test Report |
· 測試報告 |
2h |
· Size Measurement |
· 計算工做量 |
1h |
· Postmortem & Process Improvement Plan |
· 過後總結, 並提出過程改進計劃 |
2h |
合計 |
53h
|
3.性能分析&改進
a.測試輸入爲 -r 10 -n 10 時對應的性能分析圖以及程序中各個函數的消耗。
b.測試輸入爲 -r 10 -n 100 時對應的性能分析圖以及程序中各個函數的消耗。
c.測試輸入爲 -r 10 -n 1000 時對應的性能分析圖以及程序中各個函數的消耗。
d.測試輸入爲 -r 10 -n 10000 時對應的性能分析圖以及程序中各個函數的消耗。
e.針對生成的10000道四則運算題目,測試輸入爲 -e Exercises.txt -a Answers.txt 時對應的性能分析圖以及程序中各個函數的消耗。
性能的優化以及改進
1.fopen函數在函數調用圖中能夠看出佔用了大量的時間(特別是在生成四則運算題目較少時尤其明顯),在必定程度上會影響性能,這也是由讀取硬盤與讀取內存速度差別形成的。因爲程序設計是有兩個要求,一個要求隨機生成四則運算表達式並把答案寫入文件,另外一個要求讀取文件評測而且輸出結果至文件,因此沒有必要同時打開多個文件,而在判斷輸入參數結束後纔打開相應的文件,這樣節省了以前所有打開文件時fopen操做所花的進一半的時間。
2.在四則運算評測的時候,因爲我對於真分數採用字符串進行表示以及存儲,因此不停地讀寫字符串,形成了sscanf,sprintf大量的調用於是耗費了大量的CPU時間,其實對於字符串的存取能夠採用將真分數用struct結構定義的方法來替代,這樣能夠大量的省去讀寫字符串所耗費的CPU時間,並且struct的存取和字符串的存取相比空間佔用差很少甚至可能更少,因此可使用struct來提升程序性能。
4.測試用例&程序正確性分析
測試用例
1.測試輸入爲 -r 10 -n 10000,程序正常執行。
2.測試輸入爲 -n 10000 -r 10,程序正常執行。
3.測試輸入爲 -w 10 -s 10000,程序給出參數錯誤提示信息。
4.測試輸入爲 -r 10 ,程序給出參數不足的提示信息。
5.測試生成10000題目,可以生成10000道題目,而且均爲天然數、真分數表示,且符合四則運算合法表達式的要求。
6.測試生成大量題目,輸入爲 -r 10 -n 50000,程序運行78s結束,輸出結果。
7.測試生成大數題目,輸入爲 -r 100 -n 100,題目計算過程當中可能產生越界,越界的題目計算結果爲空,可是程序不會崩潰。
8.隨機生成100題目,檢查是否有中間結果產生負數,是否出現除法時候分母爲0,通過檢查,沒有負數以及除零狀況的出現。
9.隨機生成10000題目,檢查是否存在倆個相同的題目,通過檢查,沒有相同題目出現的狀況。
10.手工寫10個正確的四則運算題目,而且給出10道題的隨機答案,通過程序運行能正確的進行評判。
正確性分析
程序可以實現問題描述的全部功能需求,且具有有必定的魯棒性。
5.收穫&感悟
1.因爲對c語言的語法有些淡忘,因此在編寫程序時候對於真分數的表示採用了直觀的字符串處理,而沒有把其做爲一個具備內在聯繫的總體定義爲一個struct,因此在代碼編寫後期陷入了字符串處理的泥潭不能自拔,致使開發速度降低並且頻繁出bug,歸根到底前期考慮不周到,準備工做不充分,由於懼怕不能在規定時間完成而過早的投入到代碼的編寫過程當中致使浪費了更多的時間,因此我會在以後的開發中更多的精力放在編碼前的準備當中,以期達到事半功倍的效果。
2.從測試的角度來講,開始時我使用本身的程序生成的四則運算題目,繼而讀入本身生成的題目文件進行評測,或者根據本身認爲可能出問題的點設計測試,發現結果沒有問題,我就覺得大功告成,後來經過其餘同窗的測試結果發現出現了幾處錯誤,後經調試發現是本身在一個小點兒上出現了盲視,直接忽略了其存在的可能性,因此我以爲當你本身以爲沒問題時候要善於接受不一樣的考驗,這樣才能發現自身忽略的細節,這也是結對編程和團隊合做的優點所在吧。