如何理解软件与软件工程.docx

《如何理解软件与软件工程.docx》由会员分享，可在线阅读，更多相关《如何理解软件与软件工程.docx（31页珍藏版）》请在三一文库上搜索。

1、第一章软件与软件工程1. 1软件（Software）1.1.1 软件与软件的组成计算机软件一一与计算机系统操作有关的程序、规程、规则及任何与之有关的文档和数据。软件程序及有关数据一机器可执行；文档（与软件开发、运行、维护、使用、培训有关）不可执行。程序（PrOgram）用程序设计语言描述的，适合于计算机处理的语句序列。程序设计语言三种类型：1 .机器语言、汇编语言：依赖于机器，面向机器2 .高级语言：独立于机器，面向过程或面向对象3 .面向问题语言：独立于机器，非过程式语言（4GL）文档（document）一种数据媒体和其上所记录的数据。文档记录软件开发活动和阶段成果，具有永久性，可供人或机器

2、阅读。文档可用于专业人员和用户之间的通信和交流；软件开发过程的管理；运行阶段的维护。1 .软件的特点软件是逻辑产品，硬件是物理产品。特点：（软件开发更依赖于开发人员的业务素质、智力、人员的组织、合作和管理。软件开发、设计几乎都是从头开始，本钱和进度很难估计。（2）软件存在潜伏错误，硬件错误一般能排除。（3）软件开发成功后，只需对原版进行复制。（4）软件在使用过程中维护复杂：D纠错性维护一改正运行期间发现的潜伏错误；2）完善性维护一提高或完善软件的性能；3）适应性维护一修改软件，以适应软硬件环境的变化；4）预防性维护一改良软件未来的可维护性和可靠性。（5）软件不会磨损和老化。2 软件的开展第一阶

3、段一一20世纪60年代中期以前，软件开发处于个体化生产状态。在这一阶段中，软件还没有系统化的开发方法。目标主要集中在如何提高时空效率上。第二阶段一一从20世纪60年代中期到70年代末期。软件开发已进入了作坊式生产方式，即出现了“软件车间。软件开发开始形成产品。到20世纪60年代末，“软件危机变得十分严重。第三阶段一一从20世纪70年代中期到20世纪80年代末期。软件开发进入了产业化生产，即出现了众多大型的“软件公司。在这一阶段，软件开发开始采用了“工程的方法，软件产品急剧增力口，质量也有了很大的提高。第四阶段一一从20世纪80年代末期开始的。这是一个软件产业大开展的时期。也是软件工程大开展的时

4、期，人们开始采用面向对象的技术和可视化的集成开发环境。1. 1.2软件危机软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。1 .软件危机的表现1）对软件开发本钱和进度的估计常常很不准确。常常出现实际本钱比估算本钱高出一个数量级、实际进度比方案进度拖延几个月甚至几年的现象，从而降低了开发商的信誉，引起用户不满。2）用户对已完成的软件不满意的现象时有发生。3）软件产品的质量往往是靠不住的。4）软件常常是不可维护的。5）软件通常没有适当的文档资料。文档资料不全或不合格，必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。6）软件本钱在计算机系统总本钱中所占比例逐

5、年上升。特别是软件维护本钱迅速增加，已经占据软硬件总本钱的40限75%。7）开发生产率提高的速度远跟不上软件需求。60%40%20%1955年1970年1985年oo%80%图1-1-1软件、硬件成本变化焰势2 .产生软件危机的原因1）用户对软件需求的描述不精确。2）软件开发人员对用户需求的理解有偏差，这将导致软件产品与用户的需求不一致。3）缺乏处理大型软件工程的经验。开发大型软件工程需要组织众多人员共同完成。一般来说，多数管理人员缺乏大型软件的开发经验，而多数软件开发人员又缺乏大型软件工程的管理经验，致使各类人员的信息交流不及时、不准确、容易产生误解。4）开发大型软件易产生疏漏和错误。5）缺

