一、规格化设计发展历史
自从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，搞得大家都对这个印象不好，虽然我运气还不错，但我身边有不少就被坑了。