《软件过程与管理》复习

admin管理员组

文章数量:1794759

《软件过程与管理》复习

《软件过程与管理》复习

1 高质量编程及测试

1.1 如何选择正确的评审方法

选择评审方法最有效的标准是： “对于最可能产生风险的工作成果，要采用最正式的评审方法.”

例如：核心代码的失效也会带来很严重的后果，所以也应该采用审查或小组评审的方法进行评审，而一般的代码，则可以采用临时评审、同桌评审等比较随意的评审方法。

1.1.1 代码审查

代码审查的目的是检查源程序编码是否符合详细设计的编码规定,确保编码与设计的一致性和可追踪性。

1.1.2 静态分析

静态分析的目的是通过对源程序分析、目测,但不执行程序,找出源代码中可能的错误和缺陷,对程序设计的结构属性如:分支、路径、转移等进行审查,尽可能的掌握源程序的结构,为单元测试设计测试用例和进行单元测试提供信息。

1.1.3 代码走查

走查(walkthrough)是一种使用静态分析方法的非正式评审过程；走查过程是让与会成员充当计算机,由被指定作为测试员的小组成员提出一批测试实例,在会议上对每个测试实例用头脑来执行程序,在纸上或黑板上监视程序的状态(即变量的值)；

1.2 软件测试目标

由于软件开发人员思维上的主观局限性,且目前开发的软件系统都具有相当的复杂性, 决定了在开发过程中出现软件错误是不可避免的,软件过多的或严重的错误会导致程序或系统的失效。

1.2.1 软件错误产生的主要原因

1. 需求规格说明书(requirement specification or functional specification)包含错误的需求、或漏掉一些需求,或没有准确表达客户所需要的内容；
2. 需求规格说明书中有些功能不可能或无法实现的； 系统设计(system design)中的不合理性 ；
3. 程序设计中的错误、程序代码中的问题,包括错误的算法、复杂的逻辑等。

1.2.2 软件测试的目的

1. 软件测试是为了发现错误而执行程序的过程；
2. 一个好的测试能够在第一时间发现程序中存在的错误；
3. 一个好的测试是发现了至今尚未发现的错误的测试。

2 高质量需求与设计

2.1 需求变更控制

变更控制

访问控制和汇入控制

需求变更处理流程

3 软件配置管理

3.1 基线

3.1.1 基线定义

IEEE对基线的定义: 已经正式通过复审核批准的某规约或产品,它因此可作为进一步开发的基础,并且只能通过正式的变更控制过程进行改变。 基线是软件生存期各开发阶段末尾的特定点，也称里程碑。

常用软件基线

3.1.2 软件过程中配置基线

3.2 软件配置管理10个核心活动

1. 建立配置管理组织
2. 确定配置策略
3. 制定配置管理计划
4. 配置项标识
5. 版本控制
6. 配置项和基线管理
7. 变更控制
8. 配置状态报告
9. 配置审核
10. 发布及交付管理

4 软件评审

4.1 为什么需要评审?

4.1.1 从成本上来衡量

缺陷发现得越晚纠正费用越高，而软件评审的重要目的就是通过软件评审尽早的产品中的缺陷，减少大量的后期返工。

4.1.2 从技术上来衡量

前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会逐渐累积，越来越多。

4.2 管理评审

4.2.1 管理评审的内容

对质量体系进行回顾和总结并确保其适宜性、有效性和充分性

4.2.2 管理评审的流程

管理评审是以实施质量方针和目标的质量体系的适应性和有效性为评价基准,对体系文件的适应性和质量活动的有效性进行评价。 “由最高管理者就质量方针和目标，对质量体系的现状和适应性进行正式评价。”

4.3 评审方法

4.4 评审结果

• 接受：评审内容不存在大的缺陷，可以通过。
• 有条件接受：评审内容不存在大的缺陷，修订其中的一些小缺陷后，可以通过。
• 不能接受：评审内容中有较多的缺陷，作者需要对这些缺陷进行修改，并在修改之后重新进行评审。
• 评审未完成：由于某种原因，评审未能完成，还需要后续会议。

5 软件质量保证

5.1 组织结构

SQA组织模型：独立的SQA部门，独立的SQA工程师，独立的SQA小组

5.1.1 独立的SQA部门

在整个企业的组织结构中设立一个独立的职能/行政部门SQA部门，与其他职能部门平级，又称职能型组织结构。

