前言

无论什么过程都不能适用于任何项目，我们应该根据项目的特点去选择合适的过程。只有这样才能在过程一级保证项目的成功。

地税部门对项目的组织采用rup及xp结合的方式，根据项目的特点来决定对rup及xp的侧重。但一个至高无上的目标是必须遵守的，就是以最快的速度向客户提交可执行的版本，而要做到这一点则必须坚持小步骤迭代及测试自动化。

过程分类

rup

属于重量级的开发过程，强调分析设计及迭代开发。对于研发型项目，前期没有基础，在形成稳定的框架之前应该走一段分析设计的过程。形成稳定的开发框架之后，则应该转向敏捷过程。

Xp

属于轻量级开发过程，强调重构（编程中的设计）及测试自动化。对于有一定基础的项目应该是首选。

项目过程

约束

• 每个开发人员必须将服务器上的weblogic拷贝至本地，对程序的修改基于vss在本地进行修改测试，数据库配置成开发专用数据库。
• 单元测试由开发人员自己负责，发布后的功能测试由测试组负责并将启用butterfly进行缺陷跟踪。
• 发布专用数据库由ＤＢＡ单独负责。任何人不得更改。
• 开发过程中发现问题随时提出来，不要有事后诸葛亮得做法。
• 开发之前搞清楚需求，不要出现大的反工。

每天走之前简单描述自己的当前的工作成果，发送给开发负责人并抄送项目组所有成员，作为每天的工作周报。

工具

ant

vss

jdk

junit

checkStyle

数据库同步脚本（刘明开发）

rational rose

visio

butterfly

核心思想

• 尽快提交版本
• 每日创建
• 持续集成
• 简单设计
• 自动化单元测试与重构
• 基于模型进行工作，自动化生成文档
• 自动化检查代码规范
• 自动化生成javadoc

尽快提交版本

衡量进度最直接的方法是可运行的软件。所以开发过程一个终极目标是持续快速的提交版本。开发组以最快的速度提交版本，提供测试人员进行测试。经过项目组测试人员测试的版本，同样以最快的速度提交客户测试人员进行测试。为达到这个目标，必须建立相应的机制，达到版本的快速持续发布。通过测试得到反馈，而这些反馈能够驱动开发

尽快提交版本包括：

• 开发人员尽快的将代码提交到配置管理开发库中，最长不能超过一天
• 开发人员提交的代码必须是编译通过的
• 开发人员本地代码与配置开发库代码尽量保持一致
  每日创建保证版本的快速全编译及部署，提供测试人员测试

每日创建

开发组每天的工作成果，在每天发布的版本中充分体现。每天晚上进行全版本的编译发布，第二天测试人员进行测试，将结果反馈给开发组。每日创建的实现完全基于ant实现，通过定时任务每日进行。

步骤：

1. 取得vss中最新源代码
2. 取得vss中数据库操纵脚本并运行
3. 生成ormap
4. 编译最新源代码
5. 停服务器
6. 完全删除老系统
7. 部署新系统
8. 启动服务器

详细内容参见自动发布脚本

持续集成

具备了每日创建的机制后，每天开发组完成的新功能或修改的bug将在当天晚上集成发布到测试服务器上。这样，开发组可以得到测试结果的快速反馈，又促进了下一轮的迭代。

简单设计

目前整个系统已经具备稳定的开发框架，所以我们的业务实现可以设计拖后，开始进行简单设计，明确接口及xml格式，在编程中通过重构进行设计，时刻把握一点就是最快的发布版本。

自动化单元测试与重构

为了达到最快速度的发布版本，我们可能会产生一个拙略的实现，这可以通过重构来在以后的版本中改进，当然，必须通过单元测试提供重构过程中的质量保证。

基于模型进行工作，自动化生成文档

维护模型比维护文档更轻松，在维护一致性方面也更有效。所以我们必须基于模型工作，而文档可以随时根据模板自动生成。

通过rational rose建立一套分析设计模型，将rose与vss进行集成，整个项目组可以在整个模型上进行协作。通过定义rose模板实现文档的自动化。

自动化检查代码规范

代码规范的检查我们基于checkstyle进行，目前采用的检查模板是J2EE标准模板，我们可以开发自己的模板进行检查。

Checkstyle对程序命名规范，缩进规范等，通过与ant集成可以自动化，并生成结果报告。

自动化生成javadoc

系统的接口等文档通过javadoc生成，通过ant发布脚本在每天的版本发布中可以自动生成。为了达到我们要求的格式，可以自己定义xsl样式表。

对于框架稳定的软件，目前rup与xp相结合的软件开发过程，整个过程经历：

1.发布计划、迭代计划及任务分配

2.用例（素材）分析

3.简单设计

4.测试驱动开发

5.重构与持续集成

6.版本迭代

7.配置、版本管理贯串整个过程

角色包括：

需求分析人员：确认需求，理解需求，明示需求

