一、規格化設計發展曆史
自從20世紀50年代第一台電子計算機的問世，軟體也同時誕生。然而在計算機發展的初期，由于軟體編寫沒有規範，它們的通用性是十分有限的。
20世紀60年代，軟體作為計算機的剛需，覆寫的範圍越來越廣泛，與此同時的是軟體的維護成本越來越高,由軟體錯誤而引起的資訊對視、系統報廢事件屢有發生。為此,1968年,荷蘭學者E.W.Dijkstra提出了程式設計中常用的GOTO語句的三大危害:破壞了程式的京東一緻性,程式不易測試,限制了代碼優化,此舉引起了軟體界長達數年的論戰,并由此産生了結構化程式設計方法,同時誕生了基于這一設計方法的程式設計語言Pascal。Pascal語言在20世紀70年代占有統治地位。
然而在20世紀70年代末，随着計算機科學技術的進一步發展，面向過程的程式設計已經難以使用者需求的變化。于是程式員們開始尋找更加先進的軟體開發技術，面向對象的程式設計應運而生。面向對象的程式設計的誕生是程式設計方法學的一場革命，大大提高了開發效率，減少了軟體開發的複雜性，提高了軟體的可維護性，可拓展性。1990年以來，面向對象分析、測試、度量和管理研究都得到長足發展。
二十一世紀初期開始，規格基本完善成如今的形式，并更加側重于基于構件的對象使用和對象實作。應用現有的規格規範，軟體可以輕松的實作分布式，跨平台，松耦合的開發需求。
二、bug統計及分析
| 規格bug |
| 第9次作業 |
| 第10次作業 |
| 第11次作業 |
雖然未被報告bug，但是JSF并非規範，反而是因為很幸運的遇到了對JSF同樣了解不太深的同學是以能夠沒被報告bug，經過分析後仍是發現了一些JSF不規範之處。
1.有的地方前置條件不寫
/**
* @MODIFIES:this
*/
public RequestIn(TaxiGUI gui,mapInfo map) { 雖然隻是一個構造方法，但是實際上在這個重載的方法中有參數傳遞進入，應該明确，增加可讀性。
2.有的描述自然語言化
/**
*@REQUIRES: p is in map
* xxx
*/
改進
/**
*@REQUIRES: 0<=p.x<size && 0<=p.y<size
* xxx
*/ 更加标準化語言，規範化。
3.沒有對全局變量進行限制
/**
* @REQUIRES:None;
* xxx
*/
public boolean InputCheck(String s) {
改進
/**
* @REQUIRES:time >= 0;
* xxx
*/
public boolean InputCheck(String s) { time作為初始設定有至少為0，而作為全局變量它可能被改寫，是以應該在這裡有限制，以增強可讀性。
4.對異常處理應當算作後置條件寫進EFFECTS
/**
* xxx
* @EFFECTS:None;
*/
public void loadfile(String path) {
改進
/**
* xxx
* @EFFECTS:exceptional_behavior(xxx);
*/
public void loadfile(String path) { 規格bug産生原因分析
雖然沒有被報bug，但是不規範的原因，我認為
1）是我對代碼嚴謹性的思考還不夠，以自己寫代碼的角度去考慮，但這也有原因，第一次寫計程車是第7次作業，那個時候并沒有JSF這個東西，第9次作業的代碼在此基礎上修改而成，那麼很多地方實際上是先寫了代碼再寫的規格。
2）對于這種形式的規格并不熟悉而且布爾表達式用來概括代碼實在不習慣。
三、功能bug與規格bug在方法上的聚集關系
雖然實際上規格寫法仍然有一些不規範的地方，但是這些不規範的寫法并沒有影響到代碼實作。我的功能性bug更多在于自身代碼經驗不足導緻的代碼能力太低，其中導航方法由于計算的問題，導緻了每一步的時間會略微超出規定的時間窗，畢竟進行一些計算再sleep時間窗的時長，時間一定會超，這就會造成幾步之後時間不同步，車會走回頭路，但即使是這樣，他也與規格沒有相關。
四、心得體會
要說規格真的沒什麼用的話，我認為很大一部分原因正如我原因分析1）所說：第一次寫計程車是第8次作業，那個時候并沒有JSF這個東西，第9次作業的代碼在此基礎上修改而成，那麼很多地方實際上是先寫了代碼再寫的規格。而且規格的思想在前八次作業并沒有，是以在前大半學期的作業思考方法加上第7次作業的代碼繼承，真的很難避免一些慣性思維。
再者，部分人指望着JSF多挂人bug，搞得大家都對這個印象不好，雖然我運氣還不錯，但我身邊有不少就被坑了。