5.1.2 独立的SQA工程师

又称项目型组织结构，这种模式 以项目为主体进行运作，在每个项目中都设立有专门的SQA岗位。SQA工程师属于项目组成员，向项目经理汇报。

5.1.3 独立的SQA小组

由独立的SQA工程师构成SQA小组，该组织是上述两种组织结构的综合结果。从职能/行政结构上说，创建了独立的SQA小组。该结构综合前面两种结构优点，既便于SQA融入项目组，又便于部门之间经验的分享，还利于SQA能力的提高。

5.2 SQA组织的目标和责任

5.2.1 组织级SQA

组织级SQA：文档化的过程描述/开发标准/规程/模板 通常由质量组织SEPG（软件工程过程组）预先定义好，供各个项目使用、定制

5.2.2 项目级SQA

项目级SQA：保证所定义的流程被正确的执行。 SQA计划、SQA审计和评审、SQA度量、评估和过程改进、SQA报告等跟随软件开发过程例行开展。

5.2.3 SQA质量保证过程

5.3 纠正措施&预防措施的区别

纠正措施指的是为消除已发现的不合格或其他潜在不期望情况的原因所采取的措施。 预防措施指的是消除潜在的不合格或其他潜在不期望情况的原因所采取的措施。

5.4 软件质量改进

5.4.1 QCC（Quality Control Circle）品管圈

QCC（Quality Control Circle）品管圈，由石川馨提出。由员工自发组成一个Group，旨在发现并解决日常工作中质量问题。

• 全员普遍具备质量改进意识。
• 多数员工掌握一定的质量工具和质量管理手法。
• 组织支持。例：QCC辅导员、提供相关培训。
• IT支持。运用IT工具对改进活动过程管理。

实施过程：

5.4.2 漏测问题分析

漏测试问题: 软件产品缺陷没有在测试过程中尽早被发现

漏测问题分析过程

漏测试问题识别：改进过程的现状分析，确认改进 范围。

判断是否遗留bug依据

分析漏测原因：对测试过程进行回放，结合测试过程及输出的记录情况，判断测试流程哪一步的原因导致的漏测。

改进措施示例:

• 更新测试用例。例：测试用例增加验证点。
• 输出测试经验。例：补充测试案例、添加到测试经验库。
• 提高测试技能。例：进行相关测试技能培训。
• 改进测试工具。例：增加对日志的自动化验证功能。
• 改进测试流程。例：修改测试方案模板，增加观察点分析。

5.4.3 质量回溯

质量回溯：指从产品质量问题的现象出发，一步步地向上追踪问题的发生过程，找到导致问题的根本原因，并针对问题根因采取改进措施。

1.问题定位与处理 描述问题发生–定位–处理的完整过程 2.根因分析 首先确认问题的根源对象，明确缺陷引入点和缺陷控制点；然后分别进行根因分析，从技术根因、认为根因和管理根因三方面展开分析，列出可能的原因以及各种原因之间的可能关系。根因分析工具因果图、5WHY法等。 3.改进措施 对于改进措施，除了纠正措施外，更多考虑预防措施。

6 软件质量度量

6.1 软件过程质量度量-测试阶段的过程质量度量

【案例】某项目在测试阶段收集到数据，请分析测试过程质量。

测试用例的深度TCD =100/(10000/1000)=10(个/LOC) 测试用例发现缺陷TCQ =10/50=20% 百用例发现缺陷问题数 =10/(100/100)=10(个) 缺陷密度 =50/(10000/1000)=5(个/LOC)

6.2 软件产品规模与复杂度度量-PertSizing估计方法

也称为三点估算法。Pert指计划评审技术，运用网络图来分析项目工期。Barry Boehm 将此技术应用到估计软件的规模、工作量或者成本。

6.3 包的抽象性和依赖性计算公式

6.4 软件质量度量尺度

• 分类尺度（Nomnal scale） ——定类 某个指标被分成一系列的类别。如产品质量属性有：性能、可靠性等。（可计算频率）
• 序列尺度（Ordinal scale ) ——定序 分类的序列，即在分类的基础上，再加以排序。例：1~5表示满意度。（可进行比较）
• 间隔尺度（Interval scale） ——定距 通过数值来表示两个邻近测量点之间的差异，但没有绝对的“零”值。（可加减）
• 比值尺度（Ratio Scale） 和间隔尺度相似，但有绝对的“零”值存在。（可加减乘除）

