如何理解软件与软件工程

1、第一章软件与软件工程1.1 软件（ Software ）1.1.1 软件与软件的组成计算机软件 与计算机系统操作有关的程序、规程、 规则及任何与之有关的文档和数据。软件程序及有关数据一机器可执行；使用、培训有关） 不可执行。程序（ program） 用程序设计语言描述的， 程序设计语言三种类型：1机器语言、汇编语言：依赖于机器，面向机器 2高级语言：独立于机器，面向过程或面向对象3面向问题语言： 独立于机器，非过程式语言 （4GL）文档（documen）种数据媒体和其上所记录的数据。 文档记录软件开发活动和阶段成果， 具有永久性，可供人或机器阅读。 文档可用于专业人员和用户之间的通信和交流；

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

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

4、 20世纪80年代末期开始的。这是一个软件产业大发展的时期。也是 软件工程大发展的时期，人们开始采用面向对象的技术和可视化的集成开发环 境。1.1.2 软件危机 软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。1软件危机的表现1）对软件开发成本和进度的估计常常很不准确。 常常出现实际成本比估算成本高出 一个数量级、实际进度比计划进度拖延几个月甚至几年的现象，从而降低了开发 商的信誉，引起用户不满。2）用户对已完成的软件不满意的现象时有发生。3）软件产品的质量往往是靠不住的。4）软件常常是不可维护的。5）软件通常没有适当的文档资料。 文档资料不全或不合格， 必将给软件开

5、发和维护 工作带来许多难以想象的困难和难以解决的问题。6）软件成本在计算机系统总成本中所占比例逐年上升。 特别是软件维护成本迅速增加，已经占据软硬件总成本的 40%75%。7）开发生产率提高的速度远跟不上软件需求。图1-1-1软件、硬件成本变化趋势2. 产生软件危机的原因1）用户对软件需求的描述不精确。2）软件开发人员对用户需求的理解有偏差，这将导致软件产品与用户的需求不一致。3）缺乏处理大型软件项目的经验。开发大型软件项目需要组织众多人员共同完成。一般来说，多数管理人员缺乏大型软件的开发经验，而多数软件开发人员又缺乏 大型软件项目的管理经验，致使各类人员的信息交流不及时、不准确、容易产生 误

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

7、算机科学会议，由Fritz Bauer首次提出了软件工程”的概念。软件工程一一用工程、科学和数学的原则与方法开发、维护计算机软件的有关 技术和管理方法。软件工程由方法、工具和过程三部分组成，称软件工程的三要素。1.2.1软件工程的定义软件工程中的各种方法是完成软件工程项目的技术手段，它们支持软件工程的各个阶段。软件工程使用的软件工具能够自动或半自动地支持软件的开发、管理和文档的生成。软件工程中的过程贯穿于整个工程的各个环节，在这一过程中，管理人员应对软 件开发的质量、进度、成本等进行评估、管理和控制，包括计划跟踪与控制、成 本估算、人员的组织、质量保证、配置管理等1.2.2软件工程的基本原理著

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

9、性、可重用性、可适应性、可移植性、可追踪性和可 互操作性并满足用户需求的软件产品。名词解释1) 可修改性(modifiability )，允许对软件系统进行修改而不增加其复杂性。它支 持软件调试与维护。2) 有效性(efficie ncy)，指软件系统的时间和空间效率。这是一个应当努力追求的 重要目标。3) 可靠性(reliability )，是指在给定的时间间隔内，程序成功运行的概率。可靠性 是衡量软件质量的一个重要目标。4) 可理解性(understandability)，指系统具有清晰的结构，能直接反映问题的需求。 可理解性有助于控制软件系统的复杂性， 并支持软件的维护、 移植和重用。5

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

11、 设计、 概念和方法等等的重用。一般来说，重用的层次越高，带来的效益越可重用性有 助于提高软件产品的质量和开发效率、 降低软件开发和维护费用。7) 可适应性(adaptability)，是指软件在不同的系统约束条件下，使用户需求得到 满足的难易程度。选择广为流行的软硬件支持环境、采用广为流行的程序设计语言编码、采用标 准的术语和格式书写文档可增强软件产品的可适应性。8) 可移植性(portability)，是指软件从一个计算机系统或环境移植到另一个上去 的难易程度。 采用通用的运行支持环境和尽量通用的程序设计语言的标准部分可 提高可移植性。而应将依赖于计算机系统的低级(物理)特征部分相对独立、

