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

 

              中型规模的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 测试及修改，提高了项目效率同时也降低了发布风险，所以设计一次迭代。

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