项目软件过程的迭代设计作业(案例设计)
2007-07-28 19:21
204 查看
中型规模的CRM系统
软件开发计划
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测试及修改,提高了项目效率同时也降低了发布风险,所以设计一次迭代。
最后在完成每次迭代开发过程的同时可以尽早的发现风险,降低开发成本,提高了重用程度,最终可以提高整个产品的质量。
软件开发计划
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测试,确认新系统与用户期望一致。 培训用户,制作用户手册。 最终发布,移交新系统给用户。 | 产品发布 | 产品是否通过用户评审,新系统与用户期望是否一致。 实际的开发资源消耗是否超出计划预算。 |
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测试及修改,提高了项目效率同时也降低了发布风险,所以设计一次迭代。
最后在完成每次迭代开发过程的同时可以尽早的发现风险,降低开发成本,提高了重用程度,最终可以提高整个产品的质量。
相关文章推荐
- 项目软件过程的迭代设计作业(案例设计)
- 软件过程与项目管理(第三周作业)
- 软件过程与项目管理(第七周作业)
- Android实训案例(九)——答题系统的思绪,自己设计一个题库的体验,一个思路清晰的答题软件制作过程
- 软件项目的面向对象设计、开发及管理——外企真实项目案例分析
- Android实训案例(九)——答题系统的思绪,自己设计一个题库的体验,一个思路清晰的答题软件制作过程
- 软件过程与项目管理(第六周作业)
- 软件过程与项目管理(第七周作业)
- 软件过程与项目管理(第四周作业)
- 软件过程与项目管理(作业一)
- Android实训案例(九)——答题系统的思绪,自己设计一个题库的体验,一个思路清晰的答题软件制作过程
- 软件过程与项目管理(第三次作业)
- 软件过程与项目管理(第四周作业)
- 软件过程与项目管理第一周作业
- 软件过程与项目管理(作业二)
- 软件过程与项目管理(第五周作业)
- 软件过程与项目管理(作业三)
- 软件过程与项目管理(第八周作业)
- 软件过程与项目管理(第一周作业)
- 软件过程与项目管理(第二次作业)