软件度量总结[★]

第一篇：软件度量总结

软件度量结课总结

软件度量总结

这次总结的结构比较简单，就是按照五个章节分别阐述了自己的理解。一．软件度量的应用范围。

经过这一阶段的学习，我认为想要明白软件度量，首先要分清度量和测量的区别。度量具有前置性，它提供了一种定量研究软件问题的方法；测量具有实时性或后置性，主要集中在给度量提供数据或者处理数据的方法上。由于软件工程强烈的不确定性，使得软件工程的精确测量困难重重，但软件度量主要研究的是可能性的规律，通过概率和统计学的研究，寻找事物内在的规律。其并不具备1＋1=2的特征，而是研究在多大可能性上这个结论是合理的，因为软件的主体是人，具有概率属性，设备和材料容易度量，但人很难度量。软件度量的主要作用是评估状况、跟踪进展情况、评价产品有效性和改进设计和过程的质量。定性分析可以提供迅速地判断能力，但定性分析终究需要定量分析的验证与支持，否则其结果很可能成为无目之本，出现错误。

软件度量的方法体系主要包括5个方面：1.项目度量，目的在于度量项目规模、成本、进度、顾客满意度等，辅助项目管理进行项目控制；2.规模度量，主要依靠经验和经验的模型，是决定项目成败的重要原因之一，是估算工作量、成本预算及策划项目进度的基础；3.成本度量，4。产品度量，实质上是软件质量的度量，软件的质量由一系列质量要素组成，每个质量要素又由一些衡量标准组成，主要肚量方法是McCabe复杂性度量法；5，过程度量，对软件开发过程的个各方面进行度量，目的在于预测过程的未来属性，减少结果的偏差，主要包括成熟度度量（例如CMMI, GJB5000A）、管理度量（主要包括里程碑管理、风险度量等项目管理度量，审查度量、质量保证度量等质量管理度量，变更控制、版本管理度量等配置管理度量）、生命周期度量三个大的方面。

不同层次的人员对软件度量有不同的需求。高级管理人员，如CEO、COO，关注点在上市时间、客户满意度、费用的节省等商业策略的组成部分上；中级管理层，如部门经理、总监等，则主要关注生产力、成本控制、效率等，他们更多的是着眼于总体的性能，交付情况以及产品的运行状态等，而不是项目每天完成的情况；项目管理层对度量的需求则是准确估计和控制软件产品，主要考虑通过每周的对比评测、研究进展，以确保项目开发方向的正确性，或者主动捕捉测量点，由度量分析师发展成一种模型，预测项目未来的结果。

二．软件测量基础。

软件测量是经典测量科学基础上的具体应用，为了使软件度量真正发挥作用，必须掌握测量的基础知识。软件度量不能用现成的公式进行计算，需要根据自己的实际情况建立模型，并通过历史数据来定义参数。首先，测量的表示理论。人们一般习惯从比较中获得对事物的理解，例如二元关系、三元关系中谁比谁大等，而这种关系可以映射到数学世界中，由此可以把测量定义为从经验世界到关系世界的一种映射，把度量定义为为了描述实体的某种属性，而为这个实体赋予的数字或者符号。比如为了描述人的年龄，将这个人从出生到现在的所经历的年数作为年龄属性赋予这个人。第二，测量和模型。模型是对显示的抽象，除去了实现的细枝末节，使我们可以我们从特定的角度看待实体和概念。测量可以分为直接测量和间接测量两种，而一个预测系统通常由一个数学模型和一组预测规程组成，其中，预测规程的作用是确定预测参数并对结果进行解释。第三，测量数据收集与分析。良好的数据应该具有正确性、准确性、一致性的特点，并要具有合适的精度，能与特定活动或持续时间相关联，且能够重复出现。就数据的收集而 软件度量结课总结

言，第一步要制订数据收集计划，然后决定测量项，根据需要选取合适的测试粒度，并确保产品处于配置控制之下，必须了解对产品的哪些版本进行测量； 三．软件规模的估算与度量。

软件规模的估算与度量部分，我主要想写一下我理解的功能点估算及用例点估算的主要流程及估算过程中需要注意的问题。在此之前先简单地描述一下传统的代码行度量，一般认为空白行和注释行不应该计算在代码行中，并把不带注释的行数缩写为NCLOC(又称为有效代码行ELOC),并将注释行定义为CLOC,则总长度为LOC=NCLOC+ELOC，注释行的密度用CLOC/LOC表示。但由于所用的语言不同导致代码行不同等原因，代码行不适于作估算，更适合用作完成之后的测量。

接下来是功能点估算。功能点估算提出的目的是使得不同国家，不同人对同样的需求估算得到的规模大小基本相同；其缺点是对需求描述的要求比较高。在这个方法中，功能点是一个度量单元，度量所得到的值和软件的代码量没有关系，也就不再依赖于选择的编程语言。至于功能点估算的过程，最简单地来说包括4个步骤：①估算数据功能规模，②估算事务处理规模，③计算调整因子，④根据公式计算功能点数。数据功能规模主要涉及系统所处理的数据文件对系统复杂性的影响，可以分为内部逻辑文件和外部接口文件两种。事务处理规模则可以分为三种形式，即外部输入、外部输出、外部查询。首先要对上述概念进行识别，内部逻辑文件可以描述为一个基本处理在应用程序内部维护逻辑上相关的数据块或者控制信息，其中，“维护”指增删改查等操作，“逻辑上相关”指仅考虑用到的或者逻辑上有关系的数据；外部接口文件可以理解为系统不进行维护的逻辑文件。这两种文件的复杂贡献度可以分别通过数据元素类型（字段个数）和记录元素类型（数据表的数目）两个纬度来考虑，每个具体文件所对应的加权系数可以查询对应的复杂型矩阵来得到，最后把加权系数相加即得到这两种文件的总功能点数，即数据功能的功能点数。这个过程中，难点在于对每个文件进行数据元素类型和记录元素类型的识别，有一系列的注意事项。接下来是对外部输入、外部输出和外部查询的识别，外部输入可以简单地理解为用户通过系统所进行地增、删、改，其结果可以是维护了内部的数据文件，也可以是改变了系统地行为状态；外部输出可以理解为系统所作出的反映，例如显示屏上显示某些结果，或者系统行为发生某些改变；外部查询没有对数据的处理，仅仅是对已有信息的抓取。这一部分相对容易理解，识别起来也比上面那部分容易一些，其加权系数由数据元素类型DET（与内部逻辑文件和外部接口文件中的DET基本相同）和参考文件类型FTR（被事务处理的文件总数）两个维度考虑，具体数值也是可以通过查询矩阵表来获得，分别得到后相加即可以得到事务处理的功能点数。接下来需要计算值调整因子VAF，VAF根据非功能需求获得，不同的项目可能会根据实际情况有一些调整，然后根据公式求得VAF的具体值。最后一步就是将前面两步所得的功能点相加，再乘以调整因子，得到最终的功能点数。