12、集 中起来。可移植性支持软件的可重用性和可适应性。9) 可追踪性(traceability)，是指根据软件需求对软件设计、程序进行正向追踪， 或根据程序、软件设计对软件需求进行逆向追踪的能力。软件开发各阶段的文档 和程序的完整性、一致性、可理解性支持软件的可追踪性。10)可互操作性( interoperability )，是指多个软件元素相互通信并协同完成任务的 能力。1.2.4 软件工程的原则1. 抽象(abstraction),抽取各个事物中共同的最基本的特征和行为，暂时忽略它 们之间的差异。一般采用分层次抽象的方法来控制软件开发过程的复杂性。抽象 使软件的可理解性增强并有利于开发过程的管

13、理。2. 信息隐藏(in formation hidi ng)，将模块内部的信息(数据和过程)封装起来。其他模块只能通过简单的模块接口来调用该模块，而不能直接访问该模块内部的数据或过程，即将模块设计成黑箱”信息隐藏的原则可使开发人员把注意力集 中于更高层次的抽象上。3. 模块化：4. 局部化(localization)，即在一个物理模块内集中逻辑上相互关联的计算资源。 局部化支持信息隐藏，从而保证模块之间具有松散的耦合、模块内部有较强的内 聚。这有助于控制每一个解的复杂性。5. 致性(consistency)，整个软件系统(包括程序、数据和文档)的各个模块应 使用一致的概念、符号和术语；程序内

