github鏈結
1、拿到題目後，覺得這題目和八皇后的題挺像的，都是行列衝突問題，因此覺得可以通過將乙個99的數獨圖變成9個33的圖，對每張33的圖進行數字的填充，例如先將1填入9張小圖中。按以上思路寫完程式後，在行數下移的同時還需要在對應的圖中找到下乙個數填入的位址，產生了可能會跳過某一行填入數值的問題，便又加了個在33圖中找數填入的位置，效率變得很慢。
2、第二版是發現了還有dfs演算法的解法，然後修改了一下思路，還是先將數逐一填入，然後每一行優先填入。考慮到第一版在小圖中尋找數值需要很大的時間消耗，就用乙個二維陣列來記錄數字填入了哪一張小圖。
**結構其實很簡單，num_pic函式找出行列對應的圖號，judge函式判斷該位置能否放入對應值，dfs函式進行數值的回溯。
核心**是進行for迴圈中每一行進行填入數值的判斷與遞迴。
void sudo::dfs(int row, int z, int end)
return;
} else
dfs(0, newz, end);//遞迴下乙個數
} }for (int i = 0; i < 9; i++)
}}
cout比printf的效能低好多，最後改成輸出到檔案時執行時間又縮短很多。以下是n==10000時的效能資料
預估耗時（分鐘）
實際耗時（分鐘）
planning
計畫·estimate
·估計這個任務需要多少時間
450440
development
開發·analysis
·需求分析（包括學習新技術）
6060
·design spec
·生成設計文件
2010
·design review
·設計複審 (和同事審核設計文件)
·coding standard
·**規範 (為目前的開發制定合適的規範)
·design
·具體設計
9090
·coding
·具體編碼
120120
·code review
·**複審
4030
·test
·測試（自我測試，修改**，提交修改）
5050
reporting
報告·test report
·測試報告300
·size measurement
·計算工作量
1520
·postmortem & process improvement plan
·事後總結, 並提出過程改進計畫
3030
合計455
410
軟體工程實踐2017第二次作業
github連線 利用程式隨機構造出n個已解答的數獨棋盤 輸入 數獨棋盤題目個數n 0 n 1000000 輸出 隨機生成n個不重複的已解答完畢的數獨棋盤，並輸出到sudoku.txt中。參考 其實看了這個 以後，我深受影響，把自己的設想都推翻了，總覺得自己的方法不太好，想學習這個方法。我認真理解了...
軟體工程實踐2017第二次作業
預估耗時 分鐘 實際耗時 分鐘 planning 計畫20 10 estimate 估計這個任務需要多少時間 2010 development 開發375 465 analysis 需求分析 包括學習新技術 3030 design spec 生成設計文件 1010 design review 設計複...
軟體工程實踐2017第二次作業
由於書本買到得比較遲，看的內容不太多，其中印象比較深刻的是第二章中提到的單元測試和效能分析。作為乙個好 是要經過大量效能分析後的改進，提煉而成的，不能盲目地去改 要通過效能分析工具測試後，得出 的各部分函式耗時資料，找出相對耗時較長的部分，進行優化演算法等，才是正確的 改進方法。單元測試部分，我目前...