今天在看这本书

看到哪里发到哪里,果然用电脑看电子书很慢

是啊
而且电脑看书，简直对眼睛是一种折磨

月色鬼真的很勤奋涅

敲头,你才是懒惰呢,
今天有没有看书,如果不好好学习,我以后就抓只蟑螂放你衣服里

4.4.3 组织机构的独立性问题
为使那些要求独立性的关键实践得到恰当的解释和遵循，组织必须十分小心。特别对小
的项目都小的组织更是如此。当技术上或机构上的偏差可能影响有关项目的质量或风险时，
关键实践要求独立性。例如，两个涉及独立性的实践是；
?? SQA 组有～个独立于项目经理、项目软件工程组和其它软件一有关组的向高级管
理者报告的渠道（软件质量保证中的约定1．2）。
?? (统和验证）测试用例和测试规程由独立于软件开发者的测试组进行规划和准备（软
件产品工程中活动7．3）。
需要系统测试和验证测试的独立性是基于技术上的考虑。该独立性保证测试者不会受到
软件开发者或维护者所作的设计决策和实施决策的不恰当的影响。
软件质量保证组的独立性是必须的，这样才能使其成员的工作能不受进度和成本压力的
影响。没有机构上的独立性要保证有效的操作上的独立性是困难的。例如，即使存在严重的
不符合问题，一个要向项目经理报告的雇员也可能不愿意停止测试活动。
组织必须确定这样的组织机构，它将在组织的战略经营目标和经营环境的上下文中支持
要求独立性的活动，例如SQA。
独立性应该：
?? 给执行SQA 任务的个人提供组织上的自由度，使其能成为高级管理者了解项目的
“耳目”。
?? 执行SQA 任务的个人，使其免受被监督项目管理者所作的性能评价的影响，
?? 使高级管理者相信正在报告的有关项目过程和产品的信息是客观的。
由于关键实践允许对独立性准则作解释，在确定关键过程区域的目标是否已达到时组织
必须运用专业判断。

4.5 运用专业判断
使得所提供的一组完整的正确的原则能运用到广泛的情况，对某些关键实践有意阐述得
允许有灵活性。在关键实践中广泛采用了不确定的短语如“受影响的组”、“当合适时”和“当
需要时”。在关键实践中通常已经努力做到最少使用这种不确定的术语，而且在许多情况下
提供了例子，至少在策一次使用该术语时是如此。但是，对于两个不同的组织，对于同一组上，这些短语可能有不同的含义。因
此，每个项目或组织必须就其具体情况澄清这些短语。
澄清这些短语要求组织考虑使用它们时的整体的上下文。一个贴切的提问是对这样一个
短语的具体解释是否满足该关键过程区域的目标。在确定目标是否已满足时必须采用专业判
断。附录B 中的术语汇编在解释关键实践中的这些短语或其它短语时能提供指导。
当解释关键实践和它们如何对关键过程区域的目标作贡献时也必须使用专业判断。一般
讲，关键过程区域描述所有软件组织均应该具有的～组基本的行大，而不管他们的规模或他
们的产品如何。可是必须根据项目的或组织的经营环境或具体情况解释CMM 中的关键实
践。
这种解释应该既基于对CMM的深刻了解，也基于对组织和其项目的丰富知识。关键过
程区域的目标提供了构造这个解释的一个方法。如果一个组织关键过程区域的实施方法能满
足该区域的目标，但它们明显地不同于一般意义下的关键实践，那么解释的理论基础必须用
文档记载。已文档化的理论基础将帮助评估或评价组理解为什么某些实践以他们现在的方式
实施。
运用专业判断导致软件过程的“化度｛goodnes。）”问题。尽管在许多软件环境中CMM
确实建立了用于判断一个“合理”过程的最低限度的准则，但它并不对软件过程提出“优度”
要求。过程管理的目的是建立能使用的过程，并且该过程能作为基于组织的经营需求进行系
统改进的基础。
用于判断一个“合理”软件过程的准则是什么呢？一个合理的软件过程是这样的过程，
它在建立组织的能力方面是有效的，并且满足已定义过程的大多数要求。具体地讲，它是实
用的、已文档化的、已实施的、经培训的、已测量的和能改进的。
如果一个组织建立一个用于估计的软件过程，而该估计由掷骰子组成，那么它是一个合
理的过程吗？可以肯定它能文档化并得到一致遵循。某些人甚至说它和许多其它估计技术一
样实际。可是大多数软件专业人员不会认为“掷骰子”是一个合理的估计过程。因为它仅仅
遵从概率定律，它不可能被改进。
“掷骰子”和另一个过程“去问乔治”之间差别有多大？后者可能是一个非常好的估计
方法。只要乔治在周围，估计甚至是一致的和可重复的。可是它也不能满足我们的准则，因
为其它的个人不可能受到此方法的培训。这正是一个以人为中心的过程，没有乔治过程就不
可能重复。它不能建立一种前进的组织能力。
通常认为采用Delphi 方法（此方法是有关某专题的专家评审考虑中的议题，并且就有
关此议题的建议形成一致意见）的某种变形去作估计是合理的软件过程。基于DelPhi 方法
的规模估计方法满足用以判断一个合理、有效过程的准则，尽管Delnhi 方法也是一个以人
为中心的过程。组织的能力可以建立在诸如Detohi 方法等结构化技术之上。
在根本意义上说，为了作出这样的区分，专业判断是必须的。困难在于分辨出符合性和
优度。目标概括关键实践，而关键实践又描述合理的软件过程。可是符合一个合理过程并不
意味着该过程在实现其目的上是有效的。可能有许多因素影响组织和项目的成功。例如某些
成功的项目生产出的产品无人购买，这在商界是个失败。
“优度”属性只能在经营环境和具体的项目和组织情况下加以解释。只有组织能作出这
样的“优度”判断，这种判断是组织连续过程改进周期的一部分。因为永远不会实现完美元
缺，因此连续过程改进决不会终止。

等级2 关键实践

需求管理
等级2（可重复的）的一个关键过程区域

需求管理的目的是在顾客和将处理顾客需求的软件项目之间建立对顾客需求的共同理
解。
需求管理包括和顾客一起建立和维护有关软件项目需求的协议，该协议称作“分配给软
件的系统需求”。“顾客”可解释为系统工程组、销售组、另一个内部组织、或者一个外部顾
客。协议既包括技术需求、又包括非技术需求（例如交付日期）。该协议形成估计、策划和
跟踪整个软件生存周期内软件项目活动的基础。
将系统需求分配给软件、硬件和其它系统成分的工作可能由软件工程组之外的组测如系
统工程组）完成，软件工程组可能对此分配无直接控制。在项目约束范围内，软件工程组采
取恰当步骤以保证对分配给软件的需求建档、并加以控制，该组负责处理分配给软件的系统
需求。
为实现此控制，软件工程组评审初始的和经修改的分配给软件的系统需求，以便在它们
被纳入软件项目之前使问题得以解决。每当改变分配给软件的系统需求时，都要调整受
到影响的软件计划，工作产品和活动，使其与更新后的需求保持一致。

目标
目标1 分配给软件的系统需求是受控的，建立供软件工程和管理使用的基线。
目标2 软件计划、产品和活动与分配给软件的系统需求保持一致。

软件项目策划
等级2（可重复的）的一个关键过程区域
软件项目策划的目的是为完成软件工程和管理软件项目制定合理的计划。
软件项目策划包含估计待完成的工作，建立必要的约定和确定进行该工作的计划。
软件策划首先作出有关待完成的工作和其它定义及界定软件项目的约束和目标（由宪来
管理关键过程区域的实践所建立的）的陈述。软件策划过程包括以下步骤：估计软件工作产
品规模及所需的资源，制定时间表，鉴别和评估软件风险和协商约定。为了制定软件计划（即
软件开发计划），可能需要重复地通过这些步骤。
该计划提供完成和管理软件项目活动的基础，并按照软件项目的资源、约束和能力，阐
述对软件项目的顾客作的约定。
目标
目标1
对供策划和跟踪软件项目用的软件估计已建立文档。
目标2
软件项目的活动和约定是有计划的并已建立文档。
目标3
受影响的组和个人同意他们的关于软件项目的约定。
执行约定
约定1 指定项目软件经理负责协商约定和制定项目软件开发计划。
约定2 项目遵循书面的组织的用于策划软件项目的方针。
该方针一般规定：
1、配给软件的需求用作为策划软件项目的基础。
参考需求管理关键过程区域的活动2。
2、下列人员之间协商软件项目的约定：
?? 项目经理，
?? 项目软件经理，和
?? 其它的软件经理。
3、其它的工程组协商他们介入该软件活动的事宜，并记入文档。
其它工程组的例子包括：
一系统工程组，
一硬件工程组，和
一系统测试组。
4、影响的组评审软件项目的；
?? 软件规模估计，
?? 工作量和成本估计，
?? 进度，和
?? 其它约定。
受影响的组的例子有；
一软件工程组（包括所有的小组，例如软件设计小组），
一软件估计组，
一系统工程组，
一系统测试组，
一软件质量保证组，
一软件配置管理组，
一合同管理组，和
一文档支持组。
5、级管理者评审所有的对组织外部的个人和组所作的软件项目约定。
6、项目的软件开发计划进行管理和控制。
在所有这些实践中术语“软件开发计划”习惯上指的是管理软件项目的全面的计划。采
用“开发”术语并不是有意排除软件维护项目或软件支持项目，应在每个项目的上下文中恰
当地解释该术语。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备的纪律之下，正如在软件配置管理关键过程区域中所描述的。
执行能力
能力1
对软件项目存在文档化的经批准的工作陈述。
1、作陈述包括；
?? 工作的范围，
?? 技术目标和对象，
?? 对顾客和最终用户的识别，
这些实践中所指的最终用户是顾客指定的最终用户或最终用户的代表。
?? 要求实施的标准，
?? 安排的职责，
?? 成本和进度的约束及目标，
?? 软件项目和其它组织间的依赖关系。
其它组织的例子有；
一顾客，
一子承包商。和
一合资伙伴。
?? 资源限制和目标，和
?? 对开发和（或）维护的其它的约束和目标。
2、作陈述由下列人员评审；
?? 项目经理，
?? 项目软件经理，
?? 其它软件经理，和
?? 其它受影响的组。
3、工作陈述进行管理和控制。
能力2
?? 安排制定软件开发计划的职责。
1、目软件经理，直接工作或通过委托代表，协调项目的软件策划。


2、可追踪，可说明的方式分解对软件产品和活动的职责，并将其安排给软件经理。
软件工作产品的例子包括；
一适当时，交付给外部在客或最终用户的工作产品；
一供其它工程组使用的工作产品；和
一供软件工程组内部使用的主要工作产品。
能力3
为策划软件项目提供足够的资源和投资。
1、可能处，可以使用对正在策划的软件项目的应用领域有专门知识的有经验的个人来
制定软件开发计划。
2、得支持软件项目策划的工具合用。
支持工具的例子有：
一电子表格程序，
一估计模型，和
一项目策划和调度程序。
能力4 介入软件策划的软件经理、软件工程师和其它个人，在适用于其职责范围的软件
估计和策划规程方面受到培训。
执行的活动
活动1
软件工程组参加项目建议群组。
1、件工程组与下列各项工作有关：
?? 建议的准备和提交，
?? D 说明的讨论和提交，和
?? 对影响软件项目的约定作更改而进行的协商。
2、件工程组评审所建议的项目约定。
项目约定的例子包括：
一项目的技术目标和对象；
一系统和软件的技术解；
一软件预算、进度和资源；和
一软件标准和规程。
活动2
?? 在整个项目策划的早期阶段起动软件项目策划，此两项策划平行进行。
活动3
?? 在项目的整个生存期内，软件工程组和其它受影响的组一起参加整个项目的策划。
1、件工程组评审项目层的计划。
活动4
高级管理者参加按照已文档化的规程评审对组织外部的个人和组所作的软件项目约定。
活动5
识别或确定具有可管理规模的预先规定阶段的软件生存周期。
软件生存周期的例子有：
一瀑布型，
—重叠瀑布型，
一螺旋型，
—单型构造，和
—单个原型／重叠瀑布型。
活动6
?? 按照已文档化的规程制定项目的软件开发计划。
该规程一般规定：
1、件开发计划基于且遵守；
?? 顾客的标准，当合适时；
?? 项目的标准；
?? 经批准的工作陈述；和
?? 分配需求。
2、软件一有关组和其它工程组协商他们介入软件工程组活动的计划，把该项支持工作
编入预算，并对协议建立文档。
软件一有关组的例子有：
一软件质量保证组，
一软件配置管理组，和
一文档支持组。
其它工程组的例子有：
一系统工程组，
一硬件工程组，和
一系统测试组。
3、其它软件一有关组和其它工程组协商软件工程组介入其活动的计划，把该支持工作
编入预算，并对协议建立文档。
4、下列人员评审软件开发计划：
?? 项目经理，
?? 项目软件经理，
?? 其它软件经理，和
?? 其它受影响的组。
5、软件开发计划进行管理和控制。
活动7
对有关软件项目的计划建立文档。
在关键实践中，这个计划或计划的集合称为软件开发计划。
参考软件项目跟踪和监督关键过程区域的活动1 以便找到关于项目使用软件开发计划
的实践。
软件开发计划包括：
1、件项目的目的、范围、目标、和对象。
2、件生存周期的选择。
3、选的供开发和（或）维护软件用的规程、方法和标准的确定。
软件标准和规程的例子有；
一软件开发策划，
一软件配置管理，
一软件质量保证，
一软件设计，
一问题跟踪和解决，和
一软件测量。
4、开发软件工作产品的确定。
5、软件工作产品的规模估计和对软件工作产品的更改。
6、软件项目的工作量和成本的估计。
7、键计算机资源的预计使用情况。
8、件项目的进度，包括里程碑和评审的确定。
9、目软件风险的识别和评估。


。。。。。。。。。。。。。。。。。。。哥哥还在看啊？

测量与分析
测量1
进行测量并将测量结果用于确定SQA 活动的成本和进度状态。
测量的例子有：
—SQA 活动的里程碑的完成情况与计划作比较；
一在SQA 活动中所完成的工作、所化费的工作量和所消耗的资金与计划作比较；和
一产品审计和活动评审的次数与计划相比较。
验证实施
验证1
高级管理者定期参与评审SQA 活动。
高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软
件过程活动。评审间隔应该满足组织的需要，只要已存在报告例外情况的合适机制，间隔可
以长。
参考软件项目跟踪和监督关键过程区域的验证1 以便找到包括高级管理者监督评审的
典型内容的实践。
验证2
项目经理既定期地也事件驱动地参与评审SQA 活动。
参考软件项目跟踪和监督关键过程区域的验证2 以便找到包括项目管理者监督评审的
典型内容的实践。
验证3
独立于SQA 组的专家定期评审项目SQA 组的活动和软件工作产品。