14、部接口应保持一致；软件与环境的接口应 保持一致；系统规格说明应与系统行为保持一致；用于形式化规格说明的公理系 统应保持一致。6. 完全性(completeness，软件系统不丢失任何重要成分，完全实现所需的系统 功能的程度。为了保证系统的完全性，在软件的开发和维护过程中需要严格的技 术评审。7. 可验证性(verifiability )，开发大型软件系统需要对系统逐层分解。系统分解应 遵循易于检查、测试、评审的原则，以使系统可验证。抽象、信息隐藏、模块化和局部化的原则支持可理解性、可修改性、可靠性等目 标，并可提高软件产品的质量和开发效率； 一致性、完全性和可验证性等原则可以帮助软件开发人员去

15、实现一个正确的系 统。1.3软件生存周期软件从定义开始，经过开发、使用和维护，直到最终退役的全过程称为软件生存周期。可将软件生存周期划分为3个过程共9个阶段。3个过程是：软件定义过程、软件开发过程、软件使用与维护过程。9个阶段有：可行性研究、需求分析、概要设计、详细设计、实现、组装测试、验收测试、使用与维护、退役。它们之间的关系如图1-3-1所示。可行性研究r需求分析概要设计详细设计开发过程实现,组装测试验收测试啟用与维护使用与维护过程_L退役（图 1-3-1）1.3.1软件定义软件定义的基本任务是确定软件系统的工程需求，也就是要搞清做什么” 软件定义过程可通过软件系统的可行性研究和需求分析两

16、个阶段来完成。1.可行性研究本阶段的任务是根据用户提出的工程项目的性质、目标和规模，进一步了解用户 的要求及现有的环境及条件，从技术、经济和社会等多方面研究并论证该项目的 可行性。即该项目是否值得去解决，是否存在可行的解决办法。此时，系统分析人员应在用户的配合下对用户的要求和现有的环境进行深入调查 并写出调研报告。进而进行可行性论证。可行性论证包括经济可行性、技术可行 性、操作可行性、法律可行性等。在此基础上还要制定初步的项目计划，包括需 要的软硬件资源、定义任务、风险分析、成本/效益分析以及进度安排等。可行性研究的结果将是使用部门负责人做出是否继续进行该项目决定的重要依 据。2. 需求分析1

17、）需求分析的任务需求分析的任务是确定待开发的软件系统做什么”具体任务包括确定软件系统的功能需求、性能需求和运行环境约束，编制软件需求规格说明书、软件系统的验收测试准则和初步的用户手册。2）需求分析的实现途径软件系统需求一般由用户提出。系统分析员和开发人员在需求分析阶段必 须与用户反复讨论、协商，充分交流信息，并用某种方法和工具构建软件系统的 逻辑模型。为了使开发方与用户对待开发软件系统达成一致的理解，必须建立相 应的需求文档。有时对大型、复杂的软件系统的主要功能、接口、人机界面等还 要进行模拟或建造原型，以便向用户和开发方展示待开发软件系统的主要特征。 确定软件需求的过程有时需要反复多次，最终

18、得到用户和开发者的确认。3）需求分析的阶段成果需求分析阶段的主要成果有软件需求规格说明、软件验收测试计划和准Software Requirements贝叽初步的用户手册等。其中，软件需求规格说明（Specification，即SRS），是一个关键性的文档。1.3.2软件开发软件开发过程由概要设计、详细设计、实现（即编码与单元测试）、组装测试、 验收测试共5个阶段组成。其中，概要设计和详细设计统称为设计；编码即编程；单元测试、组装测试和验 收测试统称为测试。开发者通常可提出多种设计方案，并对各种方案在功能、性能、成本、进度等方 面进行比较和折衷，从中选出一种最佳方案”。1.3.3软件的使用与维护

19、1.软件使用与维护阶段 任务：通过各种维护活动使软件系统持久地满足用户的需求。每项维护活动实质上都是一次压缩和简化了的软件定义和软件开发过程。都要经历提出维护要求、分析维护要求、提出维护方案、审批维护方案、确定维护计划、修改软件设计、修改程序、测试程序、评审、验收等步骤。1. 软件使用与维护阶段应当指出，软件在使用的过程中，应及时收集被发现的软件错误，并定期撰写 软 件问题报告”；而每一项维护活动都应该准确地记录下来，并作为正式的文档资料 保存。据统计，软件维护人员为了分析和理解原软件系统所花费的工作量约占整个维护工作量的60%以上。在软件开发的过程中应重视对软件可维护性的支持。2 .退役运行

20、与维护可行性研究需求分析（验收测试计划）概要设计（组装测试计划） 详细设计I（单元测试计划）单元测试验收测试组装测试编码与调试图1-3-2软件研制与软件测试的层次对应关系1.4软件开发模型软件开发模型（又称为软件生存周期模型）软件项目开发和维护的总体过程思路的框架。它指出了软件开发过程各阶段之间的关系和顺序，是软件开发过程的概括。它为 软件开发过程提供原则和方法，并为软件工程管理提供里程碑和进度表。因此， 软件开发模型也是软件工程的重要内容。软件开发模型的几种类型:以软件需求完全确定为基础的瀑布模型；在开发初期仅给出基本需求的渐进式模型， 如原型模型、螺旋模型、喷泉模型等;以形式化开发方法为基

21、础的变换模型、基于四代技术的模型；基于知识的智能模型等等。在实际开发时，应根据项目的特点和现有的条件选取合适的模型，也可以把几 种模型组合起来使用以便充分利用各模型的优点。1.4.1瀑布模型瀑布模型（waterfall model）是由W. Royce于1970年提出来的。又称为软件生 存周期模型。瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果 及文档，每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评 审，通过后才能开始下一阶段的工作。因此，它是一种以文档作为驱动的模型。图1-4-1带反

22、馈的瀑布模型退役瀑布模型优点：提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。瀑布模型缺点1）在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件 来说是极其困难的。2）在需求分析阶段，当需求确定后，无法及时验证需求是否正确、完整。3）作为整体开发的瀑布模型，由于不支持产品的演化，缺乏灵活性，对开发过程中 很难发现的错误，只有在最终产品运行时才能暴露出来，从而使软件产品难以维 护。瀑布模型适应场合瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如操作系统、编译系统

23、、数据库管理系统等系统软件的开发。应用有一定的局 限性。1.4.2原型模型原型模型（Prototyping model）的基本框架是软件开发人员根据用户提出的软件 基本需求快速开发一个原型，以便向用户展示软件系统应有的部分或全部功能和 性能，在征求用户对原型的评价意见后，进一步使需求精确化、完全化，并据此 改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并 达成一致的理解为止。软件需求确定后，便可进行设计，编码、测试等以后的各 个开发步骤。快速原型的开发途径有三种：1）仅模拟软件系统的人机界面和人机交互方式。2）开发一个工作模型，实现软件系统中重要的或容易产生误解的功能。3

24、）利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功 能。总之，建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技 术，在运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系 统的可见部分，如人机界面、数据的输入方式和输出格式等。原型模型的适应场合原型模型比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框架。它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目 组成员（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情 况。143螺旋模型螺旋模型（spiral model）是B. Boehm于1988年提出的。它综合

25、了瀑布模型和原型模 型的优点，即将两者结合，并加入了风险分析机制。螺旋模型的基本框架如图 螺旋模型的每一个周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。1 .计划（需求定义）第一周期开始利用需求分析技术理解应用领域，获取初步用户需求，制定项目 开发计划（即整个软件生命周期计划）和需求分析计划。经过一个周期后，根据 用户和开发人员对上一周期工作成果评价和评审，修改、完善需求，明确下一周期软件开发的目标、约束条件，并据此制定新一轮的软件开发计划。2. 风险分析根据本轮制定的开发计划，进行风险分析，评估可选方案，并构造原型进一步 分析风险，给出消除或减少风险的途径。此时根据风险分析的

26、结果决策项目是否 继续。所以，螺旋模型是一个风险驱动的模型。3. 工程实现利用构造的原型进行需求建模或进行系统模拟，直至实现软件系统。4.用户评价与阶段评审将原型提交用户使用并征求改进意见。开发人员应在用户的密切配合下进一步 完善用户需求，直到用户认为原型可满足需求，或对软件产品设计进行评价或确 认等。螺旋模型从第一个周期的计划开始，一个周期、一个周期地不断迭代，直到整 个软件系统开发完成。螺旋模型的缺点和适应场合缺点： 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间； 使用该模型需要有相当丰富的风险评估经验和专门知识， 要求开发队伍水平较高。 适应场合：支持需求不明确、

27、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。习题思考题什么是软件工程？构成软件工程的要素是什么?软件工程的7条原理都是什么？软件工程的目标是什么？1.31.41.51.7软件工程的7条原则是什么？说明这些原则的作 用。1.8软件生存周期由哪几个过程组成？每个过程分别 包括哪几个阶段？1.13软件开发模型、软件开发方法、集成的 CASE工具与环境在软件工程中各有什么作用?第2章软件项目管理软件项目管理必须从项目的开头介入，并贯穿于整个软件生存周期的全过程。软件项目管理的范围主要集中于3个P上，即：Peopie （人员）、Probl

28、em （问题） 和 Process （过程）。软件项目管理的主要任务是：根据选定的软件开发过程框架（即软件开发模型）和对其估算的结果制定软 件项目实施计划；再根据计划对人员进行组织、分工；按照计划的进度，以及成 本管理、风险管理、质量管理的要求，控制并管理软件开发和维护的活动，最终 以最小的代价完成软件项目规定的全部任务。软件项目的成本管理、软件质量管理和软件配置管理有一定的特殊性和独立性， 可单独立项。其任务分别是：成本管理一一估算软件项目的成本，作为立项和签合同的依据之一，并在软件开 发过程中按计划管理经费的使用；质量管理一一制定软件质量保证计划，按照质量评价体系控制软件质量要素，对 阶段

29、性的软件产品进行评审，对最终软件产品进行确认，确保软件质量；配置管理一一制定配置管理计划，对程序、数据、文档的各种版本进行管理，确 保软件的完整性和一致性。在制定有效的项目实施计划的过程中，首先要对项目的工作量、完成期限等等参 考量进行估算。估算的结果将成为项目计划其他活动的基础，同时，为了对软件 项目进行科学、有效的管理，就必须对软件开发过程的有关特征进行度量，度量 的结果用于软件开发过程的管理与监控。本章主要介绍软件度量的概念，软件的规模度量，软件项目的估算，软件的质量 度量、复杂性度量、可靠性度量、风险的分析与度量以及软件项目管理过程与步 骤等等。2.1软件度量对软件工程项目的规模、成本

30、、产品质量等属性进行定量的描述，可以帮助项目 管理人员和开发者制定有效的项目计划，监控项目的风险、进度和阶段产品的质 量，并为调整过程中活动和做出重要决策提供可靠的依据。下面介绍软件度量的 基本概念，并介绍软件的规模度量和功能度量。2.1.1软件度量的基本概念1. 测量、度量、估算和指标软件工程项目的定量描述涉及测量、度量、估算和指标等一些基本概念。1）测量（measure :对产品或过程的某个属性的范围、数量、维度、容量或大小 提供一个定量的指示。2）度量（metric）:对系统、部件或过程的某一特性所具有的程度进行的量化测量。 如软件质量度量等。3）估算（estimation）：对软件产品

31、、过程、资源等使用历史资料或经验公式等进 行预测。如工作量、成本、完成期限等。估算一般用于立项、签订合同、制定工 作计划等。4）指标（guideline）指标一一是一个度量或度量的组合，它可对软件产品、过程或资源提供更深入的理 解。如有4个小组共同完成一个软件项目，每一个小组都必须采用自行选择的评 审类型进行技术评审。管理者检查每小时每人所发现的错误数”这一度量结果时 发现：采用正式技术评审方法的两个小组的该度量值要比另外两个小组高出40%。假设4个小组的其他参数都相同，这就给管理者提供了一个指标：正式技术评审 方法比其他技术评审方法更有效率。于是，管理者可决定建议所有小组都采用更 加正式的技

32、术评审方法。2. 软件项目管理的对象及其属性软件项目管理的对象主要包括产品、过程和资源等。 产品（Product）是指软件开发过程得到的文档和程序，如：需求规格说明、设计 规格说明、源代码、测试报告等；过程（ProcesS是指与软件项目有关的活动，如软件项目计划、开发活动、维护 活动、管理活动等；资源（resource是指进行软件项目所需要的各种支持，如人力、经费、方法、 工具、软硬件环境等。要对软件项目管理的对象进行有效的管理与控制，就必须对这些对象的属性进行测量、度量与估算。一般来说，产品、过程、资源等对象都具有内部属性和外部属性。对象的属性内部属性是指对象本身的属性，如软件产品的代码长度

33、、模块化的程度、复杂性 等。对象的外部属性体现了对象与环境的关系，如软件的可靠性、可维护性、可移植 性、成本、人员的生产率等。对象的部分属性如表 2-1所示。对象的属性项目管理员和用户都十分关心产品、过程、资源的外部属性，于是可将外部属性 看成是面向管理员和用户的属性。但在软件开发的过程中，软件的外部属性一般 是很难度量和控制的。这些外部属性是由软件的内部属性所决定的，因此，可以 通过研究内部属性与外部属性之间的关系来解决外部属性的度量问题，进而逐步建立起了软件工程度量系统。3. 软件度量的分类可分为直接度量和间接度量两类：1）直接度量。即对不依赖于其他属性的简单属性的测量。 如软件的模块数、

34、 程序的代码行数、操作符的个数，工作量、成本等。2）间接度量。即对涉及若干个其他属性的软件要素、准则或属性的度量。 因为它们必须通过建立一定的度量方法或模型才能间接推断而获得。如软件的功 能性、复杂性、可靠性、可维护性等等。2-1-1所软件度量系统还可进一步划分为两个侧面。它们之间的关系如图2.1.2面向规模的度量面向规模的度量是以软件的代码行（LOC, Line of Code）数为基础的直接度量。 一般的软件开发组织对开发过的每个软件项目都有如代码行、工作量、成本、错 误、人数、文档页数等的统计记录。利用代码行数可以度量软件规模、生产率、 平均成本、出错率、文档率等参考量。设：L表示软件的

35、代码行数，单位为KLOC （千行代码）或LOC ； E表示开发软件 所需工作量，单位为人月（PM）或人年（PY）; S表示软件成本，单位为美元 或元；N表示错误个数；Pd表示软件文档页数；M表示开发所用的人数。则有：1. 软件开发的生产率P （即平均每人月开发的代码行数，以LOC/PM为单位）为：P = L / E2 .开发每行代码的平均成本C （以美元/LOC或元/LOC为单位）为：C = S / L以个/KLOC为单位）为:3. 代码出错率EQR （即每千行代码的平均错误数，EQR = N / L以页/KLOC为单位）为:4. 软件的文档率D （即平均每千行代码的文档页数，D = Pd /

36、 L【例2.1】已知有一个国外典型的软件项目的记录,开发人员 M=6人，其代码行数=20.2KLOC，工作量E=43PM，成本S=314000美元，错误数N=64,文档页数Pd=1050 页。试计算开发该软件项目的生产率P、平均成本C、代码出错率EQR和文档率D。解：根据给出的已知数据，可得：P = L / E =20.2 KLOC /43 PM = 0.47 KLOC / PM =470 LOC / PMC = S / L = 314000美元 / 20.2 KLOC=15.54 美元 / LOCEQR = N / L = 64个 / 20.2KLOC = 3.17 个 / KLOCD =

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

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

39、与过去完成的软件项目进行比较，从各子任务中 区分出类似的和不同的部分。类似的部分按已知的实际量计算，不同的部分则采 用某种方法进行估算。差别估算法综合了以上两种方法的优点。优点：估算的准确程度高。缺点：不容易划分相似的界限。4. 根据经验估算公式通过众多实际软件项目的经验，总结出一些有价值的软件成本和工作量估算的经 验模型。这些模型对于软件项目管理具有一定的指导意义和验证效果。没有一种估算模型能够适合于所有类型的软件项目。因此，对估算的结果应当慎 重使用。在实际估算时，几种估算方法可单独、同时或组合使用，以便提高估算的准确程 度。222代码行和功能点的估算采用2.2.1中介绍的估算方法可以估算

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

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

42、McCall提出了三层次软件质量度量模型；1985年, ISO提出了 SQM （Software Quality Metric，软件质量度量）工作报告等 等。1. McCall等人的软件质量度量模型 McCall等人提出了由软件质量要素、评价准则、定量度量三个层次组成的三层次 度量模型。其中：第一层是将对软件质量的度量归结为对直接影响软件质量的若干个软件质量要 素的度量；第二层是用若干个可度量的评价准则来间接度量软件质量要素；第三层是对相应评价准则的直接度量。2. 软件质量要素软件质量要素(factor)是指直接影响软件质量的软件质量特性。 随着对软件质量的认识的逐步提高，软件质量要素也可能有

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

44、结果等)的难易程 度;灵活性(flexibility ):指改变一个操作的顺序所需工作量的多少；可测试性(testability)：指测试软件以便使其具有预定功能所需工作量的多少;可互操作性(interoperability):5)4)6)指程序与其他系统相互交换并使用信息的能力。2. 软件质量要素软件质量要素不是独立的，一个要素可能与其他几个要素有关系， 如表2-12所示, 其中：正相关以&表示，负相关以裟表示。对于具有负相关的质量要素，在开发时应根据具体情况加以取舍或进行折衷。 例如，对于实时控制系统，必须确保系统的可靠性和有效性，而软件的可重用 性、可移植性等质量要素就可以放宽要求。2.