6、乏有力的方法学的指导和有效的开发工具的支持。软件开发过多地依靠程序员的“技巧，从而加剧了软件产品的个性化。6）面对日益增长的软件需求，人们显得力不从心。从某种意义上说，解决供求矛盾将是一个永恒的主题。3 .缓解软件危机的途径到了20世纪60年代末期，软件危机已相当严重。这促使计算机科学家们开始探索缓解软件危机的方法。他们提出了“软件工程的概念，即用现代工程的原理、技术和方法进行软件的开发、管理、维护和更新。于是，开创了计算机科学技术的一个新的研究领域。1.2软件工程的概念1.2.1软件工程的定义1968年，北大西洋公约组织在原西德召开计算机科学会议，由FritZBaUer首次提出了“软件工程的

7、概念。软件工程一一用工程、科学和数学的原则与方法开发、维护计算机软件的有关技术和管理方法。软件工程由方法、工具和过程三局部组成，称软件工程的三要素。1. 2.1软件工程的定义 软件工程中的各种方法是完成软件工程工程的技术手段，它们支持软件工程的各个阶段。 软件工程使用的软件工具能够自动或半自动地支持软件的开发、管理和文档的生成。 软件工程中的过程贯穿于整个工程的各个环节，在这一过程中，管理人员应对软件开发的质量、进度、本钱等进行评估、管理和控制，包括方案跟踪与控制、本钱估算、人员的组织、质量保证、配置管理等1.2.2软件工程的根本原理著名的软件工程专家B.W.BOehm于1983年综合了软件工

8、程专家学者们的意见并总结了开发软件的经验，提出了软件工程的7条根本原理。这7条原理被认为是确保软件产品质量和开发效率的原理的最小集合，又是相互独立、缺一不可、相当完备的最小集合。下面就简单介绍软件工程的这7条原理：1 .用分阶段的生存周期方案严格管理2 .坚持进行阶段评审3 .实行严格的产品控制4 .采用现代程序设计技术5 .结果应能清楚地审查6 .开发小组的人员应少而精7 .成认不断改良软件工程实践的必要性1.2.3 软件工程的目标软件工程的目标是在给定本钱、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并满足用户需求

9、的软件产品。名词解释1)可修改性(modifiability),允许对软件系统进行修改而不增加其复杂性。它支持软件调试与维护。2)有效性(efficiency),指软件系统的时间和空间效率。这是一个应当努力追求的重要目标。3)可靠性(reliability),是指在给定的时间间隔内，程序成功运行的概率。可靠性是衡量软件质量的一个重要目标。4)可理解性(UnderStandability),指系统具有清晰的结构，能直接反映问题的需求。可理解性有助于控制软件系统的复杂性，并支持软件的维护、移植和重用。5)可维护性(maintainability),是指软件产品交付使用后，在实现改正潜伏的错误、改良

10、性能等属性、适应环境变化等方面工作的难易程度。由于软件的维护费用在整个软件生存周期中占主要的比重，因此，可维护性是软件工程中的一个十分重要的目标。软件的可理解性和可修改性支持软件的可维护性。6)可重用性(reusability),是指软部件可以在多种场合使用的程度。概念或功能相对独立的一个或一组相关模块可构成一个软部件。软部件应具有清晰的结构和注释、正确的编码和较高的时空效率。可将各种软部件按照某种规则放在软部件库中供开发人员选用。广义地讲，可重用性还应包括应用工程、规格说明、设计、概念和方法等等的重用。一般来说，重用的层次越高,带来的效益越可重用性有助于提高软件产品的质量和开发效率、降低软件

11、开发和维护费用。7)可适应性(adaptability),是指软件在不同的系统约束条件下，使用户需求得到满足的难易程度。选择广为流行的软硬件支持环境、采用广为流行的程序设计语言编码、采用标准的术语和格式书写文档可增强软件产品的可适应性。8)可移植性(POrtability),是指软件从一个计算机系统或环境移植到另一个上去的难易程度。采用通用的运行支持环境和尽量通用的程序设计语言的标准局部可提高可移植性。而应将依赖于计算机系统的低级(物理)特征局部相对独立、集中起来。可移植性支持软件的可重用性和可适应性。9)可追踪性(traceability),是指根据软件需求对软件设计、程序进行正向追踪，或根

