软件工程——第八章 用户界面设计(二)
若对程序进行若干次不同的功能测试，可得到一系列实验数据。
利用植入故障法估算程序中原有故障总数ET—捕获—再捕获抽样法
具体算法见笔记图片
软件配置管理
在软件建立时变更是不可避免的，因为在进行更变前没有仔细分析，或没有进行变更控制，变更加剧了项目中软件人员之间的混乱。
协调软件开发使得混乱减到最小的技术叫做配置管理。
软件配置管理的概念
软件配置管理，简称SCM，是一种“保护伞”活动，它应用于整个软件工程过程。
SCM活动的目标是为了
1、 标识变更
2、 控制变更
3、 确保变更正确的实现
4、 向其他有关的人报告变更
基线（Baseline）
基线是软件生存期中个开发阶段末尾的特定点，又称里程碑。
由正式的技术评审而得到的SCI协议和软件配置的正式文本才能成为基线。
基线的作用是把各阶段工作的划分更加明确化，以便于检验和肯定阶段成果。
项目数据库
一旦一个SCI成为基线，就把它存放到项目数据库中。
当软件组织成员想要对基线SCI进行修改时，把它从项目数据库中复制到该工程师的专用工作区中。
软件配置项SCI
软件配置管理的对象就是SCI—软件配置项。
1、 系统规格说明
2、 软件项目实施计划
3、 软件需求说明
4、 可执行的原型
5、 初步的用户手册
6、 设计规格说明
7、 源代码清单
8、 测试计划和过程、测试用例和测试结果记录
9、 操作和安装手册
10、 可执行程序（可执行程序模块、连接模块）
11、 数据库描述（模式和文件结构、初始内容）
12、 正式的用户手册
13、 维护文档（软件问题报告、维护请求、工程变更次序）
配置对象
在实现SCM时，把SCI组织成配置对象，在项目数据库中用一个单一的名字组织它们。
一个配置对象有个一名字和一组属性，并通过某些联系“连接”到其它对象。
每个对象与其它对象的联系用箭头表示。箭头指明了一种构造关系。
双向箭头则表示一种互相关系。如果对“源代码”对象做了一个变更，软件工程师就可以根据这种相互关系确定，其它哪些对象和SCI可能受到影响。
软件配置管理的任务
软件配置管理（SCM）的任务是：
标识单个的SCI
标识和管理软件各种版本
控制变更
审查软件的配置
报告所有加在配置上的变更。
配置标识
一方面随着软件生存期的向前推进，SCI的数量不断增多。
为了方便对软件配置的各个片段（SCI）进行控制和管理，不制造成混乱，首先应给它们命名。
演变图
整个软件工程过程中所涉及的软件对象都必须加以标识。
在对象成为基线以前可能要做多次变更，在成为基线之后也可能需要频繁的变更。
对于每一配置对象都可以建立一个演变图，用演变图记叙对象的变更历史。
版本管理的主要任务
集中管理档案，安全授权机制：
版本管理的操作将开发组的档案集中的存放在服务器上，经系统管理员授权给各个用户。
用户通过登入（Check In）和检出（Check out）的方式访问服务器上的文件，未经授权的用户无法访问服务器上的文件。
软件版本升级管理：
每次登入时，在服务器上都会生成新的版本。
任何版本都可以随时检出编辑，同一应用的不同版本可以像树枝一样向上增长。
变更控制
软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息。
变更控制包括建立控制点和建立报告与审查制度。
为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。这类变更必须进过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其它部分的影响。
这种变更报告和审查制度，对变更控制来说起了一个安全保证作用。
在一个SCI成为基线之前，可以对所有合理的项目和技术申请进行非正式的变更。
一旦某个SCI经过正式的技术评审并得到批准，它就成了基线。
配置状态报告
为了清楚、及时地记载软件配置的变化，需要对开发的过程做出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。
对于每一项变更，记录：发生了什么？为什么会发生？谁做的？什么时候发生的？会有什么影响？
软件的变更控制机制通常只能跟踪到工程变更顺序产生为止。为确认变更是否正确完成？一般可以用以下两种方法去审查：
正式技术评审、软件配置评审。
软件能力成熟度模型CMM
（Capability Maturity Model for Software）
CMM的特征
1、 基于实际实践
2、 最好的反映了实践的情况
3、 反映了软件过程改进和软件过程评估执行人员的需求
4、 形成的文档
5、 文档可以公开使用。
什么事CMM
软件开发机构用于定义、实施、测量、控制和改进其软件过程的一种阶段性描述，该模型使得对现有过程能力的确定，以及对软件质量和过程改进的重要问题的识别变得方便，从而为选择过程改进策略提供指南。
提高软件开发能力的手段
1、 是软件过程改进的指南，是适应软件生产过程的一个标准。
2、 以具有实践为基础。（软件工程时间的纲要）
3、 在原有软件工程基础上提出的，描述了软件过程中的关键元素。
总之，CMM除了可以用作过程改进的指南以外，还提供了一个不断发展的基础，他是一个明确的框架，可以供软件工程师使用、讨论和扩展。
CMM描述了有效地软件过程单位元的框架。
CMM为软件机构描述了从混乱的、不成熟的软件过程向成熟的、有记录的软件过程改进的一条路径。
CMM的主要用途
1、用于软件过程的评价
由一组受过训练的专业人员做出的评价，目的在于确定机构现行软件过程的状态，确定面向机构的高优先级的软极爱你过程相关问题，以确到机构对软件过程改进的支持。
2、用于软件过程的改进
CMM可以给有关过程改进的讨论提供一些启发性的议题，帮助揭示与通用软件工程实践所采用的完全不同的各种必备条件。
4、 用于软件能力的评价
由一组受过训练的专业人员做出的评价，目的在于实施软件工作的承制方的资格进行鉴别，或对现有软件工作中使用的软件过程状态进行监督。
基于CMM的估价方法
1、选择估价小组（受过CMM训练）
2、被评估单位填卷，回答评价组的问题。
3、评价组进行相应分析，明确哪些问题对，再进一步调查。
4、现场访问被评估单位。
5、提出调查清单，明确机构软件过程中的强项和弱项。（加入内险分析）
6、准备出软件关键过程域剖面图，显示机构在哪些区域已满足，那些没满足目标，向有关部门给出结论、意见。
关键过程域：
一组相互关联的活动，实现一组对建立过程能力至关重要的目标。规定每一个关键过程域属于某个成熟度级别。每个关键过程域由SEI标识为一个基本结构单元域，以帮助确定机构的软件过积能力和了解要达到软件成熟度级别所需要的过程改进。CMM的2级关键过程域包括需求管理、软件项目计划，软件项目跟踪和监督、软件分包合同管理、软件质量保证和软件配置管理。CMM的第3级关键过程域包括机构过程焦点、机构过程定义、培训大纲、综合软件管理、软件产品工程、组间协调和同行评审。第4级关键过程域包括定量过程管理和软件质量管理。第5级关键过程域包括缺陷预防、技术更新管理和过程更改管理。
IDEAL方法（软件改进方法）
CMM制订了一套描述成熟软件的特征的应用准则，供软件开发机构改进软件开发和维护的过程，或由政府或商业机构用于评估选择软件项目承制方所面临的风险。
Initiating（起始阶段）第一阶段，发起并确定软件过程改进过程改进基础设施。
Diagnosing Phase（诊断阶段）第二阶段，实施评估，确定机构的软件过程成熟度基线，向机构提出改进建议。
Establishing Phase(建立阶段)第三阶段，建立起软件过程改进基础设施，包括成立过程协同小组，定义软件过程，改进策略和目标。
Acting Phase（行动阶段）第四阶段，实施过程改进。
Leveraging Phase（推进阶段）最后阶段，分析软件过程改进中的经验教训，进一步更新软件过程改进的过程。重新发起，建立起下一个改进周期的新目标。
有关的基本概念
1、 过程：针对确定的目的所实施的序列步骤。即：为实现系统的目标所执行一系列的操作步骤。
2、 软件过程：有关开发和维护软件及其相关产品的活动、方法、实践和变换的集合。即：软件从开发到维护的一系列产品。
3、 软件过程管理：有效地管理、人、方法、工具的集成。
4、 软件过程能力：遵循某过程可能达到的预期结果的范围。
5、 软件过程性能：对实际结果的度量。
6、 软件过程熟度：
一个特定的软件过程被清晰地定义、管理、测量、控制以及有效使用的程度。程首度意味着能力证长的一种潜力，预示机构的软件过程的丰富性和他在整个机构中应用于各项目的一致性。即：一个确定的软件过程有明确的定义、评价管理达到有效地程度。
CMM的体系结构
一、 级别化
1、 初始级（软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。）
2、 可重复值（建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。
3、已定义级（已将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁得标准软件过程来开发和维护软件。）
4、以管理级（收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。）
5、优化级（过程的量化反馈和先进的新思想新技术促进过程不断改进）
二、CMM的内部结构
三、关键过程域
除了级别1，每个成熟度级别都包含几个关键过程域，一个机构应当重视这些关键过程域，以改进其软件过程。关键过程域确定了实现一个成熟级别所必须解决的问题。
每一个关键过程域都确定了一套相应的活动，完成了这些活动，就达到了被认为是对改进过程能力非常重要的一组目标。
关键过程过程域体现了该成熟度级别的要求。
关键过程域的目标总结了它的关键实践，可以用来判断一个机构或项目是否又似奥的实现了关键过程域。
关键过程域是静态的，他高层次的、抽象的描述了过程，但不说明如何执行过程。
软件过程碎成熟度级别而变化，关键过程域则稳在一个固定的成熟级别上。
四、关键实践
每一个关键过程域都用关键实践的概念进行描述。关键实践描述要做“什么”，但他们没有强行规定应当“怎样”完成目标。
没一个关键实践由一个单独的句子组成，后面常常有更详细的描述信息。
关键实践的目标在于，沟通那些在大多数项目和机构中使用的原理，沟通那些在典型的软件应用系统中发挥可作用并且能够长期发挥作用的原理。
五、共同特性
共同特性是一些属性，指明一个关键过程域的执行和制度化是否有效、可重复和可持续。
1、 执行约定：描述机构为确保过程的建立和持续而必须采取的一些措施。
2、 执行能力：描述项目或机构完整地实现软件过程所必须有的先决条件。
3、 执行活动：描述了执行一个关键过程域所必须的活动、任务和规程。
4、 测量和分析：描述了为确定与过程有关的状态所需的基本测量实践。
5、 验证时间：描述了为确保执行的活动与已建立的过程一致所采取的步骤。
机构结构和任务
1、 机构任务
负责人：在其责任范围内对实施任务和活动的人员提供技术、管理指导与控制，其职能包括职责范围内的计划、组织、指导和控制工作。
上级负责人：上级负责人是机构中足够高层的负责人，主要关注该机构的长期活动，而不是短期计划和契约性质的事务与压力。
项目负责人：对整个项目负完全责任，是指导、控制、管理和规范某个软件或软/硬件系统建设的人，是最终对客户负责的人。
2、 机构结构
机构指公司或其他实体中的一个单位，从整体上管理许多项目。
项目：是机构承担的具体任务，该任务要求对特定产品进行开发和维护，这需要机构中的各部门合作共同完成。
小组：由负责一组任务或活动的部门、负责人、人员组成。
软件工程组：负责一个项目的软件开发和维护活动的人员。
软件相关组：代表一个软件工程科目的一组人员，他们支持但不直接负责软件开发和维护。
软件工程过程组：协助对机构所使用的软件过程进行定义、维护和改进的一个专家小组。
系统工程组：负责规格说明系统需求，分配系统需求到硬件、软件和其他部件，规格说明硬件、软件和其他部件之间的软件接口，并监督对这些部件的设计和开发。
系统测试组：负责计划和实施对软件的额单独系统测试。
软件质量保证组：负责计划和实施项目的质量保证活动，确保软件开发活动遵循软件过程规程和标准。
软件配置管理组：负责计划、协调和实施项目的正规配置管理活动。
培训组：负责协调和安排机构的培训活动。