发信人: hotsale2000(流水)
整理人: leeyg(2001-01-05 11:15:02), 站内信件
|
第二节 软件项目计划
目的是制定执行软件工程和管理软件项目的合理计划。
软件项目计划包括对于要进行的工作的发展评估,确定必要的责任,详细说明进行工作的计划。
软件计划起始于陈述那些要进行的工作和其他对于软件项目(由KPA-需求管理的活动建立)进行定义和约束的限制和目标。软件计划过程包括评估软件工作产品和所需资源,制定进度表,鉴定和评估软件风险以及责任磋商。重申这些步骤也许对于制定软件项目计划(即软件开发计划)是必要的。
这一计划为执行和管理软件项目活动以及根据软件项目的资源、限制和能力对软件项目的客户定义责任提供基础。
目标
目标1 软件评估文档化以用于计划和跟踪软件项目。
目标2 计划软件项目活动和责任并文档化。
目标3 受影响的部门和个人同意与软件计划相关的责任。
行为的责任
责任 1 指派一个项目软件经理负责磋商责任和发展项目的软件开发计划。
责任 2 项目依据一个书面的组织性的原则计划软件项目。
这一原则代表性地说明了:
1. 软件方面的系统需求用于作为计划软件项目的基础。
参阅KPA(需求管理)的活动2。
2. 软件项目责任在以下部门中进行磋商:
l 项目经理
l 项目软件经理
l 其他软件经理
3. 牵涉到其他工程部门的软件活动要和这些部门进行磋商并存档。
其他工程部门的例子包括:
系统工程
硬件工程
系统测试
4. 受影响的部门审核软件项目的:
l 软件规模评估
l 努力和成本评估
l 进度表
l 其他责任
受影响的部门的例子包括:
软件工程(包括所有子部门,如软件设计)
软件评估
系统工程
系统测试
软件质量保证
软件配置管理
合同管理
文档支持
5 高级经理审核所有针对个人和机构外部的部门的软件项目责任。
6 项目软件开发计划受管理和控制。
"软件开发计划"贯穿于实践活动,指的是管理软件项目的全面计划。"开发"这一术语的运用不是要排除软件维护或支持项目,而应在特定项目的上下文中恰当阐释。
"受管理和控制"意指了解某一时期(过去或现在)的工作产品的版本(既版本控制),改动是以受控的方式并入。(既改动控制)
若要求"管理和控制"所指的更深度的控制,工作产品可被放在配置管理的全部规则之下,即如在KPA(软件配置管理)中所描述的。
行为的能力
能力 1 针对软件项目形成一个文档化并获批准的工作陈述。
1. 工作陈述包括:
l 工作范围
l 技术目标和目的
l 客户和最终用户的鉴别
这些实践中提到的最终用户是客户指明的最终用户或最终用户的代表。
l 施加的标准
l 分配的责任
l 成本,进度限制,目标
l 软件项目和其他机构间的依赖性
其他机构的例子包括:
客户
分包人(次承包商)
合资伙伴
l 资源限制和目标
l 其他开发和维护的限制和目标
2. 工作陈述由下述审核:
l 项目经理
l 项目软件经理
l 其他软件经理
l 其他受影响部门
3. 工作陈述受管理和控制
能力2 指派开发软件开发计划的责任。
1. 项目软件经理直接或经授权地协调项目软件计划。
2. 软件工作产品和活动的责任以可追溯,应负责的方式被划分和指派给软件经理。
软件工作产品的例子包括:
提交给外部客户或最终用户的工作产品;
用于其他工程部门的工作产品
用于软件工程部门内部的主要工作产品。
能力3 为计划软件项目提供足够的资源和资金。
1. 在所计划的软件项目应用领域中有专门技术的有经验的人可被用来发展软件开发计划。
2. 开发利用支软件项目活动的工具。
支持工具的例子包括:
电子数据表程序
评估模型
项目计划和进度确定程序
能力4 软件经理,软件工程师和其他与软件项目计划有关的人在软件评估和适用其各自责任区域的计划程序方面受到培训。
进行的活动
活动1 软件工程部门加入项目提议组中。
1. 软件工程部门参与:
l 提议的准备与提交
l 阐述内容的讨论与提交
l 磋商责任的修改,其修改将影响软件项目。
2. 软件工程部门审核项目被提议的责任。
项目责任的例子包括:
项目技术目标和目的
系统和软件技术的解决
软件预算,进度表和资源
软件标准和过程
活动2 软件项目计划开始于全面项目计划的初始阶段并随其同步进行。
活动3 软件工程部门在整个项目生命周期中和其他受影响的部门一起参与全面的项目计划。
1. 软件工程部门审核项目层次上的计划。
活动4 协同高级经理,根据文档化的过程审核针对个人和机构外部门的软件项目责任。
活动5 鉴别或定义软件生命周期,该周期包含预先确定的便于规模管理的发展阶段。
生命周期的例子包括:
瀑布式
重叠瀑布式
螺旋式
渐进式
单一原型/重叠瀑布式
活动6 依据一个文档化的程序制定项目软件开发计划。
这个程序代表性地指明了:
1. 软件开发计划是基于并符合:
l 客户的标准
l 项目标准
l 经批准的工作陈述
l 分配需求
2. 软件工程部门的活动中涉及到软件相关的部门和其他工程部门的计划应与这些部门进行磋商,支持活动编入预算,达成的协定文档化。
软件相关部门的例子包括:
软件质量保证
软件配置管理
文档支持
其他工程部门的例子包括:
系统工程
硬件工程
系统测试
3. 软件工程部门参与到其他软件相关部门和其他工程部门的活动的计划应与这些部门进行磋商,支持活动编入预算,达成的协定文档化。
4. 软件开发计划由下述审核:
l 项目经理
l 项目软件经理
l 其他软件经理
l 其他受影响的部门
5. 软件开发计划是受管理和控制的。
活动7 软件项目计划是文档化的。
在该主要实践中,计划或计划收集是指软件开发计划。
参阅KPA(软件项目跟踪和监管)的活动1中关于项目运用软件开发计划的实践。
软件开发计划包括:
1. 软件项目的用途,范围,目标和目的。
2. 选择一种软件生命周期。
3. 确定开发和维护软件的经选择的程序,方法和标准。
软件标准和程序的例子包括:
软件开发计划
软件配置管理
软件质量保证
软件设计
问题跟踪和解决
软件度量
4. 开展对于软件工作产品的鉴定。
5. 软件工作产品的规模评估以及对软件工作产品的任何改动。
6. 软件项目的努力和成本的预算。
7. 评估关键计算机资源的利用。
8. 软件项目的进度表,包括里程碑的鉴定和审核。
9. 项目软件风险的鉴定和评估 。
10. 项目的软件工程设备和支持工具的计划。
活动8 确定建立和维护控制软件项目所需的软件工作产品。
参阅KPA--软件配置管理的活动4。
活动9 按照文档化的程序评估软件工作产品的规模(或对软件工作产品规模的改动)。
这个程序代表性地指明:
1. 规模评估是针对所有主要的软件工作产品和活动。
软件规模度量的例子包括:
功能点
特征点
代码行
需求的数量
页数
进行规模评估的工作产品和活动的类型的例子包括:
运行软件和支持软件
可提交的及不可提交的工作产品
软件和非软件工作产品(例如文档)
开发,校验和验证工作产品的活动
2. 软件工作产品被分解为符合评估目标的粒度。
3. 在可用的地方利用历史数据。
4. 规模评估设想文档化。
5. 规模评估文档化,经审核及认同。
审核和认同规模评估的部门和个人的例子包括:
项目经理
项目软件经理
其他软件经理
活动10 按照文档化的程序预算软件项目的努力和成本。
这个程序代表性地指明:
1 评估软件项目的努力和成本与软件工作产品规模(或规模的改动)的评估相关。
2.可能的话,将生产力数据(历史和/或现在的) 用于预算。这些数据的原始资料和基本原理文档化。
l 如果可能,生产力和成本数据从机构的项目中得到。
l 生产力和成本数据要考虑到制造软件工作产品的努力和重大成本。
制造软件工作产品的重大成本的例子包括:
直接劳动费用
一般管理费用
旅行费用
计算机利用成本
3.努力,职员和成本估算是基于过去的经验。
l 如果可能,参照相似的项目。
l 活动的时间判定
l 准备软件生命周期上的努力,职员和成本估算的分配。
3. 预算及预算起源的设想文档化,经审核和认同。
活动11 按照文档化的程序评估项目的关键计算机资源。
关键计算机资源可在主机环境,整合和测试环境,目标环境或上述环境的总合中。
这个程序代表性地指明:
1. 确定项目的关键计算机资源。
关键计算机资源的例子包括:
计算机存储容量
计算机处理器
交流通道容量
2. 关键计算机资源的评估与下述评估有关:
l 软件工作产品规模
l 运行处理负载
l 流量
3. 关键计算机资源的评估文档化,经审核和认同。
活动12 按照文档化的程序制定项目软件进度。
这个程序代表性地指明:
1. 软件进度与下列有关:
l 软件工作产品规模(或规模改动)的评估
l 软件努力和成本
2. 软件进度基于过去的经验。
l 如果可能,利用相似的项目
3. 软件进度符合规定的里程碑日期,关键依赖日期和其他限制。
4. 软件进度活动有适当的持续时间,里程碑有适当的时间间隔以支持准确的进程度量。
5. 进度起源的设想文档化。
6. 软件进度文档化,经审核和认同。
活动13 鉴定,评估和文档化与成本,资源,进度和项目的技术方面相关的软件风险。
1. 基于风险对项目的潜在影响对风险进行分析和排序。
2. 鉴定风险的接触点。
接触点的例子包括:
进度缓冲器
职员更替计划
附加计算机设备的更替计划
活动14 准备关于项目软件工程设备和支持工具的计划。
1. 对于这些设备和支持工具的容量要求的估算是基于软件工作产品规模评估和其他特征。
软件开发设备和支持工具的例子包括:
软件开发计算机和外围设备
软件测试计算机和外围设备
标的计算机环境软件
其他支持软件
2. 划分和讨论责任以获得和开发这些设备和支持工具。
3. 计划由所有受影响的部门审核。
活动15 记录软件计划数据。
1. 需记录的信息包括评估和重建评估相关的信息并评定它们的合理性。
2. 软件计划数据是受管理和控制的。
度量和分析
度量1 进行度量,用于判定软件计划活动的状况。
度量的例子包括:
软件项目计划活动里程碑的完成与计划的对比,软件项目计划活动的工作的完成、花费的努力和消耗的资金与计划的对比。
验证的实施:
验证1 协同高级经理定期审核软件项目计划的活动。
高级经理定期审核的主要目的是在适当的抽象层次上及时获知和洞察软件过程活动。审核的间隔应满足机构的需要,可是长期的,只要具备足够的异议报告机制。
1. 审核技术、成本、员工和进度表的进行情况。
2. 确定在较低层次上未获解决的矛盾和问题。
3. 定义软件项目风险。
4. 分配、审核和跟踪活动项目直至完成。
5. 完成并分发每个会议的汇总报告给受影响的部门和个人。
验证 2 定期或事件驱动下协同项目经理审核软件项目计划的活动。
1. 体现出受影响的部门。
2. 根据软件项目的工作陈述和分配需求审核软件项目计划活动的状况和当前的结果。
3. 定义部门间依赖关系。
4. 确定在较低层次上未获解决的矛盾和问题。
5. 审核软件项目风险。
6. 分配、审核和跟踪活动项目直至完成。
7. 完成并分发每个会议的汇总报告给受影响的部门和个人。
验证 3 软件质量保证部门审核软件项目计划的活动和工作产品并报告结果。
参阅KPA(软件质量保证)
作为最低限度,这些审核要验证:
1. 软件评估和计划的活动。
2. 审核和制定项目责任的活动。
3. 制定软件开发计划的活动。
4. 制定软件开发计划的标准。
5. 软件开发计划的内容。
|
|