12、据程序、软件设计对软件需求进行逆向追踪的能力。软件开发各阶段的文档和程序的完整性、一致性、可理解性支持软件的可追踪性。10)可互操作性(interoperability),是指多个软件元素相互通信并协同完成任务的能力。1.2.4 软件工程的原则1 .抽象(abstraction),抽取各个事物中共同的最根本的特征和行为，暂时忽略它们之间的差异。一般采用分层次抽象的方法来控制软件开发过程的复杂性。抽象使软件的可理解性增强并有利于开发过程的管理。2 .信息隐藏(informationhiding),将模块内部的信息(数据和过程)封装起来。其他模块只能通过简单的模块接口来调用该模块，而不能直接访问该

13、模块内部的数据或过程，即将模块设计成“黑箱。信息隐藏的原则可使开发人员把注意力集中于更高层次的抽象上。3 .模块化：4 .局部化(localization),即在一个物理模块内集中逻辑上相互关联的计算资源。局部化支持信息隐藏，从而保证模块之间具有松散的耦合、模块内部有较强的内聚。这有助于控制每一个解的复杂性。5 .一致性(COnSiStenCy),整个软件系统(包括程序、数据和文档)的各个模块应使用一致的概念、符号和术语；程序内部接口应保持一致；软件与环境的接口应保持一致；系统规格说明应与系统行为保持一致；用于形式化规格说明的公理系统应保持一致。6 .完全性(completeness),软件系

14、统不丧失任何重要成分，完全实现所需的系统功能的程度。为了保证系统的完全性，在软件的开发和维护过程中需要严格的技术评审。7 .可验证性(Verifiability),开发大型软件系统需要对系统逐层分解。系统分解应遵循易于检查、测试、评审的原则，以使系统可验证。抽象、信息隐藏、模块化和局部化的原则支持可理解性、可修改性、可靠性等目标，并可提高软件产品的质量和开发效率；一致性、完全性和可验证性等原则可以帮助软件开发人员去实现一个正确的系统。1.3软件生存周期软件从定义开始，经过开发、使用和维护，直到最终退役的全过程称为软件生存周期。可将软件生存周期划分为3个过程共9个阶段。3个过程是：软件定义过程、

15、软件开发过程、软件使用与维护过程。9个阶段有：可行性研究、需求分析、概要设计、详细设计、实现、组装测试、验收测试、使用与维护、退役。它们之间的关系如图3-1所示。定工程I可行性研彳J需求分析口既要设计详细设计开发过程实现组装测试作收测试用与维护使用与维护过程_L1退役(图1-3T)1. 3.1软件定义软件定义的根本任务是确定软件系统的工程需求，也就是要搞清“做什么。软件定义过程可通过软件系统的可行性研究和需求分析两个阶段来完成。1 .可行性研究 本阶段的任务是根据用户提出的工程工程的性质、目标和规模，进一步了解用户的要求及现有的环境及条件，从技术、经济和社会等多方面研究并论证该工程的可行性。即

16、该工程是否值得去解决，是否存在可行的解决方法。 此时，系统分析人员应在用户的配合下对用户的要求和现有的环境进行深入调查并写出调研报告。进而进行可行性论证。可行性论证包括经济可行性、技术可行性、操作可行性、法律可行性等。在此基础上还要制定初步的工程方案，包括需要的软硬件资源、定义任务、风险分析、本钱/效益分析以及进度安排等。 可行性研究的结果将是使用部门负责人做出是否继续进行该工程决定的重要依据。2 .需求分析D需求分析的任务需求分析的任务是确定待开发的软件系统“做什么。具体任务包括确定软件系统的功能需求、性能需求和运行环境约束，编制软件需求规格说明书、软件系统的验收测试准则和初步的用户手册。2

17、需求分析的实现途径软件系统需求一般由用户提出。系统分析员和开发人员在需求分析阶段必须与用户反复讨论、协商，充分交流信息，并用某种方法和工具构建软件系统的逻辑模型。为了使开发方与用户对待开发软件系统达成一致的理解，必须建立相应的需求文档。有时对大型、复杂的软件系统的主要功能、接口、人机界面等还要进行模拟或建造原型，以便向用户和开发方展示待开发软件系统的主要特征。确定软件需求的过程有时需要反复屡次，最终得到用户和开发者确实认。3）需求分析的阶段成果需求分析阶段的主要成果有软件需求规格说明、软件验收测试方案和准则、初步的用户手册等。其中，软件需求规格说明（SoftwareRequirementsS

