一.概述                   

软件开发过程(software development process)描述了构造、部署以及维护软件的方式。统一过程[JBR99]已经成为一种流行的构造面向对象系统的迭代软件开发过程。特别是Rational统一过程是对统一过程的详细精化，并且已经被广泛采纳。

迭代开发是软件开发过程和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期（如三个星期）小项目，称为迭代；每次迭代都产生经过测试、集成并可执行的局部系统。每次迭化都具有各自的需求分析、设计、实现和测试活动。

过程制品和时限样例（s：开始时间，r:精化时间）

二. 需求调研

(1).了解需求

人    员：

项目经理，分析员（2名），客户。

地    点：

客户办公地点。

工作要点：

着重了解客户的整体业务功能和各业务相关的部门与职务和人员信息。基本了解业务流程与主要业务要求。

文   档：

生成《需求调研表》。

规    则：

1、调研人员数量不应少于2人，在需求调研过程中应保证人员稳定性。

2、调研人员应着重了解业务的整体性，应控制客户讲述的内容。

3、调研人员应以多听少说为主。

4、调研人员应对各业务相关部门和人员都进行交流，以保证对各方面人员需求有全方面了解。

(2).需求整理

人    员：

项目经理，分析员（2名）。

地    点：

公司会议室 。

工作要点：

调研人员进行讨论，并详细整理编写《需求调研表》。划分各业务层次与业务关系，找出各业务主要相关人员与系统要求。整理各业务主流程。

文    档：

编写《需求调研表》。

规    则：

1、调研人员整理系统整体业务功能，并基本了解业务流程和业务需求重点。

2、进行讨论记录不明确的业务。

(3).需求确认

人    员：

项目经理，分析员（2员），各业务客户。

地    点：

客户办公地点。

工作要点：

向客户讲述调研人员所理解的业务和流程。由客户进行确认和补充，调研人员进行记录。客户确认后在《需求调研表》相关业务部分签字。客户非确认业务返回第2步。

文    档：

编写《需求调研表》。

规    则：

1、需求确认应有业务主要相关人员签字。

2、调研人员应多讲，让客户多了解调研人员对业务理解的正确。

3、同一业务可能需要进行多次需求确认。

三.系统分析

分析强调是的对问题和需求的调查研究，不是解决方案。例如需要一个新的在线交易系统，那么，应该如何使用它，它应该具有哪些功能？

“分析”一词含义广泛，最好加以限制，如需求分析（对需求的调查研究）或需求对象分析（对领域对象的调查研究）。

概括为：做正确的事（分析）。

在进行系统分析过程中用例分析、领域模型分析、基本路径分析、用例文档各活动应相互交差进行的，相交补充与完善的进行。

 (1).用例分析

用例就是需求，主要是说明系统如何工作的功能性或行为性需求。

人    员：

分析员（3员）

工作要点：

使用UML技术编写用例图，分析出系统用例、系统参与者和其相互之间关系。

文    档：

UML《系统用例图》。

规    则：

1、正确区分参与者，主要参与者应是直接与系统进行交互的人员。

2、系统用例是待开发系统中所有要实现的所有功能,应包括用户业务功能和系统维护功能等。

3、执行者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。

执行者要点

系统外—必须和它交互。

系统边界—责任边界，非物理边界。

有意义交互—属于目标系统的责任。

任何事物—人、外系统、外部因素、时间。

4、用例要点

价值结果—有意义的目标。

系统执行—价值结果由系统生成。

执行者可见—业务语言，用户观点。

一组用例实例—用例的料度。

 (2).领域模型分析

领域模型是对领域的概念类或现实世界的可视代表示。领域模型也称为概念模型。

人    员：

分析员（3员）

工作要点：

使用UML技术编写领域模型类图。确定与当前迭代相关的概念类。创建初始的领域模型。为模型建立适当的属性和关联。

文    档：

UML《领域模型》类图。

规    则：

       1、对现实世界的可视代表示。

(3).基本路径分析

基本路径用于描述用例的处理流程。

人    员：

分析员（3员）

工作要点：

使用UML时序图技术对每个用例进行系统流程的建模。

文    档：

UML《基本路径》

规    则：

1、主要对系统业务进行建模。