6.5 软件质量测量标准

要保证测量本身的质量，就是保证测量的有效性和可靠性。

• 有效性：测量结果反映被测试对象的实际状况和程度。
• 可靠性：使用同样测量方法对同样事物多次测量，值的一致性。

7 软件质量管理与软件质量工程体系

7.1 软件质量控制

质量控制是一个设定标准（根据质量要求）、测量结果，判定是否达到了预期要求，对质量问题采取措施进行补救并防止再发生的过程，质量控制已不再仅仅是检验，而更多地倾向于确保生产出来的产品满足要求的过程控制。 休哈特提出统计过程控制的概念与实施方法 工具：控制图，Statistical Process Control－ SPC

7.2 软件质量保证

7.2.1 内部质量保证&外部质量保证 区分

内部质量保证是组织向自己的管理者提供信任； 外部质量保证是组织向外部客户或其它方提供信任。

7.3 高质量的质量管理

7.3.1 全面质量管理

全面质量管理(TQM)是全面的、全过程的、全员的和科学的质量管理的指导思想。 “全”表现在以下4个方面: 1.全面质量的管理。 2.全过程的质量管理。 3.全员参与的质量管理。 4.全面地运用科学的方法进行管理。

7.3.2 零缺陷管理

• 质量大师克劳士比的“零缺陷管理”，强调预防为主，事情第一次就做好。
• 建立一种体系或管理原则来预防产生于企业经营过程中的缺陷，为实现工作的完美无缺而努力。

7.3.3 六西格玛质量管理

6 Sigma是一种以数据为基础、追求几乎完美的质量管理方法和实施技术，能够严格、集中和高效地改善企业流程管理质量 。6 Sigma体现了新的管理理念和追求卓越的价值观，“顾客需求、过程统一、严谨分析、及时执行”，旨在提高顾客满意度的同时降低不良成本和经营周期的过程革新方法。

7.4 区分质量保证体系中组织层次和项目层次涉及内容的区别

7.5 质量成本

7.5.1 质量成本的构成

• 质量成本＝质量保证成本＋损失成本 保证成本：为保证满意的质量而发生的费用 损失成本：没有达到满意的质量所造成损失
• 质量成本＝质量预防成本＋评价成本＋失效成本
• 保证成本＝预防成本＋评价成本 预防成本：预防产生质量问题（软件缺陷）的费用，是企业的计划性支出，专门用来确保在软件产品交付和服务的各个环节不出现失误。 评价成本：是指在交付和服务环节上，为评定软件产品或服务是否符合质量要求而进行的试验、软件测试和质量评估等所必需的支出。 失效成本：分为内部的和外部的，如果在软件发布之前发现质量问题，而要求重做、修改和问题分析所带来的成本属内部失效成本，包括修正软件缺陷、回归测试等，以及因产品或服务不合要求导致的延误。

7.5.2劣质成本PONC和COPQ

• PONC，即“不符合要求的代价 (Price of Nonconformance)” 或称“劣质成本”，是指由于缺乏质量而造成的人力、财力、物力以及时间成本的浪费。PONC是在“零缺陷”质量管理中，为了更有效地衡量质量成本而引入的一个重要概念。
• COPQ，即“不良成本 (Cost of Poor Quality)” 或称“劣质成本”的概念。COPQ指所有由过程、产品和服务中的质量缺陷引起的费用。COPQ则是“6西格玛（Six sigma）”质量管理中的一个重要概念，用于有效地衡量质量成本、质量改进过程在经营效益上的表现。

7.5.3 劣质成本的分类

故障成本，包括质量成本中的外部故障成本、内部故障成本，需采取返工、返修、纠正等补救措施所花费的成本。 过程成本，包括非增值成本(非增值的预防成本和鉴定成本)、低效率过程成本(如多余的操作、重复的作业等)、机会损失成本(指如果没有缺陷而就不会发生的费用等)。 损失成本，包括顾客损失成本(指给顾客所造成的各种额外的费用及负担)、信誉损失成本。

8 软件质量计划

8.1 软件质量计划目标

• 质量计划是为了满足用户的期望。
• 质量计划是为了降低不良质量的成本(COPQ 或PONC),进一步提高企业的竞争力。
• 质量计划是为了在软件开发全过程中实施质量保证。

8.2 质量保证计划管理内容