45、4软件复杂性度量通过软件的复杂性度量值可以估算出软件中故障的数量；也能估算出软件开发所需的工作量；定量度量的结果还可以用于比较不同设计方案的优劣。同时，软件 的复杂性也能从某些方面影响软件的可维护性、可靠性等软件质量要素。因此， 软件复杂性度量是软件度量的一个重要组成部分。2.4.1软件复杂性的概念及度量原则1. 软件复杂性的概念理解程序的难度； 维护程序的难度； 向其他人解释程序的难度； 按指定方法修改程序的难度； 根据设计文件编写程序的工作量; 执行程序时需要资源的多少。 K . Magel从6个方面来描述软件复杂性：1)2)3)4)5)6)软件复杂性反映了软件的可理解性、模块化、简单性等

46、属性。2.软件复杂性度量的原则软件复杂性的度量，的一些基本原则：1)2)3)4)5)软件的复杂性与其规模的关系不是线性的；数据结构复杂的程序较复杂；控制结构复杂的程序较复杂；转向语句使用不当的程序较复杂；循环结构比选择结构复杂、选择结构比顺序结构复杂；6) 语句、数据、子程序模块等出现的顺序对复杂性有影响；7) 非局部变量较多的程序较复杂；8) 参数按地址调用(Call by referenee)比按值调用(Call by value)复杂;9) 函数副作用比显式参数传递难理解；10) 作用不同的变量同名时较难理解；11) 模块、过程间联系密切的程序较复杂；12) 程序嵌套层数越多越复杂。以上

