苦苦的搜索真正工作后开发项目流程
通过来这个论坛这么久我的收获也有很多 对JAVA方向基本有了很深刻的了解就像准备做项目前需要搭好一个有伸缩性的框架一样，剩下的就是实践中 积累经验和充实自己。
通过来这个论坛这么久我的收获也有很多 对JAVA方向基本有了很深刻的了解就像准备做项目前需要搭好一个有伸缩性的框架一样，剩下的就是实践中 积累经验和充实自己。
J2EE在国内还只是起步....理论开发流程在实际中不一定全部实现。
软件开发流程(或者说软件开发过程更术语化一点)依赖于具体的项目有所不同。我简单阐明针对技术难点不多的应用产品的一个开发过程，产品的特点在于技术难点不多，业务复杂繁多。做这类项目，主要是挖掘和理清业务需求，严谨渐进地映射到最终的实现。
一般的开发过程无外乎几个关键的开发环节：分析，设计，实现和测试。主要依据团队的开发能力和工期的要求，可以选择一次完成或者分阶段完成。
1.分析
主要生产描述业务需求的文档，规格并不重要，以描述清楚为目的。个人觉得IEEE 的软件需求说明书和TSP中的SRS都是可以作为基础的文档规格。
1.1需求说明的草稿
根据客户的描述和自已的调查，生产一份软件需求说明的草稿。采用需求特征列表（RCL）是一个可选的方式。它是仅仅只是一个简单的列表，每项包括业务需求标识，说明，需求级别，实现难度。其目的是将软件需求初步粒化描述。质量高的RCL对项目的工期预算很有帮助。
1.2化分USE CASE
根据RCL，生产USE CASE 图。整个USE CASE至少要涵盖所有的RCL的功能需求部分（系统需求部分，如性能，实现限制，物理限制之类，留在SRS里描述）。
USE CASE是用户为达到某种目的而与系统进行一系列的交互，它的定义实际上使得一个完整系统只用一个USE CASE表示也是正确的，但这对于我们挖掘整理需求没什么意义，我个人觉得USE CASE最大也只能到团队可以有共识，比如团队都比较清楚一个论坛的需求，那么，论坛可以作为USE CASE，否则只得再往下划分。
1.3conceptual use case
站在用户的角度描述use case的使用流程，只是简单的用户请求，系统响应的描述。它着重于用户会提出什么样的请求，提交什么样的数据，应该获得什么样的数据，不描述系统是如何完成的。
严谨的conceptual use case能保障严谨的test case，这些测试用例是系统级的功能测试用例。
1.4静态DEMO
conceptual use case完成后，平面设计人员就可以介入项目。如果需要，平面设计人员可以做
静压DEMO（用html可以完成browse式的客户端也可以做client式的客户端）。静态DEMO在一个平面设计要求不高和需求比较明确的项目中是不需要的。但我觉得静态DEMO是目前最有效的挖掘需求的手段，它能比较好的促进分析人员和客户代表交流，更好地整理业务流程，挖掘业务数据项，所以，一般而言，做静态DEMO是很有必要的.
1.5SRS
根据以上产品生产SRS。
虽然1.1-1.4是按时间排列的，但是它们更多而言是生产SRS的辅助手段而不是流程，换而言之，可有可无。
设计过程的最终目的是生产指导实现的规格文档，包括很多子过程，比如概要设计（也称为高层设计），基本设计，功能设计，详细设计之类的。各个公司对于它们的定义也可能不同。粗要地谈谈我对它们的理解。
2.1 概要设计（高层设计）
概要设计的目的是为了规划出逻辑层次的子系统，规划出系统的物理拓扑，因为沾了“设计”二字，所以我放在这节聊。做项目时，特别是做招标的项目，往往都把它把在分析阶段，和SRS整合成方案，仅因为为了更好地描述清楚应标方案;为了描述清楚硬件环境，得花多少银子的预算等等。
概要设计针对简单的软件系统没什么重要性，但是基于安全性，性能等原因，往往会直接影响系统的软件实现，使得部分子系统需要物理上分离。比如，用户系统单独部署在一个服务器上，user client server和admin client server部署在不同的计算机上。
2.2基本设计
仅仅只是借用这个传统的名字，实际上我个人预期这个过程产生实现单元，产生各个逻辑单元的协作关系。这也使得功能设计在这个开发过程中找不到地方体现。
2.2.1real use case
不知道如何翻译妥当，大抵上，它根据conceptual use case做进一步的工作。概念层的use case，着重于用户端，real use case着重于描述系统内部如何运作。
实际上，我们不能一步到位地构造出系统的细节逻辑单元，而且也为了不直接依赖于系统的实现机制，所以在real use case里引入三个关键单元view, control, entity。如果映射到j2ee实现框架上来讲.
view指的就是jsp，control包含了servlet(或者action)，业务对象，dao，持久化存储框架的辅助类，entity指的就是常说的po，
2.2.2静态类图
经过初步的描述real use case，析离出view,control,entity，再整合view,cotrol,entity。整合时原则上是减少逻辑单元间的通讯交叉，避免逻辑单元承担过重的任务.设计模式在这个阶段起比较重要的作用。
2.2.3协作图（顺序图）
结合静态类图和real use case，生产协作图。
2.2.4类规格
根据2.2.3可以生产类规格，它只描述对外接口，或者说是java中的public和protected方法。其中entity用于设计数据库。生产类规格时，CRC是一个记录，积累类责任的辅助方法。
在这个开发过程中基本设计对系统的设计框架和实现起决定性作用，所以需要多对2.2.1-2.2.4的产物多作分析和验证是值得的。以前做项目时，几个同事花了很多时间拿着CRC卡片象演话剧一样走业务流程，事实上也证明早期的准确，可以大大地避免后期工作的返工和混乱。
2.3 详细设计
基本设计实际没有依赖于实现技术。详细设计才开始真正依据基本设计中的协作图和类规格进行java化。
比如类的接口参数转化为java类型.视图设计引入tiles之类的。我个人觉得详细设计应该尽可能考虑private方法，主要目的是为了更好地规化出工具类。
系统的配置文件也在这个阶段规范化，比如错误验证文件，资源文件。
实现倒是没有太多聊的，如果项目团队成员相互之间并不熟悉，code review值得多太时间；一般用code review工具和核心开发人员检查或者抽查code也可以。
4 测试
如果要求比较严谨的测试，多用工具加强自动测试，虽然对起初比较花时间，但整体而言绝对省时间。不知道别人怎么看，我是一直比较怕这个过程，繁。
上面仅仅只是谈针对技术点少，业务复杂的软件系统的一个开发过程样例，也是我曾经做过的一个项目的开发过程。实际上，一个严谨的开发过程会产生很多非具体开发任务，推动这个过程得以完成，需要项目团队内划分出组长角色，配置管理角色，质量管理角色，计划管理角色等去分担这些任务。
划分开发过程的关键是项目组内能有人有效的把关过程的终结点，无论是利用规范还是自身经验和技术，否则过程只会流于形式。checklist是一种比较好的可积累方法。
取舍工具依赖于软件系统和项目团队素质，各式各类的工具：cvs,eclipse,myeclipse,strutsstudio,struts,hibernate,log4je,checkstyle,japloy,junit都是相当不错，得看自己怎样用好。装配了一些有用的plugin的eclipse比jbuilder实在好用得太多，可惜需要自已去找，而且有的是商业版本，依赖于其知名度，未必象jbuilder那样容易找到crack。