由于软件工程不断向着面向对象甚至面向过程方向发展，而功能点估算仍然是结构化的估算方法，所以出现了用例点估算。用例点估算的方法和功能点估算原理相似，都是讲系统先按照一定的原则分割成数个部分，分别得到估算结果之后再相加得到总的结果。用例点估算首先要明确什么是用例，我认为用例描述了一个动作序列，这些动作是系统为了响应事件而做的，其结果是产生了对发起事件的角色有价值的可见的结果。用例点估算必须具备的基础是良好的用例图和场景描述，有了这两个基础，估算过程相对来说就很简单，也可以分为4个基本步骤：①确定未调整功能点数，②计算复杂因子，③计算软件规模，④估算工作量。第①个过程主要是用例角色复杂度和用例事务数的识别，角色可以是人，计算机或者组织，关键是分清它用什么方式与系统交互，查到对应的权重，从而计算获得未平衡角色数；事物是指从用户到系统再到用户的一个“回路”，根据场景描述确定每个用例的事物数，同样查询其对应的权值之后计算得 软件度量结课总结

到未平衡用例数，最后这两个数值相加得到未调整功能点数。第②步中复杂度因子的计算主要分为技术复杂度因子TCF和环境复杂度因子ECF两类，与功能点估算中调整因子的计算方法相同，对各个项目分别打分后得出两个复杂因子。第③步，软件规模UCP即为技术复杂度因子TCF×环境复杂度因子ECF×软件规模UCP。最后根据历史数据确定每个UCP完成的工作量（通常为16人时~30人时），与计算所得的UCP相乘即为开发工作量，在此之外，用例点模型将项目管理、质量保证等时间作为补充效果SE计算，补充效果SE+开发工作量就是最终的估算结果。四．过程规划、预测与监控中的度量。

这一章主要简单地说一下对项目评估预评审技术（PERT）、原始的CoCoMo模型、诤值分析以及项目监控中数据分析的理解。由于理解不是特别深刻，所以只能简单的描述一下现有的了解。关于PERT，我认为最主要的就是对三个数据的评估，即乐观的OD（不考虑效率和中断，完成任务的最小时间量）、悲观的PD（考虑各种培训、生病以及工作时间做与工作无关的事情等各种延误情况）和最有可能的ED（不是OD和PD的中间值，而是根据经验估算认为的最可能的情况）。根据这三个值得出项目的beta分布及其图像（使用beta分布而不是用正态分布的原因是人们的评估往往偏向于乐观），图中使得左右两侧面积近似相等的分割线所对应的时间即为最可能的工作量。这种估算方法需要策划小组人员分别进行估算得到结果后，再对结果按照一定的策略进行对比分析，得到最终的估计值。

原始的CoCoMo模型是用于软件开发不同阶段的三个模型的集合。基本、中间、详细这三个层次的模型分别用于对项目了解很少、明确需求、完成设计以后三个阶段，但都具有相同的形式，即E=aSbF。E是按人月计算的工作量，S是按千行交付的原指令数目的测量规模，F是调整因子（不同层次的模型中取不同值），a和b又根据软件的三种类别（有机式、半分离式和嵌入式）分别取不同的数值。

诤值分析法是为了将项目的范围偏差跟踪、进度偏差跟踪和成本偏差跟踪统一起来。这个方法的核心是比较准确的估算出工作完成的百分比。计划的费用PV是一条表示期望值的基线，代表着截止到某一时刻计划完成的工作，可以用计划消耗的费用来表示；实际的费用AC表示截止到某一时刻实际的成本；诤值EV表示截止某一时刻，实际完成的工作应该消耗的成本。同一时刻的EV与PV的单一变量是工作量，分别是实际的工作量和计划的工作量，所以这两个值可以得出进度的偏差；AC与EV的单一变量是实际的费用，分别是实际消耗的费用和计划消耗的费用，所以这两个值可以得出成本的偏差。这是两个最重要的偏差。

五．产品设计质量度量与控制。

我认为 非功能性需求是软件度量中最容易被忽略的，也最不容易被清晰掌握的部分。在需求分析中，常见的非功能性需求虽然都能设计感官需求、易使用性、安全性、可靠性、可维护性等方面，但对其要求的描述都只停留在定性的描述上，没有明确的度量标准。而需求是度量的重要标准，也是设计和测试的参考，需求描述的不明确很容易造成最后交付过程中出现分歧，这就需要在对产品的非功能性需求描述、设计和实现过程中引入可度量的体系。

正如老师所说，没有度量不是不能成功，但成功不能复制，有了良好的度量体系，可以通过比较、管理、复制取得更多次的成功，软件度量将在软件工程中起到越来越重要的作用。最后，感谢老师的辛苦教授，受益匪浅。

第二篇：软件度量总结(精)

软件度量总结

这次总结的结构比较简单,就是按照五个章节分别阐述了自己的理解。一.软件度量的应用范围。

经过这一阶段的学习,我认为想要明白软件度量,首先要分清度量和测量的区别。度量具有前置 性,它提供了一种定量研究软件问题的方法;测量具有实时性或后置性,主要集中在给度量提供数据或者 处理数据的方法上。由于软件工程强烈的不确定性,使得软件工程的精确测量困难重重,但软件度量主要 研究的是可能性的规律,通过概率和统计学的研究,寻找事物内在的规律。其并不具备 1+1=2的特征, 而是研究在多大可能性上这个结论是合理的,因为软件的主体是人,具有概率属性,设备和材料容易度 量,但人很难度量。软件度量的主要作用是评估状况、跟踪进展情况、评价产品有效性和改进设计和过程 的质量。定性分析可以提供迅速地判断能力,但定性分析终究需要定量分析的验证与支持,否则其结果很 可能成为无目之本,出现错误。