47、这些基本原则是指导我们进一步研究定量度 量软件复杂性的基础。(a)顺序结构V (G) = E -N + 2 = 1-2 + 2 = 1R1QO(G)=E -N + 2 = 4=E -N + 2 = 3=E -N + 2 = 3-4 + 2 = 2-3 + 2 = 2-3 + 2 = 22.4.2 McCabe度 量模型 1976年, McCabe提出了基于程序拓扑结构的软件复杂性度量模型。该方法是把 程序流程图转化为程序图：即把程序看成是有一个入口结点和一个出口结点的有向图，图中每个结点对应一个语句、一个简单判断或一个顺序流程的代码块，原 来程序流程图中的箭头变成连接各结点的有向弧(或称为边)

48、。一般地，可以假 设从程序图中的开始结点可以到达图中的任一结点，而从图中的任一结点都可以到达出口结点。程序图又称为程序控制结构图或程序流图。242 McCabe度量模型 McCabe合出了程序控制结构图G的巡回秩数V(G)作为程序控制结构复杂性的 度量，其度量模型为：(2-22)程序图中结点的总数。V (G)又称为V ( G) = E -N + 2其中：E 程序图G中边的总数；N图G的环形复杂度。可以证明，V( G)的值等于结构图中有界和无界的封闭区域的个数。242 McCabe度量模型程序结构的复杂性度量值V (G)取决于程序控制流的复杂程度。当程序内的分支数和循环数增加时，V(G)值将随之