18、pecification,即SRS）,是一个关键性的文档。1.3.2 软件开发 软件开发过程由概要设计、详细设计、实现（即编码与单元测试）、组装测试、验收测试共5个阶段组成。 其中，概要设计和详细设计统称为设计；编码即编程；单元测试、组装测试和验收测试统称为测试。 开发者通常可提出多种设计方案，并对各种方案在功能、性能、本钱、进度等方面进行比较和折衷，从中选出一种“最正确方案。1.3.3 软件的使用与维护1 .软件使用与维护阶段任务：通过各种维护活动使软件系统持久地满足用户的需求。每项维护活动实质上都是一次压缩和简化了的软件定义和软件开发过程。都要经历提出维护要求、分析维护要求、提出维护方案、

19、审批维护方案、确定维护方案、修改软件设计、修改程序、测试程序、评审、验收等步骤。1 .软件使用与维护阶段应当指出，软件在使用的过程中，应及时收集被发现的软件错误，并定期撰写“软件问题报告；而每一项维护活动都应该准确地记录下来，并作为正式的文档资料保存。据统计，软件维护人员为了分析和理解原软件系统所花费的工作量约占整个维护工作量的60%以上。在软件开发的过程中应重视对软件可维护性的支持。2 .退役B1-3-2软淋啸与物用岫层次对殷系1.4软件开发模型 软件开发模型（又称为软件生存周期模型）一软件工程开发和维护的总体过程思路的框架。 它指出了软件开发过程各阶段之间的关系和顺序，是软件开发过程的概括

20、它为软件开发过程提供原则和方法，并为软件工程管理提供里程碑和进度表。因此，软件开发模型也是软件工程的重要内容。 软件开发模型的几种类型： 以软件需求完全确定为基础的瀑布模型； 在开发初期仅给出根本需求的渐进式模型，如原型模型、螺旋模型、喷泉模型等； 以形式化开发方法为基础的变换模型、基于四代技术的模型； 基于知识的智能模型等等。在实际开发时，应根据工程的特点和现有的条件选取适宜的模型，也可以把几种模型组合起来使用以便充分利用各模型的优点。1. 4.1瀑布模型瀑布模型（waterfallmodel）是由W.ROyCe于1970年提出来的。又称为软件生存周期模型。瀑布模型严格按照软件生存周期各个

21、阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果及文档，每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通过后才能开始下一阶段的工作。因止匕它是一种以文档作为驱动的模型。借求分析IM洌1I4,I;三yIIBi-4-i带反蕾娜布皿瀑布模型优点：提供了软件开发的根本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。瀑布模型缺点1）在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。2）在需求分析阶段，当需求确定后，无

22、法及时验证需求是否正确、完整。3）作为整体开发的瀑布模型，由于不支持产品的演化，缺乏灵活性，对开发过程中很难发现的错误，只有在最终产品运行时才能暴露出来，从而使软件产品难以维护。瀑布模型适应场合瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如操作系统、编译系统、数据库管理系统等系统软件的开发。应用有一定的局限性。1.4.2 原型模型原型模型（prototypingmodel）的根本框架是软件开发人员根据用户提出的软件根本需求快速开发一个原型，以便向用户展示软件系统应有的局部或全部功能和性能，在征求用户对原型的评价意见后，进一步使需求精确化、完全化，并据此改良、完善原型，

23、如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。软件需求确定后，便可进行设计,编码、测试等以后的各个开发步骤。快速原型的开发途径有三种：O仅模拟软件系统的人机界面和人机交互方式。2）开发一个工作模型，实现软件系统中重要的或容易产生误解的功能。3）利用一个或几个类似的正在运行的软件向用户展示软件需求中的局部或全部功能。总之，建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技术，在运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系统的可见局部，如人机界面、数据的输入方式和输出格式等。原型模型的适应场合原型模型比瀑布模型更符合人们认识事物的过程和规律

24、是一种较实用的开发框架。它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些工程组成员（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情况。1.4.3 螺旋模型螺旋模型（SPiralmOdel）是B.Boehm于1988年提出的。它综合了瀑布模型和原型模型的优点，即将两者结合，并参加了风险分析机制。螺旋模型的根本框架如图螺旋模型的每一个周期都包括方案（需求定义）、风险分析、工程实现和评审4个阶段。1 .方案（需求定义）第一周期开始利用需求分析技术理解应用领域，获取初步用户需求，制定工程开发方案（即整个软件生命周期方案）和需求分析方案。经过一个周期后，根据用户和开发人员

