软件质量保证和管理论文Word格式.doc

软件质量保证和管理论文Word格式.doc

《软件质量保证和管理论文Word格式.doc》由会员分享，可在线阅读，更多相关《软件质量保证和管理论文Word格式.doc（8页珍藏版）》请在冰点文库上搜索。

软件质量

1.1软件特点

软件是相对硬件的概念，是逻辑的，知识性的产品集合，是对物理世界的一种抽象或者是某种物理形态的虚拟化。

软件与硬件是完全不同的。

但是随着时间的推移，硬件构建会由于各种原因收到不同程度的磨损，软件不会。

新的硬件故障少，软件则相反。

另一方面，软硬件的维护差别很大。

1.2软件过程

软件过程为一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

软件过程（SoftwareProcess）是指一套关于项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关Artifacts（计划、文档、模型、编码、测试、手册等）组成。

软件过程可概括为三类：

基本过程类、支持过程类和组织过程类。

基本过程类包括需求分析、设计过程、编程过程、测试过程、维护过程。

支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及过程。

组织过程类包括基础设施过程、改进过程以及培训过程。

1.2.2软件开发过程模型

软件开发模型（SoftwareDevelopmentModel）是指软件开发全部过程、活动和任务的结构框架。

软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。

软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。

软件开发模型包括：

瀑布模型，原型模型，快速应用开发模型，螺旋模型，增量模型和迭代模型，构件组装模型，开发模型，并发模型，驱动测模型，RATIONAL统一过程模型，协议开发——形式描述技术FDT，敏捷方法——极限编程模型。

1.2.3V模型的完整诠释

V模型是在快速应用开发模型基础上演变而来的，由于将整个开发过程构成一个V字而得名。

V模型强点软件开发写作的速度和协作，将软件实现和验证邮寄的结合起来，在保证较高的软件质量情况下缩短开发周期。

图为简单的V模型

V模型的缺陷　　仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段　　忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。

1.2.4敏捷方法的极限编程

是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。

它们的具体名称、理念、过程、术语都不尽相同，相对于"

非敏捷"

，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

敏捷开发的宗旨就是“沟通，简化，反馈，激励”。

极限编程是敏捷方法的代表是一个轻量级的、灵巧的软件开发方法；

同时它也是一个非常严谨和周密的方法。

它的基础和价值观是交流、朴素、反馈和勇气；

即，任何一个软件项目都可以从四个方面入手进行改善：

加强交流；

从简单做起；

寻求反馈；

勇于实事求是。

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；

通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

极限编程中有四个核心价值是我们在开发中必须注意的：

沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。

XP用“沟通、简单、反馈和勇气”来减轻开发压力和包袱；

无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。

这是一种帮助理解和更容易激发人的潜力的手段。

XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

1.2.5阶段性开发模型

软件开发不管采用什么手段什么模型都不是一蹴而就的，一个软件产品的开发往往是分阶段进行的，所以阶段性开发模型是很有必要的。

软件分阶段开发主要原因：

1.市场的压力和竞争策略的需要。

2.产品的开发周期和资源会受到预算的限制。

3.可以尽在发现错误，降低成本。

4.系统设计越来越困难。

分阶段软件开发可以通过增量模型和迭代模型两种来描述。

两者的最终目标是一致的，都是为了实现一个功能完善的、高质量的、稳定的产品。

1.3软件缺陷

　软件缺陷（Defect），常常又被叫做Bug。

所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。

缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

IEEE729-1983对缺陷有一个标准的定义：

从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；

从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

在软件开发生命周期的后期，修复检测到的软件错误的成本较高。

1.3.1产生的原因

在软件开发的过程中，软件缺陷的产生是不可避免的。

那么造成软件缺陷的主要原因有哪些？

从软件本身、团队工作和技术问题等角度分析，就可以了解造成软件缺陷的主要因素。

　　软件缺陷的产生主要是由软件产品的特点和开发过程决定的。

软件本身

①需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。

　　②系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；

即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。

③对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。

④对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。

⑤没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。

⑥系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；

在系统实际应用中，数据量很大。

从而会引起强度或负载问题。

⑦由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。

　　⑧新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

1.3.2软件缺陷的分类

属性名称描述缺陷标识（Identifier）缺陷标识是标记某个缺陷的一组符号。

每个缺陷必须有一个唯一的标识缺陷类型（Type）缺陷类型是根据缺陷的自然属性划分的缺陷种类。

缺陷严重程度（Severity）缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

缺陷优先级（Priority）缺陷的优先级指缺陷必须被修复的紧急程度。

缺陷状态（Status）缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

缺陷起源（Origin）缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。

缺陷来源（Source）缺陷来源指引起缺陷的起因。

缺陷根源（RootCause）缺陷根源指发生错误的根本因素。

缺陷类型（Type）

　　缺陷类型编号缺陷类型描述10F-Function影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。

并且设计文档需要正式的变更。

如逻辑，指针，循环，递归，功能等缺陷。

20A-Assignment需要修改少量代码，如初始化或控制块。

如声明、重复命名，范围、限定等缺陷。

30I-Interface与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。

40C-Checking提示的错误信息，不适当的数据验证等缺陷。

