考核系统快结束了，将此项目的经历回忆如下，也小结一下，先谈这个项目中值得提倡的地方：

1、在开发之前进行了完整的需求分析，形成了系统的需求文档，需求文档中最有用的部分感觉就是界面原型，还有系统的菜单，这样给了用户一个初步的直观的印象，同时文档中的一些对于界面原型的描述以及计算规则等内容在后期的开发中也起了指导作用。

2、在需求分析完成之后，进行了概要设计，包括完整的数据库设计，这样在后期的开发中对数据库表结构方面没有大的修改了，只是添加了一些表和视图。

再谈谈项目中的缺点吧：

1、首先就说说需求文档，虽说需求文档写了很多，大概有100页左右（word），但由于一篇文档中集中的内容太多，对于用户来说只是关注了界面原型，系统菜单等部分，对于其它内容用户关注度不高；同时由于篇幅太大，开发人员打开查看或者后续修改也比较麻烦。

对于以后的需求文档是否可以这样编写：首先有一个正文，正文中包括大纲，然后将每一个具体的需求放在单独的一个文档中，最好能类似html链接那样，这样查看也方便，也一目了然。

原来用RobotHelp写过帮助，照此看来，岂不可以用来写需求文档了，呵呵

2、再说数据库设计，还不够细致，很多应用场景由于设计的不够细致，导致数据库表也有所欠缺，因此对于以后的项目设计有两个注意点：

a、加强应用场景设计，具体可以用流程图，甚至序列图描述清晰的业务流程，完善数据库表设计。

b、要求一定先修改模型（这里指PowerDesigner中的数据库设计），然后再去修改POJO类等具体代码，最好不要先改代码，再修改模型，这样难免会有遗漏，时间久了，就会导致模型和代码的不一致，慢慢的，模型文档就没有人看，也没有人维护了。

c、顺便提一下，模型文档的好处一是方便后来者，二是可以方便的导出数据字典。

3、对于命名规范没有在开发前考虑全面，虽然在开发前对命名规范有一定的规定，但是不够全面，造成了后期开发中各人各人的命名有所偏差。

4、分层架构中的dao层和service层处理的不够好，导致service层实际上是混杂了dao和service的功能，业务代码不够清晰。以后的项目考虑dao就是dao，提供数据访问的操作，service层则提供业务处理方法，service与dao的关系应该是多对多的关系。

5、考核系统中使用了JSF/Richfaces做为表现层，好像不太好使，经常会出现多次重复访问方法的问题，后续还需要加强对JSF的学习，避免类似问题。另外Richfaces在生成大数据量的页面时，一个表格有1440行数据，页面巨慢无比:(，后来没有使用RichaFaces的表格，直接使用jstl+html标签，速度倒是很快。

6、项目中的日志输出、异常处理不够明晰，这个和命名规范一样应该在项目开始时给出清晰的思路，在具体开发中应该经常检查。