49、增加，即程序的复杂性增大。McCabe研究大量程序后指出，V (G)可作为程序规模的定量指标，V( G)值越 高的程序往往是越复杂、越容易出问题的程序。10McCabe建议模块规模应满足：V( G) 【例2.5】程序流程图如图2-4-2所示，试求出其巡回秩数V解：(1)画出程序流程图对应的程序图。图2-4-3 程序图abb5C开始1)9DR3 i;C结束 )试求出其巡回秩数V( G)(2) 由程序图(或流图)可得：V (G) = E -N + 2 = 11 -9 +2 = 4(3) 由程序图可以看出，其有界区域有R1、R2、R3共3个， 还有1个无界区域R4,共4个 封闭区域，所以：V (G)

50、 = 42.4.3 Halstead 量模型 20世纪70年代初，Halstead合出了称为文本复杂性度量的模型。它是根据统计程 序中的操作符和操作数的个数来度量程序的复杂程度。程序可以看成是由操作符和操作数组成的符号序列。操作符是指程序中出现的语法符号，如+、if-then-else、while等。操作数是操作对象，如程序中定义或使用的变量、常量、 数组、指针等。2.6软件开发过程的管理在前几节中介绍了软件度量和估算，这些即是评价软件的重要依据，也是软件开 发过程管理的组成部分和基础。在本节中将介绍软件项目管理的过程、 风险分析, 软件开发计划的进度安排，软件开发人员的组织与分工等等。2.6

