github:sudoku
題目位址
這次的作業大意就是寫個數獨庫生成器(對於輸入的n1~1000000,生成相對應數量的不同數獨)
psp2.1psp**
personal software process stages
預估耗時(分鐘)
實際耗時(分鐘)
planning
計畫30
20· estimate
· 估計這個任務需要多少時間
development
開發· analysis
· 需求分析 (包括學習新技術)
160320
· design spec
· 生成設計文件
· design review
· 設計複審 (和同事審核設計文件)
· coding standard
· **規範 (為目前的開發制定合適的規範)
· design
· 具體設計
2030
· coding
· 具體編碼
300220
· code review
· **複審
· test
· 測試(自我測試,修改**,提交修改)
100300
reporting
報告· test report
· 測試報告
· size measurement
· 計算工作量
· postmortem & process improvement plan
· 事後總結, 並提出過程改進計畫
4045
合計650
965
1.做出正確的數獨圖(左上角的數字為(1+6)%9+1=8)(如何生成,思路)看了題目後的分析過程(解題思路):
思路:回溯(dfs),直觀的感覺就像一棵樹一樣延伸下去
第乙個空格直接生成不用判斷(題目要求)
然後往下一格一格生成,需要判斷是否滿足行,列,3*3矩陣
2.輸出n個數獨圖其中不能夠重複(如何判斷重複)
這個回溯的做法就直接排除了
3.輸出檔案到指定目錄
4.由於要用命令列檢測,這裡的主函式中要改成支援命令列的形式
類:乙個9*9數獨類實現過程:
其中需要的函式:
主函式,輸出函式,dfs函式,判斷1~9其中的數字哪些可以被填入(判斷函式)
主要的**:
bool panduan(int x,int y,int num)
if(sudoku[i][y]==num) }
for(int i=x/3*3;i8) }
for(int i=1;i<=9;i++)else
} }
return false;
}
測試執行:
選了10000個資料進行測試:效能分析:
主要在dfs函式上面消耗的時間最長
還沒想到實質性的改進思路,等成績出了,拜讀幾篇大佬的部落格後再做改進。改進的思路:
問題想的太簡單,具體做的時候錯誤百出,導致沒能按時提交,當做乙個警告了。反思:
軟體工程第二次作業
題目鏈結位址 github鏈結位址 難度瓶頸 最終選擇 改進版本 只是生成數獨終盤,不考慮附加作業,就沒有考慮類,只是函式。array 0 0 7 basic.erase 7 basic為集合名稱 if basic.size 0 for int k 0 k row k else 版本二 void c...
軟體工程第二次作業
github 位址 我剛開始打 的時候覺得打完就好,能過樣例就ok。經歷過一段時間後會發現有可能樣例過了其他測試點全錯,所以就會開始多測試幾組資料,希望自己的 能夠盡量準確。當準確性開始有保障後,我就會去思考程式本身是不是可以進一步改進,使 執行速度變的更快。在我看來自己出資料測試就相當於書中說的單...
軟體工程第二次作業
1.簡述軟體過程 軟體生存週期 軟體過程模型 軟體生存週期模型 三者之間的概念區別。軟體過程 軟體生存週期中的一系列相關過程所涉及的活動 軟體生存週期 軟體生命週期 同任何事物類似,軟體也有乙個從生到死的過程,這個過程一般稱為軟體生存週期或生命週期 軟體過程模型 軟體生存週期模型 為了能高效地開發乙...