25、对上一周期工作成果评价和评审，修改、完善需求，明确下一周期软件开发的目标、约束条件，并据此制定新一轮的软件开发方案。2 .风险分析根据本轮制定的开发方案，进行风险分析，评估可选方案，并构造原型进一步分析风险，给出消除或减少风险的途径。此时根据风险分析的结果断策工程是否继续。所以，螺旋模型是一个风险驱动的模型。3 .工程实现利用构造的原型进行需求建模或进行系统模拟，直至实现软件系统。4 .用户评价与阶段评审将原型提交用户使用并征求改良意见。开发人员应在用户的密切配合下进一步完善用户需求，直到用户认为原型可满足需求，或对软件产品设计进行评价或确认等。螺旋模型从第一个周期的方案开始，一个周期、一个周

26、期地不断迭代，直到整个软件系统开发完成。螺旋模型的缺点和适应场合缺点：如果每次迭代的效率不高，致使迭代次数过多，将会增加本钱并推迟提交时间；使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。适应场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。习题思考题1.3 什么是软件工程？构成软件工程的要素是什么？1.4 软件工程的7条原理都是什么？1.5 软件工程的目标是什么？1.7 软件工程的7条原则是什么？说明这些原则的作用。1.8 软件生存周期由哪几个过程组成？每个过程分别包括哪几个阶段？1.1

27、3 软件开发模型、软件开发方法、集成的CASE工具与环境在软件工程中各有什么作用？第2章软件工程管理软件工程管理必须从工程的开头介入，并贯穿于整个软件生存周期的全过程。软件工程管理的范围主要集中于3个P上，BP：People（人员），Problem（问题）和ProCeSS（过程）。 软件工程管理的主要任务是：根据选定的软件开发过程框架（即软件开发模型）和对其估算的结果制定软件工程实施方案;再根据方案对人员进行组织、分工；按照方案的进度，以及本钱管理、风险管理、质量管理的要求，控制并管理软件开发和维护的活动，最终以最小的代价完成软件工程规定的全部任务。 软件工程的本钱管理、软件质量管理和软件配置

28、管理有一定的特殊性和独立性，可单独立项。其任务分别是： 本钱管理一一估算软件工程的本钱，作为立项和签合同的依据之一，并在软件开发过程中按方案管理经费的使用； 质量管理一一制定软件质量保证方案，按照质量评价体系控制软件质量要素，对阶段性的软件产品进行评审，对最终软件产品进行确认，确保软件质量； 配置管理一一制定配置管理方案，对程序、数据、文档的各种版本进行管理，确保软件的完整性和一致性。 在制定有效的工程实施方案的过程中，首先要对工程的工作量、完成期限等等参考量进行估算。估算的结果将成为工程方案其他活动的基础，同时，为了对软件工程进行科学、有效的管理，就必须对软件开发过程的有关特征进行度量，度量

29、的结果用于软件开发过程的管理与监控。 本章主要介绍软件度量的概念，软件的规模度量，软件工程的估算，软件的质量度量、复杂性度量、可靠性度量、风险的分析与度量以及软件工程管理过程与步骤等等。2软件度量对软件工程工程的规模、本钱、产品质量等属性进行定量的描述，可以帮助工程管理人员和开发者制定有效的工程方案，监控工程的风险、进度和阶段产品的质量，并为调整过程中活动和做出重要决策提供可靠的依据。下面介绍软件度量的根本概念，并介绍软件的规模度量和功能度量。2.1.1软件度量的根本概念1 .测量、度量、估算和指标软件工程工程的定量描述涉及测量、度量、估算和指标等一些根本概念。D测量（measure）：对产品

30、或过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示。2）度量（metric）：对系统、部件或过程的某一特性所具有的程度进行的量化测量。如软件质量度量等。3）估算（estimation）：对软件产品、过程、资源等使用历史资料或经验公式等进行预测。如工作量、本钱、完成期限等。估算一般用于立项、签订合同、制定工作方案等。4）指标（guideline）指标一一是一个度量或度量的组合，它可对软件产品、过程或资源提供更深入的理解。如有4个小组共同完成一个软件工程，每一个小组都必须采用自行选择的评审类型进行技术评审。管理者检查“每小时每人所发现的错误数这一度量结果时发现：采用正式技术评审方法的