50BBuild/package/merge由于配置库、变更管理或版本控制引起的错误。

60D-Documentation影响发布和维护，包括注释。

70G-Algorithm算法错误。

80U-UserInterface人机交互特性：

屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。

90P-Performance不满足系统可测量的属性值，如：

执行时间，事务处理速率等。

100N-Norms不符合各种标准的要求，如编码标准、设计符号等。

缺陷严重程度（Severity）

　　1.3.1软件测试错误严重程度　　#缺陷严重等级描述1Critical不能执行正常工作功能或重要功能。

或者危及人身安全。

2Major严重地影响系统要求或基本功能的实现，且没有办法更正。

（重新安装或重新启动该软件不属于更正办法）3Minor严重地影响系统要求或基本功能的实现，但存在合理的更正办法。

（重新安装或重新启动该软件不属于更正办法）4Cosmetic使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。

5Other其它错误。

　　1.3.2同行评审错误严重程度　　#缺陷严重等级描述Major主要的，较大的缺陷Minor次要的，小的缺陷

缺陷优先级（Priority）

　　#缺陷优先级描述1ResolveImmediately缺陷必须被立即解决。

2NormalQueue缺陷需要正常排队等待修复或列入软件发布清单。

3NotUrgent缺陷可以在方便时被纠正。

缺陷状态（Status）

　　缺陷状态描述Submitted已提交的缺陷Open确认“提交的缺陷”，等待处理Rejected拒绝“提交的缺陷”，不需要修复或不是缺陷Resolved缺陷被修复Closed确认被修复的缺陷，将其关闭

缺陷起源（Origin）

　　缺陷起源描述Requirement在需求阶段发现的缺陷Architecture在构架阶段发现的缺陷Design在设计阶段发现的缺陷Code在编码阶段发现的缺陷Test在测试阶段发现的缺陷

缺陷来源（Source）

缺陷来源描述　　Requirement：

由于需求的问题引起的缺陷　　Architecture：

由于构架的问题引起的缺陷　　Design：

由于设计的问题引起的缺陷　　Code：

由于编码的问题引起的缺陷　　Test：

由于测试的问题引起的缺陷　　Integration：

由于集成的问题引起的缺陷

1.4软件质量

概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。

具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。

影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。

可划分为三组，分别反应用户在使用软件产品时的三种观点。

正确性、健壮性、效率、完整性、可用性、风险（产品运行）；

可理解性、可维修性、灵活性、可测试性（产品修改）；

可移植性、可再用性、互运行性（产品转移）。

标准

（1）软件需求是度量软件质量的基础，与需求不一致就是质量不高。

（2）指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。

　　（3）通常，有一组没有显式描述的隐含需求（如期望软件是容易维护的）。

如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。

编辑本段QA和QC

　　QA即英文QUALITYASSURANCE的简称，中文意思是质量保证；

　　QC即英文QUALITYCONTROL的简称，中文意义是质量控制。

　　QC和QA的主要区别前者是保证产品质量符合规定,后者是建立体系并确保体系按要求运作,以提供内外部的信任.同时QC和QA又有相同点:

即QC和QA都要进行验证,如QC按标准检测产品就是验证产品是否符合规定要求,QA进行内审就是验证体系运作是否符合标准要求,又如QA进行出货稽核和可靠性检测,就是验证产品是否已按规定进行各项活动,是否能满足规定要求,以确保工厂交付的产品都是合格和符合相关规定的。

编辑本段软件开发

需求分析

　　确保客户所要求的系统是可行的。

　　确保客户指定的需求确实能够满足他的真正要求。

　　避免开发者和客户之间的误解。

　　向用户提供为满足他所提出的需求而实际构建的适当软件系统。

软件规格说明

　　通过建立需求跟踪文档，确保规格说明书与系统需求保持一致。

　　确保规格说明书能适当地改进系统的灵活性、可维护性以及性能。

　　确保已建立了测试策略。

　　确保已建立了现实的开发进度表，包括预定的评审。

　　确保已为系统设计了正式的变更规程。

设计

　　确保已建立用于描述设计的标准，并且确保遵循这些标准。

　　确保适当地控制并用文档记录对设计进行的变更。

　　确保在系统设计组件已按照商定的准则得到批准之后才开始编码。

　　确保对设计的评审按照进度进行。

　　确保代码遵循已建立的风格、结构和文档标准。

　　确保代码经过适当测试和集成，同时对编码模块的修改得到适当的标识。

　　查看代码编写是否遵循既定的进度。

　　确保代码评审按照进度进行。

测试

　　确保测试计划的建立和遵循。

　　确保创建的测试计划能够满足所有系统规格说明书的要求。

　　确保经过测试和返工后软件与规格说明书保持一致。

维护

　　确保代码和文档的一致性。

　　确保对已建立的变更控制过程进行监测，包括将变更集成到软件的产品版本中的过程。

　　确保对代码的修改遵循编码标准，并且要对其进行评审，不要破坏整个代码结构。

1.5小结

本章主要介绍了软件的自身特点，然后介绍了软件的基本过程：

需求分析，设计，编程，测试和维护等。

介绍了软件开发模型以及质量内容和缺陷。

解释了软件开发的规律。

特征和基本方法。

何江敬

5月30日