软件度量的方法体系主要包括 5个方面:1.项目度量,目的在于度量项目规模、成本、进度、顾客满 意度等,辅助项目管理进行项目控制;2.规模度量,主要依靠经验和经验的模型,是决定项目成败的重要 原因之一,是估算工作量、成本预算及策划项目进度的基础;3.成本度量, 4。产品度量,实质上是软件 质量的度量,软件的质量由一系列质量要素组成,每个质量要素又由一些衡量标准组成,主要肚量方法是 McCabe 复杂性度量法;5,过程度量,对软件开发过程的个各方面进行度量,目的在于预测过程的未来属 性,减少结果的偏差,主要包括成熟度度量(例如 CMMI, GJB5000A、管理度量(主要包括里程碑管 理、风险度量等项目管理度量,审查度量、质量保证度量等质量管理度量,变更控制、版本管理度量等配 置管理度量、生命周期度量三个大的方面。

不同层次的人员对软件度量有不同的需求。高级管理人员,如 CEO、COO ,关注点在上市时间、客 户满意度、费用的节省等商业策略的组成部分上;中级管理层,如部门经理、总监等,则主要关注生产 力、成本控制、效率等,他们更多的是着眼于

总体的性能,交付情况以及产品的运行状态等,而不是项目 每天完成的情况;项目管理层对度量的需求则是准确估计和控制软件产品,主要考虑通过每周的对比评 测、研究进展,以确保项目开发方向的正确性,或者主动捕捉测量点,由度量分析师发展成一种模型,预 测项目未来的结果。

二.软件测量基础。

软件测量是经典测量科学基础上的具体应用,为了使软件度量真正发挥作用,必须掌握测量的基础 知识。软件度量不能用现成的公式进行计算,需要根据自己的实际情况建立模型,并通过历史数据来定义 参数。首先,测量的表示理论。人们一般习惯从比较中获得对事物的理解,例如二元关系、三元关系中谁 比谁大等,而这种关系可以映射到数学世界中,由此可以把测量定义为从经验世界到关系世界的一种映 射,把度量定义为为了描述实体的某种属性,而为这个实体赋予的数字或者符号。比如为了描述人的年 龄,将这个人从出生到现在的所经历的年数作为年龄属性赋予这个人。第二,测量和模型。模型是对显示 的抽象,除去了实现的细枝末节,使我们可以我们从特定的角度看待实体和概念。测量可以分为直接测量 和间接测量两种,而一个预测系统通常由一个数学模型和一组预测规程组成,其中,预测规程的作用是确 定预测参数并对结果进行解释。第三,测量数据收集与分析。良好的数据应该具有正确性、准确性、一致 性的特点,并要具有合适的精度,能与特定活动或持续时间相关联,且能够重复出现。就数据的收集而

言,第一步要制订数据收集计划,然后决定测量项,根据需要选取合适的测试粒度,并确保产品处于配置 控制之下,必须了解对产品的哪些版本进行测量;三.软件规模的估算与度量。

软件规模的估算与度量部分,我主要想写一下我理解的功能点估算及用例点估算的主要流程及估算 过程中需要注意的问题。在此之前先简单地描述一下传统的代码行度量,一般认为空白行和注释行不应该 计算在代码行中,并把不带注释的行数缩写为 NCLOC(又称为有效代码行 ELOC, 并将注释行定义为 CLOC, 则总长度为

LOC=NCLOC+ELOC,注释行的密度用 CLOC/LOC表示。但由于所用的语言不同导致 代码行不同等原因,代码行不适于作估算,更适合用作完成之后的测量。

接下来是功能点估算。功能点估算提出的目的是使得不同国家,不同人对同样的需求估算得到的规 模大小基本相同;其缺点是对需求描述的要求比较高。在这个方法中,功能点是一个度量单元,度量所得 到的值和软件的代码量没有关系,也就不再依赖于选择的编程语言。至于功能点估算的过程,最简单地来 说包括 4个步骤:①估算数据功能规模,②估算事务处理规模,③计算调整因子,④根据公式计算功能点 数。数据功能规模主要涉及系统所处理的数据文件对系统复杂性的影响,可以分为内部逻辑文件和外部接 口文件两种。事务处理规模则可以分为三种形式,即外部输入、外部输出、外部查询。首先要对上述概念 进行识别,内部逻辑文件可以描述为一个基本处理在应用程序内部维护逻辑上相关的数据块或者控制信 息,其中, “ 维护 ” 指增删改查等操作, “ 逻辑上相关 ” 指仅考虑用到的或者逻辑上有关系的数据;外部接口 文件可以理解为系统不进行维护的逻辑文件。这两种文件的复杂贡献度可以分别通过数据元素类型(字段 个数和记录元素类型(数据表的数目两个纬度来考虑,每个具体文件所对应的加权系数可以查询对应 的复杂型矩阵来得到,最后把加权系数相加即得到这两种文件的总功能点数,即数据功能的功能点数。这 个过程中,难点在于对每个文件进行数据元素类型和记录元素类型的识别,有一系列的注意事项。接下来 是对外部输入、外部输出和外部查询的识别,外部输入可以简单地理解为用户通过系统所进行地增、删、改,其结果可以是维护了内部的数据文件,也可以是改变了系统地行为状态;外部输出可以理解为系统所 作出的反映,例如显示屏上显示某些结果,或者系统行为发生某些改变;外部查询没有对数据的处理,仅 仅是对已有信息的抓取。这一部分相对容易理解,识别起来也比上面那部分容易一些,其加权系数由数据 元素类型 DET(与内部逻辑文件和外部接口文件中的 DET 基本相同和参考文件类型 FTR(被事务处理 的文件总数两个维度考虑,具体数值也是可以通过查询矩阵表来获得,分别得到后相加即可以得到事务 处理的功能点数。接下来需要计算值调整因子 VAF , VAF 根据非功能需求获得,不同的项目可能会根据 实际情况有一些调整,然后根据公式求得 VAF 的具体值。最后一步就是将前面两步所得的功能点相加, 再乘以调整因子,得到最终的功能点数。

由于软件工程不断向着面向对象甚至面向过程方向发展,而功能点估算仍然是结构化的估算方法, 所以出现了用例点估算。用例点估算的方法和功能点估算原理相似,都是讲系统先按照一定的原则分割成 数个部分,分别得到估算结果之后再相加得到总的结果。用例点估算首先要明确什么是用例,我认为用例 描述了一个动作序列,这些动作是系统为了响应事件而做的,其结果是产生了对发起事件的角色有价值的 可见的结果。用例点估算必须具备的基础是良好的用例图和场景描述,有了这两个基础,估算过程相对来 说就很简单,也可以分为 4个基本步骤:①确定未调整功能点数,②计算复杂因子,③计算软件规模,④ 估算工作量。第①个过程主要是用例角色复杂度和用例事务数的识别,角色可以是人,计算机或者组织, 关键是分清它用什么方式与系统交互,查到对应的权重,从而计算获得未平衡角色数;事物是指从用户到 系统再到用户的一个“回路”,根据场景描述确定每个用例的事物数,同样查询其对应的权值之后计算得

到未平衡用例数,最后这两个数值相加得到未调整功能点数。第②步中复杂度因子的计算主要分为技术复 杂度因子 TCF 和环境复杂度因子 ECF 两类,与功能点估算中调整因子的计算方法相同,对各个项目分别 打分后得出两个复杂因子。第③步,软件规模 UCP 即为技术复杂度因子 TCF ×环境复杂度因子 ECF ×软 件规模 UCP。最后根据历史数据确定每个 UCP 完成的工作量(通常为 16人时 ~30人时,与计算所得的 UCP 相乘即为开发工作量,在此之外,用例点模型将项目管理、质量保证等时间作为补充效果 SE 计算, 补充效果 SE+开发工作量就是最终的估算结果。

四.过程规划、预测与监控中的度量。

这一章主要简单地说一下对项目评估预评审技术(PERT、原始的 CoCoMo 模型、诤值分析以及项 目监控中数据分析的理解。由于理解不是特别深刻,所以只能简单的描述一下现有的了解。关于 PERT , 我认为最主要的就是对三个数据的评估,即乐观的 OD(不考虑效率和中断,完成任务的最小时间量、悲观的 PD(考虑各种培训、生病以及工作时间做与工作无关的事情等各种延误情况和最有可能的 ED(不是 OD 和 PD 的中间值,而是根据经验估算认为的最可能的情况。根据这三个值得出项目的 beta 分 布及其图像(使用 beta 分布而不是用正态分布的原因是人们的评估往

往偏向于乐观,图中使得左右两侧 面积近似相等的分割线所对应的时间即为最可能的工作量。这种估算方法需要策划小组人员分别进行估算 得到结果后,再对结果按照一定的策略进行对比分析,得到最终的估计值。

原始的 CoCoMo 模型是用于软件开发不同阶段的三个模型的集合。基本、中间、详细这三个层次的 模型分别用于对项目了解很少、明确需求、完成设计以后三个阶段,但都具有相同的形式,即 E=aSb F。E 是按人月计算的工作量, S 是按千行交付的原指令数目的测量规模, F 是调整因子(不同层次的模型中取 不同值, a 和 b 又根据软件的三种类别(有机式、半分离式和嵌入式分别取不同的数值。

诤值分析法是为了将项目的范围偏差跟踪、进度偏差跟踪和成本偏差跟踪统一起来。这个方法的核心 是比较准确的估算出工作完成的百分比。计划的费用 PV 是一条表示期望值的基线,代表着截止到某一时 刻计划完成的工作,可以用计划消耗的费用来表示;实际的费用 AC 表示截止到某一时刻实际的成本;诤 值 EV 表示截止某一时刻,实际完成的工作应该消耗的成本。同一时刻的 EV 与 PV 的单一变量是工作 量,分别是实际的工作量和计划的工作量,所以这两个值可以得出进度的偏差;AC 与 EV 的单一变量是 实际的费用,分别是实际消耗的费用和计划消耗的费用,所以这两个值可以得出成本的偏差。这是两个最 重要的偏差。

五.产品设计质量度量与控制。

我认为 非功能性需求是软件度量中最容易被忽略的,也最不容易被清晰掌握的部分。在需求分析中, 常见的非功能性需求虽然都能设计感官需求、易使用性、安全性、可靠性、可维护性等方面,但对其要求 的描述都只停留在定性的描述上,没有明确的度量标准。而需求是度量的重要标准,也是设计和测试的参 考,需求描述的不明确很容易造成最后交付过程中出现分歧,这就需要在对产品的非功能性需求描述、设 计和实现过程中引入可度量的体系。

正如老师所说,没有度量不是不能成功,但成功不能复制,有了良好的度量体系,可以通过比较、管 理、复制取得更多次的成功,软件度量将在软件工程中起到越来越重要的作用。最后,感谢老师的辛苦教 授,受益匪浅。

第三篇：软件度量总结

软件度量结课总结

软件度量总结

这次总结的结构比较简单，就是按照五个章节分别阐述了自己的理解。

一．软件度量的应用范围。

经过这一阶段的学习，我认为想要明白软件度量，首先要分清度量和测量的区别。度量具有前置性，它提供了一种定量研究软件问题的方法；测量具有实时性或后置性，主要集中在给度量提供数据或者处理数据的方法上。由于软件工程强烈的不确定性，使得软件工程的精确测量困难重重，但软件度量主要研究的是可能性的规律，通过概率和统计学的研究，寻找事物内在的规律。其并不具备1＋1=2的特征，而是研究在多大可能性上这个结论是合理的，因为软件的主体是人，具有概率属性，设备和材料容易度量，但人很难度量。软件度量的主要作用是评估状况、跟踪进展情况、评价产品有效性和改进设计和过程的质量。定性分析可以提供迅速地判断能力，但定性分析终究需要定量分析的验证与支持，否则其结果很可能成为无目之本，出现错误。

软件度量的方法体系主要包括5个方面：1.项目度量，目的在于度量项目规模、成本、进度、顾客满意度等，辅助项目管理进行项目控制；2.规模度量，主要依靠经验和经验的模型，是决定项目成败的重要原因之一，是估算工作量、成本预算及策划项目进度的基础；3.成本度量，4。产品度量，实质上是软件质量的度量，软件的质量由一系列质量要素组成，每个质量要素又由一些衡量标准组成，主要肚量方法是McCabe复杂性度量法；5，过程度量，对软件开发过程的个各方面进行度量，目的在于预测过程的未来属性，减少结果的偏差，主要包括成熟度度量（例如CMMI, GJB5000A）、管理度量（主要包括里程碑管理、风险度量等项目管理度量，审查度量、质量保证度量等质量管理度量，变更控制、版本管理度量等配置管理度量）、生命周期度量三个大的方面。

不同层次的人员对软件度量有不同的需求。高级管理人员，如CEO、COO，关注点在上市时间、客户满意度、费用的节省等商业策略的组成部分上；中级管理层，如部门经理、总监等，则主要关注生产力、成本控制、效率等，他们更多的是着眼于总体的性能，交付情况以及产品的运行状态等，而不是项目每天完成的情况；项目管理层对度量的需求则是准确估计和控制软件产品，主要考虑通过每周的对比评测、研究进展，以确保项目开发方向的正确性，或者主动捕捉测量点，由度量分析师发展成一种模型，预测项目未来的结果。

二．软件测量基础。

软件测量是经典测量科学基础上的具体应用，为了使软件度量真正发挥作用，必须掌握测量的基础知识。软件度量不能用现成的公式进行计算，需要根据自己的实际情况建立模型，并通过历史数据来定义参数。首先，测量的表示理论。人们一般习惯从比较中获得对事物的理解，例如二元关系、三元关系中谁比谁大等，而这种关系可以映射到数学世界中，由此可以把测量定义为从经验世界到关系世界的一种映射，把度量定义为为了描述实体的某种属性，而为这个实体赋予的数字或者符号。比如为了描述人的年龄，将这个人从出生到现在的所经历的年数作为年龄属性赋予这个人。第二，测量和模型。模型是对显示的抽象，除去了实现的细枝末节，使我们可以我们从特定的角度看待实体和概念。测量可以分为直接测量和间接测量两种，而一个预测系统通常由一个数学模型和一组预测规程组成，其中，预测规程的作用是确定预测参数并对结果进行解释。第三，测量数据收集与分析。良好的数据应该具有正确性、准确性、一致性的特点，并要具有合适的精度，能与特定活动或持续时间相关联，且能够重复出现。就数据的收集而

言，第一步要制订数据收集计划，然后决定测量项，根据需要选取合适的测试粒度，并确保产品处于配置控制之下，必须了解对产品的哪些版本进行测量；

三．软件规模的估算与度量。

软件规模的估算与度量部分，我主要想写一下我理解的功能点估算及用例点估算的主要流程及估算过程中需要注意的问题。在此之前先简单地描述一下传统的代码行度量，一般认为空白行和注释行不应该计算在代码行中，并把不带注释的行数缩写为NCLOC(又称为有效代码行ELOC),并将注释行定义为

CLOC,则总长度为LOC=NCLOC+ELOC，注释行的密度用CLOC/LOC表示。但由于所用的语言不同导致代码行不同等原因，代码行不适于作估算，更适合用作完成之后的测量。

接下来是功能点估算。功能点估算提出的目的是使得不同国家，不同人对同样的需求估算得到的规模大小基本相同；其缺点是对需求描述的要求比较高。在这个方法中，功能点是一个度量单元，度量所得到的值和软件的代码量没有关系，也就不再依赖于选择的编程语言。至于功能点估算的过程，最简单地来说包括4个步骤：①估算数据功能规模，②估算事务处理规模，③计算调整因子，④根据公式计算功能点数。数据功能规模主要涉及系统所处理的数据文件对系统复杂性的影响，可以分为内部逻辑文件和外部接口文件两种。事务处理规模则可以分为三种形式，即外部输入、外部输出、外部查询。首先要对上述概念进行识别，内部逻辑文件可以描述为一个基本处理在应用程序内部维护逻辑上相关的数据块或者控制信息，其中，“维护”指增删改查等操作，“逻辑上相关”指仅考虑用到的或者逻辑上有关系的数据；外部接口文件可以理解为系统不进行维护的逻辑文件。这两种文件的复杂贡献度可以分别通过数据元素类型（字段个数）和记录元素类型（数据表的数目）两个纬度来考虑，每个具体文件所对应的加权系数可以查询对应的复杂型矩阵来得到，最后把加权系数相加即得到这两种文件的总功能点数，即数据功能的功能点数。这个过程中，难点在于对每个文件进行数据元素类型和记录元素类型的识别，有一系列的注意事项。接下来是对外部输入、外部输出和外部查询的识别，外部输入可以简单地理解为用户通过系统所进行地增、删、改，其结果可以是维护了内部的数据文件，也可以是改变了系统地行为状态；外部输出可以理解为系统所作出的反映，例如显示屏上显示某些结果，或者系统行为发生某些改变；外部查询没有对数据的处理，仅仅是对已有信息的抓取。这一部分相对容易理解，识别起来也比上面那部分容易一些，其加权系数由数据元素类型DET（与内部逻辑文件和外部接口文件中的DET基本相同）和参考文件类型FTR（被事务处理的文件总数）两个维度考虑，具体数值也是可以通过查询矩阵表来获得，分别得到后相加即可以得到事务处理的功能点数。接下来需要计算值调整因子VAF，VAF根据非功能需求获得，不同的项目可能会根据实际情况有一些调整，然后根据公式求得VAF的具体值。最后一步就是将前面两步所得的功能点相加，再乘以调整因子，得到最终的功能点数。

由于软件工程不断向着面向对象甚至面向过程方向发展，而功能点估算仍然是结构化的估算方法，所以出现了用例点估算。用例点估算的方法和功能点估算原理相似，都是讲系统先按照一定的原则分割成数个部分，分别得到估算结果之后再相加得到总的结果。用例点估算首先要明确什么是用例，我认为用例描述了一个动作序列，这些动作是系统为了响应事件而做的，其结果是产生了对发起事件的角色有价值的可见的结果。用例点估算必须具备的基础是良好的用例图和场景描述，有了这两个基础，估算过程相对来说就很简单，也可以分为4个基本步骤：①确定未调整功能点数，②计算复杂因子，③计算软件规模，④估算工作量。第①个过程主要是用例角色复杂度和用例事务数的识别，角色可以是人，计算机或者组织，关键是分清它用什么方式与系统交互，查到对应的权重，从而计算获得未平衡角色数；事物是指从用户到系统再到用户的一个“回路”，根据场景描述确定每个用例的事物数，同样查询其对应的权值之后计算得

到未平衡用例数，最后这两个数值相加得到未调整功能点数。第②步中复杂度因子的计算主要分为技术复杂度因子TCF和环境复杂度因子ECF两类，与功能点估算中调整因子的计算方法相同，对各个项目分别打分后得出两个复杂因子。第③步，软件规模UCP即为技术复杂度因子TCF×环境复杂度因子ECF×软件规模UCP。最后根据历史数据确定每个UCP完成的工作量（通常为16人时~30人时），与计算所得的UCP相乘即为开发工作量，在此之外，用例点模型将项目管理、质量保证等时间作为补充效果SE计算，补充效果SE+开发工作量就是最终的估算结果。

四．过程规划、预测与监控中的度量。

这一章主要简单地说一下对项目评估预评审技术（PERT）、原始的CoCoMo模型、诤值分析以及项目监控中数据分析的理解。由于理解不是特别深刻，所以只能简单的描述一下现有的了解。关于PERT，我认为最主要的就是对三个数据的评估，即乐观的OD（不考虑效率和中断，完成任务的最小时间量）、悲观的PD（考虑各种培训、生病以及工作时间做与工作无关的事情等各种延误情况）和最有可能的ED（不是OD和PD的中间值，而是根据经验估算认为的最可能的情况）。根据这三个值得出项目的beta分布及其图像（使用beta分布而不是用正态分布的原因是人们的评估往往偏向于乐观），图中使得左右两侧面积近似相等的分割线所对应的时间即为最可能的工作量。这种估算方法需要策划小组人员分别进行估算得到结果后，再对结果按照一定的策略进行对比分析，得到最终的估计值。

原始的CoCoMo模型是用于软件开发不同阶段的三个模型的集合。基本、中间、详细这三个层次的模型分别用于对项目了解很少、明确需求、完成设计以后三个阶段，但都具有相同的形式，即E=aSbF。E是按人月计算的工作量，S是按千行交付的原指令数目的测量规模，F是调整因子（不同层次的模型中取不同值），a和b又根据软件的三种类别（有机式、半分离式和嵌入式）分别取不同的数值。

诤值分析法是为了将项目的范围偏差跟踪、进度偏差跟踪和成本偏差跟踪统一起来。这个方法的核心是比较准确的估算出工作完成的百分比。计划的费用PV是一条表示期望值的基线，代表着截止到某一时刻计划完成的工作，可以用计划消耗的费用来表示；实际的费用AC表示截止到某一时刻实际的成本；诤值EV表示截止某一时刻，实际完成的工作应该消耗的成本。同一时刻的EV与PV的单一变量是工作量，分别是实际的工作量和计划的工作量，所以这两个值可以得出进度的偏差；AC与EV的单一变量是实际的费用，分别是实际消耗的费用和计划消耗的费用，所以这两个值可以得出成本的偏差。这是两个最重要的偏差。

五．产品设计质量度量与控制。

我认为 非功能性需求是软件度量中最容易被忽略的，也最不容易被清晰掌握的部分。在需求分析中，常见的非功能性需求虽然都能设计感官需求、易使用性、安全性、可靠性、可维护性等方面，但对其要求的描述都只停留在定性的描述上，没有明确的度量标准。而需求是度量的重要标准，也是设计和测试的参考，需求描述的不明确很容易造成最后交付过程中出现分歧，这就需要在对产品的非功能性需求描述、设计和实现过程中引入可度量的体系。

正如老师所说，没有度量不是不能成功，但成功不能复制，有了良好的度量体系，可以通过比较、管理、复制取得更多次的成功，软件度量将在软件工程中起到越来越重要的作用。最后，感谢老师的辛苦教授，受益匪浅。

第四篇：软件开发工具总结

1.软件开发工具：在高级程序设计语言（第三代语言）的基础上，为提高软件开发的质量和效率，从规划、分析、设计、测试、成文和管理各方面，对软件开发者提供各种不同程度的帮助的一类广泛的软件。

2.软件开发工具的功能要求：（1）认识与描述客观系统

（2）存储及管理开发过程中的信息

（3）代码的编写或生成（4）文档的编制或生成（5）软件项目的管理

3.软件开发工具的性能：（1）表达能力或描述能力

（2）保持信息一致性的能力

（3）使用的方便程度

（4）工具的可靠程度

（5）对硬件和软件环境的要求

4软件开发工具的类别（1）按工作阶段划分：分为设计工具、分析工具、计划工具

（2）按集成程度划分：分为集成化的和专用的（3）按与硬件、软件的关系划分：分为依赖于特定的计算机或特定的软件、独立于硬件与其他软件的。

5.软件开发过程：需求分析、总体设计、实现阶段、测试或调试阶段

6.通用软件的弱点：

（1）有许多工作是通用软件所无法完成的。

（2）用通用软件完成某些工作，只能表现其表面的形式，而不能反映其逻辑内涵。

（3）用通用软件来帮助人们完成软件开发工作时，常会遇到难于保持一致性的困难。

7.软件开发工具的发展表现在：

（1）自动化程度的提高

（2）把需求分析包括进了软件工作范围之内，从而使软件开发过程进一步向用户方面延伸，离用户更近了。

（3）把软件开发工作延伸到项目及版本管理。

（4）吸收了许多管理科学的内容与方法。

8大型软件开发中的困难：（1）一致性的保持成为十分困难的问题。

（2）测试的困难大大增加

（3）工作进度难以控制。

（4）文档与代码的协调十分困难。

（5）版本更新带来的困难。

9大型软件开发中困难产生的原因

（1）这些困难来自大系统的复杂性

（2）许多具有主动性的个人之间的组织与协调本身也会带来大量的困难。

（3）各个应用领域之间的差别也导致这些困难的加重。

（4）时间的因素、变化的因素也给软件开发工作带来许多困难。

10.结构化程序设计分解的三个基本模块：处理单元、循环机制、二分决策机制。

11.结构化程序设计划分模块的基本要求：

（1）模块的功能在逻辑上尽可能地单一化、明确化。

（2）模块之间的联系及相互影响尽可能少，明确说明必需的联系，避免传递控制信号，避免逻辑耦合，仅限于数据耦合。

（3）模块的规模应足够小，以便使它本身的调试易于进行。

1.IBM提出的应用软件的开发过程：需求分析、分析与设计阶段、编程阶段、测试阶段、使用及维护阶段。

2.面向对象的程序设计的基本思想：

（1）课观世界的任何事物都是对象，它们都有一些静态属性，也都有一些有关的操作，作为一个整体，这些对象对外不必公开这些属性与操作，这就是所谓“封装性”

（2）对象之间有抽象与具体、群体与个体、整体与部分等几种关系

（3）抽象的、较大的对象所具有的性质包括静态属性和动态操作，自然地成为它的子类的性质，不必加以重复说明或规定，这是“遗传性”

（4）对象之间可以互送消息，这一消息可以是传送一个参数，也可使这个对象开始某个操作

3.对软件质量进行测评的标准：

（1）正确地实现所要求的功能，准确地给出预定的输出结果

（2）用户界面友好，符合实际用户的使用习惯与知识水平

（3）具有足够的速度，能在符合用户要求的时间限度内，给出所要求的处理结果

（4）具有足够的可靠性，能够在各种干扰下保持正常的工作

（5）程序易读，结构良好，文档齐全，从而保证系统易于修改

4.单个程序员需要具备的知识与技能：

（1）具有程序设计所需要的基本知识与技能

（2）对本项目所在的领域有较深入的了解

（3）对软件开发的技术环境比较熟悉

5.项目组的一员，除了实现自己分担的功能外，还需要

（1）保证严格地在本模块范围内操作，绝不要使用可能干扰其他模块的命令或函数

（2）严格按总体设计的要求和理解去传递参数值，决不要随意修改其内容或函数

（3）在对公用的文件或数据库进行存取时，必须完全地、准确地按统一规定的格式去操作，决不能擅自改变

（4）在使用标识符时，应按照统一的原则，尽量使用易于看出逻辑含义的名称，特别是涉及公用数据及参数的时候

（5）严格按照统一的要求编写文档，在内容、格式、表达方式、符号使用上遵循项目组的统一规定

（6）尽量保持程序风格的一致

6.好的项目组应具备的条件：

（1）有严格的、成文的工作规范和文档标准

（2）人员之间有严格的分工

（3）每个项目都要事先制定详细的时间表，且得到严格执行，每一项目完成之后都有完整的资料，并得到妥善保存

7.可视化程序设计的技术手段：

（1）指点与卡嗒，简称“点”

（2）删剪与粘贴，简称“剪贴”

（3）拖拉与扔下，简称“拖扔”

8.软件开发中涉及的信息有

（1）有关系统环境、现状及需求的信息

（2）有关软件的功能设计与物理设计的各种信息

（3）软件成果本身，包括程序与文档

（4）用户对系统的各种变更要求，以及系统的各种变更的记录

9.对各类信息的管理工作有：

（1）许多信息需要长期保存，包括一致性的检查与维护、方便迅速的查询与调用

（2）在许多环节上都要进行数据的转换与加工

（3）大量的人与人之间的信息交流

10.软件开发工具用到的理论和方法：

（1）认知科学中关于概念模式的概念与方法

（2）数据库技术的理论与方法

（3）编译技术的有关方法

（4）关于人机界面的理论与方法

（5）管理科学中关于项目管理与版本管理的理论与方法

（6）系统科学与系统工程中的有关理论与方法

1.在选择与购置软件开发工具时，最重要的是设置有限的、现实的目标，以及充分考虑各方面的环境因素，这两点对于软件开发工具是否切实发挥作用起着根本性的制约作用。

2.自行开发软件开发工具时应注意：

（1）从实际出发，设定现实的、有限的目标

（2）坚持短小实用、逐步积累、避免期望过高，贪大求全

（3）注意文档的齐全与资料的积累

（4）谨慎对待商品化

3.对于自行研制软件开发工具来说，除了技术上的各种考虑之外，主要是区分自己用还是作为商品出售

4.软件开发工具购置与开发权衡，考虑以下因素：

（1）准备从事软件开发工作的性质与要求

（2）开发人员对支持工作与支持程度的实际需要

（3）工作环境

（4）人员的情况

5.购置软件开发工具应考虑的问题：开发工具的功能如何，性能/价格比如何，开发工具所使用或依据的开发方法或开发理论是什么，开发工具运行环境是什么，文档资料是否齐全，服务、培训的条件如何以及实用性如何。

6.购置软件开发工具时，首先要明确目的与要求。

7.确定购置软件开发工具后，要明确目的与要求即明确

（1）为哪个软件开发项目而使用工具

（2）在哪个工作阶段使用工具

（3）工具将供那些人使用

（4）工具将在怎样的软、硬件环境下运行

8.在引入软件开发工具后，使用者必须从一开始就对它的使用过程进行认真地组织与管理，包括

（1）制定严格的使用制度

（2）记录实用的详细过程

（3）培训使用人员

（4）经常进行审计与评价工作

9.记录的内容包括：系统运行的次数、时间；信息库的输入与更新时间；各种输出的质量与

数据量；使用者的反映与满意程度，各种故障及处理的情况。

10.在软件开发工具的选择与购置中，应按照一下步骤进行

（1）明确购买软件开发工具的目的与要求

（2）明确购买软件开发工具的环境与制约条件

（3）市场调查

（4）对可供选择的各种工具进行综合比较

（5）进行测试和检验

（6）正式签约购置

(7)安装与试用

11.工作环境包括硬件配置、系统软件、网络通信等各种条件

12.决定购置还是自行开发工具的最根本因素是准备从事软件开发工作的性质与要求。

13.如果已决定配置软件开发工具，进行市场调查时，首先应该调查软件开发工具的功能。

14.引入软件开发工具后，还需要经常进行审计工作，即对软件工具使用的环境、人员、工作效果、存在问题及改进方向等方面进行评价。

第五篇：软件安全总结

一． 软件安全的基本概念

安全的基本概念：

1.计算环境内的软件安全

2.安全是相对的，安全是一种平衡 【软件的概念

与一系统（尤指计算机系统）有关的程序、步骤和有关文件编制的完整集合。特指特定类型的计算机所使用的程序的总称，连同与计算机或程序相关的资料，例如手册、图表和操作指令。【什么是信息

所谓信息，就是客观世界中各种事物的变化和特征的最新反映，是客观事物之间联系的表征，也是客观事物状态经过传递后的再现。【什么是信息安全



一类是指具体的信息技术系统的安全。

而另一类则是指某一特定信息体系的安全。

 但是有人认为这两种定义失之于过窄，而应定义为：一个国家的社会信息化状态不受外来的威胁与侵害，一个国家的信息技术体系不受外来的威胁与侵害。【信息安全的5个基本属性

安全性 可用性 保密性 可控性 可靠性 【软件的安全性

 软件安全性是指软件不被恶意使用或者攻击进而造成用户信息资产损失的属性。 软件安全：软件在恶意攻击下能够正确地完成其功能。【软件安全的属性3个

 软件的可信性，软件的完整性，软件的可用性，【软件安全研究范畴

 软件安全研究：如何设计、构造、验证和维护软件以保证其是安全的。 包括：改进和实现软件安全的架构或结构

改进和实现软件安全的工具

改进或实现软件安全的方法

【漏洞和脆弱性

安全漏洞：计算机系统具有的某种可能被入侵者恶意利用的属性；

有时安全漏洞也成为脆弱性；漏洞是软件的属性 【漏洞的本质

漏洞是系统的一组特性，恶意的主体（攻击者或者攻击程序）能够利用这组特性，通过已授权的手段和方式获取对资源的未经授权访问，或者对系统造成损害。【安全的的代码 vs 安全性的代码

安全的代码：能够抵抗恶意攻击的代码；安全的代码同时也是健壮的代码；

安全性代码：实现安全功能的代码； 二． 典型的安全问题及分析

【安全问题来源

安全问题的根本来源：1漏洞（漏洞是软件的属性）；2攻击者；3软件存在的攻击路径-攻击面问题； 【产生漏洞的原因

（1）软件或协议设计时的瑕疵（2）软件或协议实现中的弱点（3）软件本身的瑕疵（4）系统和网络的错误配置

【意外行为和缺陷

 意外行为（Unexpected Behavior）：也称程序安全缺陷，是由于程序脆弱性引起的不适当的程序行为。

 缺陷（Flaw）：缺陷可以是故障（Fault），或者失效（Failure）

 程序安全缺陷可能来源于任何种类的软件错误：无意或疏忽的，故意或有意

【缺陷类型

有意的缺陷（1）恶意的（Malicious）（2）非恶意的（Nonmalicious 无意中的缺陷（1）确认错误（2）域的错误（3）顺序化和混淆现象（4）不完全的身份识别和认证（5）边界条件违反（6）其它可利用的逻辑错误 【漏洞的两种类型

 设计漏洞：设计错误，往往发现于软件的安全功能特性中。 实现漏洞：来源于软件实际编码中的安全缺陷。

【常见安全设计问题

1缓冲区溢出 2未校验输入3资源竞争4访问控制问题5认证、授权、加密缺陷

【Owasp top 10 1注入2失效的身份认证3跨站脚本4不安全的直接对象引用5安全配置错误6敏感信息泄露7功能级访问控制缺失8跨站请求伪造9使用含有已知漏洞的组件10未验证的重定向和转发 三． 安全工程

【Sse-cmm 5级

能力级别１――非正式执行

公共特征：执行基本实施 能力级别２――计划与跟踪

公共特征：1计划执行2规范化执行3验证执行4跟踪执行 能力级别３――充分定义

公共特征：1定义标准过程2执行已定义的过程3协调安全实施 能力级别４――定量控制

公共特征：1建立可测的质量目标2客观地管理过程的执行 能力级别５――连续改进

公共特征：1改进组织能力2改进过程的有效性

【安全工程的三个基本过程

安全工程分三个基本过程：风险、工程和保证

– 风险过程是要确定产品或者系统的危险性，并对这些危险性进行优先级排序

– 工程过程是针对面临的危险性，安全工程过程与相关工程过程一起来确定并实施解决方案

– 保证过程是建立起对解决方案的信任，并把这种信任传达给顾客

【受攻击面分析

 受攻击面分析：枚举所有接口、协议以及可执行代码的过程。 软件的受攻击面：代码

接口

服务

协议

其他

【隐私影响分级 3级

 隐私分级1：满足以下任何一项，具有最高隐私分级

– 该软件储存PII或传输PII – 该软件目标是针对儿童或对儿童产生吸引力，或包含任何可以了解年龄的用户体验（按美国法案要求，收集PII需要成人权限，必须保护13岁以下儿童）

– 该软件不间断监控用户行为

– 该软件安装新的软件或改变用户文件类型的关联（如改变JPEG解码程序）

 隐私分级2：该软件传输匿名数据给开发人员或第三方

 隐私分级3：如果软件不包含隐私分级1、2中任何一种行为，则被划分为隐私分级3 四． 测试

【安全漏洞分级

DREAD模型：进行威胁程度级别分析的有效技术。

 DREAD：1潜在的破坏2再现性3可利用性4受影响用户5可发现性

TRAP模型：

 基于可利用性提出。

 TRAP包括因素：1时间2可靠性/再现性3访问4定位

【安全的常规测试方法

1.基于风险的安全测试3个步骤：1信息搜集2威胁（风险）建模3可用性分析 在一个威胁路径上的9个高风险活动：

1数据解析 2文件访问 3数据库访问 4生成子进程 5身份鉴别 6授权

7同步或会话管理

8处理私密数据

9网络访问

2.白盒，黑盒，灰盒测试

白盒测试：也称明盒测试、开盒测试或信息充分测试。白盒测试可以看作是内部的攻击。测试人员可以访问源代码和设计文档，可以进行威胁建模或逐行的代码检查。白盒测试是找出漏洞最为有效的方法。

黑盒测试：以局外人的身份对系统进行攻击，使用工具检查系统的攻击面，并探查系统的内部信息。黑盒测试是白盒测试的补充。方向工程团队利用黑盒测试验证隐蔽式安全方法的强度。

灰盒测试：组合使用白盒测和黑盒测试。白盒测试用于发现在设计和开发中详细说明

的功能中的缺陷；黑盒测试在无法了解程序内部信息的时候找出缺陷。程序开发中的调 试运行是典型的灰盒测试方法。

五 SDL的3原则

安全的设计

缺省安全 安全提交 六 信息系统的主要特征：

1一定是依赖于计算机的； 2涉及了计算机的软件和硬件；

3实现数据的采集、传递、加工、处理功能。

安全模型

业务数据用户界面逻辑业务逻辑登录控制网络数据服务用户数据访问日志数据信息主管权限管理日志审计系统管理员异常探测机 ISO 7498 五种

1身份鉴别2访问控制3数据保密4数据完整性5抗抵赖 七

WEB应用及其安全问题

WEB应用可以理解为利用HTTP与用户或者其他系统实现交互的C/S程序。而用户所使用的CLIENT一般是类似于IE等的浏览器或者是专门开发的HTTP代理。WEB SERVICE是一个打包在一起的功能集合，作为一个实体，发布至网络被其他程序所使用。

威胁建模的五个步骤

步骤 1 ：确定安全目标。步骤 2 ：创建应用程序概述。步骤 3 ：分解应用程序。步骤 4 ：确定威胁。步骤 5 ：确定漏洞。主要WEB应用协议

HTTP FTP MAIL协议 SSL 附加

微软安全工具使用相关知识 CWE,OWP OWASP是一个非盈利组织，其主要目标是致力于web 应用的安全问题。