软件过程管理期末复习资料整理

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第一章过程规范
1.1软件过程
1.1.1过程
软件过程管理定义:用于软件开发及维护的一些列方法、活动及实践。

过程管理不当将导致产品质量低下、进度延误、成本高昂
过程活动由输入、输出、实施活动三个环节组成
管理的目的:最大限度的提高软件产品的质量和生产率,降低成本。

过程一般可分为:产品的实现过程、管理过程和支持过程
1.1.2软件过程的分类和组成
IEEC12007软件生命周期由三个过程:基本过程、支持过程、组织过程。

ISO/IEC15504软件过程评估标准中软件被分为5个过程:组织过程、支持过程、管理过程、工程过程、客户-供应商过程。

其中组织过程是基础、工程过程是核心、管理过程是关键。

1.1.3 软件过程定义的层次性
软件过程的层次有三个:公共软件过程、组织标准软件过程、项目自定义的软件过程1.3 软件生命周期的过程需求
1.3.1 软件工程过程
开发过程、运行过程、维护过程
1.3.2 软件支持过程
文档编制过程、配置管理过程、质量保证过程、验证过程、产品确认、联合评审、审核、解决问题
1.3.3 软件管理过程
项目管理过程、质量管理过程、风险管理过程、子合同商管理过程
1.3.4 软件组织过程
业务规划过程、定义过程、改进过程、人力资源和培训过程、基础设施过程
1.3.5 客户-供应商过程
获取过程、客户需求管理过程、供应过程、软件操作过程、客户支持过程
第二章软件过程成熟度
2.1 过程成熟度标准
2.1.1 软件过程不成熟的特点
软件过程能力是遵循软件过程所能够实现的预期结果
软件过程性能是遵循软件过程所能够实现的实际结果
软件过程成熟度是指一个具体的软件过程被明确的定义、管理、评价、控制和产生实效的程度
不成熟过程的特点软件过程能力低、过程性能的不可预见性、过程的不可视性、过程的不稳定性、过程的被动性缺乏改进的主动性
2.1.2 软件过程成熟的标准软件过程能力高、软件过程性能可预见性、软件过程规范性过程的一致性、过程的丰富性、过程的可视性、过程的稳定性、过程的不断改进
2.2 能力成熟度模型概述
CMM 的基本内容和结构成熟度等级、关键过程域、关键实践、共同特点
共同特点(关键实践的共同特点)执行约定、执行能力、执行活动、测量分析、验证实施CMMI 的组成软件系统工程集成化产品与过程开发
2.3 过程成熟度级别
初始级特点是:杂乱无章的
可重复级/受管理级特点是:对单个项目进行管理
已定义级特点是:全组织过程的管理
定量管理级/已管理级特点是:缺乏防范
优化级特点是:软件过程的持续改进
第三章软件过程的组织管理
软件过程财富:组织标准软件过程、生命周期、历史数据库、裁剪指南、软件过程文档PSP 个体软件过程
PSP成熟度模型个体度量过程、个体计划过程、个体质量管理过程、个体循环过程
TSP 团队软件过程
第四章软件过程的需求管理
4.1 需求管理的模型和流程
在软件项目的开发过程中,需求的变更贯穿了软件项目的整个生命周期
软件需求工程分为两个部分:需求开发和需求管理
业务需求高层领导
需求获取用户需求用户
需求分析功能需求开发人员
需求开发编写规格说明书
验证已建议
需求工程已批准
需求状态跟踪已实现
需求跟踪已删除
需求管理变更控制
版本控制
软件需求包括了三个不同层次:业务需求、用户需求、功能需求
软件定义产生两个文档:软件规格说明书,前期文档
4.2 需求开发
在需求获取的过程,可以采用如下的几种方法:
需求研讨会头脑风暴用例模型访谈角色扮演原型法德尔菲法
需求跟踪矩阵:正向跟踪(根据文档检查程序功能)、你想跟踪(根据程序功能查文档)合成双向跟踪
第五章软件过程的技术管理
5.1.1 软件过程的技术架构
软件过程的技术架构主要是指用于支持软件过程成功实现与过程改进的技术基础设施
5.1.2 软件过程资源的管理
软件过程技术架构的一个主要目的就是充分利用好过程中所存在的各种资源。

5.2.3 决策分析与决定
决策分析和决定的步骤
制定计划、建立评价标准、确定候选方案、评价候选方案、选择候选方案
缺陷的解决:被修正、在下一个版本中修正、不修正
发现缺陷和修复缺陷的关系:1、发现缺陷越接近水平、表示产品质量比较稳定,但不代表质量好;2、发现缺陷和修复缺陷可以辅助分析收敛趋势的变化情况,如果发现缺陷数目大于修复缺陷数,那么收敛趋势就上扬,反之就下跌。