51、.1软件开发项目管理过程为达到软件工程的目标，必须对软件开发项目的工作范围、所需的工作量和成本、 必需的人力和软硬件资源、可能遇到风险、进度的安排、待实现的任务、经历的 里程碑等进行管理。软件开发过程的管理应在所有技术工作开始之前启动，直至 软件工程过程的结束。软件开发项目管理过程主要包括以下几个方面：1. 启动一个软件项目一般情况，软件人员与客户是在可行性研究阶段确定软件工程项目的范围 和目标的。其中，目标指明了软件开发项目的目的，范围标明了软件要实现的基 本功能，并寻求解决方案。2. 成本估算在软件项目管理过程中的一个关键活动是制定项目计划。在制定计划时， 必须对项目的规模、所需的人力等资

52、源、项目的持续时间、工作量和成本进行估 算。软件开发项目管理过程主要包括以下几个方面3. 风险分析开发一个软件项目总存在某些不确定性，即存在风险。有些风险如果控制 得不好，可能导致灾难性的后果。风险分析实际上就是贯穿于软件工程过程中的 一系列风险管理步骤，包括风险标识、风险估算、风险评价、风险驾驭和监控。4. 进度安排首先识别一组项目任务，再确定各任务之间的相互关联，然后估算各个任务的 工作量，制定进度时序，建立分隔任务的里程碑，确定关键路径，分配人力和其 他资源。软件开发项目管理过程主要包括以下几个方面5. 追踪和控制项目管理人员负责追踪和控制在进度安排中标识的每一个任务。如果任务实际完成日