开发人员：设计、编码、单元测试

测试人员：功能测试，一般与需求分析人员公用，客户人员进行验收测试更佳

配置人员：开发环境的配置，包括配置管理、服务器配置等

dba：数据库管理员

发布计划、迭代计划及任务分配

发布计划：作为一次大的发布，一般给客户或测试人员一个完整的阶段性版本

迭代计划：开发组内部迭代，可以每天多次，至少每天一次

原则：

• 任务细分：细化到每个功能模块的各个阶段，包括

1. 需求人员分析
2. 需求人员向开发人员讲解（内部评审）
3. 开发人员简单设计
4. 开发人员多个版本迭代，尤其明确第一个提交测试的版本发布时间

• 责任到单个人：单人负责，杜绝多人负责同一项任务
• 明确第一个提交测试的迭代版本的时间点：明确第一个版本的发布时间至关重要，这也是测试驱动开发的起点
• 每个小版本迭代不超过一天，整个功能模块开发的迭代次数不超过一周
• 任务接受制：计划宣布，没有异议，视为接受任务，则严格按计划执行
• 计划中各任务的含义要当面说清楚，确保任务负责人明摆任务的具体含义

用例（素材）分析

用例分析部分采用rational rose，整个小组在rose模型上协同工作，共同维护模型的一致性，通过建立“单元”以及rose与vss的集成保证模型完整性及一致性。实现对需求的统一管理。通过定义rose模板，实现文档的随时自动生成。

需求人员组织内部评审时将分析的结果与开发人员进行交流，确保开发人员正确理解需求。需求人员完成的内容包括：

• 业务逻辑分析
• 界面设计
  数据库表格初步设计
  简单设计

目前开发框架基本稳定，具体业务的设计可以拖后，开发人员可以通过简单设计明确接口并快速进入版本迭代，在迭代过程中通过不断重构及持续集成来达到最佳设计。

前置条件：开发人员正确理解需求分析的结果

后置条件：

1. 明确包结构
2. 明确类的职责
3. 明确接口定义
4. 明确参数的格式定义及其内在含义
5. 内部评审通过

测试驱动开发

测试的功效在测试之外，测试优先的原则，除了在实现前先写测试能够明确业务外，还可以促使开发人员在设计结构上进一步优化。每天运行的单元测试程序还能够尽早的发现程序中的错误，避免错误曝露延后带来的维护成本，也就在开发方法上保证了效率的提高。

前置条件：

简单设计后，明确了接口定义及参数格式定义，对业务理解基本清楚

后置条件：

1. 根据接口定义实现JUNIT测试代码，彻底明确业务
2. 在没有具体实现的条件下，搭出业务实现框架，尽快发布版本
3. 实现业务逻辑，频繁运行测试程序
4. 进行多次版本迭代

重构与持续集成

重构能够改善既有代码的设计，重构的过程是设计的过程，优化的过程。

测试程序给重构提供了质量保证。

重构结果通过持续集成体现在各版本中

前置条件：

基本实现了业务框架，已经发布了第一个版本。也可以随时重构，但不能影响版本发布

后置条件：

1. 优化了程序结构
2. 优化代码质量
3. 修改了bug
   代码review的过程

版本迭代

通过版本迭代快速准确的体现目前的项目进度。给管理人员明确的进度展示。参考进度如下：

配置、版本管理贯串整个过程

环境：

1. 开发环境：
2. 客户端：rational rose2002、jbuilder10或eclipse30、vss client等
3. 应用服务器：weblogic704、ant16、jdk13、junit381、checkstyle、数据库同步脚本
4. 数据库服务器：开发专用数据库oracle9i
5. 配置管理：vss client
6. 测试环境：
7. 应用服务器：weblogic704、ant16、jdk13、junit381、checkstyle、数据库同步脚本
8. 数据库服务器：测试专用数据库oracle9i
9. 版本数据库：
10. 用于数据库脚本抽取

版本管理：

小发布：开发人员每天提交代码到vss开发库，开发环境每天集成自动发布，提供开发人员及内部测试人员测试。测试后满足需求则成为产品代码。不满足反馈开发人员修正。

每日创建脚本自动执行以下功能：

1. vss打标签，以便以后可以取到每天的版本
2. 自动运行junit测试程序并生成测试报告
3. 自动运行编码规范检查并生成报告
4. 自动编译部署
5. 自动完成抽取数据库脚本并迁入vss
   大发布：根据发布计划，每周（假定）发布测试版本提供集成、验收测试，最好是客户人员测试。通过一套自动发布脚本完成。配置人员负责组织、汇总《版本发布说明》

相关规范及模板

请参考配置库中相关规范及模板

• ant发布脚本
• 数据库版本同步脚本
• 编码规范
• 代码格式检查模板xml
• 分析设计模板
• 项目执行规范
• 版本发布增量说明_20040916_发布人》
• butterfly问题流转规范
• 数据库开发活动管理规范
• 其他