关闭

一位软件工程师的软件过程总结

552人阅读 评论(0) 收藏 举报
 前言

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

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

过程分类

rup

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

Xp

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

项目过程

约束

l         每个开发人员必须将服务器上的weblogic拷贝至本地,对程序的修改基于vss在本地进行修改测试,数据库配置成开发专用数据库。

l         单元测试由开发人员自己负责,发布后的功能测试由测试组负责并将启用butterfly进行缺陷跟踪。

l         发布专用数据库由DBA单独负责。任何人不得更改。

l         开发过程中发现问题随时提出来,不要有事后诸葛亮得做法。

l         开发之前搞清楚需求,不要出现大的反工。

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

工具

ant

vss

jdk

junit

checkStyle

数据库同步脚本(刘明开发)

rational rose

visio

butterfly

核心思想

l         尽快提交版本

l         每日创建

l         持续集成

l         简单设计

l         自动化单元测试与重构

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

l         自动化检查代码规范

l         自动化生成javadoc

尽快提交版本

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

尽快提交版本包括:

l         开发人员尽快的将代码提交到配置管理开发库中,最长不能超过一天

l         开发人员提交的代码必须是编译通过的

l         开发人员本地代码与配置开发库代码尽量保持一致

每日创建保证版本的快速全编译及部署,提供测试人员测试

每日创建

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

步骤:

l         取得vss中最新源代码

l         取得vss中数据库操纵脚本并运行

l         生成ormap

l         编译最新源代码

l         停服务器

l         完全删除老系统

l         部署新系统

l         启动服务器

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

持续集成

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

简单设计

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

自动化单元测试与重构

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

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

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

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

自动化检查代码规范

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

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

自动化生成javadoc

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

对于框架稳定的软件,目前rupxp相结合的软件开发过程,整个过程经历:

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

2.         用例(素材)分析

3.         简单设计

4.         测试驱动开发

5.         重构与持续集成

6.         版本迭代

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

角色包括:

需求分析人员:确认需求,理解需求,明示需求

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

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

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

dba:数据库管理员

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

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

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

原则:

l         任务细分:细化到每个功能模块的各个阶段,包括

n         需求人员分析

n         需求人员向开发人员讲解(内部评审)

n         开发人员简单设计

n         开发人员多个版本迭代,尤其明确第一个提交测试的版本发布时间

l         责任到单个人:单人负责,杜绝多人负责同一项任务

l         明确第一个提交测试的迭代版本的时间点:明确第一个版本的发布时间至关重要,这也是测试驱动开发的起点

l         每个小版本迭代不超过一天,整个功能模块开发的迭代次数不超过一周

l         任务接受制:计划宣布,没有异议,视为接受任务,则严格按计划执行

l         计划中各任务的含义要当面说清楚,确保任务负责人明摆任务的具体含义

用例(素材)分析

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

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

l         业务逻辑分析

l         界面设计

数据库表格初步设计
 

简单设计

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

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

后置条件:

l         明确包结构

l         明确类的职责

l         明确接口定义

l         明确参数的格式定义及其内在含义

l         内部评审通过

测试驱动开发

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

前置条件:

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

后置条件:

l         根据接口定义实现JUNIT测试代码,彻底明确业务

l         在没有具体实现的条件下,搭出业务实现框架,尽快发布版本

l         实现业务逻辑,频繁运行测试程序

l         进行多次版本迭代

重构与持续集成

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

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

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

前置条件:

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

后置条件:

l         优化了程序结构

l         优化代码质量

l         修改了bug

代码review的过程
 

版本迭代

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

阶段

衡量标准

完成

确认人

周期

估计值

完成

百分比

需求确认

指根据需求文档与需求人员进行确认后,对以下内容深入理解:

1)  该业务的使用场景

2)  业务流程

3)  该业务与其他业务的关系及交互方式

4)  该业务的输入输出及业务规则或算法

设计人员

一天

10%

简单设计

指明确定义类的名称及所在包的位置,明确定义业务方法的名称及传入传出参数的类型,明确定义XML格式及数据模型。

开发人员

半天

20%

迭代版本一

指开发过程中第一次体现在每天发布的最新版本中的实现,达到前后台根据接口定义实现连通,已经完成了junit单元测试程序,但可以不包括具体的业务实现;在此版本实现的过程中,开发人员彻底明确接口的含义,并在连通过程中彻底理解业务逻辑。

测试人员

一天

40%

迭代版本二

指在迭代版本一的基础上进一步重构所得到的版本;该版本应该实现具体的业务逻辑,在正常操作的情况下能够完成业务,但在程序健壮性(如各种合法性检查)方面还相对很差。

测试人员

半天

60%

迭代版本三

指在迭代版本二的基础上进一步重构所得到的版本;该版本应该在程序健壮性方面加强,增加各种合法性检查、前后业务环节的交互等。

测试人员

半天

80%

迭代版本四

对结构进行重构,合理分配类的职责,提炼公用的类及方法等,修改bug

测试人员

半天

100%

 

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

环境:

l         开发环境:

n         客户端:rational rose2002jbuilder10eclipse30vss client

n         应用服务器:weblogic704ant16jdk13junit381checkstyle、数据库同步脚本

n         数据库服务器:开发专用数据库oracle9i

n         配置管理:vss client

l         测试环境:

n         应用服务器:weblogic704ant16jdk13junit381checkstyle、数据库同步脚本

n         数据库服务器:测试专用数据库oracle9i

l         版本数据库:

n         用于数据库脚本抽取

版本管理:

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

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

l         vss打标签,以便以后可以取到每天的版本

l         自动运行junit测试程序并生成测试报告

l         自动运行编码规范检查并生成报告

l         自动生成ormap

l         自动编译部署

l         自动完成抽取数据库脚本并迁入vss

大发布:根据发布计划,每周(假定)发布测试版本提供集成、验收测试,最好是客户人员测试。通过一套自动发布脚本完成。配置人员负责组织、汇总《版本发布说明》

相关规范及模板

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

l         ant发布脚本

l         数据库版本同步脚本

l         编码规范

l         代码格式检查模板xml

l         分析设计模板

l         项目执行规范

l         版本发布增量说明_20040916_发布人》

l         butterfly问题流转规范

l         数据库开发活动管理规范

l         其他

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:87458次
    • 积分:1353
    • 等级:
    • 排名:千里之外
    • 原创:43篇
    • 转载:39篇
    • 译文:0篇
    • 评论:6条
    文章分类
    最新评论
    ASP.NET学习