2、编写时应包括各个层次类的建模。

3、一般系统可分为三层：界面层，业务层，数据层。

(4).编写用例文档

用例文档是指对与系统用例编写的文本文档。用与补充时序图无法描述业务流程中各节点详细情况。

人    员：

分析员（3员）

工作要点：

指对每个用例图中的用例，使用文档方式详细主参与者与系统之间的交互情况。

文    档：

《用例文档》

规    则：

1、针对与系统用例图中每一个用例，都应包括一个用例文档。

2、主要用于描述人与系统间的交互过程和系统的处理结果。

3、用例文档中包括的内容有：用例编号、用例名称、执行者、前置条件、后置条件、涉众利益、基本路径、扩展路径、字段列表、业务规则、非功能需求、设计约束。

(5).编写体验界面

体验界面是系统分析基本完成后对系统界面建模。

人    员：

分析员（3员）

工作要点：

快速使用开发工具对所待开发系统的人机操作界面进行建模。用户可以通过体验界面了解到待开发系统的每个业务操作情况。

文    档：

《体验界面源代码》

规    则：

1、对系统分析的每个用户进行界面建模。

2、体验界面应包括真实系统的所有界面。

(6).用户体验调查

用户体验调查是将系统分析出各制品与用户进行交流，用户可在此阶段重新整理需求，发觉出新的潜在需求。

人    员：

项目经理、分析员（3员）

工作要点：

以用户体验界面为主，向用户介绍本系统最终可实现的功能和业务操作流程，引导用户发现法潜在需求。并对用户的反馈信息进行记录和整理。可重新对系统分析不足之处进行修改。

文    档：

《体验调查表》

规    则：

       1、对用户体验调查需要多次重复进行。

       2、详细记录用户反馈信息。

       3、对分析不足之处，需返回到以上各环节重新分析。

四.系统设计

设计强调的是满足需求的概念上的解决方案（在软件方面和硬件方面），而不是其实现。最终，设计可以实现，而实现（如代码）则表达了真实和完整的设计。

与“分析”相同，对“设计”一词最好也加以限制，如面向对象设计或数据库设计。

概括为：正确地做事（设计）。

(1).框架设计

框架设计首先决定了整个结构。

人    员：

分析员，设计员。

工作要点：

实现语言，软件分布方式，系统逻辑结构，重点技术的测试。

文    档：

《框架设计》

规    则：

1、对系统中技术可能行测试。

2、系统层次不益过多。

3、各层间交互技术应简单、稳定。

(2).类图设计

人    员：

设计员

工作要点：

以分析阶段中的类图为蓝本，从源代码实现语言出发，进行类图设计。

文    档：

UML《类图设计》

规    则：

1、对系统不同层次的类进行设计。

2、一般系统可分解成：界面层、业务层，数据层、数据控制层。

界面层：负责与用户进行交互。

业务层：负责进行用户业务操作。

数据层：系统中需要进行处理的各种信息。

数据控制层：负责对系统信息进行持久化操作。

3、近可能实现伪代码。

(4).路径设计

人    员：

设计员，测试员。

工作要点：

以分析阶段的《基本路径》为蓝本，从实现语言出发，对业务操作中类的操作流程进行设计。测试员根据操作流程编写测试用例文档。

文    档：

UML《设计路径》，《测试用例》

规    则：

       1、以实现程序流程出发进行设计。

       2、对业务中各种业务情况进行设计。

       3、测试员需编写测试用例

(5).数据库设计

人    员：

设计员

工作要点：

根据设计出的数据类图，进行数据库模型设计。

文    档：

《数据库模型》

规    则：

       1、数据库设计中各表和表关系应与类图中各类和类关系进行对映。

五.实现

 (1).开发

人    员：

程序员，设计员

工作要点：

由程序员对系统设计对各程序进行代码开发。在开发中对设计出现的最大设计问题进行修改。

第一步实现各层类接口。

第二步各层代码可同时进行开发。

第三步在代码编写过程中编写单元测试代码。

第四步进行各层单元测试。

第五步业务测试。

文    档：

       代源码

规    则：

       1、程序员与设计员协同开发，对设计问题进行修改。

需求调研表

用例文档