发信人: hotsale2000(流水)
整理人: leeyg(2001-01-05 11:11:48), 站内信件
|
Level 2(可重复级)的关键过程区域：1/7
基本的项目管理过程是为跟踪成本，进度和功能而建立的。设立必要的过程规则可实现同以前项目的成功经验相似的运用。
Level 2 的关键过程区域：
第一节 需求管理
第二节 软件项目计划
第三节 软件项目跟踪和监管
第四节 软件子合同管理
第五节 软件质量保证
第六节 软件配置管理
第一节 需求管理
目标是在客户和根据客户要求在软件项目中定义的内容之间建立一种良好的理解。需求管理包括就软件项目与客户之间达成和维持共识。这种共识被称作"软件的系统需求"。"客户"可被理解为系统工程部，市场部，另一个内部机构或外部客户.该共识同时涵盖技术和非技术（如提交日期）的需求。这种共识形成了评估、计划、实行和跟踪软件项目活动的基础，贯穿整个软件生命周期。
系统需求在软件，硬件和其他系统元素（如人力）上的分配可能是由软件工程部之外的部门执行（如系统工程部），软件工程部可不直接控制这种分配。在项目约束下，软件工程部采取适当的步骤确保控制和存档软件方面的系统需求。
为达到这一控制，软件工程部门在最初及修改过的软件方面的系统需求被纳入软件项目之前对其进行审核以解决问题。无论软件方面的系统需求何时变化，都要调整受影响的软件计划、工作产品和活动以保持与更新后的需求一致。
目标
目标1 控制软件方面的系统需求，建立一个基线用于软件工程和管理。
目标2 保持软件计划、产品和活动与软件方面的系统需求一致。
行为的责任
责任1 项目依照一个书面的组织性的原则，以管理软件方面的系统需求。
在这些实践中软件方面的系统需求被称为"分配需求"（allocated requirements）.
分配需求是系统需求的子集，在系统的软件部分中执行。它是软件开发计划中的主要部分。软件需求分析详细阐述和提炼了分配需求，结果体现为文档化的软件需求。
这一原则代表性地说明了：
1． 分配需求是文档化的；
2．分配需求由：
l 软件经理及
l 其他受影响部门
进行审核。
受影响部门的例子包括：
系统测试
软件工程（包括所有的子部门，例如软件设计）
系统工程
软件质量保证
软件配置管理
文档支持
3． 软件计划、工作产品和活动应随分配需求的变化而修改，以与其保持一致。
行为的能力
能力1 对于每个项目而言，建立分析系统需求和将其划分到硬件、软件和其他系统元素上的责任。
系统需求的分析和划分不是软件工程部的责任，但是是其工作的前提。
责任包括：
1． 在整个项目生命周期中管理和文档化系统需求及其分配。
2． 执行对系统需求及其分配的修改。
能力2 分配需求是文档化的。
分配需求包括：
1． 影响和决定软件项目的活动的非技术需求（如：协议、环境、和/或合同条款）
协议，环境和合同条款的例子包括：
要提交的产品
提交日期
里程碑
2． 软件的技术需求：
技术需求例子包括：
最终用户，操作者，支持，或整体功能
性能需求
设计约束
程序语言
界面需求
3． 用于验证软件产品是否符合分配需求的接受标准。
能力3 提供充足的资源和资金以管理分配需求。
1． 指定在应用领域和软件工程方面有经验和专门技术的人来管理分配需求。
2． 开发支持管理需求活动的工具
支持工具的例子包括：
电子数据表程序
用于配置管理的工具
用于追溯的工具
用于文档管理的工具
能力4
培训软件工程部门和其他软件相关部门的成员执行其需求管理活动。
培训的例子包括：
方法，标准，项目所用的程序
应用领域
进行的活动
活动1 软件工程部门在分配需求纳入软件项目之前审核之。
1．鉴定未完成和遗漏的分配需求。
2．审核分配需求，判断其是否：
l 具灵活性，适于在软件中执行。
l 被清晰，恰当地陈述
l 彼此一致
l 可测试
3． 协同负责分析和分配系统需求的部门，审核任何被鉴别出有潜在问题的分配需求，并进行必要的修改。
4． 就由分配需求产生的责任与受影响的部门进行磋商。
受影响的部门的例子包括：
软件工程（包括所有子部门，如软件设计）
软件评估
系统工程
系统测试
软件质量保证
软件配置管理
合同管理
文档支持
参阅 KPA（软件项目计划）的活动6 中之涉及责任磋商的实践活动。
活动2 软件工程部门以分配需求作为软件计划、工作产品和活动的基础。
分配需求：
1． 是受管理和控制的。
"受管理和控制"意指了解某一时期（过去或现在）的工作产品的版本（既版本控制），改动是以受控的方式并入。（既改动控制）
若要求"管理和控制"所指的更深度的形式,工作产品可被放在配置管理的全部规则之下，即如在KPA（软件配置管理）中所描述的。
2． 是软件开发计划的基础。
3． 是开发软件需求的基础。
活动3 审核对于分配需求的改动并纳入软件项目中。
1． 评定对现存责任的影响，讨论改动使之适当。
l 协同高级经理审核对于个人和机构的外部组织的责任的改动。
参阅KPA（软件项目计划）的活动4及KPA（软件项目跟踪和监管）的活动3中涉及机构外部责任的实践活动。
l 就对于机构内部的责任的改动与受影响的部门进行磋商。
参阅KPA（软件项目跟踪和监管）的活动5，6，7和8中涉及责任改动讨论的实践活动。
2． 对分配需求的改动带来的需要对于软件计划、工作产品和活动进行的改动是：
l 可鉴别的
l 经评估的
l 经风险评估的
l 文档化的
l 经计划的
l 与受影响部门和个人交流过的
l 跟踪执行的
度量和分析
度量 1 进行度量，用来确定管理分配需求的活动的状况。
度量的例子包括：
每个分配需求的状况；
对于分配需求的修改活动；
对于分配需求改动的累积数量，包括经提议的，未决定的，获批准的和已纳入系统基线的改动的总数。
验证实施
验证1 定期协同高级经理审核管理分配需求的活动。
高级经理定期审核的主要目的是在适当的抽象层次上及时获知和洞察软件过程活动。审核的间隔应满足机构的需要，可是长期的，只要具备足够的异议报告机制。
参阅KPA（软件项目跟踪和监管）的验证1中涉及高级经理监管审核的典型内容的实践。
验证 2 定期或事件驱动下协同项目经理审核管理分配需求的活动。
参阅KPA（软件项目跟踪和监管）的验证2 中涉及项目经理监管审核的典型内容的实践。
验证 3 软件质量保证部门审核管理分配需求的活动和工作产品并报告结果。
参阅KPA（软件质量保证）
作为最低限度，这些审核要验证：
1． 分配需求经过了审核，在软件工程部门提交之前问题得到了解决。
2． 当分配需求改动后，软件计划，工作产品和活动被相应修改。
3． 就由分配需求变化而引起的责任改动与受影响的部门磋商。
|
|