31、两个小组的该度量值要比另外两个小组高出40%。假设4个小组的其他参数都相同，这就给管理者提供了一个指标：正式技术评审方法比其他技术评审方法更有效率。于是，管理者可决定建议所有小组都采用更加正式的技术评审方法。2 .软件工程管理的对象及其属性软件工程管理的对象主要包括产品、过程和资源等。 产品（ProdUCt）是指软件开发过程得到的文档和程序，如：需求规格说明、设计规格说明、源代码、测试报告等； 过程（PrOCeSS）是指与软件工程有关的活动，如软件工程方案、开发活动、维护活动、管理活动等； 资源（resource）是指进行软件工程所需要的各种支持，如人力、经费、方法、工具、软硬件环境等。要对软

32、件工程管理的对象进行有效的管理与控制，就必须对这些对象的属性进行测量、度量与估算。一般来说，产品、过程、资源等对象都具有内部属性和外部属性。对象的属性 内部属性是指对象本身的属性，如软件产品的代码长度、模块化的程度、复杂性等。 对象的外部属性表达了对象与环境的关系，如软件的可靠性、可维护性、可移植性、本钱、人员的生产率等。对象的局部属性如表2T所示。对象的属性 工程管理员和用户都十分关心产品、过程、资源的外部属性，于是可将外部属性看成是面向管理员和用户的属性。但在软件开发的过程中，软件的外部属性一般是很难度量和控制的。这些外部属性是由软件的内部属性所决定的，因此，可以通过研究内部属性与外部属性

33、之间的关系来解决外部属性的度量问题，进而逐步建立起了软件工程度量系统。3.软件度量的分类可分为直接度量和间接度量两类：1）直接度量。即对不依赖于其他属性的简单属性的测量。如软件的模块数、程序的代码行数、操作符的个数，工作量、本钱等。2）间接度量。即对涉及若干个其他属性的软件要素、准则或属性的度量。因为它们必须通过建立一定的度量方法或模型才能间接推断而获得。如软件的功能性、复杂性、可靠性、可维护性等等。软件度量系统还可进一步划分为两个侧面。它们之间的关系如图2-IT所示。2.1.2面向规模的度量面向规模的度量是以软件的代码行（LOC,LineofCode）数为基础的直接度量。一般的软件开发组织对

34、开发过的每个软件工程都有如代码行、工作量、本钱、错误、人数、文档页数等的统计记录。利用代码行数可以度量软件规模、生产率、平均本钱、出错率、文档率等参考量。设：L表示软件的代码行数，单位为KLoC（千行代码）或LOC；E表示开发软件所需工作量，单位为人月（PM）或人年（PY）；S表示软件本钱，单位为美元或元；N表示错误个数；Pd表示软件文档页数；M表示开发所用的人数。则有：1 .软件开发的生产率P（即平均每人月开发的代码行数，以Loe/PM为单位）为：P=L/E2 .开发每行代码的平均本钱C（以美元/LOC或元/LOC为单位）为：C=S/L3 .代码出错率EQR（即每千行代码的平均错误数，以个/

35、KLOC为单位）为：EQR=N/L4 .软件的文档率D（即平均每千行代码的文档页数，以页/KLOC为单位）为：D=Pd/L【例】有一个国外典型的软件工程的记录，开发人员MW人,其代码行数，工作量E=43PM,本钱S=314000美元，错误数N=64,文档页数Pd=IO50页。试计算开发该软件工程的生产率P、平均本钱C、代码出错率EQR和文档率D。解：根据给出的数据，可得：P=L/E=20.2KLOC/43PM=0.47KLOC/PM=470LOC/PMC=S/L=314000美元/20.2KLOC=15.54美元/LOCEQR=N/L=64个/20.2KL0C=3.17个/KLOCD=Pd/L

