CSDN博客

img chinapcer

毕业论文:B/S架构的OA系统的管理与研发过程(三)

发表于2004/6/13 15:57:00  3036人阅读

分类: 软件工程

1.     件过程

1.1.       软件过程模型概述

最早的软件开发,并没有很明显的过程模型,一切工作都是顺其自然的。随着人们经验的积累以及项目规模扩大的需要,人们不断地总结出各种软件过程模型,用来指导人们软件开发的过程。过程模型包括软件开发过程的规定以及相应的角色定义、制品定义。比较常见的有瀑布模型和增量模型。很多过程模型都是由这两者演化而来的。现在增量模型中的迭代的思想近乎为所有的流行过程模型所采用。这里要重点说一下瀑布模型。现在普遍认为瀑布模型已经过时,是不应采用的。其实,我觉得实际项目中,瀑布模型是非常有效的,需要去掌握。瀑布模型的优势在于符合软件开发的思维过程并且容易掌握和运用。过程模型的运用是以深刻理解为前提的,一知半解地套用模型反而会给项目带来灾难性后果。在实际的项目中,应该是借鉴某(几)个模型,结合自己团队的实际情况制定自己团队的模型。过去的项目经验看来,瀑布模型是相当不错的,但是不能单纯的使用。应该先运用增量迭代思想将项目分割成可以逐步增量的小系统(一次发布)。每次发布为一个迭代,每次迭代系统的规模和复杂度小到足以用瀑布模型来开发。

1.2.       统一过程VS敏捷过程

当前业界最有影响力的应当是统一过程模型(UP),在UP模型中,以Rational公司提出的RUP模型最有影响力,并有完善的工具支持。RUP以用例为中心,使用UML9种图形作为交流语言。RUP在项目之初就制定详尽的用例说明,并指定了很详细的计划。RUP关注文档制品,大部分的活动都产生丰富而完备的文档。RUP将系统开发分为若干次迭代,每次迭代都都包括需求、分析、设计、实现、测试等工作流。每个工作流都规定了输入制品、输出制品、参与角色、工作流的具体活动内容。RUP被称为重型软件过程模型,它包含几十个角色,上千份文档制品并和Rational的系列工具紧密结合。因此,我们在实施RUP的时候,一般都要进行删减,有选择地实施。

由于统一过程在很多时候过于烦琐,实施成本太高,并且对需求的变化反映不够敏捷,因此,敏捷过程越来越受欢迎。敏捷过程是一系列轻量的过程模型的总称,其代表是XP(极限编程)模型。敏捷过程的主要思想可以从《敏捷软件开发宣言》看出:

我们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,我们认为:

l        个体和交互      胜过  过程和工具

l        可以工作的软件  胜过  面面惧到的文档

l        客户合作        胜过  合同谈判

l        响应变化        胜过  遵循变化

虽然右项也有价值,但我们认为左项具有更大的价值。

 

在此,以最完善也最有代表性的XP来说明敏捷开发的一些做法和原则:

1.        客户作为团队成员。这样可以保证获取有效的需求。客户要能和团队一起工作。该客户必须了解该项目需求,并对项目的需求变化具有发言权。如果客户方无法一起工作,则需要找一个代替者,其需要能完整理解并表达客户的需求,比如可以是可以对客户需求负责的领域专家,可以是需求调研归来的业务分析员。

2.        使用用户素材作为记录需求的材料。用户素材记录和用户交谈的信息要点。XP不鼓励过早分析用户素材并形成格式化的需求规格说明书,因为这些工作会在需求发生变化后变成无用功

3.        短期交付。XP通过不断提交可运行的产品来增强客户的。XP每两周交付一个工作的软件版本。每次迭代中根据优先级别和依赖顺序来选择实现一一些用户素材。XP还通过发布计划来规划一个更长的周期内要实现的用户素材。

4.        结队编程。这是XP中创新的开发模式,两个共用一部机器从事编程工作。同时,每个对子是自由组合和经常变动的。这样可以促进团队成员的互相学习,并保障编码的质量。事实证明,结对编程不会降低效率。

5.        测试驱动开发。编写类时,先写这个类的测试类。这种“带着想法编程”的模式,目标非常明确,测试类调试通过的时候,目标类就编写完成并经过测试了,并且测试类还是很好的文档,它描述了类该如何使用。

6.        一起工作。项目的成员一起在一个开放的空间工作。这是保持良好沟通的保证。

7.        保持最简单的设计。能简单的事情不要复杂化。避免重复的代码,所有的代码如果出现过两次,你应该马上想到如何抽象以消除重复的代码。

8.        代码就是设计。XP认为代码就是最好的设计文档,代码比其他文档更容易说明问题。尤其是测试驱动开发模式下,测试代码就是最有价值的设计文档。其他的UML图表仅起辅助说明作用。

 

经过一段时间的实践证明,在像WebOA.NET这样的中小型项目中敏捷过程比统一过程更容易实施也更加有效。