53、期滞后于进度安排，则管理员可以使用一种自动的项目进度安排工具来确定 在项目的中间里程碑上进度误期所带来的影响，并及时采取措施加以解决。如重 新分配资源、对任务重新安排等等。作为最坏的情况，只好推迟软件产品的交付 日期。2.6.2风险分析风险的特点： 具有不确定性，某项风险可能发生也可能不发生； 一旦某项风险变成了现实，就必然会给项目带来不良的影响和损失， 甚至灾难性 后果。风险分析的四个主要活动：风险标识；风险估算；风险评价； 风险驾驭和监控。1.风险标识风险按影响的范围，可分为三类： 项目风险是指项目在预算、进度、人力等资源、客户和需求等方面可能存在 的问题。这些问题一旦发生将对软件开发项目

54、产生不利影响。 技术风险是指在需求、设计、实现、接口、验证和维护等方面的潜在问题。 如果技术风险发生了，将直接威胁软件产品的质量和交付日期。 商业风险是指开发一个没人需要的优质软件产品、开发一个销售部门不知道如何销售的软件产品、或开发一个不再符合整体商业策略的产品等等。2 .风险估算一一风险预测。软件项目管理人员主要从影响风险的因素和风险发生后带来的损失来度量风险。要对风险进行估算，首先应建立风险度量指标体系、指明风险带来的影响和损失, 确定影响风险的因素，估计风险出现的可能性或概率，即进行定量的估算。3. 风险评价定义项目的风险参照水准；定义每种风险的三元组r i，p i，x i,并找出和每

55、个参照水准之间的关系;预测一组参照点以定义一个项目终止区域，用一条曲线或一些易变动区域1)2) 一般来说，参照点不是一条平滑的曲线，而是一个易变动的区域，在这个区域要 做出基于参照值组合的管理判断往往是不准确的。因此，风险评价过程可分四步 进行：3）来定界；4）预测各种风险组合的影响是否超出参照水准。4. 风险驾驭和监控 风险分析的目的是建立处理风险的策略，监控、驾驭风险。驾驭风险是利用原型化、软件自动化、可靠性工程学等技术和软件项目管理方法 设法避开或转移风险。描述风险的三元组r i，p i，x i 是驾驭风险的基础。 风险驾驭与监控活动如图2-6-2所示。2.6.3进度安排进度安排可能是如下两种方式之一：1）软件产品最终交付日期已经确定，开发方只能根据最终交付日期安排进度；2）最后交付日期主要由软件开发方来确定。软件项目的进度安排的准确程度可能比成本估算的准确程度更重要，如果进度安 排不当会导致客户不满、丧失市场机会和成本的增加。因此，进度安排必须解决 好以下几个问题。1. 任务、人力、时间等资源的分配应与工程进度相一