软件过程管理复习

软件过程管理简答题

1.4.实施软件过程管理并遵循过程规范的目的是什么？

答:软件过程管理可以为快速开发高质量软件、有效地维护软件运行等各类活动提供指导性框架、实施方法和最佳实践。软件过程规范可以保证过程活动的一致性、有效性和持续性。其最终目的是以低成本生产高质量的软件产品。

1.5.什么是软件过程规范，实施软件过程规范的积极作用有哪些？

答：软件过程规范是软件开发组织行动的准则与指南，可以依据上述各类过程的特点而建立相应的规范，如软件基本过程规范、软件支持过程规范和软件组织过程规范。
积极作用：
（1）帮助团队实现共同的目标
（2）一个规范的软件过程必将能带来稳定的、高水平的过程质量
（3）过程规范使软件组织的生产效率更高

1.7试分析在以下情况应该采用哪种软件过程模型进行开发，为什么？

(1)为咖啡馆开发一个付费系统。该系统使用人脸识别和触摸屏。人脸识别系统用来识别客人，然后客人可以通过触摸屏选择咖啡。最后客人离开时可以通过人脸识别身份并付账。系统需求相对清晰。
答：采用瀑布模型。
理由：项目规模小，系统需求相对清晰，变化缓慢，适合瀑布模型。

(2)为一家工厂开发一个存货控制系统。系统包含许多低耦合的子系统。客户对他们的管理熟悉并清楚知道系统需要完成什么功能。最初对系统的描述展示了一个相对较大的需求，并且有些功能并不是需要立即交付。
答：采用增量模型。
理由：系统需求相对较大，子系统间耦合较低，适合增量模型，可以逐步增加功能。

(3)客户想要开发一个房屋安全监测系统。客户认为该系统将会有很大的市场潜力并具有很高的热情。客户对软件开发并不了解，因此不能很好地描述系统。但他们有深厚的领域知识。
答：采用螺旋模型。
理由：客户不能很好地描述系统需求，系统有很大的潜力，也说明风险性高，适合螺旋模型，有效降低风险。

2.7 CMMI2级和CMMI3级关注的目标有什么不同？

CMMI2级关注项目管理，也就是目标主要针对项目，帮助你建立起项目管理的框架；而CMMI3级关注组织级，也就是公司级，在公司级建立起持续改进的框架。CMMI3级过程一般描述的比CMMI2级过程更加严格，并且CMMI3允许裁剪指南。

3.14.试述PSP、TSP以及CMMI之间的关系

答：PSP，TSP，CMMI三者相互配合，互有侧重，可以形成一个有机整体。
CMMI是过程改进的第一步，它提供了评价组织的能力、识别优先改进需求和追踪过程改进的管理方式。CMMI为企业软件过程建设与改进提供指南。企业只有实施CMMI后，才能认识到自身的不足，才能注重对员工能力的培养，合理分配项目人员，并且建立起有效的项目小组。

PSP (Personal Software Process)即个人软件过程,是一种可用于控制、管理和改进个人工作方式的自我持续改进过程。PSP帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；是实施TSP及CMMI的基础保障。

TSP（Team Software Process）即小组软件过程，是为开发软件产品的开发团队提供指导，TSP的侧重于帮助开发团队改善其质量和生产率。目标是在企业过程管理框架下，对过程标准及规范进行裁剪，在有限的资源和时间内实现项目目标。TSP是企业实施CMMI的具体体现，并将工程师的个体过程PSP融入小组软件过程。

3.5简述定义项目所用软件过程，即裁剪组织标准软件过程的流程

答：项目定义软件过程是指对项目所用软件过程的可操作的定义。项目定义软件过程是一个已很好特征化的和已理解的软件过程，用软件标准、规程、工具和方法予以描述。
裁剪组织标准软件过程的流程：
如图所示，首先通过组织标准软件过程和裁剪指南和准则进行指导，进入裁剪过程以及项目定义软件过程，反复与计划目标对比，在裁剪过程更新迭代，直至审核通过，最后实施应用与监控项目定义软件过程。

4.4简述为什么需要需求评审

(1)从成本上衡量
参加评审的各利益方需求若不明确或者不一致，需求项目将出现重大缺陷，执行风险提高，大概率失败。
(2)从技术上衡量
前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会逐渐累积，越来越多。

6.34简述项目范围的定义