5.4 知识的传递
纵向传递:具有很强的时间顺序的接力过程(版本..)
横向传递:是指软件产品和技术知识在不同团队之间的传递过程。

横向传递时一个实时性的过程。

第六章软件过程的项目管理
6.1 软件配置管理
6.1.1 软件配置管理(SCM)简单而言就是管理软件的变化。

基线:经过正式评审和认可的一组软件配置项,此后它们将作为下一步开发工作的基础,而且只有通过正式的变更控制流程在能被更改。

软件配置控制主要包括:(对软件的)存取控制、版本控制、变更控制和产品发布控制
存取控制:保证了软件爱你开发过程及软件产品的一致性和安全性
版本控制:记录了软件的中间状态
变更控制:位软件产品变更提供了一个明确的流程,要求任何进行配置管理的软件产品变更都要经过相应的授权与批准才能实现
产品发布的控制保证了提交给用户的软件产品是完整的、正确的。

不同的基线
6.1.3 版本控制
版本控制主要分为版本的访问与同步控制、版本的分支和合并
6.1.4 变更控制
变更控制流程主要分类七个阶段:变更请求提交、接收、评估、决策、实现、验证和完成
变更请求提交:变更申请人,日期,申请变更的内容
变更请求接收:接收请求和建议跟踪机制
变更请求评估:对变更的影响范围,严重程度、经济和技术可行性方面评估
变更请求决策:在生命周期早期:开发人员会尽力在当前版本中修复该缺陷。

在后期,开发人员可以进行评估,但是没有决策权,而是需要得到项目领导人活测试组织的批准
变更请求实现:由管理者措施制定的人员在受控的情况下进行变更
变更请求验证:由配置管理人员对变更的结果进行评价,确定变更结果是否与预期的相符并更新相关文档
变更请求完成:主要步骤是由提交请求的原有请求者中止者已循环过程
6.2 项目估算和资源管理
6.2.2 成本估算
项目的成本分为两大部分,直接成本和间接成本。

直接成本包括了工人、硬件设备、和软件等费用。

间接成本:间接陈本是由几项服务或是几个部门共同引起的成本叫做间接成本。

P136 项目成本的估算
德尔菲法:匿名发表意见,彼此之间不讨论,多次讨论,多轮发表意见
采用匿名发表意见的方式,即专家之间不得互相讨论,不发生横向联系,只能与调查人员联系;
通过多轮次调查专家对问卷所提问题的看法,经过反复征询、归纳、修改,最后汇总成专家基本一致的看法,作为预测的结果。

这种方法具有广泛的代表性,较为可靠
SWOT分析:是一种环境分析方法。

优势(Strengths);劣势(Weaknesses);竞争市场上的机会(Opportunities);威胁(Threats)
WBS工作分解表
P146 网络图、甘特图
第七章软件过程的质量管理
7.3.3 软件评审方法
1、临时评审
临时评审时最不正式的一种评审方法
2、轮查
3、走查
4、小组评审
5、审查
评审结果:接受、有条件接受、不能接受、评审未完成
对于组可能产生风险的工作成果,要采用最正式的评审方法。

对于需求分析报告,因为他的不正确和不完善会给软件的后期开发带来极大的风险,所以必须要采用最正式的评审方法,如审查或者小组评审。

又如,核心代码的失效也会带来很严重的后果,所以也应该采用最正式的评审方法或者小组评审的方法进行评审。

而一般的代码,采用同行检查或者特别检查就可以满足要求了。

P166 鱼骨图
分析鱼骨图的步骤:1、确定问题的特征;2、确定主要问题主要原因和类别;3、根据主要问题的类别确定细节原因
主要问题主要原因和类别有:5M 人力、机械、物料、方法、环境
鱼骨图又叫做因果分析图先解决小问题后解决主要问题
软件度量主要包括了3个部分的度量,项目度量、产品度量和过程度量
7.5.2 基于缺陷的质量度量
1.WTP:测试过程中发现缺陷的权重(测试小组及其他小组发现的缺陷)
2.WF:产品发布后发现缺陷的权重
3.KCSI:新增加的和修改的千行代码数
4.WTTP:测试过程中测试小组发现的缺陷权重
5.WT :测试小组发现的所有缺陷
1. 代码质量度量:
这个质量指标的值越低,说明发现缺陷越少,同时说明开发小组完成的代码质
量越高。

(WTP + WF)/ KCSI
2. 产品质量度量:
遗留给客户的缺陷的权重。

WF/ KCSI
3. 测试改进质量度量:
测试小组发现的缺陷权重和产品规模之间的关系。

WTTP/ KCSI
4. 测试效率度量
测试小组发现的缺陷和产品总缺陷的关系。

WT / (WTP + WF)
第九章软件过程的评估和改进
9.2 软件过程度量
软件过程度量分类
测试效率和缺陷数量的矩阵模型。

相关文档
最新文档