管理信息化信息化知识如何理解软
件与软件工程
软件危机
——软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和
难题。
1．软件危机的表现
1）对软件开发成本和进度的估计常常很不准确。常常出现实际成本比估算成本高出
一个数量级、实际进度比计划进度拖延几个月甚至几年的现象，从而降低了开发商
的信誉，引起用户不满。
2）用户对已完成的软件不满意的现象时有发生。
3）软件产品的质量往往是靠不住的。
4）软件常常是不可维护的。
5）软件通常没有适当的文档资料。文档资料不全或不合格，必将给软件开发和维护
工作带来许多难以想象的困难和难以解决的问题。
6）软件成本在计算机系统总成本中所占比例逐年上升。
特别是软件维护成本迅速增加，已经占据软硬件总成本的 40%~75%。
7）开发生产率提高的速度远跟不上软件需求。
2．产生软件危机的原因
1）用户对软件需求的描述不精确。
2）软件开发人员对用户需求的理解有偏差，这将导致软件产品与用户的需求不一致。
3）缺乏处理大型软件项目的经验。开发大型软件项目需要组织众多人员共同完成。
一般来说，多数管理人员缺乏大型软件的开发经验，而多数软件开发人员又缺乏大
型软件项目的管理经验，致使各类人员的信息交流不及时、不准确、容易产生误解。
4）开发大型软件易产生疏漏和错误。
5）缺乏有力的方法学的指导和有效的开发工具的支持。软件开发过多地依靠程序员
的“技巧”，从而加剧了软件产品的个性化。
6）面对日益增长的软件需求，人们显得力不从心。从某种意义上说，解决供求矛盾
将是一个永恒的主题。
3．缓解软件危机的途径
到了 20世纪 60年代末期，软件危机已相当严重。这促使计算机科学家们开始探索
缓解软件危机的方法。他们提出了“软件工程”的概念，即用现代工程的原理、技
术和方法进行软件的开发、管理、维护和更新。于是，开创了计算机科学技术的一
个新的研究领域。
软件工程的概念
软件工程的定义软件工程的定义
1968年，北大西洋公约组织在原西德召开计算机科学会议，由 FritzBauer首次提出
了“软件工程”的概念。
软件工程——用工程、科学和数学的原则与方法开发、维护计算机软件的有关技术
和管理方法。
软件工程由方法、工具和过程三部分组成，称软件工程的三要素。
软件工程的定义软件工程的定义
软件工程中的各种方法是完成软件工程项目的技术手段，它们支持软件工程的各个
阶段。
软件工程使用的软件工具能够自动或半自动地支持软件的开发、管理和文档的生成。
软件工程中的过程贯穿于整个工程的各个环节，在这一过程中，管理人员应对软件
开发的质量、进度、成本等进行评估、管理和控制，包括计划跟踪与控制、成本估
算、人员的组织、质量保证、配置管理等
软件工程的基本原理
著名的软件工程专家 于 1983 年综合了软件工程专家学者们的意见并总
结了开发软件的经验，提出了软件工程的 7 条基本原理。这 7 条原理被认为是确保
软件产品质量和开发效率的原理的最小集合，又是相互独立、缺一不可、相当完备
的最小集合。下面就简单介绍软件工程的这 7条原理：
1．用分阶段的生存周期计划严格管理
2．坚持进行阶段评审
3．实行严格的产品控制
4．采用现代程序设计技术
5．结果应能清楚地审查
6．开发小组的人员应少而精
7．承认不断改进软件工程实践的必要性
软件工程的目标
软件工程的目标是在给定成本、进度的前提下，开发出具有可修改性、有效性、可
靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操
作性并满足用户需求的软件产品。
名词解释
1）可修改性（modifiability），允许对软件系统进行修改而不增加其复杂性。它
支持软件调试与维护。
2）有效性（efficiency），指软件系统的时间和空间效率。这是一个应当努力追求
的重要目标。
3）可靠性（reliability），是指在给定的时间间隔内，程序成功运行的概率。可
靠性是衡量软件质量的一个重要目标。
4）可理解性（understandability），指系统具有清晰的结构，能直接反映问题的
需求。可理解性有助于控制软件系统的复杂性，并支持软件的维护、移植和重用。
5）可维护性（maintainability），是指软件产品交付使用后，在实现改正潜伏的
错误、改进性能等属性、适应环境变化等方面工作的难易程度。由于软件的维护费
用在整个软件生存周期中占主要的比重，因此，可维护性是软件工程中的一个十分
重要的目标。软件的可理解性和可修改性支持软件的可维护性。
6）可重用性（reusability），是指软部件可以在多种场合使用的程度。概念或功
能相对独立的一个或一组相关模块可构成一个软部件。软部件应具有清晰的结构和
注释、正确的编码和较高的时空效率。可将各种软部件按照某种规则放在软部件库
中供开发人员选用。广义地讲，可重用性还应包括应用项目、规格说明、设计、概
念和方法等等的重用。一般来说，重用的层次越高，带来的效益越可重用性有助于
提高软件产品的质量和开发效率、降低软件开发和维护费用。
7）可适应性（adaptability），是指软件在不同的系统约束条件下，使用户需求得
到满足的难易程度。
选择广为流行的软硬件支持环境、采用广为流行的程序设计语言编码、采用标准的
术语和格式书写文档可增强软件产品的可适应性。
8）可移植性（portability），是指软件从一个计算机系统或环境移植到另一个上
去的难易程度。采用通用的运行支持环境和尽量通用的程序设计语言的标准部分可
提高可移植性。而应将依赖于计算机系统的低级（物理）特征部分相对独立、集中
起来。可移植性支持软件的可重用性和可适应性。
9）可追踪性（traceability），是指根据软件需求对软件设计、程序进行正向追踪，
或根据程序、软件设计对软件需求进行逆向追踪的能力。软件开发各阶段的文档和
程序的完整性、一致性、可理解性支持软件的可追踪性。
10）可互操作性（interoperability），是指多个软件元素相互通信并协同完成任
务的能力。
软件工程的原则
1．抽象（abstraction），抽取各个事物中共同的最基本的特征和行为，暂时忽略
它们之间的差异。一般采用分层次抽象的方法来控制软件开发过程的复杂性。抽象
使软件的可理解性增强并有利于开发过程的管理。
2．信息隐藏（informationhiding），将模块内部的信息（数据和过程）封装起来。
其他模块只能通过简单的模块接口来调用该模块，而不能直接访问该模块内部的数
据或过程，即将模块设计成“黑箱”。信息隐藏的原则可使开发人员把注意力集中
于更高层次的抽象上。
3．模块化：
4．局部化（localization），即在一个物理模块内集中逻辑上相互关联的计算资源。
局部化支持信息隐藏，从而保证模块之间具有松散的耦合、模块内部有较强的内聚。
这有助于控制每一个解的复杂性。
5．一致性（consistency），整个软件系统（包括程序、数据和文档）的各个模块
应使用一致的概念、符号和术语；程序内部接口应保持一致；软件与环境的接口应
保持一致；系统规格说明应与系统行为保持一致；用于形式化规格说明的公理系统
应保持一致。
6．完全性（pleteness），软件系统不丢失任何重要成分，完全实现所需的系统功
能的程度。为了保证系统的完全性，在软件的开发和维护过程中需要严格的技术评
审。
7．可验证性（verifiability），开发大型软件系统需要对系统逐层分解。系统分
解应遵循易于检查、测试、评审的原则，以使系统可验证。
抽象、信息隐藏、模块化和局部化的原则支持可理解性、可修改性、可靠性等目标，
并可提高软件产品的质量和开发效率；
一致性、完全性和可验证性等原则可以帮助软件开发人员去实现一个正确的系统。
软件生存周期
软件从定义开始，经过开发、使用和维护，直到最终退役的全过程称为软件生存周
期。
可将软件生存周期划分为 3个过程共 9个阶段。
3个过程是：软件定义过程、软件开发过程、软件使用与维护过程。
9个阶段有：可行性研究、需求分析、概要设计、详细设计、实现、组装测试、验收
测试、使用与维护、退役。
它们之间的关系如图 1-3-1所示。
（图 1-3-1）
软件定义
软件定义的基本任务是确定软件系统的工程需求，也就是要搞清“做什么”。
软件定义过程可通过软件系统的可行性研究和需求分析两个阶段来完成。
1．可行性研究
本阶段的任务是根据用户提出的工程项目的性质、目标和规模，进一步了解用户的
要求及现有的环境及条件，从技术、经济和社会等多方面研究并论证该项目的可行
性。即该项目是否值得去解决，是否存在可行的解决办法。
此时，系统分析人员应在用户的配合下对用户的要求和现有的环境进行深入调查并
写出调研报告。进而进行可行性论证。可行性论证包括经济可行性、技术可行性、
操作可行性、法律可行性等。在此基础上还要制定初步的项目计划，包括需要的软
硬件资源、定义任务、风险分析、成本/效益分析以及进度安排等。
可行性研究的结果将是使用部门负责人做出是否继续进行该项目决定的重要依据。
2．需求分析
1）需求分析的任务
需求分析的任务是确定待开发的软件系统“做什么”。
具体任务包括确定软件系统的功能需求、性能需求和运行环境约束，编制软件需求
规格说明书、软件系统的验收测试准则和初步的用户手册。
2）需求分析的实现途径
软件系统需求一般由用户提出。系统分析员和开发人员在需求分析阶段必须与用户
反复讨论、协商，充分交流信息，并用某种方法和工具构建软件系统的逻辑模型。
为了使开发方与用户对待开发软件系统达成一致的理解，必须建立相应的需求文档。
有时对大型、复杂的软件系统的主要功能、接口、人机界面等还要进行模拟或建造
原型，以便向用户和开发方展示待开发软件系统的主要特征。确定软件需求的过程
有时需要反复多次，最终得到用户和开发者的确认。
3）需求分析的阶段成果
需求分析阶段的主要成果有软件需求规格说明、软件验收测试计划和准则、初步的
用户手册等。其中，软件需求规格说明（SoftwareRequirementsSpecification，即
SRS），是一个关键性的文档。
软件开发
软件开发过程由概要设计、详细设计、实现（即编码与单元测试）、组装测试、验
收测试共 5个阶段组成。
其中，概要设计和详细设计统称为设计；编码即编程；单元测试、组装测试和验收
测试统称为测试。
开发者通常可提出多种设计方案，并对各种方案在功能、性能、成本、进度等方面
进行比较和折衷，从中选出一种“最佳方案”。
软件的使用与维护
1．软件使用与维护阶段
任务:通过各种维护活动使软件系统持久地满足用户的需求。
每项维护活动实质上都是一次压缩和简化了的软件定义和软件开发过程。都要经历
提出维护要求、分析维护要求、提出维护方案、审批维护方案、确定维护计划、修
改软件设计、修改程序、测试程序、评审、验收等步骤。
1．软件使用与维护阶段
应当指出，软件在使用的过程中，应及时收集被发现的软件错误，并定期撰写“软
件问题报告”；而每一项维护活动都应该准确地记录下来，并作为正式的文档资料
保存。
据统计，软件维护人员为了分析和理解原软件系统所花费的工作量约占整个维护工
作量的 60%以上。在软件开发的过程中应重视对软件可维护性的支持。
2．退役
软件开发模型
软件开发模型（又称为软件生存周期模型）
—软件项目开发和维护的总体过程思路的框架。
它指出了软件开发过程各阶段之间的关系和顺序，是软件开发过程的概括。它为软
件开发过程提供原则和方法，并为软件工程管理提供里程碑和进度表。因此，软件
开发模型也是软件工程的重要内容。
软件开发模型的几种类型：
以软件需求完全确定为基础的瀑布模型；
在开发初期仅给出基本需求的渐进式模型，如原型模型、螺旋模型、喷泉模型等；
以形式化开发方法为基础的变换模型、基于四代技术的模型；
基于知识的智能模型等等。
在实际开发时，应根据项目的特点和现有的条件选取合适的模型，也可以把几种模
型组合起来使用以便充分利用各模型的优点。
瀑布模型
瀑布模型（waterfallmodel）是由 于 1970年提出来的。又称为软件生存周
期模型。
瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶
段的输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果及文
档，每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通
过后才能开始下一阶段的工作。因此，它是一种以文档作为驱动的模型。
瀑布模型优点：
提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利
于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。
瀑布模型缺点
1）在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件
来说是极其困难的。
2）在需求分析阶段，当需求确定后，无法及时验证需求是否正确、完整。
3）作为整体开发的瀑布模型，由于不支持产品的演化，缺乏灵活性，对开发过程中
很难发现的错误，只有在最终产品运行时才能暴露出来，从而使软件产品难以维护。
瀑布模型适应场合
瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如
操作系统、编译系统、数据库管理系统等系统软件的开发。应用有一定的局限性。
原型模型
原型模型（prototypingmodel）的基本框架是软件开发人员根据用户提出的软件基
本需求快速开发一个原型，以便向用户展示软件系统应有的部分或全部功能和性能，
在征求用户对原型的评价意见后，进一步使需求精确化、完全化，并据此改进、完
善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的
理解为止。软件需求确定后，便可进行设计，编码、测试等以后的各个开发步骤。
快速原型的开发途径有三种：
1）仅模拟软件系统的人机界面和人机交互方式。
2）开发一个工作模型，实现软件系统中重要的或容易产生误解的功能。
3）利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功能。
总之，建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技术，在
运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系统的可见
部分，如人机界面、数据的输入方式和输出格式等。
原型模型的适应场合
原型模型比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框架。
它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目组成员
（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情况。
螺旋模型
螺旋模型（spiralmodel）是 于 1988 年提出的。它综合了瀑布模型和原型
模型的优点，即将两者结合，并加入了风险分析机制。螺旋模型的基本框架如图
螺旋模型的每一个周期都包括计划（需求定义）、风险分析、工程实现和评审 4个
阶段。
1．计划（需求定义）
第一周期开始利用需求分析技术理解应用领域，获取初步用户需求，制定项目开发
计划（即整个软件生命周期计划）和需求分析计划。经过一个周期后，根据用户和
开发人员对上一周期工作成果评价和评审，修改、完善需求，明确下一周期软件开
发的目标、约束条件，并据此制定新一轮的软件开发计划。
2．风险分析
根据本轮制定的开发计划，进行风险分析，评估可选方案，并构造原型进一步分析
风险，给出消除或减少风险的途径。此时根据风险分析的结果决策项目是否继续。
所以，螺旋模型是一个风险驱动的模型。
3．工程实现
利用构造的原型进行需求建模或进行系统模拟，直至实现软件系统。
4．用户评价与阶段评审
将原型提交用户使用并征求改进意见。开发人员应在用户的密切配合下进一步完善
用户需求，直到用户认为原型可满足需求，或对软件产品设计进行评价或确认等。
螺旋模型从第一个周期的计划开始，一个周期、一个周期地不断迭代，直到整个软
件系统开发完成。
螺旋模型的缺点和适应场合
缺点：
①如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；
②使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。
适应场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、
面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。
习题思考题
什么是软件工程？构成软件工程的要素是什么？
软件工程的 7条原理都是什么？
软件工程的目标是什么？
软件工程的 7条原则是什么？说明这些原则的作
用。
软件生存周期由哪几个过程组成？每个过程分别
包括哪几个阶段？
软件开发模型、软件开发方法、集成的 CASE工
具与环境在软件工程中各有什么作用？
第2章 软件项目管理
软件项目管理必须从项目的开头介入，并贯穿于整个软件生存周期的全过程。
软件项目管理的范围主要集中于 3个 P上，即：People（人员）、Problem（问题）
和 Process（过程）。
软件项目管理的主要任务是：
根据选定的软件开发过程框架（即软件开发模型）和对其估算的结果制定软件项目
实施计划；再根据计划对人员进行组织、分工；按照计划的进度，以及成本管理、
风险管理、质量管理的要求，控制并管理软件开发和维护的活动，最终以最小的代
价完成软件项目规定的全部任务。
软件项目的成本管理、软件质量管理和软件配置管理有一定的特殊性和独立性，可
单独立项。其任务分别是：
成本管理——估算软件项目的成本，作为立项和签合同的依据之一，并在软件开发
过程中按计划管理经费的使用；
质量管理——制定软件质量保证计划，按照质量评价体系控制软件质量要素，对阶
段性的软件产品进行评审，对最终软件产品进行确认，确保软件质量；
配置管理——制定配置管理计划，对程序、数据、文档的各种版本进行管理，确保
软件的完整性和一致性。
在制定有效的项目实施计划的过程中，首先要对项目的工作量、完成期限等等参考
量进行估算。估算的结果将成为项目计划其他活动的基础，同时，为了对软件项目
进行科学、有效的管理，就必须对软件开发过程的有关特征进行度量，度量的结果
用于软件开发过程的管理与监控。
本章主要介绍软件度量的概念，软件的规模度量，软件项目的估算，软件的质量度
量、复杂性度量、可靠性度量、风险的分析与度量以及软件项目管理过程与步骤等
等。
软件度量
对软件工程项目的规模、成本、产品质量等属性进行定量的描述，可以帮助项目管
理人员和开发者制定有效的项目计划，监控项目的风险、进度和阶段产品的质量，
并为调整过程中活动和做出重要决策提供可靠的依据。下面介绍软件度量的基本概
念，并介绍软件的规模度量和功能度量。
软件度量的基本概念
1．测量、度量、估算和指标
软件工程项目的定量描述涉及测量、度量、估算和指标等一些基本概念。
1）测量（measure）：对产品或过程的某个属性的范围、数量、维度、容量或大小
提供一个定量的指示。
2）度量（metric）：对系统、部件或过程的某一特性所具有的程度进行的量化测量。
如软件质量度量等。
3）估算（estimation）：对软件产品、过程、资源等使用历史资料或经验公式等进
行预测。如工作量、成本、完成期限等。估算一般用于立项、签订合同、制定工作
计划等。
4）指标（guideline）
指标——是一个度量或度量的组合，它可对软件产品、过程或资源提供更深入的理
解。
如有 4 个小组共同完成一个软件项目，每一个小组都必须采用自行选择的评审类型
进行技术评审。管理者检查“每小时每人所发现的错误数”这一度量结果时发现：
采用正式技术评审方法的两个小组的该度量值要比另外两个小组高出 40%。假设 4个
小组的其他参数都相同，这就给管理者提供了一个指标：正式技术评审方法比其他
技术评审方法更有效率。于是，管理者可决定建议所有小组都采用更加正式的技术
评审方法。
2．软件项目管理的对象及其属性
软件项目管理的对象主要包括产品、过程和资源等。
产品（product）是指软件开发过程得到的文档和程序，如：需求规格说明、设计
规格说明、源代码、测试报告等；
过程（process）是指与软件项目有关的活动，如软件项目计划、开发活动、维护
活动、管理活动等；
资源（resource）是指进行软件项目所需要的各种支持，如人力、经费、方法、工
具、软硬件环境等。
要对软件项目管理的对象进行有效的管理与控制，就必须对这些对象的属性进行测
量、度量与估算。一般来说，产品、过程、资源等对象都具有内部属性和外部属性。
对象的属性对象的属性
内部属性是指对象本身的属性，如软件产品的代码长度、模块化的程度、复杂性等。
对象的外部属性体现了对象与环境的关系，如软件的可靠性、可维护性、可移植性、
成本、人员的生产率等。对象的部分属性如表 2-1所示。
对象的属性对象的属性
项目管理员和用户都十分关心产品、过程、资源的外部属性，于是可将外部属性看
成是面向管理员和用户的属性。但在软件开发的过程中，软件的外部属性一般是很
难度量和控制的。这些外部属性是由软件的内部属性所决定的，因此，可以通过研
究内部属性与外部属性之间的关系来解决外部属性的度量问题，进而逐步建立起了
软件工程度量系统。
3．软件度量的分类
可分为直接度量和间接度量两类：
1）直接度量。即对不依赖于其他属性的简单属性的测量。如软件的模块数、程序的
代码行数、操作符的个数，工作量、成本等。
2）间接度量。即对涉及若干个其他属性的软件要素、准则或属性的度量。因为它们
必须通过建立一定的度量方法或模型才能间接推断而获得。如软件的功能性、复杂
性、可靠性、可维护性等等。
软件度量系统还可进一步划分为两个侧面。它们之间的关系如图 2-1-1所示。
面向规模的度量
面向规模的度量是以软件的代码行（LOC，LineofCode）数为基础的直接度量。一
般的软件开发组织对开发过的每个软件项目都有如代码行、工作量、成本、错误、
人数、文档页数等的统计记录。利用代码行数可以度量软件规模、生产率、平均成
本、出错率、文档率等参考量。
设：L 表示软件的代码行数，单位为 KLOC（千行代码）或 LOC；E 表示开发软件所
需工作量，单位为人月（PM）或人年（PY）；S表示软件成本，单位为美元或元；N
表示错误个数；Pd表示软件文档页数；M表示开发所用的人数。则有：
1．软件开发的生产率 P（即平均每人月开发的代码行数，以 LOC/PM为单位）为：
P=L/E
2．开发每行代码的平均成本 C（以美元/LOC或元/LOC为单位）为：
C=S/L
3．代码出错率 EQR（即每千行代码的平均错误数，以个/KLOC为单位）为：
EQR=N/L
4．软件的文档率 D（即平均每千行代码的文档页数，以页/KLOC为单位）为：
D=Pd/L
【例 】已知有一个国外典型的软件项目的记录，开发人员 M=6 人，其代码行数
=，工作量 E=43PM，成本 S=314000美元，错误数 N=64，文档页数 Pd=1050
页。试计算开发该软件项目的生产率 P、平均成本 C、代码出错率 EQR和文档率 D。
解：根据给出的已知数据，可得：
P=L/E=
=470LOC/PM
C=S/L=314000美元/
=美元/LOC
EQR=N/L=64个/=个/KLOC
D=Pd/L=1050页/=页/KLOC
基于代码行面向规模的度量方法的
优缺点、适用场合
优点：简单、直接。
缺点：如它依赖于程序设计语言的功能和表达等特征、在开发初期很难准确估算出
代码行数、对设计水平高的软件项目产生不利影响。
适用场合：适合于过程式程序设计语言和事后度量。
软件项目估算
软件项目的估算方法软件项目的估算方法
常用的软件项目的估算方法主要有以下 4种：
1．自顶向下的估算方法
基本思想：首先根据已完成项目的总成本或总工作量来推算待开发软件的总成本或
总工作量，然后再按比例将其分配到各开发任务中去。即从整体到局部。
优点：估算工作量小、速度快。
缺点：对项目中的特殊困难估计不足，有可能产生遗漏，估算出的值盲目性较大。
22．自底向上的估算方法．自底向上的估算方法
基本思想是：把待开发软件细分，直到每一个子任务或阶段都已经明确所需要的开
发工作量或成本，然后再把它们累加起来，得到待开发软件的总工作量或总成本。
需要指出，在对软件进行细分时，一种是按照功能将大的软件项目划分为若干个子
项目；另一种是按照软件生命周期分解为各个阶段。当然，也可以两者同时进行。
优点：计算各个部分的准确性较高。
缺点：缺少各个子任务之间相互联系的工作量和系统工作量（如项目管理、配置管
理、质量管理），估算值往往偏低，必须用其他方法进行校正。
3．差别估算法
基本思想：把待开发的软件项目与过去完成的软件项目进行比较，从各子任务中区
分出类似的和不同的部分。类似的部分按已知的实际量计算，不同的部分则采用某
种方法进行估算。差别估算法综合了以上两种方法的优点。
优点：估算的准确程度高。
缺点：不容易划分相似的界限。
4．根据经验估算公式
通过众多实际软件项目的经验，总结出一些有价值的软件成本和工作量估算的经验
模型。这些模型对于软件项目管理具有一定的指导意义和验证效果。
没有一种估算模型能够适合于所有类型的软件项目。因此，对估算的结果应当慎重
使用。
在实际估算时，几种估算方法可单独、同时或组合使用，以便提高估算的准确程度。
代码行和功能点的估算
采用 中介绍的估算方法可以估算出代码行或功能点的乐观值 a、一般值 m 和
悲观值 b，并用如下的加权平均公式计算 LOC或 FP的期望值（expectation）：
X=（a+4m+b）/6（2-10）
软件的 LOC或 FP的期望值估算出来后，就可以根据已有的标准生产率对成本和工作
量等进行估算了。
软件质量度量
软件质量是软件的生命。它作为软件工程的一部分，贯穿于整个软件生存周期之中。
生产高质量的软件产品是软件工程的首要目标。
由于软件是逻辑产品，软件质量很难直接度量。因此，应当给出软件质量的科学的、
实用的定义，并通过一定的度量模型进行度量，以便在整个软件生存周期中对其进
行评价和控制。
软件质量的定义
1983年，ANSI/IEEEstd729标准给出了软件质量的定义如下：
软件质量是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，包括：
1．软件产品满足用户要求的程度；
2．软件拥有所期望的各种属性的组合程度；
3．用户对软件产品的综合反映程度；
4．软件在使用过程中满足用户需求的程度。
软件质量的度量模型
软件质量与软件的内部特性及其组合有关。要度量软件质量，就应根据这些内部特
性（即软件属性）建立起软件度量模型，进而构建软件质量度量体系。
1976年，Boehm提出了定量度量软件质量的概念，他给出了软件质量的层次模型，
并给出了 60个软件质量度量公式；
1978年，Walters和 McCall提出了三层次软件质量度量模型；
1985年，ISO提出了 SQM（SoftwareQualityMetric，软件质量度量）工作报告等等。
1．McCall等人的软件质量度量模型
McCall等人提出了由软件质量要素、评价准则、定量度量三个层次组成的三层次度
量模型。其中:
第一层是将对软件质量的度量归结为对直接影响软件质量的若干个软件质量要素
的度量；
第二层是用若干个可度量的评价准则来间接度量软件质量要素；
第三层是对相应评价准则的直接度量。
2．软件质量要素
软件质量要素（factor）是指直接影响软件质量的软件质量特性。
随着对软件质量的认识的逐步提高，软件质量要素也可能有所变化。
当时 McCall 等人认为，软件质量由 11 个软件质量要素来衡量。这 11 个质量要素
可划分为三类：
面向运行特征的软件质量要素有正确性、可靠性、有效性、完整性和可用性；
面向软件承受修改的质量要素有可维护性、灵活性、可测试性；
面向转移的软件质量要素有可移植性、可重用性、可互操作性。这三类要素构成了
软件质量的三个侧面，如图 2-3-2所示。
质量要素新概念
1）正确性（correctness）：
指程序满足需求规格说明及用户目标的程度；
2）完整性（integrity）：
指对未授权人员访问程序或数据加以控制的程度；
3）可用性（usability）：
指学习使用软件（即操作软件、准备输入数据、解释输出结果等）的难易程度；
4）灵活性（flexibility）：
指改变一个操作的顺序所需工作量的多少；
5）可测试性（testability）：
指测试软件以便使其具有预定功能所需工作量的多少；
6）可互操作性（interoperability）：
指程序与其他系统相互交换并使用信息的能力。
2．软件质量要素
软件质量要素不是独立的，一个要素可能与其他几个要素有关系，如表 2-12所示，
其中:
正相关以“√”表示，
负相关以“×”表示。
对于具有负相关的质量要素，在开发时应根据具体情况加以取舍或进行折衷。
例如，对于实时控制系统，必须确保系统的可靠性和有效性，而软件的可重用性、
可移植性等质量要素就可以放宽要求。
软件复杂性度量
通过软件的复杂性度量值可以估算出软件中故障的数量；也能估算出软件开发所需
的工作量；定量度量的结果还可以用于比较不同设计方案的优劣。同时，软件的复
杂性也能从某些方面影响软件的可维护性、可靠性等软件质量要素。因此，软件复
杂性度量是软件度量的一个重要组成部分。
软件复杂性的概念及度量原则
1．软件复杂性的概念
从 6个方面来描述软件复杂性：
1）理解程序的难度；
2）维护程序的难度；
3）向其他人解释程序的难度；
4）按指定方法修改程序的难度；
5）根据设计文件编写程序的工作量；
6）执行程序时需要资源的多少。
软件复杂性反映了软件的可理解性、模块化、简单性等属性。
2．软件复杂性度量的原则
软件复杂性的度量，的一些基本原则：
1）软件的复杂性与其规模的关系不是线性的；
2）数据结构复杂的程序较复杂；
3）控制结构复杂的程序较复杂；
4）转向语句使用不当的程序较复杂；
5）循环结构比选择结构复杂、选择结构比顺序结构复杂；
6）语句、数据、子程序模块等出现的顺序对复杂性有影响；
7）非局部变量较多的程序较复杂；
8）参数按地址调用（Callbyreference）比按值调用（Callbyvalue）复杂；
9）函数副作用比显式参数传递难理解；
10）作用不同的变量同名时较难理解；
11）模块、过程间联系密切的程序较复杂；
12）程序嵌套层数越多越复杂。
以上这些基本原则是指导我们进一步研究定量度
量软件复杂性的基础。
度量模型
1976 年，McCabe 提出了基于程序拓扑结构的软件复杂性度量模型。该方法是把程
序流程图转化为程序图：即把程序看成是有一个入口结点和一个出口结点的有向图，
图中每个结点对应一个语句、一个简单判断或一个顺序流程的代码块，原来程序流
程图中的箭头变成连接各结点的有向弧（或称为边）。一般地，可以假设从程序图
中的开始结点可以到达图中的任一结点，而从图中的任一结点都可以到达出口结点。
程序图又称为程序控制结构图或程序流图。
度量模型
McCabe 给出了程序控制结构图 G 的巡回秩数 V（G）作为程序控制结构复杂性的度
量，其度量模型为：
V（G）=E–N+2（2-22）
其中：E——程序图 G 中边的总数；N——程序图中结点的总数。V（G）又称为图 G
的环形复杂度。
可以证明，V（G）的值等于结构图中有界和无界的封闭区域的个数。
度量模型
程序结构的复杂性度量值 V（G）取决于程序控制流的复杂程度。当程序内的分支数
和循环数增加时，V（G）值将随之增加，即程序的复杂性增大。
McCabe研究大量程序后指出，V（G）可作为程序规模的定量指标，V（G）值越高的
程序往往是越复杂、越容易出问题的程序。
McCabe建议模块规模应满足：V（G）≤10
【例 】程序流程图如图 2-4-2所示，
试求出其巡回秩数 V（G）
解：（1）画出程序流程图对应的程序图。
试求出其巡回秩数 V（G）
（2）由程序图（或流图）可得：
V（G）=E–N+2=11–9+2=4
（3）由程序图可以看出，其有界
区域有 R1、R2、R3共 3个，
还有 1个无界区域 R4，共 4个
封闭区域，所以：
V（G）=4
度量模型
20世纪 70年代初，Halstead给出了称为文本复杂性度量的模型。它是根据统计程
序中的操作符和操作数的个数来度量程序的复杂程度。程序可以看成是由操作符和
操作数组成的符号序列。操作符是指程序中出现的语法符号，如+、–、if-then-else、
while等。操作数是操作对象，如程序中定义或使用的变量、常量、数组、指针等。
软件开发过程的管理
在前几节中介绍了软件度量和估算，这些即是评价软件的重要依据，也是软件开发
过程管理的组成部分和基础。在本节中将介绍软件项目管理的过程、风险分析，软
件开发计划的进度安排，软件开发人员的组织与分工等等。
软件开发项目管理过程
为达到软件工程的目标，必须对软件开发项目的工作范围、所需的工作量和成本、
必需的人力和软硬件资源、可能遇到风险、进度的安排、待实现的任务、经历的里
程碑等进行管理。软件开发过程的管理应在所有技术工作开始之前启动，直至软件
工程过程的结束。
软件开发项目管理过程主要包括以下几个方面：
1．启动一个软件项目
一般情况，软件人员与客户是在可行性研究阶段确定软件工程项目的范围和目标的。
其中，目标指明了软件开发项目的目的，范围标明了软件要实现的基本功能，并寻
求解决方案。
2．成本估算
在软件项目管理过程中的一个关键活动是制定项目计划。在制定计划时，必须对项
目的规模、所需的人力等资源、项目的持续时间、工作量和成本进行估算。
软件开发项目管理过程主要包括以下几个方面
3．风险分析
开发一个软件项目总存在某些不确定性，即存在风险。有些风险如果控制得不好，
可能导致灾难性的后果。风险分析实际上就是贯穿于软件工程过程中的一系列风险
管理步骤，包括风险标识、风险估算、风险评价、风险驾驭和监控。
4．进度安排
首先识别一组项目任务，再确定各任务之间的相互关联，然后估算各个任务的工作
量，制定进度时序，建立分隔任务的里程碑，确定关键路径，分配人力和其他资源。
软件开发项目管理过程主要包括以下几个方面
5．追踪和控制
项目管理人员负责追踪和控制在进度安排中标识的每一个任务。如果任务实际完成
日期滞后于进度安排，则管理员可以使用一种自动的项目进度安排工具来确定在项
目的中间里程碑上进度误期所带来的影响，并及时采取措施加以解决。如重新分配
资源、对任务重新安排等等。作为最坏的情况，只好推迟软件产品的交付日期。
风险分析
风险的特点：
①具有不确定性，某项风险可能发生也可能不发生；
②一旦某项风险变成了现实，就必然会给项目带来不良的影响和损失，甚至灾难性
后果。
风险分析的四个主要活动：
风险标识；
风险估算；
风险评价；
风险驾驭和监控。
1．风险标识
风险按影响的范围，可分为三类：
①项目风险是指项目在预算、进度、人力等资源、客户和需求等方面可能存在的问
题。这些问题一旦发生将对软件开发项目产生不利影响。
②技术风险是指在需求、设计、实现、接口、验证和维护等方面的潜在问题。如果
技术风险发生了，将直接威胁软件产品的质量和交付日期。
③商业风险是指开发一个没人需要的优质软件产品、开发一个销售部门不知道如何
销售的软件产品、或开发一个不再符合整体商业策略的产品等等。
2．风险估算——风险预测。
软件项目管理人员主要从影响风险的因素和风险发生后带来的损失来度量风险。
要对风险进行估算，首先应建立风险度量指标体系、指明风险带来的影响和损失，
确定影响风险的因素，估计风险出现的可能性或概率，即进行定量的估算。
3．风险评价
一般来说，参照点不是一条平滑的曲线，而是一个易变动的区域，在这个区域要做
出基于参照值组合的管理判断往往是不准确的。因此，风险评价过程可分四步进行：
1）定义项目的风险参照水准；
2）定义每种风险的三元组[ri，pi，xi]，并找出和每个参照水准之间的关系；
3）预测一组参照点以定义一个项目终止区域，用一条曲线或一些易变动区域来定界；
4）预测各种风险组合的影响是否超出参照水准。
4．风险驾驭和监控
风险分析的目的是建立处理风险的策略，监控、驾驭风险。
驾驭风险是利用原型化、软件自动化、可靠性工程学等技术和软件项目管理方法设
法避开或转移风险。
描述风险的三元组[ri，pi，xi]是驾驭风险的基础。
风险驾驭与监控活动如图 2-6-2所示。
进度安排
进度安排可能是如下两种方式之一：
1）软件产品最终交付日期已经确定，开发方只能根据最终交付日期安排进度；
2）最后交付日期主要由软件开发方来确定。
软件项目的进度安排的准确程度可能比成本估算的准确程度更重要，如果进度安排
不当会导致客户不满、丧失市场机会和成本的增加。因此，进度安排必须解决好以
下几个问题。
1．任务、人力、时间等资源的分配应与工程进度相一致
由于大型软件项目的开发必然是项目管理人员、分析人员、设计人员等的集体劳动，
又是一项复杂的智力劳动，因此，必须制定合理的进度计划，并根据计划合理地分
配任务、人力、时间等资源。
比如，人力的分配要符合大型软件项目的 Rayleigh-Norden曲线。如果人力分配不
合理，比如在设计高峰投入的程序员不足，拖延了进度，这时临时加入新的程序员
不但不能加快进度，反而会使进度变得更慢。项目管理人员应努力寻求任务、人力、
时间的最佳组合，以便在满足进度要求的前提下获得最大的效益。在可能的情况下，
适当减少开发人员、相对延长一些开发时间，也可以取得较大的经济效益。
2．任务的分解与并行开发
为了充分发挥开发人员的潜力、缩短工期，软件工程项目的任务分解与安排应尽力
挖掘可并行开发的部分。
图 2-6-3是一个典型项目任务网络图。其中“▲”表示软件工程过程的里程碑，当
软件开发活动到达某个里程碑时，应当交付包括文档在内的阶段性产品并要通过评
审。软件开发项目的里程碑为管理人员提供了项目进度的可靠依据。图中给出了各
个子任务间的相互依赖关系。
3．工作量的分配
图 2-6-4给出了在整个软件项目定义与开发各阶段一种典型的工作量分布原则，称
为 40-20-40分布原则。即：
编码前的工作量约占 40%左右；
编码的工作量仅占 20%左右；
编码后的工作量约占 40%左右。
该原则只能从宏观上作为一个指南，实际工作量分配的比例必须根据具体项目的类
型和特点来确定。比如，和人命相关的软件项目在测试阶段的工作量可能达到其余
各个阶段的 3～5倍。
图 2-6-4软件开发工作量的分布
3．工作量的分配
在制定进度计划时，可以利用估算模型对工作量做出估计。如果利用基本 CoCoMo
模型或其他公式，可参照表 2-16给出的进度分配百分比来安排进度。
可按照表 2-16 给出的比例进一步确定每一阶段所需的开发时间。然后，在每一阶
段，进行任务分解，对各个任务再进行工作量和进度的分配。
4．具体进度安排
目前，软件项目的进度安排的两种比较常用的方法是程序评估与审查技术（PERT）
和关键路径法（CPM），这两种方法都生成描述项目进展状态的任务网络图。
图 2-6-5给出了用 MacProjectⅡ软件工具生成的项目进度安排图的一部分。图中：
方框——子任务；
带圆角的方框——里程碑；
框左上方的日期——子任务的开始时间；
框左下角的数字——完成本子任务所需的天数
4．具体进度安排
PERT和 CPM方法为软件项目规划人员提供了定量描述工具，具体有：
1）用经验模型估算完成每个子任务所需的工作量和时间；
2）确定关键路径。完成关键路径上的所有任务所需时间为项目开发所需的最短时间；
3）确定各子任务的时间窗口，即确定各子任务的最早启动时间和最迟启动时间。
4．具体进度安排
某子任务的最早启动时间是指该子任务的所有各前导子任务完成的最早时间；
该子任务的最早启动时间与完成该子任务所需时间之和就是该子任务的最早结束
时间。
而某个子任务的最迟启动时间是指在保证项目按时完成的前提下最晚启动该子任
务的时间；
最迟启动时间与完成该子任务所需时间之和就是该子任务的最迟结束时间。
在制定进度计划时，应首先找到影响进度的关键路径，并在关键路径上安排一定的
节假日和机动时间，以便应付可能出现的问题和难点。
软件质量保证
1．软件质量保证活动的内容
为了开发出高质量的软件，达到软件工程的目标，必须有计划地、系统地进行软件
质量保证（SQA，SoftwareQualityAssurance）活动。SQA活动主要包括以下内容：
1）在需求分析阶段提出对软件质量的需求，并将其自顶向下逐步分解为可以度量和
控制的质量要素，为软件开发、维护各阶段软件质量的定性分析和定量度量打下基
础；
2）研究并选用软件开发方法和工具；
3）对软件生存周期各阶段进行正式的技术评审
（FTR）；
4）制定并实施软件测试策略和测试计划；
5）及时生成软件文档并进行其版本控制；
6）保证软件开发过程与选用的软件开发标准相一致；
7）建立软件质量要素的度量机制；
8）记录 SQA的各项活动，并生成各种 SQA报告。
这里仅介绍软件工程的正式技术评审，其他内容在本书的其他章节中介绍。
2．软件工程的正式技术评审
1）FTR的作用
①FTR是保证软件质量的重要措施。
由于开发者在软件生存周期各个阶段的工作都可能产生错误。错误将随着工作的进
展而具有一种积累和放大效应，如图 2-6-6 所示。所以，在每一个阶段结束时，都
要进行正式的技术评审，以便及时发现并消除阶段性产品中的错误或缺陷，从而可
以保证软件质量。
②正式的技术评审是降低软件成本的重要措施。
软件开发实践表明，后期改正一个错误要比早期改正同一个错误需要付出的成本和
代价高出二到三个数量级，错误发现得越早，越易改正，损失越少。
2）正式的技术评审的组织和过程
FTR采用正式会议的方式。通常的做法是成立一个由 3~5人组成的技术评审小组，他
们是熟悉软件项目且水平较高的技术人员、管理人员。其中由组长 1 人、设计者 1
人、评审员 1~3人组成，1人兼做记录员。组长的任务是组织和领导评审过程的工作。
设计者的任务是负责回答技术上的问题，评审员的任务是合理、公证地评论工程中
的技术问题。
软件项目组织的建立与人员分工
1．组织原则
建立一个好的软件项目组织是保证软件开发能够顺利进行的必要条件之一。在建立
软件开发组织的时候要注意的原则是：
①尽早落实责任。特别是项目负责人的责任；
②减少接口。组织应该有良好的组织结构、合理的人员分工，以减少不必要的通信；
③责权均衡。指软件经理的责任不应比赋予他的权力还大。
2．组织结构的模式—常采用的 3种
1）按课题划分的模式（ProjectFormat）
将软件人员按照项目（课题）组成小组，小组成员始终参加所承担课题的各项任务，
即参加软件产品的定义、设计、编码、测试、评审、文档编制、直到维护的全过程。
2）按职能划分的模式（FunctionalFormat）
将人员按照软件生存周期各个阶段划分成若干个专业小组。比如分别建立计划组、
需求分析组、设计组、实现组、测试组、维护组、质量保证组等等。
优点：便于熟悉本组的工作。
缺点：各个小组之间通信频繁。
2．组织结构的模式—常采用的 3种
3）矩阵模式（MatrixFormat）
这种模式是以上 2种模式的组合。一方面，按工作性质成立一些专门组，如开发组、
业务组、测试组、维护组等；另一方面，每个项目都指派一个项目经理负责管理。
于是，每个软件人员即属于某一个专门组，又参加某一个项目的工作。因此，他要
接受专门组和项目经理的双重领导。
优点：专门组内的成员可互相交流在各自参加的项目中取得的经验教训，从而有利
于发挥专业人员的作用；而每个项目又有专人负责管理，有利于项目完成。
3．程序设计小组的组织形式
程序设计小组的组织和小组内部人员的组织形式对生产率都会产生影响。常采用的
组织形式有主程序员制小组、民主制小组、层次式小组 3种。
1）主程序员制小组（ChiefProgrammerTeam）
小组由 1位主程序员（高级工程师）、2~5位程序员（技术员）、1位后援工程师组
成，还可以配备辅助人员（如资料员）。主程序员是小组的领导和核心，他负责小
组全部技术活动的计划、协调与管理、关键技术、评审等工作。程序员负责项目的
开发、文档资料的编写等具体工作。后援工程师协助和支持主程序员的工作，也做
部分具体工作，必要时代替主程序员的工作。
（a）主程序员制小组
这种组织形式强调主程序员与其他程序员的直接联系，从而简化了程序员之间的通
信。而工作效果的好坏主要取决于主程序员的技术水平和管理才能。
2）民主制小组（DemocraticTeam）
虽然也设置一位组长，但是每当遇到问题时，组内的成员可以进行民主协商，以平
等的地位交换意见。工作目标的制定、做出决定都有全体组员参加，即强调发挥小
组每一个成员的积极、主动性和协作精神。
优点：集思广益、取长补短，适于时间长难度大的项目；
缺点：削弱了个人的责任心、并使开发效率有所降低。
3）层次式小组（HierarchicalTeam）
即将组内人员分为 3级：
组长 1人：他作为项目负责人负责全组工作；他直接领导 2~7名高级程序员；
高级程序员：通过基层小组管理若干名程序员。
层次式小组比较适合于这种本身就是层次结构状的课题或大型软件项目。此时可以
按照组织形式划分课题，然后把子项目分配给各个基层小组去完成。
软件开发小组的组织形式应根据实际问题的特点进行调整，软件开发小组内部和小
组之间应经常交流情况和信息，以减少误解，消除软件中的个人特征，从而有利于
软件质量的提高。
4．人员配备
实践表明，软件开发各个阶段所需要的技术人员的类型、层次和数量是不同的。
在软件项目的计划和分析阶段，只需要少数人，主要是系统分析员、从事软件系统
论证和概要设计的软件高级工程师和项目高级管理人员，人数虽不多，但都是高层
次人员。
1）配备人员的 33 个主要个主要原则
①重质量：软件项目开发是一种高智力、高技术型的工作，使用少量有实践经验、
素质高、有能力的人员去完成关键性任务，常常比使用较多的经验不足的人员更有
效。
②重培训：花力气培养所需的技术和管理人员是解决人员问题的有效方法。
③双阶梯提升：人员要么按照技术职务提升，要么按照管理职务提升，两者不应兼
得。
2）对项目经理人员的要求
对项目经理除了管理能力外，还要求应具有的能力：
①把用户提出的非技术性要求加以整理提炼，以技术说明书形式转告给分析员和测
试员。
②能说服用户放弃那些不切实际的要求，以保证合理的要求得以满足。
③具有综合问题的能力。
④具有很强的沟通能力。
3）评价人员的标准
需要确定正确的人员评价标准并采用较好的方法了解和评价开发人员的素质、管理
能力和技术水平。
一个好的开发人员应具备的素质和能力有：
①善于与周围人员团结协作，建立良好的人际关系，善于听取别人的意见。
②牢固掌握计算机软件的基本知识和技能。
③善于分析和综合问题，具有严密的逻辑思维能力。
④工作踏实、细致，遵循标准和规范，不靠碰运气，具有严格的科学作风。
⑤工作中表现有责任心、有毅力、有耐心。
⑥具有良好的书面和口头表达能力。
软件项目的跟踪与控制
软件项目管理的重要任务是对正在开发的软件项目进行跟踪和控制，以便及时发现
和处理问题，使开发人员能够按计划和要求有条不紊地工作。
项目管理人员经常采用的跟踪方式主要有：
①定期召开项目工作会议，让每个项目成员汇报任务进展情况和存在的问题。
②在软件开发过程中，请专家和用户按照里程碑对阶段性成果进行管理复审，判定
实际开发进度是否与计划中定义的里程碑保持一致。
软件项目的跟踪与控制
③对照进度计划检查各子任务的实际开始时间是否与计划的开始时间一致。
④及时了解项目开发人员的进展情况及存在的主要问题。
软件开发标准
软件开发的标准化有利于提高软件的一致性、完整性、可理解性，有助于提高软件
的质量。
第 3章计算机系统工程
一般地，基于计算机的系统是由硬件、软件、人、文档、数据库、过程等系统要素
构成的。其中各系统要素间的关系如图 3-0-1所示。
若不考虑系统内部结构和功能，基于计算机的系统可用输入-处理-输出（IPO）模
型表示。其中：
I（Input）指信息的输入；
P（Process）指对信息的处理；
O（Output）指信息的输出。
对于大型基于计算机的系统，其要素的本身可能也是一个基于计算机的系统。这时，
系统将具有复杂的层次结构。
本章主要包括计算机系统工程的概念、系统的可行性研究、系统建模与模拟、系统
规格说明与评审等内容。
计算机系统工程的概念
计算机系统工程是用工程、科学和数学的原则与方法研制基于计算机的系统的有关
技术、方法和过程。
计算机系统工程是一种从系统层面上的问题求解活动。在开始构造一个新的基于计
算机的系统时：
①计算机系统工程师（系统分析人员和系统开发人员）首先根据用户定义的系统目
标和约束条件进行系统可行性研究和系统需求分析，此时必须做大量、细致的研究、
论证工作，如有必要，还需建造系统或其中关键部分的原型，以便正确、完整地确
定系统的功能需求和性能需求。
②然后，系统工程师将系统功能和性能分配到系统各要素之中。
此时系统工程师应提出多种预选的方案，之后根据系统设计目标和约束条件并按照
一定的原则设计并选择最佳方案。比如，在成本、进度、系统资源、系统性能、支
撑环境等方面进行取舍和折衷。
在此基础上，对系统需求进行分解并分配给硬件、软件等系统要素，进而生成硬件、
软件等系统要素的需求，并分别通过硬件工程、软件工程、人机工程、数据库工程
等几个子工程予以实现。
硬件工程
硬件工程师根据系统硬件需求设计、制造或选择主机、外部设备、网络设备等硬部
件或设备。硬件工程师可通过硬件工程来实现硬件系统。
硬件工程可划分为硬件定义、硬件设计、硬件制造与销售维修三个阶段。其中:
硬件定义阶段的任务是：①制定硬件开发计划，确定项目成本和工程进度；②进行硬
件需求分析，给出硬件规格说明。
硬件设计阶段的任务是：①设计分析，画出设计图；②必要时建造原型（即样机）
并对其进行测试；③制造分析，画出生产图。
硬件制造与销售维修阶段的任务是：按照质量保证计划生产硬件产品并出售，相应
的服务机构对硬件产品进行售后服务。
软件工程
系统工程师在系统的论证阶段应确定系统对软件的功能和性能的要求，这将成为软
件需求分析的基础。
软件工程师根据分配给软件要素的功能和性能进行详细的需求分析，并进行软件总
体结构设计。在此基础上应尽力寻求可重用软部件来支持软件的详细设计和编码。
基于计算机系统的软件要素中的软部件由程序、数据和文档组成。按照功能，软部
件可划分为系统软件和应用软件两类。
软件在基于计算机的系统的 IPO模型的各个部分都起着重要的作用。其主要作用有：
①实现系统的输入和输出。
②如有必要，软件可设置与数据库的接口，支持系统对数据库的访问。
③软件通过一系列的算法和操作控制程序使各个系统要素有条不紊地工作，从而实
现系统的功能和性能。
1．软件项目定义部分
该部分由制定软件项目开发计划、需求分析 2个阶段组成，主要完成以下 4项任务：
1）制定软件项目计划。即界定软件工作范围、进行风险分析、提出项目开发所需资
源、进行成本和进度估算，进而进行可行性论证，生成软件项目计划并经过技术和
管理评审。
2）软件需求分析和定义。即确定软件的功能需求和性能需求、详细定义软件系统要
素，确定软件资源约束。在进行需求分析时，如有必要，还可以为软件或其中的关
键部分开发原型，以获得用户满意的软件需求。
3）为软件要素制定验收准则，制定软件验收测试计划。
4）生成软件需求规格说明，通过由客户、系统分析员、软件工程师和管理部门负责
人参加的评审后生效，并作为软件开发和软件产品验收的依据。
2．软件开发部分的任务
软件开发部分的任务是将系统对软件的需求转换成可操作的系统要素，即软件。
该部分由总体设计、过程设计和编码 3个阶段组成。
1）软件总体设计阶段
软件总体设计是指软件总体结构设计和数据设计，该阶段的主要任务是：
①设计软件的模块结构。
②定义接口并建立数据结构。
③生成概要设计规格说明和组装测试计划。
④评审概要设计的质量，重点评审总体设计是否支持软件需求规格说明的完全性和
可追踪性。
2）软件过程设计阶段——主要任务是：
①对概要设计规格说明中的每一个模块的过程进行详细的描述。
②制定单元测试计划。生成详细设计规格说明。
③对详细设计的阶段产品进行评审。
3）编码阶段——任务是：
用选定的编程语言将每一个模块的详细过程描述转换成程序。应注意良好的编程风
格、简洁性和自文档化，同时还应保持与过程设计的可跟踪性。
3．软件产品的验证、提交、经销与维护部分
1）软件验证阶段的主要任务是：
①软件开发人员根据单元测试计划对每一个模块进行单元测试，验证模块的功能是
否正确且符合设计要求。
②组织开发人员和专门的软件测试工程师对软件进行综合测试，测试软件总体结构
和接口是否满足设计要求，测试各软部件是否满足相应的软件功能需求和性能需求。
③组织专家、用户和客户对测试结果进行评审。
3．软件产品的验证、提交、经销与维护部分
2）软件的提交与经销的主要任务是：
①开发正式的用户手册、对文档进行分类、整理、归档，建立配置控制机制。
②将软件提交给用户，必要时应负责把软件安装到用户的环境中。
3）软件维护的任务是：
修正软件在运行中发现的错误、改善软件的功能和性能、适应软件运行环境的变化、
提高软件的可维护性和可靠性等等。
以上所介绍的就是将系统工程的观点和方法引入软件工程，用于指导软件的开发。
可行性研究
可行性研究的任务及步骤
1．可行性研究的任务
开发任何一个基于计算机的系统都会受到时间和资源的限制。因此，开发方在接受
客户的项目之前，必须根据客户可能提供的时间和资源等条件进行可行性研究。
可行性研究工作要在初步的需求定义之后进行。其主要任务不是研究如何解决问题，
而是要用最小的代价在最短的时间内确定该项目是否值得去解决，是否存在可行的
解决方案。即在系统层面上论证系统开发的可行性。
.可行性研究的任务可行性研究的任务
1）经济可行性研究：估算项目的开发成本和投入使用后可能带来的利润，进行成本
效益分析。及对其他产品或利润的影响。
2）技术可行性研究：根据客户提出的系统功能、性能要求及实现系统的各项约束条
件，从技术的角度研究实现系统的可行性。
3）运行、操作可行性研究：主要研究系统的运行方式在用户单位是否可以有效地实
施，是否与原有其他系统相矛盾；系统的操作规程在用户单位内是否可行，它包括
人事、科技政策、管理方法等。
4）法律可行性研究：研究新系统的开发和使用是否会侵犯他人的权益，是否触犯了
国家的法律法规。
5）开发方案的选择：可行性研究的最主要任务是对以后的行动提出建议。如果问题
没有可行的解，分析人员应建议停止该项目，以避免造成进一步的浪费；如果问题
值得解决，则提出并评价实现系统的各种可行的开发方案，从中选择一种最佳方案，
并为系统制定一个初步的开发计划。
1）复查初步分析结果。
对系统初步的分析结果和报告书进行复查，改正含糊或不确切的叙述，重新确定系
统目标与规模，清晰地描述对系统的所有约束条件。
2）研究现有的系统。
找出其基本功能和信息，指出其缺点或局限性。
3）导出新系统高层逻辑模型。
用某种图形工具导出系统高层逻辑模型，并与现有系统进行比较。
4）导出新系统的高层次物理解法，提出多个供选择的方案，并对每一个方案的经济
可行性、技术可行性、运行和操作可行性等进行分析比较。
5）推荐建议的方案。
如果系统分析员认为值得开发，则应指出开发的价值、推荐方案的理由并为推荐的
系统草拟一份开发计划；若分析员认为不值得开发，也应拿出充分的理由。并提交
可行性研究报告等全部文档。
6）评审、复审和决策。
可行性研究最后要通过技术评审和管理复审，开发方和客户方或使用部门负责人根
据成本-效益分析等各项可行性研究的结论，决策是否继续这项工程。
系统模型
1．结构模板
系统分析员将基于计算机系统的功能和性能分解为若干个子系统并精确定义各子
系统的界面之后，开始建立系统模型。
任何一个基于计算机系统都可以用输入-处理-输出（IPO）图来描述，它将该系统
转换成一个信息变换模型。在 IPO 模型的基础上，Hatley 和 Pirbhai 又补充了用户
界面处理、维护和自测试处理两方面的内容，从而构成了系统结构模板，它是系统
建模的基础。
2．结构图
系统分析员用结构模板来开发系统模型。借助于结构模板，按照系统工程和软件工
程的建模技术自顶向下、由粗到细地建立具有层次结构的系统模型。
在这里，使用一种结构关系图（ACD，ArchitecturalConnectorDetail）来描述系
统的总体结构，它位于系统模型的最顶层。
利用 ACD可以定义系统的组成、各子系统使用和产生的信息，建立系统与环境间的
信息界面，实现系统与外部环境间的通信等等。
传送带在线货物在线货物分类系统总体结构关系图
方框——外部实体，即系统信息的生产者和消费者；
圆角方框——系统或子系统；
有向边——系统的信息流（数据流或控制流）。
系统规格说明与评审
系统规格说明
系统规格说明是系统分析和定义阶段生成的一种文档。
该文档描述了基于计算机系统应达到的目标，应具有的功能、性能和支配系统开发
的各种约束条件；指明了各子系统在整个系统中的作用和地位；描述了系统的输入
输出数据和控制信息。
系统规格说明是硬件工程、软件工程、数据库工程和人机工程的基础。
可供参考的系统规格说明目录（略）
系统规格说明的评审
首先，系统开发人员应当和用户、客户通力合作，对系统规格说明进行技术评审。
技术评审主要解决的问题有：
①系统规格说明中的定义是否正确，是否正确地描述了项目的范围、准确定义了系
统的功能、性能和界面，开发人员和用户对系统的目标是否有共同的认识等。
②系统功能的复杂性是否与开发风险、成本和进度预测保持一致。
③系统及各子系统功能定义是否足够详细。
④系统与环境及各子系统之间的接口定义是否详细、有否遗漏。
⑤是否指明系统性能、可靠性和可维护性等需求。
⑥是否为以后的开发打下坚实的基础。
管理复审
技术评审通过后，还要进行由项目管理部门和客户方负责人参加的管理复审。管理
复审主要解决的问题有：
①系统是否有稳定的商业需求、经济和社会效益。
②系统开发是否还有其他的选择方案。
③系统各部分开发风险如何。
④系统开发所需资源是否具备。
⑤成本和进度计划是否合理等。
管理复审最后应做出是否继续开发项目的决策。
系统规格说明技术评审和管理复审通过后，即可按照硬件工程、软件工程、数据库
工程、人机工程等并行进行开发工作。
第第44章章 需求分析需求分析
软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。
需求分析就是通过对应用问题及其环境的分析与理解，采用一系列的分析方法和技
术，将用户的需求逐步精确化、完全化、一致化，最终形成需求规格说明文档的过
程。
系统分析阶段产生的系统规格说明和项目规划是软件需求分析的基础，分析人员需
从软件的角度对其进行检查和调整，并在此基础上展开需求分析。
需求分析阶段的成果主要是需求规格说明，该成果又是软件设计、编码、测试直至
维护的主要基础。
需求分析是系统分析和软件设计的重要桥梁，是软件生存周期的关键性阶段。良好
的分析活动能够减少错误和遗漏，从而可提高软件生产率和产品质量、降低开发与
维护成本。
本章介绍需求分析的基础知识。主要包括：
需求分析的三个主要步骤：问题分析、需求描述、需求评审及各个步骤的主要任务；
进行需求分析的一般技术和方法简介，包括初步需求获取技术、需求建模技术、快
速原型技术、多视点分析方法等；
需求规格说明的作用和内容及需求评审的标准和评审过程等。
需求分析的任务
需求分析的任务可通过问题分析、需求描述和需求评审三个步骤来完成。
1．问题分析
软件系统分析人员在这一步骤中的任务是根据对问题及其环境的理解与软件开发
经验，改正用户需求的模糊性、歧义性和不一致性，排除由于用户的片面性和短期
行为所导致的不合理要求、挖掘用户尚未提出但具有价值的潜在需求，并在用户的
帮助下对相互冲突的要求进行折衷，使用户需求逐步精确化、一致化和完全化。
2．需求描述
该步骤的主要任务是以需求模型为基础，生成需求规格说明和初步的用户手册，并
制定软件产品验收测试计划。
需求规格说明是软件项目的一个关键性文档。其中应包含对目标软件系统的功能、
外部行为、性能、质量、可靠性、可维护性、约束条件和需求验证标准等的完整的
描述。
初步用户手册应包括目标软件系统的用户界面的描述和使用方法的初步构想。
验收测试计划是进行软件产品验收测试的依据。
33．需求评审．需求评审
需求评审是软件开发过程中的一个重要的里程碑。
需求评审的主要任务是分析人员在用户（客户）和软件设计人员的配合下对需求规
格说明和初步用户手册进行审核，检验软件需求的精确性、完全性和一致性，并使
用户（客户）和软件设计人员对规格说明和用户手册达成一致的理解。
经过评审确认的需求规格说明将成为客户方与开发方的合同。如果评审未通过，比
如发现了遗漏或错误，则必须进行迭代，直至通过评审为止。
需求分析的一般性技术需求分析的一般性技术
为了克服困难，更有效地开展需求分析工作，软件系统分析人员必须掌握一些基本
的需求分析技术，主要包括：
初步需求获取技术；
需求建模技术；
快速原型技术；
问题的分解与抽象；
多视点分析技术等。
初步需求获取技术初步需求获取技术
在分析阶段的初期，由于分析人员和用户的共同知识领域可能不多，致使分析人员
对问题往往知之不多，而用户对目标软件的要求及对要求的描述常常是零乱而模糊
的，从而会造成相互交流和相互理解上的困难。为了克服困难，获取初步需求，可
以采用如下的技术手段：
访谈与会议；
观察用户工作流程；
分析人员和用户组成联合小组。
11．访谈与会议．访谈与会议
分析人员采用个别访谈或小组会议的形式与用户进行初步交流。在访谈和会议之前，
分析人员根据对问题的初步描述精心准备一系列问题，通过用户对问题的回答或互
相商讨来逐步理解用户的需求。
22．观察用户工作流程．观察用户工作流程
如果可能，可通过实际观察用户的手工操作过程来提取新系统的初步用户需求。
33．用户和开发人员共同组成联合小组．用户和开发人员共同组成联合小组
为加强信息沟通、减少误解和避免产生遗漏、充分调动用户的积极性，在可能的条
件下，可以建立由开发方和用户方共同组成的联合小组。
需求建模技术
为了使用户需求逐步精细化、完全化、一致化，通常采用需求建模技术，即用建立
目标软件系统模型的方法来刻画软件系统中的信息、处理功能和外部行为。
软件需求分析的过程，实际上是软件模型的建造和不断完善的过程。
需求建模的步骤需求建模的步骤
①在分析的初期，分析人员通过访谈、会议、实际观察、分析现有系统等方法获取
初步的用户需求。
②分析人员根据选定的一种分析方法，在初步用户需求的基础上构筑初步的模型作
为开发方和用户相互沟通的表示机制。
③分析人员在用户的密切配合下，利用选定的分析方法不断地对模型进行精细化、
一致化、完全化，直至获得满意的用户需求为止。
在分析阶段构筑的模型不应涉及软件实现的细节，以免分散分析人员的注意力、限
制软件设计人员为提高软件质量和效率而选择实现方法的自由度。
需求分析结束时确立的软件模型是生成需求规格说明的依据，也是软件设计和实现
的基础。
快速原型技术快速原型技术
如果按照传统的软件开发方法，需要经过漫长的开发时间之后用户才能看到目标软
件的最初版本。此时用户常常会提出许多修改意见，有时甚至全盘否定，导致开发
失败。为了降低开发风险，在需求分析阶段常常采用快速原型技术。
1．快速原型技术的基本思想
在软件开发的早期，快速开发一个目标软件系统的原型，让用户对其进行评价并提
出修改意见，然后开发人员根据用户的意见对原型进行改进。当原型几经改进最终
确认后，它将直接进化成软件产品，或者由软件设计、编码人员按照模型所确立的
外部特征去实现软件产品。
22．采用快速原型技术的具体步骤．采用快速原型技术的具体步骤
①采用一种分析方法生成一个软件系统或其中所关心部分的简化需求规格说明。
②对该规格说明进行评审通过后，立即生成设计规格说明。为了快速生成原型，这
种设计仅注重所关心的问题，如软件的总体结构、用户界面和数据设计、或者某个
复杂的算法等等，不注重过程内部的控制流设计。
③使用可重用软部件、用户界面自动生成器等工具快速生成可运行的软件原型并通
过测试。
④将原型提交给用户进行评价，以便征求改进意见。
⑤上述过程反复迭代，直至用户完全满意。此时的原型已完全、准确地反映了目标
软件在所关心方面的需求，可作为需求规格说明的一部分而成为软件设计的基础。
33．快速原型技术的适用场合．快速原型技术的适用场合
该技术特别适合于软件产品要求大量的用户交互、或产生大量的可视输出、或设计
一些复杂的算法等场合，目前的绝大多数软件都适合于快速原型技术。
除非由于问题相当复杂，致使开发快速原型可以获得的支持太少、所冒的风险太大
时，就不易采用。但对于其中的某些子问题，尤其是用户界面，还可采用快速原型
技术进行部分分析。
问题分解与抽象、多视点分析技术问题分解与抽象、多视点分析技术
问题分解技术
分析人员常常采用一种问题分解的技术。即将一个大型复杂的问题分解为若干个子
问题，然后对每一个子问题逐个进行分析，再自底向上综合成整个问题的分析结果。
这种分解可以逐级进行，直至子问题的规模降到合适的程度。
问题抽象技术
分析人员在分析过程中要善于从诸多的特殊问题中抽象出一般的问题，首先关注一
般问题的解决途径，再用其指导特殊问题的求解。在抽象的过程中，还要注意用户
的描述所处的抽象级别的不同，以便建立清晰的思路。
需求规格说明与评审需求规格说明与评审
需求分析的主要阶段性产品是需求规格说明书。它必须通过需求评审后才能生效，
这是一个重要的里程碑。
需求规格说明书的作用与内容
1.需求规格说明书的作用主要有：
1）它是软件设计人员进行设计和编码的出发点和基础；
2）它是对目标软件产品进行验收测试的依据。这就要求需求规格说明书中的各项需
求都应该是可测试的；
3）它起到软件开发方和客户（或用户）方之间的一份合同的作用。
需求规格说明书的作用与内容需求规格说明书的作用与内容
2.需求规格说明书中的内容
应主要包括功能与行为的需求描述和非行为需求描述。
功能与行为需求的分析与描述方法将在以后几章中根据不同的需求建模方法分别
介绍。
非行为需求是指目标软件系统在工作时应具备的属性，主要有运行效率、可靠性、
安全性、可维护性、可移植性等等。
在需求规格说明书中不应包括如人员需求、成本预算、进度计划、质量保证计划等
内容，以便使其简洁、目标明确。
需求规格说明书的基本格式框架需求规格说明书的基本格式框架((略略))
需求评审需求评审
软件系统中的错误约有 15%来源于需求分析中的错误。而在维护阶段去改正这部分
错误是相当困难的。为了及时发现并纠正这类错误，必须对需求规格说明书进行评
审，即需求评审。
1.评审标准（按照重要性的次序）
1）正确性。指需求规格说明书中的每一项功能、行为、性能的描述都是正确的、合
理的，并能满足用户的期望。
2）无歧义性。指规格说明书中的每个需求陈述都只有唯一的解释。要避免产生歧义
性，就应使用标准化术语，并对术语的语义进行统一的解释。
.评审标准（按照重要性的次序）评审标准（按照重要性的次序）
3）完全性。指不遗漏任何用户需求。即需求规格说明书中包括了所有的功能、行为、
性能约束等。
4）可验证性。指需求规格说明书中的每一项需求都是可以检验的。
5）一致性。指陈述的需求之间不存在矛盾之处。
6）可理解性。指规格说明应尽量简洁、明确，便于分析人员、客户（用户）、设计
人员、测试人员和维护人员的理解。因此，应尽量减少专业化的词汇。
7）可修改性。指需求规格说明书的框架结构应能比较容易地实现对其可能进行的增
补、删除和修改，并能保持总体结构不变。
8）可追踪性。指规格说明可向前追踪，即其中的每一项需求与用户的原始需求项清
晰地联系起来；也可向后追踪，即为后续开发和其他文档引用这些需求项提供了依
据。
.需求评审过程需求评审过程
需求评审过程应采用召开正式评审会议的形式。
参加的人员应当有用户、系统分析员、系统设计人员等。在评审会上，分析人员应
说明软件产品的总体目标，也就是介绍需求规格说明书中的主要内容。之后，与会
人员对说明书的核心部分——需求模型进行评估。并按照上述的评审标准逐一进行
审查，最后确认其是否具有良好的品质、是否构成以后开发的良好的基础。如果在
评审过程中发现说明书中存在错误或遗漏，应责承分析人员返工，并再行评审。需
求评审也可采用先进行技术评审，再进行管理复审的方法进行。管理复审应有开发
方和客户方（或用户方）管理部门负责人参加，复审通过后，双方应签订正式的合
同。
第第55章章 面向数据流的分析方法面向数据流的分析方法
面向数据流的分析方法（dataflow-orientedanalysismethod）与面向数据、面向
对象的分析方法，都是需求建模方法。它们均有一组规范的语言表达机制，用于需
求分析人员表达用户需求、构造软件系统模型。此外，它们还含有一些规则和经验
知识，指导分析人员提取需求信息，促进用户需求精确化、全面化和一致化。
面向数据流的分析方法是结构化分析方法系列中的一支，具有明显的结构化特征。
结构化分析方法的雏形出现于 20世纪 60年代后期。但是，直到 1979年才由 DeMarco
将其作为一种需求分析方法正式提出。由此，结构化分析方法得到了迅速发展和广
泛应用。
本章主要介绍广为使用的数据流方法，以及需求分析 CASE工具。
数据流图与数据字典数据流图与数据字典
一个基于计算机的信息处理系统由数据流和一系列的转换构成，而这些转换将输入
数据流变换为输出数据流。
数据流图就是用来刻画数据流和转换的信息系统建模技术。它用简单的图形记号分
别表示数据流、转换、数据源以及外部实体，如下图所示。
建立数据流模型要遵循以下的原则建立数据流模型要遵循以下的原则
1．每个加工至少应有一个输入数据流（反映被处理数据的来源）和一个输出数据流
（反映加工的结果）。
2．数据流图中各构成元素的名称必须具有明确的含义且能够代表对应元素的内容或
功能。
3．对某个加工进行细化生成的下层数据流图，称为其上层图的子图。应保证分层数
据流图中任意对应的父图和子图的输入/输出数据流保持一致。
4．应按照层次给每个加工编号，用于表明该加工所处的层次及上、下层的父图与子
图的关系。编号的规则为：顶层加工不用编号；第一层加工的编号为 1,2,…,n。第
二层加工的编号为 11,12,…,21,22,…,n1,n2,…,等，以此类推。
5．在父图中不要出现子图中涉及的局部数据存储文件。通常除底层数据流图中需表
明所有数据存储外，为保持画面整洁，各中间层数据流图只需显示处于加工之间的
接口文件即可。
6．数据流图只能由四种基本符号组成，是实际业务流程的客观映象，用于说明系统
应该“做什么”，而不需要指明系统“如何做”。
7．数据流图的分解速度应保持适中。通常一个加工每次可分解为 2~4个子加工，最
多不要超过七个，否则会增加用户的理解难度。同时要注意，逐层精化必须适可而
止。
8．如果为了便于数据流图在计算机上的输入和输出，应免除斜线、弧线、圆等符号。
数据字典数据字典
数据流图机制没有描述数据流的内容。数据流图必须与描述并组织数据条目的数据
字典配套使用。
数据字典中每一数据条目包含的内容数据字典中每一数据条目包含的内容
1．数据流图中标识数据流、数据源或外部实体的名称与别名；
2．数据类型；
3．所有以它作为输入流或输出流的转换的列表；
4．如何使用该数据条目的简要说明；
5．数据条目的解释性说明；
6．其他补充说明，例如取值范围与缺省值有关的设计约束等。
数据字典数据字典
数据条目的定义必须遵循以下原则：精确、简洁，能为用户方和软件开发方共同理
解。例如，可以使用形式语言中的语法定义机制描述数据条目的内容。原子语法成
分则用简单明了的自然语言予以描述。
实体实体--关系图关系图
在数据密集型应用问题中，对复杂数据及数据之间复杂关系的分析和建模将成为需
求分析的重要任务。
实体-关系图——在数据流分析方法中适合于复杂数据建模的工具。
数据对象、属性与关系
数据对象：是现实世界中实体的数据表现；是省略了功能和行为的实体。数据源；
数据对象包括：外部实体的数据部分；数据流的内容。
数据对象、属性与关系数据对象、属性与关系
数据对象由其属性刻画。通常属性包括：
1．命名性属性：对数据对象的实例命名，其中必含有一个或一组关键属性，以便唯
一地标识数据对象的实例。
2．描述性属性：对数据对象实例的性质进行刻画。
3．引用性属性：将自身与其他数据对象的实例关联起来。
一般而言，现实世界中任何给定实体都具有许多属性，分析人员应当并且只能考虑
与应用问题有关的属性。例如，在汽车销售管理问题中，汽车的属性可能有：制造
商、型号、标识码、车体类型、颜色和买主。
数据对象、属性与关系数据对象、属性与关系
应用问题中的任何数据对象都不是孤立的，它们与其他数据对象一定存在各种形式
的关联。
数据对象、属性与关系数据对象、属性与关系
建立数据模型的规范化规则：确保一致性并消除冗余
1．数据对象的任何实例对每个属性必须有且仅有一个属性值。
2．属性是原子数据项，不能包含内部数据结构。
3．如果数据对象的关键属性多于一个，那么其他的非关键属性必须表示整个数据对
象而不是部分关键属性的特征。
4．所有的非关键属性必须表示整个对象而不是部分属性的特征。
实体实体--关系图关系图
实体-关系（Entity-Relation）图简称 E-R图，是表示数据对象及其之间关系的图
形语言机制。
数据对象（实体）用长方形、关系用菱形、属性用椭圆表示。数据对象之间数量上
的对应关系的表示如下图所示：
基于数据流的分析方法基于数据流的分析方法
创建数据流模型创建数据流模型
数据流图是目标软件系统中各个处理子功能以及它们之间的数据流动的图形表示。
数据流图的精化过程实际上是处理子功能和数据流的细化过程。随着这一过程的进
行，用户需求逐步精确化、一致化和完备化。
创建用户需求的数据流模型应遵循以下 5条规则：
1）首先建立顶级数据流图，其中只含有一个代表目标软件系统整体处理功能的转换。
2）对用户需求的文字描述进行语法分析，其中的名词和名词短语构成潜在的外部实
体、数据源或数据流，动词构成潜在的处理功能。
3）采用通常的功能分解方法，按照“强内聚、松耦合”的原则逐个对处理功能进行
精化；与此同时逐步完成对数据流的精化，并针对被精化的处理功能生成下一级数
据流图。
4）精化过程中必须维持各级数据流图之间的数据流平衡。
5）精化过程应适可而止，避免涉及软件设计细节。一般说来，如果某子功能可以用
一段简洁、精确的文字描述清楚，就无需进一步分解。
过程规格说明过程规格说明
对于数据流图中不再分解的处理功能，分析人员要借助结构化自然语言对其功能进
行精确、简洁的描述。
