苦苦的搜索真正工作后开发项目流程

CVS+开发工具Jbuilder等、集成测试等，基本就是这些流程，以前试图使用Rose来分析设计，目前真正能够将UML和代码联动进行到底的很少。

J2EE在国内还只是起步....理论开发流程在实际中不一定全部实现。

在jdon上看了段时间,牛人实在太多,益发不敢发贴,只好一直潜水,:(.看到这个贴子，手痒，打几字玩玩。

软件开发流程(或者说软件开发过程更术语化一点)依赖于具体的项目有所不同。我简单阐明针对技术难点不多的应用产品的一个开发过程，产品的特点在于技术难点不多，业务复杂繁多。做这类项目，主要是挖掘和理清业务需求，严谨渐进地映射到最终的实现。
一般的开发过程无外乎几个关键的开发环节：分析，设计，实现和测试。主要依据团队的开发能力和工期的要求，可以选择一次完成或者分阶段完成。
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.设计
设计过程的最终目的是生产指导实现的规格文档，包括很多子过程，比如概要设计（也称为高层设计），基本设计，功能设计，详细设计之类的。各个公司对于它们的定义也可能不同。粗要地谈谈我对它们的理解。
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方法，主要目的是为了更好地规化出工具类。
系统的配置文件也在这个阶段规范化，比如错误验证文件，资源文件。

3 实现
实现倒是没有太多聊的，如果项目团队成员相互之间并不熟悉，code review值得多太时间；一般用code review工具和核心开发人员检查或者抽查code也可以。

4 测试
如果要求比较严谨的测试，多用工具加强自动测试，虽然对起初比较花时间，但整体而言绝对省时间。不知道别人怎么看，我是一直比较怕这个过程，繁。

上面仅仅只是谈针对技术点少，业务复杂的软件系统的一个开发过程样例，也是我曾经做过的一个项目的开发过程。实际上，一个严谨的开发过程会产生很多非具体开发任务，推动这个过程得以完成，需要项目团队内划分出组长角色，配置管理角色，质量管理角色，计划管理角色等去分担这些任务。
划分开发过程的关键是项目组内能有人有效的把关过程的终结点，无论是利用规范还是自身经验和技术，否则过程只会流于形式。checklist是一种比较好的可积累方法。

取舍工具依赖于软件系统和项目团队素质，各式各类的工具：cvs,eclipse,myeclipse,strutsstudio,struts,hibernate,log4je,checkstyle,japloy,junit都是相当不错，得看自己怎样用好。装配了一些有用的plugin的eclipse比jbuilder实在好用得太多，可惜需要自已去找，而且有的是商业版本，依赖于其知名度，未必象jbuilder那样容易找到crack。

skyleaf24来自实践的原创，这才是高手，帮助顶一下。