对于项目来说，“范围”既可以指项目的“产品范围”，即项目业主/客户对于项目最终产品或服务所要求达到的特色和功能，也可以指项目“工作范围”，即项目团队或承包商为提交具有指定特征与功能的产品或服务所需完成的所有工作。

6.35简述三种需求收集技术

角色扮演，原型法，需求研讨会，头脑风暴，用例模型
访谈：通过当面交流和引导，获取有效信息，例如用户的痛点、用户希望解决的问题、达到什么目的等

6.36什么是确认范围，其与质量控制的关系

确认范围：正式验收已完成的项目可交付成果的过程。主要作用是，使验收过程具有客观性；同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
联系：控制质量过程一般情况下在确认范围过程之前，但两者亦可同时进行
区别：质量控制(QC)按标准检测产品，即验证产品是否符合规定要求，注重交付成果正确性，而确认范围则是注重可交付结果的验收。

6.37简述类比估算的含义及其优缺点

含义：根据以往的在同一应用领域的相似的项目来估算
将任务和与之真正相似的以往任务比较累估计完成它的成本。
成本低，耗时少，但准确性也比较低。
优点：
使用了相关的历史数据
使用简单
不需要特定的工具和培训
提供一个大概的范围估计
缺点
在项目早期要使用大的组件
大组件的历史数据有限
需要许多开发数据

6.38简述应急储备与管理储备

应急储备是包含在成本基准内的一部分预算，用来应对已经接受的识别风险，以及已经制定应急或减轻措施的已识别风险。应急储备通常是预算的一部分，用来应对那些会影响项目的“已知—未知"风险。也可以估算项目所需的管理储备。管理储备是为了管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的工作。管理储备用来应对会影响项目的“未知——未知"风险。

6.39简述质量成本的内容

质量成本包括在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求，以及因未达到要求（返工），而发生的所有成本。
质量成本分为一致性成本和非一致性成本。
为确保与要求一致而作的工作叫做一致成本，包括预防成本和鉴定成本；而以及由于不符合要求而引起的全部工作叫做不一致成本，包括故障成本（内部损失成本和外部损失成本）。

6.41简述质量保证与质量控制的区别

区别：质量控制（QC）是保证产品质量符合规定；质量保证（QA）是建立体系并确保体系按要求运作，以提供内外部的信任。QA独立于QC之外，QA审查项目的质量控制是否按照指定的体系来完成。

简述CMMI过程成熟度5个等级及特点

CMMI过程成熟度5个等级：
初始级 （L1）
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。
管理级 （L2）
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
定义级 （L3）
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
量化管理级 （L4）
分析软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
优化级 （L5）
使用过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
5个等级对应的特点：
Initial-初始级(1):过程是不可见的
Repeatable-管理级(2)：过程里程碑是可见的
Defined-定义级(3)：过程内部是可见的
Managed–量化管理级(4) ：过程可见性是定量化的
Optimizing-优化级 (5) ：可见性的更高等级，自我优化的

简述CMMI的过程域，以及如何判定某个过程域是否达到要求

（1）过程域(PA)：Process Area
简单的说就是做好一个事情的某一个方面，对应软件开发来说，就是做好软件开发的某一个方面。每个过程域都包含通用目标、通用实践和特定目标、特定实践。
（2）判定某个过程域是否达到要求的方法
每个PA包含几个目标(Goal),如果这个几个目标都达到要求了，就认为该PA达到要求了。

简述CMMI的两种表达方式

答：(1)CMMI有阶段式表示法（组织的成熟度）
CMMI过程成熟度5个等级：初始化，管理级，定义级，量化管理级，优化级。
(2)连续式表示法（组织的过程能力）
把CMMI的过程域分为4大类：支持类，工程类，项目管理，过程管理
两者有以下区别与联系：
包含的过程域相同，但是过程域分类的维度不同；
改进的路线图不同；
改进的路线图不同；
根据企业的商务需求选择不同的表示方法。

简述软件过程资产及其主要内容

答：软件过程资产可用于开发、执行和维护标准软件过程和项目定义软件过程。
软件过程资产主要包含如下内容：
（1）组织标准软件过程。
（2）软件生命周期的描述。
（3）过程剪裁指南和准则。
（4）组织软件过程数据库。
（5）软件过程的有关文档库。

简述需求的3个层次并对其进行简要说明

答：三个层次：业务需求，用户需求，功能需求
（1）业务需求（business requirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。
（2）用户需求(user requirement) 文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（user case）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。
（3）功能需求(functional requirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。