软件工程实验六Word格式.docx
《软件工程实验六Word格式.docx》由会员分享，可在线阅读，更多相关《软件工程实验六Word格式.docx（8页珍藏版）》请在冰豆网上搜索。
极限编程是一种非正式的编程方法。
在极限编程中一些管理决策权下放给小组成员。
可能出现的问题如下：
1、由于缺乏交流，会使真正的评估被隐藏。
2、项目开发前的时间将被推迟。
3、因为发生了争吵，开发该系统的方法可能被扔掉。
4、因为成员的争吵，一些不可预知的问题可能会发生。
5、因为成员缺乏沟通，系统可能中途放弃。
3结合第14章中所述气象台系统，列举在初始COCOMO估算中会产生重要影响的四个因素，并对这些因素给出可能的取值。
对于为什么考虑到这些因素进行解释。
先例的援引：
这是机构的一个新项目——取值为低（4）
开发的灵活性：
有客户介入——取值为非常低（5）
体系结构/风险解决：
没有风险分析——取值为非常低（5）
团队凝聚力：
有相关信息——取值为高
（1）
过程成熟度：
有一些过程控制——取值为一般（3）
4概述ISO9001标准和CMM软件过程模型。
ISO9001标准：
国际标准化组织（ISO）在1987年提出的概念，是指“由ISO/TC176（国际标准化组织质量管理和质量保证技术委员会）制定的国际标准。
ISO9001用于证实组织具有提供满足顾客要求和适用法规要求的产品的能力，目的在于增进顾客满意。
随着商品经济的不断扩大和日益国际化，为提高产品的信誉、维护生产者、经销者、用户和消费者各方权益,这个第三认证方不受产销双方经济利益支配，公证、科学，是各国对产品和企业进行质量评价和监督的通行证；
作为顾客对供方质量体系审核的依据；
企业有满足其订购产品技术要求的能力。
CMM软件过程模型：
能力成熟度模型（CapabilityMaturityModelforSoftware，英文缩写为SW-CMM，简称CMM）,是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
5概述CMMI软件过程改善框架。
CMMI内容分为“Required”（必需的）、“Expected”（期望的）、“Informative”（提供信息的）三个级别，来衡量模型包括的质量重要性和作用。
最重要的是"
要求"
级别，是模型和过程改进的基础。
第二级别"
期望"
在过程改进中起到主要作用，但是某些情况不是必须的可能不会出现在成功的组织模型中。
"
提供的信息"
构成了模型的主要部分，为过程改进提供了有用的指导，在许多情况下他们对需要和期望的构件做了进一步说明。
"
的模型构件是目标，代表了过程改进想要达到的最终状态，它的实现表示了项目和过程控制已经达到了某种水平。
当一个目标对应一个关键过程域，就称为"
特定目标"
；
对应整个关键过程域就称为"
公用目标"
。
整个CMMI模型包括了54个特定目标，每个关键过程域都对应了一到四个特定目标。
每个目标的描述都是非常简捷的，为了充分理解要求的目标就是扩展"
的构件。
的构件是方法，代表了达到目标的实践手段和补充认识。
每个方法都能映射到一个目标上，当一个方法对一个目标是唯一就是"
特定方法"
而能适用于所有目标时就是"
公用方法"
CMMI模型包括了186个特定方法，每个目标有两到七个方法对应。
CMMI包括了10种"
：
目的，概括和总结了关键过程域的特定目标；
介绍说明，介绍关键过程域的范围、性质和实际方法和影响等特征；
引用，关键过程域之间的指向是通过引用；
名字，表示了关键过程域的构件；
方法和目标关系，关键过程域中方法映射到目标的关系表；
注释，注释关键过程域的其他模型构件的信息来源；
典型工作产品集，定义关键过程域中执行方法时候产生的工作产品；
子方法，通过方法活动的分解和详细描述；
学科扩充，CMMI对应学科是独立的，这里提供了对应特定学科的扩展；
公用方法的详细描述，关键过程域中公用方法应用实践的详细描述。
CMMI提供了阶段式和连续式两种表示方法，但是这两种表示法在逻辑上是等价的。
我们熟悉的SW-CMM软件能力成熟模型就是是阶段式的模型，SE-CMM系统工程模型是连续式模型，而IPD-CMM集成产品开发模型结合了阶段式和连续式两者的特点
阶段式方法将模型表示威一系列"
成熟度等级"
阶段，每个阶段都有一组KPA指出一个组织应集中于何处以改善其组织过程，每个KPA用满足其目标的方法来描述，过程改进通过在一个特定的成熟度等级中满足所有KPA的目标而实现的。
连续式模型没有像阶段式那样的分散阶段，模型的KPA中的方法是当KPA的外部形式，并可应用于所有的KAP中，通过实现公用方法来改进过程。
它不专门指出目标，而是强调方法。
组织可以根据自身情况适当裁剪连续模型并以确定的KPA为改进目标。
两种表示法的差异反应了为每个能力和成熟度等级描述过程而使用的方法，他们虽然描述的机制可能不同，但是两种表示方法通过采用公用的目标和方法作为需要的和期望的模型元素，而达到了相同的改善目的。
现在CMMI面临的一个挑战就是创建一个单一的模型，可以从连续和阶段两个角度进行观察，包含相同的过程改进基本信息；
处理相同范围的一个CMMI过程能够产生相同的结论。
统一的CMMI（U-CMMI）是指产生一个只有公用方法和支持他们的KPA组成的模型。
当按一种概念性的可伸展的方式编写，并产生了用于定义组织的特定目标过程模版，定义的模版构件将定义一个模型以适用于任何工程或其他方面
6概述配置管理的基本过程和方法。
基本过程：
一个软件研发项目一般可以划分为三个阶段：
计划阶段、开发阶段和维护阶段。
然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。
项目计划阶段：
一个项目设立之初PM首先需要制定整个项研发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。
所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。
在软件配置管理计划的制定过程中，它的主要流程应该是这样的：
CCB根据项目的开发计划确定各个里程碑和开发策略；
CMO根据CCB的规划，制定详细的配置管理计划，交CCB审核；
CCB通过配置管理计划后交项目经理批准，发布实施。
项目开发维护阶段：
这一阶段时项目研发的主要阶段。
在这一阶段中，软件配置管理活动主要分为三个层面：
（1）主要由CMO完成的管理和维护工作；
（2）由SIO和DEV具体执行软件配置管理策略；
（3）变更流程。
这三个层面是彼此之间既独立又互相联系的有机的整体。
在这个软件配置管理过程中，它的核心流程应该是这样的：
（1）CCB设定研发活动的初始基线；
（2）CMO根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理就阿做好准备；
（3）开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作；
（4）SIO按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进；
（5）CCB根据项目的进展情况，审核各种变更请求，并适时的划定新的基线，保证开发和维护工作有序的进行。
这个流程就是如此循环往复，直到项目的结束。
当然，在上述的核心过程之外，还涉及其他一些相关的活动和操作流程，下面按不同的角色分工予以列出：
各开发人员按照项目经理发布的开发策略或模型进行工作；
SIO负责将各分项目的工作成果归并至集成分支，供测试或发布；
SIO可向CCB提出设立基线的要求，经批准后由CMO执行；
CMO定期向项目经理和CCB提交审计报告，并在CCB例会中报告项目在软件过程中可能存在的问题和改进方案；
在基线生效后，一切对基线和基线之前的开发成果的变更必须经CCB的批准；
CCB定期举行例会，根据成员所掌握的情况、CMO的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。
方法：
配置项配置项
配置项（SoftwareConfigurationItem，SCI）配置项
Pressman对于SCI给出了一个比较简单的定义：
“软件过程的输出信息可以分为三个主要类别：
（1）计算机程序（源代码和可执行程序），
（2）描述计算机程序的文档（针对技术开发者和用户），
（3）数据（包含在程序内部或外部）。
这些项包含了所有在软件过程中产生的信息，总称为软件配置项。
”
由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。
软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线（BaseLine）”这一概念。
IEEE对基线的定义是这样的：
“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。
所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如：
基线配置项可能包括所有的设计文档和源程序等；
非基线配置项可能包括项目的各类计划和报告等。
配置项的标识和控制
所有配置项都都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。
在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。
所有配置项的操作权限应由CMO严格管理，基本原则是：
基线配置项向软件开发人员开放读取得权限；
非基线配置项向PM、CCB及相关人员开放。
工作空间管理
在引入了软件配置管理工具之后，所有开发人员都会被要求把工作成果存放到由软件配置管理工具所管理的配置库中去，或是直接工作在软件配置管理工具提供的环境之下。
所以为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，对工作空间活动。
一般来说，比较理想的情况是把整个配置库视为一个统一的工作空间，然后再根据需要把它划分为个人（私有）、团队（集成）和全组（公共）这三类工作空间（分支），从而更好的支持将来可能出现的并行开发的需求。
每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上，例如：
对于私有开发空间而言，开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素；
而集成分支对应的是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限，它的管理工作由SIO负责；
至于公共工作空间，则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的标准版本，并作为整个组织的KnowledgeBase。
当然，由于选用的软件配置管理工具的不同，在对于工作空间的配置和维护的实现上有比较大的差异，但对于CMO来说，这些工作是他的重要职责，他必须根据各开发阶段的实际情况来配置工作空间并定制相应的版本选取规则，来保证开发活动的正常运作。
在变更发生时，应及时做好基线的推进。
版本控制
版本控制是软件配置管理的核心功能。
所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。
版本在生成过程中，自动依照设定的使用模型自动分支、演进。
除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数据（Metadata）来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。
当然如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程改进（SoftwareProcessImprovement，SPI）活动的进行。
对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。
一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。
变更控制
在对SCI的描述中，我们引入了基线的概念。
从IEEE对于基线的定义中我们可以发现，基线是和变更控制紧密相连的。
也就是说在对各个SCI做出了识别，并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就成为了软件配置管理的另一重要任务。
因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。
在本文的前面的部分中，已经把SCI分为基线配置项和非基线配置项两大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置项。
变更管理的一般流程是：
A）（获得）提出变更请求；
B）由CCB审核并决定是否批准；
C）（被接受）修改请求分配人员为，提取SCI，进行修改；
D）复审变化；
E）提交修改后的SCI；
F）建立测试基线并测试；
G）重建软件的适当版本；
H）复审（审计）所有SCI的变化；
I）发布新版本。
在这样的流程中，CMO通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建立在前文所描述的版本控制和分支策略的基础上的。
状态报告
配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况。
这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。
配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。
同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。
配置状态报告应该包括下列主要内容：
A）配置库结构和相关说明；
B）开发起始基线的构成；
C）当前基线位置及状态；
D）各基线配置项集成分支的情况；
E）各私有开发分支类型的分布情况；
F）关键元素的版本演进记录；
G）其它应予报告的事项。
配置审计
配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。
在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。
总之，软件配置管理的对象是软件研发活动中的全部开发资产。
所有这一切都应作为配置项纳入管理计划统一进行行维护和集成。
因此，软件配置管理的主要任务也就归结为以下几条：
（1）制定项目的配置计划；
（2）对配置项进行标识；
（3）对配置项进行版本控制；
（4）对配置项进行变更控制；
（5）定期进行配置审计；
（6）向相关人员报告配置的状态。
在此，我想特别指出的是：
由于软件配置管理覆盖了整个软件的开发过程，因此它是改进我们的软件过程、提高过程能力成熟度的理想的切入点。
希望本文所描述的这个软件配置管理的角色分配和工作流程能在实践中不断地得到完善，从而使我们的软件开发活动能够更加有序、高效的进行！
升级会员 