1.3.       KIND WEBOA.NET项目的软件过程

 

每一个软件过程模型都要考虑到:方法论、文档规范、角色分工,我的做法是在项目计划中就定义了以上内容,同时编写一个软件过程说明书做详细说明。

1.3.1.  过程方法

本项目之初,制定项目计划的时候,是以统一过程为参考的,到项目过半的时候才加入敏捷过程的一些做法。同时,CMMI为确保软件的质量,提出了若干标准及建议做法,我在确定项目开发过程中的部分做法时,参考了部分这方面的内容,比如风险管理和项目汇报机制。项目的过程示意图如下:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


整个项目参考UP分为准备阶段、定义阶段、设计阶段、实现阶段、产品化阶段,将任务归为若干工作流。所有工作流分成三个集合,三条线并行。项目管理集的任务是计划和监督类工作,多为周期性任务。研发集的任务则是随着项目的进行细化的。支撑级则包含了为了确保上面两类工作顺利完成的任务。下面重点说明本项目的研发过程。

首先是需求分析,因为是产品化的项目,需求并不来自特定的客户,所以就少了需求调研,需求调研阶段安排做需求收集。需求收集完之后进行分析,将需求整理成《需求描述》和《用例规格说明书》。需求分析的过程中,会不断地对需要的技术有个大致的估计,安排技术人员对一些关键技术做预研,这个是降低风险的有效做法,也为以后的时间表的建立提供依据。需求分析完成后,进行一次评审,然后将需求分为若干子系统,进入每个子系统的迭代开发。每一次迭代中,有以下几个工作流:UI设计、架构设计、数据库设计、业务分析(类设计)、单元测试、集成测试、实现,每个工作流结束的时候都产出与一份文档并接受评审。我们采用的是UI先行的原则,UI直接对应需求,其余的工作都是为了让UI的功能实现。这样带有明确的目的性,实际上是一种模块级别的“测试驱动开发”,实践证明,是很好的方法。项目过半后,因为引入XP,所以缩短了每次迭代的周期,这让每次迭代的过程中,各工作流的时间长度都缩短到两三天,所以不再强调输出文档,而是直接对可运行的发布版本做评审。实践证明,这更有效而且节约时间,老板可以不断看到系统的进展。此外,还将单元测试和实现结合起来不做区分。

角色定义

根据本项目的人力资源特点,定义了以下的角色。

角色

工作说明

项目经理

项目管理、进度控制、软件过程指导、质量评审、制定规范

系统分析员

统筹安排需求分析、架构设计、模块设计

UI设计

表现层的设计

数据库设计

数据层的设计

配置管理员

配置管理的各项工作

开发人员

负责模块的详细设计和实现以及单元测试

文档管理员

组织编写文档,管理文档

测试经理

统筹安排测试活动

需要说明的是,角色和人员还是有很大区别的,实践经验告诉我们,角色要定义清楚,什么角色的人承担什么责任要明晰,而人员可以根据情况,身兼多角色。这个时候,一个成员扮演一种角色时,就做该角色要做的事。

1.3.2.  文档规范

本项目在整个过程中产生如下文档,大部分文档也都是迭代完成的。需要说明一点的是,文档需要标准,这个标准包括需要哪些文档,由谁完成,包含那些内容,用什么样的格式等,但是文档不一定要严格参照诸如国标之类的标准。自己制定适合自己的标准是最好的做法。

l        项目开发计划。每周计划审查后推出一个新的版本。

l        项目计划变更报告。和新的项目计划配合,对计划的变动说明原因

l        需求规格说明书。分点描述产品的功能,是结项验收的依据。

l        用例规格说明书。仔细描述系统行为,是最主要的需求材料和开发的基础

l        每日任务书。分配到每个人。(对于大的团队,可以分配到小组长)

l        项目总结报告。分为周报、月报。统计工作量和工作成果并进行评价

l        架构说明书。说明架构方式,目录组织,命名规定以及采用的平台技术,作为详细设计和实现的依据

l        结项报告。项目结束后的总结

l        模型:数据库ER图,系统的类结构图,体现系统的设计。完成时导出,让后人参考。

l        代码:代码就是设计,因此没有详细设计文档。结合类结构图,阅读代码、注释及其测试代码,就可以弄清系统的设计。

l        集成测试反馈报告。包括测试用例描述和BUG描述

l        需求变更报告。描述需求的变更提起人,变更原因,审批结果。保持一份通过审批的需求变更列表。

1.3.3.  工具与平台

本次项目采用微软的WINDOWS2000+.NET Framework1.1+SQL SERVER2000为平台,使用MS PROJECT 2000作为项目计划工具,使用CVS作为配置管理工具使用VISOR作为UML绘图工具,使用VS.NET 2002作为开发实现工具。
0 0

相关博文

我的热门文章

img
取 消
img