再思教务系统
去年的八月份左右也就是在软考之前为了体验工程的感觉（或者说更好的准备软考）我们进行了教务平台的开发。从准备软考的角度来说这个教务系统是成功的，而且非常的成功！因为在做教务的过程中我们遇到了很多问题和疑惑，而这些问题在后面准备软考的学习当中都有相应的解答，所以说对于软考来说那一遍做的教务是非常成功的。但是就教务本身而言是及其失败的，虽然说可以跑起来，甚至于个别的小模块独立使用的时候效果还不错。但是如果整体的教务跑的话必定会出这样和那样的问题。
安照相对正规的开发流程做完了DRP，回头再看看我们当时的教务，又有新的感触，特记录于此和组员们共勉，权且当为第二次开发教务做准备吧。
Web开发（无论是java还是.Net）的一般的流程如下
1、需求确定
通过各种手段确定系统的功能与性能
功能：用户维护、物料维护….
性能：可同时支持 n个并发访问，并且响应时间不高于 m毫秒…
手段：
头脑风暴 (brain storm)
会议
询问
原型–界面原型、业务原型…
本阶段是项目开发的最重要阶段
在web项目中，通常界面设计会在本阶段进行
针对此步骤的总结：
在做教务的时候因为时间的原因想早点儿做完这个系统，于是在做的过程中完全是凭自己的主观臆断去猜测需求，更不用说利用原型与客户沟通确定需求了。所以一些模块用户根本就无法使用。
2、分析与设计
a) 架构分析与设计
逻辑架构
3层架构、n层架构…
MVC…
Model 1 or Model 2
…
物理架构
Web服务器的分布
数据库服务器的分布
…
技术解决方案的确定
Java / .NET
Open Source /商业
…
针对此步骤的总结：
经典的三层架构帮助我们明确了各自的分工。敲定了使用.NET也使得的开发过程大大的缩短了。总的来说架构方面当时做的还是很不错。
b) 业务逻辑分析
根据需求分析业务逻辑
有哪些人会使用本系统？
他们会使用本系统做什么？
通常他们使用本系统的步骤是什么样的？
会有哪些明显的类来支撑本系统的运行？
会有哪些不同的提示会返馈给用户？
…
本阶段与需求的确定密切相关，通常在确定需求的时候就会进行相关的分析
针对此步骤的总结：
因为前期的需求分析做的就不是很好，所以分析业务逻辑这步骤就约等于形同虚设了。上面几个问题都得不到明确的答复。再做开发的时候一定一定先把上面的问题搞清楚了再动手去做，没有思想的做永远是徒劳。
c) 业务逻辑设计
根据需求的分析来确定具体的类
确定类的属性
确定类的接口（方法）
确定类之间的关系
确定用户操作流程在设计上的反映
进行数据库的设计
不同的项目步骤可能不尽相同
…
针对此步骤的总结：
个人认为最重要的就是数据库设计，回想上次的教务系统，做到了最后还在改动表的结构，后果可想而知----牵一发而动全身。为了有效的解决这个问题我们唯一能做的就是在前期把需求分析做的详细详细再详细，在业务逻辑分析阶段和客户沟通的细致细致再细致，把每条业务逻辑都走一遍尽可能的确保自己的理解和客户的理解一致。
d) 界面设计
设计系统的界面风格
颜色、style
设计系统的具体“模拟”界面
能够从头走到尾
方便进行需求的确定
方便JSP程序员的开发
…
针对此步骤的总结：
个人认为界面的设计应该分为两个步骤，建立原型的时候可以简单一些，能保证开发者和客户之间的交流沟通就可以；但是到了真正需要拿给用户使用的时候界面就应该加一些美化。想想我们当时做教务的时候建立的的页面简直就是四不像，说它是原型吧设计的时间太长，说它是最终的页面吧又太难看了。下次再做Web开发时候必须首先建立原型，并且这个原型可以完整的表达清楚开发者的意思，保证开发者和客户的沟通；其次再去美化界面，美化的意思就是在颜色以及风格方面让用户感到舒服，这是关键。
3、开发环境搭建
开发工具的确定
配置管理工具的确定
测试工具的确定
文件服务器/配置服务器等的确定
…
针对此步骤的总结：
整个教务的开发环境是VS2010，配置管理工具统一用的是SVN（关于SVN等工具），有一个公共的服务器（所有的文档以及源代码全部上传到服务器中）。悲催的是当时没有用测试工具，这一点是下次开发的时候需要注意的地方。
4、开发-测试-开发-测试
按照设计进行开发
迅速开发原型
进行迭代开发
提早进行测试
单元测试（白盒测试）
黑盒测试(功能性测试、验收测试)
性能测试
易用性测试
…
针对此步骤的总结：
目前个人认为最好的开发方法就是首先建立原型，然后迭代开发，而不是像上次开发教务那样一下子搞一个大工程，最终一块儿没跑起来整个系统就崩了。首先保证核心的功能可以运行起来，然后在此基础上一步一步的迭代，最终达到用户满意的程度。
5、编纂文档
针对此步骤的总结：
还记得我们的大部分文档都是开发完了之后补上去的，其实文档什么时候写没有必要非得规定个时间，例如：必须边开发边写，或者必须开发之前写等等。这些都不是一定的，只要我们能够让文档发挥出他应有的作用那么什么时候写，怎么写将都不是问题。
问题来了，文档的作用是什么？
笔者认为文档就是沟通的工具，无论是团队之间的沟通，还是以前的开发人员和以后的开发人员之间的沟通都属于沟通的一种，只要文档能够保证二者之间有良好的沟通那么就可以说这个文档是成功的。
