项目软件过程的迭代设计作业（案例设计）

 

              中型规模的CRM系统

软件开发计划

Phase

Iteration

Description

Associated Milestones

Risks Addressed

Inception Phase

（初始化阶段）

初始迭代：

需求及软件原型的建立

根据用户需求定义业务模型，使用Use-Case图定义需求及需求范围。

制订软件开发计划。

利用VB等工具制作一个系统原型。

业务模型及需求的评审

需求是否完善，是否正确。

 

软件开发计划和范围的定义是否符合实际开发计划

 

从业务模型，需求及原型评价项目的可行性，确定是否需要开发。

Elaboration Phase

（细化阶段）

E1-迭代开发：

架构的原形建立

完成这个需求的概要分析及设计。

 

设计整个软件项目的

系统架构，数据库结构。

搭建开发环境，并且建立及测试系统架构原型。 

软件架构原型的建立

架构是否清晰。

 

开发是否存在技术风险。

架构原型是否通过用户评审。

Construction Phase

（构造阶段

C1-迭代开发：

详细设计，

公共模块及接口的开发

完成整个项目的详细设计。

 

开发公共模块及各个独立模块的接口。

 

测试公共模块，各子模块接口。

详细设计

 

公共模块和各子模块接口的建立

详细设计是否遵循需求。

 

公共模块及各接口的建立是否稳定，有无技术风险。

 

 

 

C2-迭代开发：

客户信息管理子系统，订单管理子系统的开发（与C3迭代并行处理）

根据详细设计开发客户信息管理子系统，订单管理子系统。

整合该两个子系统到公共模块。

测试并生成R1-beta发布版本。

客户信息管理子系统，订单管理子系统的开发整合

 

发布第一个R1-beta版本

开发出的子系统功能是否符合需求，性能是否优越。

整合时接口是否通用，是否影响整体模块的稳定性，可靠性及整体性能。

开发进度是否有拖延，资源消耗相对计划消耗是否可以接受。

第一个BETA版本是否通过用户评审，运行是否稳定。

 

C3-迭代开发：

客户投诉处理子系统，客户满意度调查子系统，客户关怀子系统的开发（与C2并行处理）

根据详细设计开发客户投诉处理子系统，客户满意度调查子系统，客户关怀子系统。

整合该三子系统到公共模块。

测试并生成R2-beta发布版本。

客户投诉处理子系统，客户满意度调查子系统，客户关怀子系统的开发整合

 

发布第二个R2-beta版本

开发出的子系统功能是否符合需求，性能是否优越。

整合时接口是否通用，是否影响整体模块的稳定性，可靠性及整体性能。

开发进度是否有拖延，资源消耗相对计划消耗是否可以接受。

第二个BETA版本

是否通过用户评审，运行是否稳定。

Transition Phas

（移交阶段）

T1-迭代开发：

进行BETA测试，培训用户，最终发布

进行beta测试，确认新系统与用户期望一致。

培训用户，制作用户手册。

最终发布，移交新系统给用户。

产品发布

产品是否通过用户评审，新系统与用户期望是否一致。

 

实际的开发资源消耗是否超出计划预算。

 

1）在Construction Phase的三个迭代过程中会产生两个发布版本，说明如下：

R1-beta版本必须是一个完整功能的能独立运行的最小软件，它主要包含如下功能：

• 用户登入，权限控制等公共功能。
• 客户基本信息注册。
• 与数据库的接口完善。
• 可以维护客户信息，并可进行查询，修改等管理操作。
• 可以维护订单信息，并可进行下订单，修改，删除，查询等订单操作。

   R1-beta版本将会成为第一个发布的产品版本，是一个包含公共模块，客户信息管理子系

   统及订单管理子系统的全部功能的一个BETA版本。这个版本必须能通过交付测试及稳定的运行。

  

   R2-beta版本追加了以下三个子系统的功能：

• 客户投诉处理子系统
• 客户满意度调查子系统
• 客户关怀子系统

       该版本是最终发布版本的BETA版，R2-beta包含了整个需求的所有功能，并且是整合后

       的一个软件版本。通过移交阶段的BETA测试后就能成为最终的发布版本。

  

2）整个开发过程使用了6次迭代；设计原因如下：

   A．初始化阶段：设计1次迭代，因为需要多次迭代的项目符合以下范围：

1、项目规模很大，项目组很难1次迭代确定系统范围；

2、要创建的系统没有先例，很难精确描述系统功能；

3、项目涉众多且关系复杂，合同谈判艰难；

4、很难一次创建业务模型，或者在项目范围和需要的投资之间做出权衡；（例如创建新的商业应用系统）

5、存在重大技术风险，或者在向涉众申请投资前要进行可行性验证；

此项目应不属于以上范围，因此设计1次迭代。

   B．细化阶段：设计1次迭代，需要根据大众的反馈及测试情况修改系统架构，但不属于高技术风险项目，所以设计一次迭代。

   C．构造阶段：设计3次迭代，通过增量式迭代开发降低项目风险，并且在公共模块开发完成后可以并行的进行两个阶段子模块的开发，这两个并行阶段迭代开发的顺序如下：

      1，客户信息管理子系统、订单管理子系统

      2，客户投诉处理子系统、客户满意度调查子系统，客户关怀子系统

      这样的并行做法可以提高这两个迭代阶段的开发效率。

   D．发布阶段：设计1次迭代：因为在构造阶段的三次迭代中已经有发布两个BETA版本因此在最后发布阶段只需在这两个发布版本上进行BETA测试及修改，提高了项目效率同时也降低了发布风险，所以设计一次迭代。

最后在完成每次迭代开发过程的同时可以尽早的发现风险，降低开发成本，提高了重用程度，最终可以提高整个产品的质量。