软件质量计划的管理内容包括3部分：组织、任务和责任。实施质量保证和管理的组织所承担的任务有：

• 软件需求、需求规格说明书的评审；
• 软件配置管理计划；
• 软件测试需求和计划；
• 软件架构设计、详细设计或程序设计的复审；
• 软件代码和单元测试的审查；
• 软件集成和系统测试的审查；
• 参与验收测试；
• 对产品质量状态、产品维护变更的全程跟踪；
• 对顾客满意度的调查。

8.3 制订质量计划

制订质量计划首先要定义好其输入内容，然后必须借助一些有效的方法和工具，最后完成其内容输出。质量管理计划可以是正式或非正式的，高度细化的或框架概括型的，以项目的需要而定。

制订质量计划的三部曲

9 软件质量控制

9.1 软件质量控制活动

软件质量控制活动包括以下几个步骤： （1） 选择软件质量控制对象，属于产品、过程、资源某一类； （2） 选择需要检查的质量特性，对于不同控制对象质量特 性不一样； （3） 确定规格标准，详细说明软件质量特性及质量要求； （4） 制定检查方案，选取能准确测量的项目、测量工具等； （5） 进行实际测量并做好数据记录； （6）分析实际与规格之间存在差异的原因； （7）采取相应的纠正措施。 进入下一个质量控制过程。

9.2 风险管理法

风险管理法步骤

风险识别：试图用系统化的方法来确定威胁项目计划的因素。识别方法包括风险检查表、头脑风暴会议、流程图分析以及与项目人员面谈等 风险分析：分为定性风险分析和定量风险分析。不同的风险发生后对项目造成的影响各不相同。 风险计划：制定风险行动计划，建立示警阈值是风险计划主要活动之一 风险控制：主要采用的应对方法有风险避免、风险弱化、风险承担和风险转移等。 风险跟踪：跟踪风险的状况、风险的对策是否有效等。

9.2 风险控制方法

风险控制方法步骤

风险回避：通过变更项目计划消除风险触发条件 例：减少项目工作范围、采用更熟悉的技术 风险弱化：将风险概率或等级降低到一个可接受的程度。 例：采用更简单的开发流程，增加备份设计 风险转移：将风险结果转移给第三方。 例：签订补偿性合同；保险转移。

9.3 PDCA循环控制法

PDCA又称戴明环,最早由休哈特1930s年代提出，后由戴明在1950s年代再度挖掘，被广泛应用于质量管理中.

完整的PDCA环 大环套小环、小环保大环、推动大循环 不断前进、不断提高 门路式上升

9.4 软件质量控制模型

软件质量控制模型要素分析

产品（质量） 产品实现符合期望 产品质量数据出现偏差,与预想的有很大差别 过程（质量） 按标准流程走 开发过程数据显示出现问题或偏差 资源 资源分配：时间、人财物 资源不足对质量的影响，通过过程数据激

9.5 老七质量控制工具

9.5.1 因果图

9.5.2 Pareto图

Pareto图，又称排列图，帕累特图 来自于Pareto定律，即：28原则：关键的少数和次要的多数。 由朱兰应用于质量管理，揭示绝大多数的问题或缺陷产生于相对有限的起因。

10 质量与软件质量

10.1 质量的概念

符合性质量的概念 能够满足国家或行业标准、产品规范的要求。 适用性质量的概念 让客户满意,不仅满足标准、规范的要求,而且满足客户的其他要求,包括隐含要求。

10.2 质量的属性

• 质量的客户属性：质量是相对客户而存在，也是质量相对性的一种体现。
• 质量的成本属性：也可以称为质量的经济性，质量越好的产品，带给社会的损失就越小 。
• 社会属性：质量很多时候体现的是一种理念，是哲学而不仅仅是方法，它与社会的价值观有直接的关系。
• 可测性：产品的质量好坏将取决对相应特征的衡量，质量的可测性决定了质量的可控特性。
• 质量的可预见性：可以预测质量在不同过程中的结果 。

10.3 软件质量的3A特性

• Accountability (可说明性) – 用户可以基于产品或服务的描述和定义进行使用。 (例如: 市场需求说明书, 功能设计说明书)
• Availability (有效性) – 产品或服务对于99.999% 客户总是有效的 (例如: 性能测试和恢复测试)
• Accessibility (易用性) – 对于用户，产品或服务非常容易使用并且一定是非常有用的功能 。(例如: 确认测试和用户可用性测试)