36、1050页/20.2KLOC=51.98页/KLOC基于代码行面向规模的度量方法的优缺点、适用场合优点：简单、直接。缺点：如它依赖于程序设计语言的功能和表达等特征、在开发初期很难准确估算出代码行数、对设计水平高的软件工程产生不利影响。适用场合：适合于过程式程序设计语言和事后度量。2.2软件工程估算2.2.1 软件工程的估算方法常用的软件工程的估算方法主要有以下4种：1 .自顶向下的估算方法 根本思想：首先根据已完成工程的总本钱或总工作量来推算待开发软件的总本钱或总工作量，然后再按比例将其分配到各开发任务中去。即从整体到局部。 优点：估算工作量小、速度快。 缺点：对工程中的特殊困难估计缺乏，有

37、可能产生遗漏，估算出的值盲目性较大。2 .自底向上的估算方法 根本思想是：把待开发软件细分，直到每一个子任务或阶段都已经明确所需要的开发工作量或本钱，然后再把它们累加起来，得到待开发软件的总工作量或总本钱。需要指出，在对软件进行细分时，一种是按照功能将大的软件工程划分为若干个子工程；另一种是按照软件生命周期分解为各个阶段。当然，也可以两者同时进行。 优点：计算各个局部的准确性较高。 缺点：缺少各个子任务之间相互联系的工作量和系统工作量(如工程管理、配置管理、质量管理)，估算值往往偏低，必须用其他方法进行校正。3 .差异估算法 根本思想：把待开发的软件工程与过去完成的软件工程进行比较，从各子任务

38、中区分出类似的和不同的局部。类似的局部按的实际量计算，不同的局部则采用某种方法进行估算。差异估算法综合了以上两种方法的优点。 优点：估算的准确程度高。 缺点：不容易划分相似的界限。4 根据经验估算公式 通过众多实际软件工程的经验，总结出一些有价值的软件本钱和工作量估算的经验模型。这些模型对于软件工程管理具有一定的指导意义和验证效果。 没有一种估算模型能够适合于所有类型的软件工程。因此，对估算的结果应当慎重使用。 在实际估算时，几种估算方法可单独、同时或组合使用，以便提高估算的准确程度。2. 2.2代码行和功能点的估算采用中介绍的估算方法可以估算出代码行或功能点的乐观值a、一般值m和悲观值b,并

39、用如下的加权平均公式计算LOC或FP的期望值(expectation)：X=(a+4m+b)/6(2TO)软件的LoC或FP的期望值估算出来后，就可以根据已有的标准生产率对本钱和工作量等进行估算了。2.3软件质量度量软件质量是软件的生命。它作为软件工程的一局部，贯穿于整个软件生存周期之中。生产高质量的软件产品是软件工程的首要目标。由于软件是逻辑产品，软件质量很难直接度量。因此，应当给出软件质量的科学的、实用的定义，并通过一定的度量模型进行度量，以便在整个软件生存周期中对其进行评价和控制。2. 3.1软件质量的定义1983年，ANSI/IEEEstd729标准给出了软件质量的定义如下：软件质量是

40、软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，包括：1 .软件产品满足用户要求的程度；2 .软件拥有所期望的各种属性的组合程度；3 .用户对软件产品的综合反映程度；4 .软件在使用过程中满足用户需求的程度。2. 3.2软件质量的度量模型 软件质量与软件的内部特性及其组合有关。要度量软件质量，就应根据这些内部特性（即软件属性）建立起软件度量模型，进而构建软件质量度量体系。 1976年，BoehIil提出了定量度量软件质量的概念，他给出了软件质量的层次模型，并给出了60个软件质量度量公式； 1978年，WalterS和MCCan提出了三层次软件质量度量模型； 1985年，ISo提出了S

41、QM（SoftwareQualityMetric,软件质量度量）工作报告等等。1. MCCall等人的软件质量度量模型 MCCaU等人提出了由软件质量要素、评价准则、定量度量三个层次组成的三层次度量模型。其中. 第一层是将对软件质量的度量归结为对直接影响软件质量的若干个软件质量要素的度量； 第二层是用若干个可度量的评价准则来间接度量软件质量要素； 第三层是对相应评价准则的直接度量。2. 软件质量要素 软件质量要素factor）是指直接影响软件质量的软件质量特性。 随着对软件质量的认识的逐步提高，软件质量要素也可能有所变化。 当时MCCan等人认为，软件质量由11个软件质量要素来衡量。这11个质

