软件开发计划
V1.0
修订历史记录
日期 |
版本 |
描述 |
作者 |
---|---|---|---|
1999 年 1 月 15 日 |
1.0 |
初始版本 |
Rick Bell |
|
|
|
|
|
|
|
|
|
|
|
|
软件开发计划
本软件开发计划的目标是从实施 Wylie College 计算机方式班级注册系统所需的阶段和迭代方面,定义开发活动。
本软件开发计划描述了 Wylie College 信息系统用来为 Wylie College 开发“课程注册系统”的总计划。迭代计划中将描述各个迭代的详细信息。
本文档中概括的计划基于远景文档 [1] 中定义的产品需求。
请参阅词汇表 [4]。
适用的参考资料有:
本软件开发计划包含以下信息:
项目概述 - 提供项目目的、范围和目标的描述。它还定义了期望项目交付的工作产品。
项目组织 - 描述项目团队的组织结构。
管理流程 - 说明估价成本和日程表,定义项目的主要阶段和里程碑,并描述将如何监视项目。
技术流程计划 - 提供软件开发流程的概述,包括要遵循的方法、工具和技术。
支持流程计划 - 这包含配置管理计划。
本软件开发计划描述了 Wylie College 信息系统用来为 Wylie College 开发“课程注册系统”的总计划。迭代计划中将描述各个迭代的详细信息。
本文档中概括的计划基于远景 [1] 中定义的产品需求。
系统旨在成为 1999 年秋季学期学生注册的主要途径。因为课程注册开始于 1999 年 8 月 1 日,所以到该日期为止,系统必须完全可以使用。
以下工作产品将在项目期间产生,并交付给维护组织。
将产生其他工作产品(如项目开发案例中所述),但不打算将它们交付给维护组织。
在开始每个迭代阶段之前,将修订软件开发计划。
项目经理将提供状态评估(如本计划中所安排)给“IT 主管”项目干系人(请参阅远景 [1])。
项目团队还将联系其他项目干系人,征求他们对相关工作产品的看法和意见。
下表列出了将负责每个规程、活动和支持流程的组织单元。
角色 |
职责 |
---|---|
项目经理 |
如 Rational Unified Process [6] 中所述。负责管理总体“项目管理”规程。领导扩大的项目管理团队。 |
流程工程师 | 负责项目环境,并如 Rational Unified Process 的“环境”规程中所定义,为项目团队提供流程相关支持。参与扩大的项目管理团队。 |
配置经理/更改控制经理 | 负责项目的配置控制,并且负责执行项目中的 Wylie College 变更请求流程。参与扩大的项目管理团队。 |
系统工程团队负责人 |
领导主要负责管理“业务建模”和“需求”规程的团队。参与扩大的项目管理团队。 |
软件工程团队负责人 |
主要负责“分析与设计”和“实施”规程。参与扩大的项目管理团队。 |
测试团队负责人 |
领导负责管理“测试”规程的团队。参与扩大的项目管理团队。 |
部署团队负责人 | 领导负责最终用户环境中的安装活动和基础结构的团队。参与扩大的项目管理团队。 |
项目估计基于“课程注册系统成本模型”和分析报告 [7]。
“课程注册系统”在复杂度和体系结构方面类似于“联机库系统”(该系统由 Wylie College 于 1997 年构建)。大约 25% 的课程注册系统数据库比较复杂,而用例的数目和复杂度显示总体大约 20% 的系统比较复杂。该报告估计的时限和工时是项目预算和日程表的基础。
工作细分结构正在准备中,并且将在本文档的下一版本中提供。
将使用分阶段方法(在一个阶段中发生多个迭代)执行“课程注册系统”的开发。该计划中的阶段和迭代不重叠。下表中显示了相对时间线的摘要:
阶段 |
迭代数 |
结束 |
---|---|---|
先启阶段 |
1 |
第 7 周 |
精化阶段 |
1 |
第 14 周 |
构造阶段 |
1 |
第 19 周 |
移交阶段 |
4 |
第 32 周 |
表 4.2.1 相对时间线摘要
表 4.2.2 描述了每个阶段和标记阶段完成的主要里程碑。
阶段 |
描述 |
里程碑 |
---|---|---|
先启阶段 |
先启阶段将开发产品需求并建立“课程注册系统”的业务案例。将开发主要的用例和高级软件开发计划。在先启阶段结束时,Wylie College 将根据业务案例决定是否投资并继续完成项目。 |
阶段结束时的业务案例复审里程碑标记项目的“继续/不继续”决定。 |
精化阶段 |
“精化阶段”将分析需求并且将开发体系结构原型。完成“精化阶段”后,为 R1.0 选择的所有用例都将完成了分析和设计。另外,R2.0 的高风险用例将完成了分析和设计。体系结构原型将测试 R1.0 所需的体系结构的可行性和性能。 |
体系结构原型里程碑标记“精化阶段”的结束。该原型指示验证构成 R1.0 发行版的主要体系结构组件。 |
构造阶段 |
在“构造阶段”期间,将分析并设计其余的用例。将开发并分发 R1.0 的 Beta 版本以进行评估。将完成支持 R1.0 和 R2.0 发行版的实施和测试活动。 |
初始运行能力里程碑(Beta 的完成)标记“构造阶段”的结束。 |
移交阶段 |
将分发并评估 R1.0 的 Beta 版本。“移交阶段”将准备用于分发的 R1.0 和 R2.0 发行版。它提供必需的支持以确保顺利安装(包括用户培训)。 |
R2.0 发行版里程碑标记“移交阶段”的结束。此时,所有能力(如远景文档 [1] 中所定义)已安装并且可供用户使用。 |
表 4.2.2 项目阶段和主要里程碑
如第 4.3 节中所述,每个阶段被分成若干开发迭代。
第 4.2.4 节说明了显示阶段、迭代和主要里程碑的高级项目日程表。
每个阶段由开发系统子集的开发迭代组成。通常,这些迭代的作用是:
下表描述了迭代以及关联的里程碑和所处理的风险。
阶段 |
迭代 |
描述 |
关联的里程碑 |
处理的风险 |
---|---|---|---|---|
先启阶段 |
初步迭代 |
定义业务模型、产品需求、软件开发计划和业务案例。 |
业务案例复审 |
预先阐明用户需求。 制定务实的软件开发计划和确定范围。 从业务的角度确定项目的可行性。 |
精化阶段 |
E1 迭代 - 开发体系结构原型 |
完成所有高风险需求的分析和设计。开发体系结构原型。
|
体系结构原型 |
阐明了体系结构问题。 降低了技术风险。 用户复审的早期原型。 |
构造阶段 |
C1 迭代 - 开发 R1 Beta |
实施并测试关键的 R1 需求以提供 R1 Beta 版本。
评估发行版是否可以接受 Beta 测试。 |
初始运行能力(R1 Beta 代码完成) |
在 Beta 中实现了所有从用户和体系结构角度来看比较关键的功能部件。
|
移交阶段 |
T1 迭代 - 开发/部署 R1 发行版 |
部署 R1 Beta。 修正 Beta 的缺陷并加入对 Beta 的反馈。
实施并测试其余 R1 需求。 封装、分发和安装 R1 发行版。 充分描述了其余的低风险 R2 用例。 |
R1 Beta 测试完成
R1 代码完成
R1 产品发行版 |
R1 发行之前的用户反馈。
产品质量应当很高。 缺陷已最小化。 降低了质量成本。 分两个阶段的发行使缺陷最小化。 分两阶段的发行让用户可以轻松地转换。 用户群充分复审了 R1。 |
|
T2 迭代 - 开发 R2 内部 1 |
设计、实施和测试 R2 内部 1 需求。 加入 R1 的增强功能和缺陷。 部署 R2 内部 1。 |
R2 内部 1 测试完成 |
如果需要,可发行 R2 内部 1 以解决 R1 缺陷,来帮助提高客户满意度。 |
|
T3 迭代 - 开发 R2 内部 2 |
设计、实施和测试 R2 内部 2 需求 加入 R2 内部 2 的增强功能和缺陷。 部署 R2 内部 2。 |
R2 内部 2 测试完成 |
用户群非正式地复审了 R2 内部 1。
如果需要,可发行 R2 内部 1 以解决 R1 缺陷,来帮助提高客户满意度。 |
|
T4 迭代 - 开发/部署 R2 发行版 |
封装、分发和安装 R2 发行版。 |
R2 代码完成
R2 产品发行版 |
用户群非正式地复审了 R2 内部 2。 分两阶段的发行让用户可以轻松地转换。 |
本软件开发计划处理“课程注册系统”的前两个发行版。远景文档 [1] 中定义的主要功能部件是前两个发行版的目标。对于学生注册至关重要的所有功能部件是计划在第一个发行版(R1.0)中实现的。
这些发行版的规划内容应当随着项目的进展而发生变化。这可能是一些业务和技术因素所引起的。为了容纳这些变化,Rational RequisitePro 将用于管理产品需求,同时跟踪发行版内容。特别是使用“益处”、“工时”和“风险”属性确定产品需求的优先级,继而确定目标发行版。
预计“课程注册系统”在经过 2-4 个主要发行版后,将发行供 Wylie College 广泛使用。
R1 必须包含和下面列出的一样少的基本功能:
R2 应当包含:
尚未确定 R3 的功能。预计该发行版将包含对现有功能的增强。
计划以后在 2005 年的 R4 中替换旧的计费系统和课程数据库系统。
另外,Beta 发行版将在 R1.0 产品发行版之前产生,并且将包含所有的关键 R1 功能。Beta 发行版将象实际系统一样进行部署,不同的只是它将与隔离开的现有旧系统副本交互作用,从而避免对现有系统造成损坏。然后将请求一组选出的学生和教员正式评估 Beta 版。
此外,将有内部发行版,以维持正常的工作秩序来帮助使项目保持在正轨上,并允许初始发行版之后有其他发行版(如果需要)。学生和教员可以非正式地复审内部发行版。下面为每个内部发行版提供了目标的简要描述:
尚未确定 R3 的功能。预计该发行版将包含对现有功能的增强。
计划以后在 2005 年的 R4 中替换旧的计费系统和课程数据库系统。
显示项目阶段、迭代和里程碑的高级日程表包含在下面显示的“课程注册高级项目日程表”[5] 中。
|
第 8.1 节的“组织图表”中确定的 IT 员工被分配给项目。在先启阶段结束时复审了业务案例并且作出项目“继续/不继续”决定之后,才会补充配备资源。
测试组织将依靠软件工程组织的支持,如组织图表中的虚线所示。
Wylie College IT 部门没有足够的开发人员和设计人员来满足项目需求。Wylie College 招聘办公室准备招聘 1 名有多年 C++ 经验的高级开发人员、1 名有经验的系统集成人员和 2 名有至少一年 C++ 经验的实施人员/测试人员(初级水平)。
在开始设计活动之前,将实施对项目团队以下技能的培训:
项目预算基于初始评估
请参阅“课程注册系统 E1 迭代计划”[11]。
在远景 [1] 和项目干系人请求 [3] 文档中记录了此系统的需求。
项目经理维护记录每个里程碑的期望日期的总日程表,并且如报告计划中所述,以它作为状态评估报告的一部分。状态评估报告提供给 IT 主管,可用来设置新的优先级或者建议更正操作。
总日程表是从团队经理维护的详细日程表得出的。详细日程表中的项目是分配给个人的工作包。分配到工作包的每个人每周向他/她的团队经理提供完成百分比信息。
开支由项目经理监视,并且通过状态评估报告进行报告并评估。
所有工作产品都要求通过适当的复审流程。要求复审是为了确保每个工作产品根据 Rational Unified Process [6] 复审准则中描述的准则和核对表,都具备可接受的质量。
另外,将记录和跟踪缺陷,并且将如 Wylie 软件流程 Web 站点 [10] 上所述,收集缺陷数据。
项目经理将每月至少准备状态评估报告一次。这包括:
- 更新的成本和日程估计
- 数据摘要
如 Wylie College 软件流程 Web 站点 [10] 所述,标准项目度量数据将收集并包含在状态评估报告中。
请参阅“课程注册系统风险列表”[8]。
日程表将显示人员向其他项目的逐渐转出。在交付系统后,IT 部门将至少保留一个兼职的开发人员,以提供系统的维护。
一份事后总结报告将提交给 IT 主管,总结所学习的经验,包括对实际/预测成本和日程表的评估。
请参阅“课程注册系统开发案例”[9]。
请参阅“Wylie College 软件流程 Web 站点”[10]。
N/A
N/A
请参阅“Wylie 软件流程 Web 站点”[10]。
不适用。
不适用。
不适用。