10.4 软件质量的特性分析

内部质量 针对内部质量需求被测量和评价，是基于内部视角的软件产品特性的总体。 外部质量 从外部视角来规定要求的质量级别，包括用户质量要求派生的需求。 使用质量 对每个开发阶段的最终软件产品的各个使用质量的特性加以估计或预测的质量，是基于用户观点的软件产品用于指定的环境和使用语境（上下文）时的质量。

10.5 广义的软件质量

软件产品质量由三部分构成，只有保证过程质量才能保证稳定的软件产品质量：

• 软件产品质量
• 软件过程质量
• 软件在其商业环境中所表现的质量

在这里插入图片描述

11 重点

5、针对质量度量工具显示的最大圈复杂度的java类structs/action/CompanyAction.java类，以下为updataCmpPass()修改密码方法的控制流图，请计算其环形复杂度。 控制流图：

计算过程： 边数-结点数+2=9-8+2=3 所以环形复杂度为3

6、以下为案例项目的相应测试用例及缺陷数据及度量指标参考值，请计算相关数据分析其软件测试过程质量。

计算过程：

TCD=200/（5948/1000）≈34(个/LOC)<80 TCQ=20/40*100%=50%<60% 百用例发现缺陷问题数=20/(200/100)=10(个)<11 缺陷密度=40/(5948/1000)≈6.8(个/LOC)<7

分析过程： 1、TCD约为34个/LOC，这表示千行代码有大约34个测试用例。根据参考值，这个值小于80个/LOC，说明测试用例的深度可能不够，这意味着相对于代码行数，测试用例的数量可能偏少，覆盖可能不够全面。 2、TCQ为50%，表示测试用例发现的缺陷占总缺陷数的一半，这个值小于参考值60%，表明测试用例在发现缺陷方面的效率不够高，可能还需要优化测试用例的设计。 3、百用例发现缺陷数为10个，小于参考值11个，这进一步说明测试用例在发现缺陷方面的效率不够理想。 4、缺陷密度约为6.8个/LOC，表示千行代码中大约有6.8个缺陷，这个值小于参考值7个/LOC，从一定程度上表明案例项目的质量可能相对较好，但不能完全反映案例项目质量的全部情况。 综上所述，可以认为当前的测试用例在执行深度和发现缺陷的效率上存在一定的不足，为了提高案例项目的质量和测试效果，可能需要增加测试用例的数量、优化测试用例的设计以及改进测试执行的策略。

《软件过程与管理》复习

---

代码语言：javascript代码运行次数：0运行复制

import torch; from transformers import GPT2Tokenizer, GPT2LMHeadModel, TextDataset, DataCollatorForLanguageModeling, Trainer, TrainingArguments; tokenizer = GPT2Tokenizer.from_pretrained('gpt2'); model = GPT2LMHeadModel.from_pretrained('gpt2'); def load_dataset(file_path, tokenizer, block_size=128): dataset = TextDataset(tokenizer=tokenizer, file_path=file_path, block_size=block_size, overwrite_cache=True); return dataset; def train_model(dataset, model): training_args = TrainingArguments(output_dir="./results", overwrite_output_dir=True, num_train_epochs=3, per_device_train_batch_size=4, save_steps=10_000, save_total_limit=2, logging_dir='./logs'); data_collator = DataCollatorForLanguageModeling(tokenizer=tokenizer, mlm=False); trainer = Trainer(model=model, args=training_args, data_collator=data_collator, train_dataset=dataset); trainer.train(); return model; def generate_text(model, tokenizer, prompt, max_length=100): inputs = tokenizer(prompt, return_tensors="pt"); outputs = model.generate(inputs['input_ids'], max_length=max_length, num_return_sequences=1, no_repeat_ngram_size=2, temperature=0.7, top_k=50, top_p=0.95, do_sample=True); return tokenizer.decode(outputs[0], skip_special_tokens=True); dataset = load_dataset('path_to_your_text_file.txt', tokenizer); model = train_model(dataset, model); prompt = "In the future, AI will"; generated_text = generate_text(model, tokenizer, prompt); print(generated_text)

本文参与 腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。 原始发表：2024-09-25，如有侵权请联系 cloudcommunity@tencent 删除前往查看测试产品管理软件设计

本文标签： 《软件过程与管理》复习