42、量要素可划分为三类： 面向运行特征的软件质量要素有正确性、可靠性、有效性、完整性和可用性； 面向软件承受修改的质量要素有可维护性、灵活性、可测试性； 面向转移的软件质量要素有可移植性、可重用性、可互操作性。这三类要素构成了软件质量的三个侧面，如图2-3-2所示。质量要素新概念1） 正确性（correctness）：指程序满足需求规格说明及用户目标的程度；2）完整性（integrity）：指对未授权人员访问程序或数据加以控制的程度；3）可用性（usability）：指学习使用软件（即操作软件、准备输入数据、解释输出结果等）的难易程度;4）灵活性（flexibility）：指改变一个操作的顺序所需

43、工作量的多少；5）可测试性（testability）：指测试软件以便使其具有预定功能所需工作量的多少；6）可互操作性（interoperability）：指程序与其他系统相互交换并使用信息的能力。2） 软件质量要素软件质量要素不是独立的，一个要素可能与其他几个要素有关系，如表2-12所示，其中：正相关以“表示，负相关以表示。对于具有负相关的质量要素，在开发时应根据具体情况加以取舍或进行折衷。例如，对于实时控制系统，必须确保系统的可靠性和有效性，而软件的可重用性、可移植性等质量要素就可以放宽要求。24软件复杂性度量通过软件的复杂性度量值可以估算出软件中故障的数量；也能估算出软件开发所需的工作量；

44、定量度量的结果还可以用于比较不同设计方案的优劣。同时，软件的复杂性也能从某些方面影响软件的可维护性、可靠性等软件质量要素。因此，软件复杂性度量是软件度量的一个重要组成局部。2. 4.1软件复杂性的概念及度量原则1 .软件复杂性的概念K.Magel从6个方面来描述软件复杂性：D理解程序的难度；2）维护程序的难度；3）向其他人解释程序的难度；4）按指定方法修改程序的难度；5）根据设计文件编写程序的工作量；6）执行程序时需要资源的多少。软件复杂性反映了软件的可理解性、模块化、简单性等属性。2.软件复杂性度量的原则软件复杂性的度量，的一些根本原则：1）软件的复杂性与其规模的关系不是线性的；2）数据结构

45、复杂的程序较复杂；3）控制结构复杂的程序较复杂；4）转向语句使用不当的程序较复杂；5）循环结构比选择结构复杂、选择结构比顺序结构复杂；6）语句、数据、子程序模块等出现的顺序对复杂性有影响；7）非局部变量较多的程序较复杂；8）参数按地址调用（Callbyreference）比按值调用（Callbyvalue）复杂；9）函数副作用比显式参数传递难理解；10）作用不同的变量同名时较难理解；ID模块、过程间联系密切的程序较复杂；12）程序嵌套层数越多越复杂。以上这些根本原则是指导我们进一步研究定量度量软件复杂性的基础。RlV(G)=E-N+2=1-2+2=1V(G)=E-N+2=4-4+2=2V (G

46、)=E-N+2=3-3+2=2Cd)untilNMV (G)=E-N+2=3-3+2=22. 4.2MCCabe度量模型1976年，MCCabe提出了基于程序拓扑结构的软件复杂性度量模型。该方法是把程序流程图转化为程序图：即把程序看成是有一个入口结点和一个出口结点的有向图，图中每个结点对应一个语句、一个简单判断或一个顺序流程的代码块，原来程序流程图中的箭头变成连接各结点的有向弧(或称为边)。一般地，可以假设从程序图中的开始结点可以到达图中的任一结点，而从图中的任一结点都可以到达出口结点。程序图又称为程序控制结构图或程序流图。2. 4.2MCCabe度量模型MCCabe给出了程序控制结构图G的巡同秩数V(G)作为程序控制结构复杂性的度量，其度量模型为：V(G)=E-N+2(2-22)其中：E程序图G中边的总数；N程序图中结点的总数。V(G)又称为图G的环形复杂度。可以证明，V(G)的值等于结构图中有界和无界的封闭区域的个数。2.4.2MCCabe度量模型 程序结构的复杂性度量值V(G)取决于程序控制流的复杂程度。当程序内的分支数和循环数增加时，V(G)值将随之增加，即程序的复杂性增大。 MCCabe研究大量程序后指出，V(G)可作为程序规模的定量指标，V(G)值越高的程序往往是越复杂