题型

1.名词解析 10题

2.简答 5题

3.综合 2题

重点看标记的，了解出小题，理解出小题或者大题，掌握出大题。

结合课本：

第一章概论

1.2软件工程

1.2.1软件工程定义（了解）

写出其中一种。

1.Friitz Bauer 在NATO会议上给出的定义

软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际的机器上高效的运行。

2.IEEE在软件工程术语汇编中的定义

软件工程是：

1. 将系统化的、严格约束的、了量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；
2. 对在1中所述方法的研究。

3.《计算机科学技术百科全书》中的定义

软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。

第二章系统工程

2.1基于计算机的系统（了解）能写出定义

所谓基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素组要有：软件、硬件、人员、数据库、文档和规程。

1. 软件：软件是指计算机程序、数据结构和一些相关的工作产品，用以实现所需的逻辑方法、规程或控制。
2. 硬件：硬件是指提供计算能力的电子设备、支持数据流的互联设备（如网络交换器。电信设备）和支持外部功能的机电设备。（如传感器、马达等）
3. 人员：人员是指硬件和软件的使用者和操作者。
4. 数据库：数据库是指通过软件访问并持久存储的大型的有组织的信息集合。
5. 文档：文档是指描绘系统的使用和/或操作的描述性信息（如模型、规格说明、使用手册、联机帮助文件、web站点）。
6. 规程：规程是指定义每个系统元素或其他外部相关流程的具体使用步骤。

2.2系统工程的任务（理解）

计算机系统工程是一个问题求解的活动，其目的是分析基于计算机的系统的功能，性能等要求，并把它们分配到基于计算机系统的各个系统元素中，确定他们的约束条件和接口。

系统工程主要包括以下任务。

1.识别用户的需求

系统工程的第一部就是识别用户对基于计算机的系统的总体要求，标识系统的功能和性能范围，确定系统的功能，性能、约束和接口。

2.系统建模和模拟（重点，需要理解并写出）

一个基于计算机的系统通常可以考虑一下模型。

1. 硬件系统模型
   • 硬件系统模型描述基于计算机系统中的硬件（包括计算机。受系统控制的其他硬件设备等）配置、通信协议、拓扑结构、以及确保基于计算机系统的安全性、可靠性、性能等需要的措施。
2. 软件系统模型
   • 基于计算机系统中的软件部分（软件系统）通常可以分解成若干个子系统。软件系统模型描述各软件子系统的功能、性能等要求，各软件子系统在硬件系统中的部署情况，以及软件子系统之间的交互。
3. 人机接口模型
   • 人机接口模型描述人如何与基于计算机的系统进行交互，包括用户环境、用户的活动、人机交互的语法和语义等。
4. 数据模型
   • 数据模型主要描述基于计算机的系统使用了哪些数据库管理系统，如果使用多个数据库管理系统，还应该描述它们之间的数据转换方式，必要时 可以给出主要的数据结构。
   • 系统模型通常可用图像描述，并加以相应的文字说明，共同完成整个基于计算机的系统的全部要求。必要时，在系统建模后可构造原型，进行系统模拟，以分析所建的模型能发满足整个基于计算机系统的要求。

3.成本估计及进度安排

开发一个基于计算机的系统需要一定的资金投入和时间约束（交付日期），因此在系统工程阶段应对需开发的基于计算机的系统进行成本估算，并作出进度安排。

4.可行性分析

可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，通常只有当解决方案可行并且有一定的经济效益和/或社会效益时，才真正开始基于计算机系统的开发。

5.生成系统规格说明

在以上各任务完成以后，应该形成一份系统规格说明，作为以后开发基于计算机的系统的依据。系统规格说明描述基于计算机的系统的功能、性能和约束条件，描述系统的输入输出和控制信息，给出各系统元素的模型，进行可行性分析，最后给出成本估算和劲速安排计划。

2.3可行性分析（了解，定义）

开发一个基于计算机的系统通常都受到资源（如人力，财力、设备等）和时间上的限制，可行性分析主要从经济、技术。法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。

第三章需求工程

3.1需求工程概述（了解，定义）

需求工程定义为：“直到（但不包括）把软件分解为实际架构和构建之前的所有活动”。需求工程时一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。

20世纪80年代，Herb Krasner定义了需求工程的5个阶段：需求定义和分析、需求决策、形成需求规约。需求实现与验证。需求演进管理。进来，Matthias Jarke和Klaus Pohl提出了3阶段周期的说法：获取、表示和见证。Roger S。pressman将需求工程过程描述为六个清晰的步骤：需求诱导，需求分析和谈判，需求规约，系统建模、需求确认以及需求管理。Lan Sommerviller等将需求工程分为需求抽取，需求分析和需求协商、系统建模、需求确认以及需求管理。

本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理6个阶段。

3.2需求获取

3.2.2需求获取方法与策略（掌握）

在与用户交流的过程中，可能会存在误解、交流障碍、缺乏共同语言等问题，这些交流上的问题会导致得到的用户需求不稳定、缺乏完整性，甚至是错误的需求，因此在获取需求前首先要建立需求获取人员（通常被称为系统分析员）与用户的顺畅的通信途径，与用户交谈，向用户提问题，通过访谈与会议、参观用户的工作流程、观察用户操作、建立联合小组和实例分析来获取需求。

1. 建立顺畅的通信途径

   • 需求获取要成功,首先要建立需求获取所必需的通信途径,即在用户、系统分析人员、软件开发小组、管理人员之间建立良好的沟通方式,以保证能顺利地对问题进行分析。

2. 访谈与调查

   • 在获取的初期阶段,分析人员往往对问题了解很少,用户对问题的描述、对目标软件的要求也通常会很模糊,甚至出现不一致,同时,在项目的初期,分析人员通常缺乏与系统相关的领域知识,从而造成双方理解的障碍。因此在项目开始之前,分析人员要从分析已经存在的同类软件产品,或从行业标准、规则中,甚至从Internet上搜索相关资料来提取初步需求,然后以个别访谈或小组会议的形式开始与用户进行初步沟通。面谈通常分为结构化和非结构化的面谈。前者主要讨论一组事先计划好的问题,并要求按计划进行面谈;而后者对将要讨论的主题只有一个粗略的想法,依赖于需求获取者在面谈进行时的“临场发挥"。
   • 在具体的实践中,通常采用折衷的方法,即适当地计划好面谈,但不要过于详细,允许有一定的灵活性。一般按照如下原则进行准备:
   • 所提的问题应该循序渐进,从整体的方面开始提问,接下来的问题应有助于对前面问题更好的理解和细化。
   • 不要限制用户对问题的回答,这有可能会引出原先没有注意的问题。
   • 提问和回答在汇总后应能够反映用户需求的全貌。
   • 可以分析下面的简单实例。表3.1是一个“赛艇比赛成绩计算系统”的第一次面谈的准备计划。由于是第一次面谈,所以问题没有过细,只是涉及主要的问题。在面谈的过程中,用户的回答可能会引出原先没有注意的问题,可以在后续的面谈中加以解决。
   • 除与用户进行面谈外,还有一些其他的调查研究方法:可以进行市场调查,了解市场对将开发的软件有什么样的要求,了解市场上有无与待开发软件类似的系统,如果有,在功能上、性能上、价格上情况如何;可以采取多种调查方式,制定调查提纲,向不同层次的用户发调查表;可以访问用户和领域专家,把从用户那里得到的信息作为重要的原始资料进行分析,访问用户领域的专家所得到的信息将有助于对用户需求的理解。

3. 观察用户操作流程

   • 除了访谈和调查外,还可以到用户的实际工作环境中对用户的工作流程进行观察,了解用户实际的操作环境、操作过程和操作要求,对照用户提交的问题陈述,对用户需求可以有更全面、更细致的认识。不过在观察过程中需要注意的是:未来的软件系统并不是完全模拟用户现有的工作流程,分析人员要结合原有的开发经验和应用经验,分析其中哪些环节应该由软件系统完成,哪些环节应该由人来完成,并且主动剔除现有系统不合理的部分,改选现有的工作流程、寻找潜在的用户需求,这些需求的实现在将来软件应用的过程中一定会得到用户的赞同。

   4.组成联合小组（重点，与FAST会议相关，是啥，步骤，对应说明）

   ​ 为了能够有效地获取和挖掘用户需求，打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势，这种方法被称为便利的应用规约技术（FAST）。

   ​ FAST鼓励建立用户和开发者团队之间的合作，他们共同工作来表示问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案。他已经成为信息系统使用的主流技术，该技术为改善各种应用中的相互通信提供了潜在可能。FAST团队来自市场、软件和硬件工程以及制造方的代表组成，并选择外来人员作为协调者。该方法有以下基本原则：

   • 在中立的地点举行由开发者和用户出席的会议。
   • 建立准备和参加会议的原则。
   • 建议一个足够正式的议程以便可以自由的交流。
   • 由一个“协调者”（可以是用户、开发者或者其他外人）来控制会议。
   • 使用一种“定义规则”（可以是工作表、图标、墙上胶粘纸或者墙板）。
   • 目标是标识问题、提出解决方案的要素、商议不同的方法以及在有利于完成目标的氛围中刻画出初步的要求。

   以产品开发为例，FAST会议大体上有以下几个步骤：

   1. 当举行了开发者和用户之间的初步访谈后,确定一个FAST会议的时间和地点,并在会议召开之前将产品请求发布给所有的与会者。
   2. 要求每个FAST出席者在会议之前列出一组围绕系统环境的对象列表,对这些对象的操作列表或对象之间的交互功能列表,以及约束列表(如成本、规模大小、权重)和性能列表(如速度、精度)。这些列表可以不是穷尽的,但是,希望每套列表反映的是每个人对系统的感觉。
   3. 进行FAST会议时,当团队的每个成员提出自己的列表后,整个团队将创建一个组合的列表,该组合列表删去冗余项,并加入在表达过程中出现的新思想。在建好所有的组合列表后,开始讨论,并缩短、加长或重新组合表中的内容以更适当地反映将被开发的产品。
   4. 一旦创建了意见一致的列表,应该将团队分为更小的小组,每个小组力图为每个列表中的一个或多个项开发出小型的规约(即对包含在列表中的单词或短语的精细化)。然后每个小组将他们开发的每个小规约提交给所有的FAST出席者讨论,进行添加、删除或进一步的精化等工作。在所有讨论过程中,团队可能提出某些不能在会议过程中解决的问题,此时要保留问题列表以使这些思想在以后的活动中产生作用。
   5. 上一步骤完成后,每个FAST的出席者将讨论的结果形成列表提交给团队,团队基于此创建一组意见一致的列表。这组列表作为需求获取的结果,为需求分析和建模提供基础信息。

   FAST会议并不能解决在早期需求获取阶段遇到的所有问题,但是该方法提供了便利的条件,集中不同的观点、即时地讨论和求精以及具体地规约开发步骤,对于进行正确的需求获取是十分有益的。

5.用况

​ 用况(use case)常称为用例,当需求作为非正式会议-FAST的一部分而收集起来之后,分析员就可以创建一组标识一串待建造系统的使用场景。这些场景被称为用况的实例,用况提供了系统将会被如何使用的描述。

创建用况模型的主要步骤如下:

①确定谁会直接使用该系统,即执行者(actor)。

②选取其中一个执行者。

③定义该执行者希望系统做什么,执行者希望系统所做的每件事将成为一个用况。

④对每件事来说,何时执行者会使用系统,通常会发生什么,这就是用况的基本过程。

⑤描述该用况的基本过程。执行者和用户并不是一回事儿。

一个典型的用户可能在使用系统时扮演了一系列不同的角色,而一个执行者表示了一类外部实体,它们仅扮演一种角色。

第四章设计工程

4.1软件设计工程概述（了解、理解）定义

​ 软件设计是把软件需求变换成软件表示的过程，早期的软件设计分为概要设计和详细设计，现在的软件设计分为数据/类设计、软件体系结构设计、接口设计和部件级设计。概要设计将需求转换为数据结构、软件体系结构及其接口。详细设计或部件级设计将软件体系结构中的结构性元素转换为软件部件的过程描述，得到软件详细的数据结构和算法。

1.软件设计的任务

软件设计的输入是分析模型，使用一种设计方法，软件分析模型中通过数据、功能和行为模型所展示软件需求信息被传送给设计阶段、产生数据/类设计，体系结构设计，接口设计，部件级设计。

1. 数据/类设计（重点，也叫数据标准化）

   • 数据/类设计将分析类模型变换成类的实现和软件实现所需要的数据结构。类 、由CRC（类-责任-写作者）中定义的数据对象和关系以及数据字典中描述的详细数据内容为数据设计活动提供了基础。部分数据可能和软件体系结构的设计同时产生，更详细的数据结构则产生于设计每个软件部件时。
   • 数据结构是数据的各个元素之间逻辑关系的一种表示。数据结构设计应确定数据的组织、存取方式、相关程度以及信息的不同处理方法。
   • 数据设计的过程包括以下两步：
     • 首先，为在需求分析阶段所确定的数据对象选择逻辑表示，需要对不同结构进行算法分析，以便选择一个最有效的设计方案。
     • 然后，确定对逻辑数据结构所必须的那些操作的程序模块，以便限制或确定各个数据设计决策的影响范围。
   • 无论采取什么样的设计方法，如果数据设计的好，往往能产生很好的软件体系结构，具有很强的模块独立性和较低的程序发复杂性。“清晰的数据定义是软件开发成功的关键”。

2. 体系结构设计

   体系结构设计体系结构设计定义了软件的整体结构,由软件部件、外部可见的属性和它们之间的关系组成。体系结构设计表示可以从系统规约、分析模型和分析模型中定义的子系统交互导出。关于软件体系结构设计的概念和风格将在4.3节中介绍。

3. 接口设计

   接口设计接口设计描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。体系结构设计为软件工程师提供了程序结构的全局视图,但是就像房子的蓝图一样,如果不画出门、窗、水管、电线和电话线,整个设计将是不完整的。

   接口设计主要包括3方面内容:设计软件模块间的接口、设计模块与其他非人的信息生产者和消费者(如外部实体)之间的外部接口以及设计人(用户)与计算机间的人机接口。·模块间的接口设计是由模块间传递的数据和程序设计语言的特性共同导致的。一般来说,分析模型中包含了足够的信息用于模块间的接口设计。

   外部接口设计起始于对分析模型的每个外部实体的评估。外部实体的数据和控制需求确定下来以后,就可以设计外部接口了。内部和外部接口设计必须与模块内的数据验证和错误处理算法紧密相关,由于副作用往往是通过程序接口进行传播的,所以必须对从某模块流向另一个模块(或流向外部世界)的数据进行检查,以保证符合需求分析时的要求。关于人机界面设计,将在第11章详细介绍。

4. 部件级设计

   部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述。从类为基础的模型、流模型、行为模型等模型中得到的信息是部件设计的基础。详细信息和工具在4.4节中介绍。

2.软件设计的目标

​ 在软件设计的过程中，要密切关注软件的质量因素。设计是在软件开发中形成质量的阶段,设计提供了可以用于质量评估的软件表示,是将用户需求准确地转化为完整的软件产品或系统的主要途径,。

MeGlanghin给出了在将需求转换为设计时,判断设计好坏的3条特征,也就是软件设计过程的目标;

• 设计必须实现分析模型中描述的所有显式需求,必须满足用户希望的所有隐式需求。
• 设计必须是可读、可理解的,使得将来易于编程、易于测试、易于维护
• 设计应从实现角度出发,给出与数据、功能、行为相关的软件全貌。

为了达到上述目标,必须建立衡量设计的技术标准,它们包括以下内容

• 设计出来的结构应是分层结构,从而建立软件成分之间的控制。
• 设计应当模块化,从逻辑上将软件划分为完成特定功能或子功能的部件。
• 设计应当既包含数据抽象,也包含过程抽象。
• 设计应当建立具有独立功能特征的模块设计应当建立能够降低模块与外部环境之间复杂连接的接口。
• 设计应能根据软件需求分析获取的信息,建立可驱动、可重复的方法。

3.软件设计的过程

软件设计是一个把软件需求变换成软件表示的过程,通常的软件设计过程分为如下6个步骤：

1. 制订规范。
2. 体系结构和接口设计。
3. 数据/类设计。
4. 部件级(过程)设计。
5. 编写设计文档。
6. 设计评审。

​ 通常在建立软件设计过程时,首先应为软件开发组制订在设计时应该共同遵守的标准,以便协调组内各成员的工作。包括阅读和理解软件需求说明书,确认用户要求能否实现;明确实现的条件,从而确定设计的目标,以及它们的优先顺序;根据目标确定最合适的设计方法;规定设计文档的编制标准;规定编码的信息形式,与硬件及操作系统的接口规约,以及會名规则。然后进入到体系结构和接口设计、数据/类设计及部件级(过程)设计。这个过程是一个迭代的过程。最初的设计只是描绘出可直接反映功能、数据、行为需求的软件整体幅架,接着设计的迭代过程开始,在框架中逐步填人细节,将其加工成在实现细节上非常接近于源程序的软件表示。在设计结束后,要编写设计文档、制订用户手册和初步的测试计划并组织进行设计评审。

第五章 结构化分析与设计

5.1结构化分析方法概述

​ 20世纪60年代末到20世纪70年代初, Yourdon等人在“结构化设计”的研究中提出一种表示数据及对数据进行加工变换的图形符号,从而形成了结构化分析方法的雏形。1979年De Marco在他的著作《结构化分析和系统规约》中引入并命名了创建信息流模型的图形符号,提出了使用这些符号的模型。以后,一些学者又陆续提出了结构化方法的一些变种。到20世纪80年代中期, Ward和Mellor以及Hatley和Pirbhai对结构化方法进行了扩展,以适应于实时系统的分析。

1.抽象和分解

​ “抽象”和“分解”是处理任何复杂问题的两个基本手段。

• 抽象是指忽略一个问题中与当前目标无关的那些方面,以便更充分地关注与当前目标有关的方面。在求解一个复杂问题时,可以有许多抽象级别。例如,欲用计算机解决一个复杂的应用问题,开发人员首先将该应用问题抽象成一个计算机软件系统。在这个抽象层次上,可以忽略应用问题内部的复杂性,只关注整个软件系统与外界的联系,即软件系统的输人和输出。
• 然后,将这个大而复杂的问题分解成若干个较小的问题(如子系统或功能),每个较小的问题又可分解成若干个更小的问题(如功能或子功能),如此自顶向下一层一层地分解下去,直至每个最底层的问题都足够简单为止,如图5.1所示[6],这样,一个复杂的问题也就迎刃而解了。

结构化方法就是采用这种自顶向下逐层分解的思想进行分析建模的,自顶向下逐层分解充分体现了分解和抽象的原则。随着分解层次的增加,抽象的级别也越来越低,即越来越接近问题的解。在图5.1中,自顶向下的过程是分解的过程,自底向上的过程是抽象的过程。

2结构化分析的过程

结构化分析的过程可以分为如下4个步骤

1. 理解当前的现实环境,获得当前系统的具体模型(物理模型)。
2. 从当前系统的具体模型抽象出当前系统的逻辑模型。
3. 分析目标系统与当前系统逻辑上的差别,建立目标系统的逻辑模型。
4. 为目标系统的逻辑模型作补充。

3.结构化分析模型的描述形式（重点部分，要知道几个图是什么）

结构化分析方法导出的分析模型采用图5.2所示的描述形式。

图5.2中，数据字典是模型的核心，包括对软件使用和产生的所有数据的描述。围绕数据字典有3重图以及相应的规范或描述。

数据流图用于软件系统的功能建模，描述系统的输入数据流如何经过一系列的加工，逐步变换成系统的输出数据流，这些对数据流的加工实际上反映了系统的某种功能或子功能。数据流图中的数据流、文件、数据项、加工都应在数据字典中描述。加工规约是对数据流图中的加工的说明，在结构化方法中用加工的“小说明”作为加工规约。

实体-关系图（E-R图）用于数据建模，描述数据字典中数据之间的关系。数据对象的属性用：”数据对象描述“来描述。通常存放在数据字典中。

状态转换图用于行为建模，描述系统接收哪些外部事件，以及在外部事件的作用下系统的状态迁移（即从一个状态迁移到另一个状态）。

控制规约用来描述控制方面的附加信息。

结构化分析的分析结果包括：一套分层的数据流图、一本数据字典（包括E-R图）、一组加工规约以及其他补充材料（如非功能性需求等）。

5.4数据字典

数据字典和数据流图结合起来构成软件的逻辑模型（分析模型）

5.4.2字典条目（理解）

​ DFD中的每个元素(数据流、文件、加工、源或宿等)都对应于一个数据字典条目的描述,不同种类的条目有不同的描述内容。对于同一种类的条目,不同的开发组织或团队也可以根据项目的需要定义不同的描述内容。字典条目中的描述内容主要包括: DFD元素的基本信息(名称、别名、简述、注解)、定义(数据类型、数据组成)、使用特点(取值范围、使用频率、激发条件)、控制信息(来源、去向、访问权限)等。

1.数据流条目（重点）

数据流条目的描述内容如下。

• 名称:数据流名(可以是中文名或英文名).
• 别名：名称的另一个名字。
• 简述:对数据流的简单说明。
• **数据流组成:**描述数据流由哪些数据项组成。
• 数据流来源:描述数据流从哪个加工或源流出。
• 数据流去向:描述数据流流入哪个加工或宿。
• 数据量:系统中该数据流的总量,如考务处理系统中“报名单”的总量是100 000或者单位时间处理的数据流数量,如80000张/天。
• 峰值:某时段处理的最大数量,如每天上午9:00~11:00处理60000张表单。
• 注解;对该数据流的其他补充说明。

其中：

1. 别名给出描述对象的另一个名字。通常人们不希望对同一个实体赋予两个不同的名字,这容易引起混淆。但实际开发中,别名也经常出现。例如,当名称用中文表示时,常常将其对应的英文名作为别名;当名称用英文表示时,常常用英文缩写作为别名。还有一种情况,在旧系统的改造过程中,对某个实体名称重新命名,这时旧系统的名称就是新系统中名副其实的别名。对这种情况在必要时可以在数据字典中增加一个“别名条目"
2. 数据流的来源和去向描述了该数据流从哪个加工或源流向哪个加工或宿。
3. 峰值是一个与性能相关的信息,例如,对一个每天处理80000张表单的软件来说,并不意味着每小时处理10000张(以一天工作8小时计),可能在每天上午9:00-11:00要处理60000张,在这个时间段里平均每小时要处理30000张。因此该软件应以30000张/小时的处理速度设计系统。
4. 数据流组成是数据流条目的核心,它列出组成该数据流的各数据项。现实生活中的数据流是多种多样的,可以用表5.1给出的描述符号来描述数据流的组成。

2.文件条目

文件条目的描述内容如下。

• 名称：文件名。
• 别名：同数据流条目。
• 简述:对文件的简单说明。
• 文件组成:描述文件的记录由哪些数据项组成。
• 写文件的加工:描述哪些加工写文件。
• 读文件的加工:描述哪些加工读文件。
• 文件组织:描述文件的存储方式(顺序、索引),排序的关键字。
• 使用权限:描述各类用户对文件读、写、修改的使用权限。
• 数据量:文件的最大记录个数。
• 存取频率:描述对该文件的读写频率。
• 注解:对该文件的其他补充说明。

其中,文件组成的描述与数据流条目相同。

3数据项条目(重点)

数据项条目的描述内容如下。

• 名称;数据项名。
• 别名:同数据流条目。
• 数据类型:描述数据项的类型,如整型、实型、字符串等。
• 简述:对数据项的简单描述。
• 计量单位:指明数据项值的计量单位,如公斤、吨等。
• 编辑方式,描述该数据项外部表示的编辑方式,如23,345. 67
• 取值范围:描述数据项允许的值域,如1… 100.
• 与其他数据项的关系:描述该数据项与数据字典中其他数据项的关系。
• 注解：对数据项的其他补充说明。

其中,“与其他数据项的关系”可用于对数据的校验。

4加工条目

加工条目的描述内容如下。

• 名称：加工名。
• 别名：同数据流条目。
• **加工号:**加工在DFD中的编号。
• **简述:**对加工功能的简要说明。
• 输入数据流:描述加工的输入数据流,包括读哪些文件。
• 输出数据流:描述加工的输出数据流,包括写哪些文件。
• 加工逻辑:简要描述加工逻辑,或者对加工规约的索引。
• 异常处理:描述加工处理过程中可能出现的异常情况,及其处理方式。
• 加工激发条件:描述执行加工的条件,如“身份认证正确”、“收到报名单”。
• 执行频率:描述加工的执行频率,如每月执行一次、每天0点执行。
• 注解:对加工的其他补充说明。

其中,加工逻辑是加工描述的核心。加工分为基本加工(无DFD子图的加工)和非基加工(有DFD子图的加工),基本加工的加工逻辑用小说明描述(见5.5节),在加工条目中可填写对加工规约的索引。非基本加工分解而成的DFD子图已反映了它的加工逻辑,不书写小说明,可在加工条目中对加工逻辑作简要介绍。

5.源或宿条目

由于源或宿表示系统外的人员或组织,当采用人员或组织的名称作为源或宿的名字时源和宿的含义已经比较清楚了,因此,开发人员常常不将源或宿据字典中、考到字典的完整性,以及便于对DFD和数据字典进行检查,在数据字典中,仍可保留源或宿目,其描述内容如下。

名称:源或宿的名称(外部实体名).

别名:同数据流条目。

简要描述:对源或宿的简要描述(包括指明该外部实体在DFD)中是用作“源”,还是“宿”,还是“既是源又是宿").

输入数据流:描述源向系统提供哪些输人数据流。

输出数据流:描述系统向宿提供哪些输出数据流。注解:对源或宿的其他补充说明。

6,别名条目

并非所有的别名都要有别名条目,只有那些有必要补充说明的别名才给出相应的别名条目。

• 别名条目的描述内容如下。
• 别名：别名的名字。类型:指出别名属于那个种类(数据流、文件、数据、加工、源或宿).
• 基本名:别名的正式名称(原名)。
• 简述：同正式名称的简述。
• 说明：对别名的补充说明。

第七章面向对象方法基础

7.1面向对象的基本概念（了解，重点）

使用下列等式识别面向对象方法：

面向对象（Object oriented） = 对象（Object） + 分类 （classification）+继承（inheritance）+通过消息的通信（communication with massage）

可以说，采用这4个概念开发的软件系统是面向对象的。

1.对象

​ 在现实世界中,每个实体都是对象,如大学生、汽车、电视机、空调等,都是现实世界中的对象每个对象都有它的属性和操作,如电视机有颜色、音量、亮度、辉度、频道等属性,可以有切换频道、增大/减低音量等操作。电视机的属性值表示了电视机所处的状态,而这些属性值只能通过其提供的操作来改变。电视机的各组成部分,如显像管、印制板、开关等都封装在电视机机箱中,人们不知道也不关心电视机是如何实现这些操作的。

​ **在计算机系统中,对象是指一组属性以及这组属性上的专用操作的封装体。属性通常是一些数据,有时也可以是另一个对象。**例如,走一对泵,它的属性可以有书名、作者、出版社、出版年份、定价等属性,其中书名、出版年份、定价是数据,作者和出版社可以是对象,它们还可以有自己(在有些简单的软件系统中可能只用到作者名和出版社名,而下关心作者和出版社的其他信息,那么,它们也可以是数据),每个对象都有自己的属性值,表示该对象的状态。**对象中的属性只能通过该对象所提供的操作来存取或修改。**操作也称为方法或服务,操作规定了对象的行为,表示对象所能提供的服务。封装是一种信息隐蔽术,用户只能看见对象封装界面上的信息,对象的内部实现对用户是隐蔽的。封装的目的是使对象的使用者和生产者分高,使对象的定义和实现分开。一个对象通常可由对象名、属作和操作3部分组成。

2,类

​ **类(class)是一组具有相同属性和相同操作的对象的集合。**一个类中的每个对象都是这个类的一个实例(instance),例如,“轿车”是一个类,“轿车”类的实例“张三的轿车”.“条四的轿车”都是对象。也就是说,对象是客观世界中的实体,而类是同一类实体的抽象描述在分析和设计时,人们通常把注意力集中在类上,而不是具体的对象上。人们也不必为每个对象逐个定义,只需对类作出定义,而对类的属性的不同赋值即可得到该类的对象实例,图7.1所示。类和对象之间的关系类似于程序设计语言中的类型(type)和变量(variable)之间的关系。通常把一个类和这个类的所有对象称为类及对象,或称为对象类。

3.继承

​ 一个类可以定义为另一个更一般的类的特殊情况,如“轿车”类是“汽车”类的特殊情况称一般类是特殊类的父类或超类(superclass),特殊类是一般类的子类(subeclass)。例如“汽车”类是“轿车”类的父类,“轿车”类是“汽车”类的子类。同样,“汽车”类还可以是“交工具”类的子类,“交通工具”类是“汽车”类的父类。这样可以形成类的一种一般特殊的5次关系,如图7.2所示。

​ 在这种一般特殊的关系中,子类可以继承其父类(或祖先类)的所有属性和操作,同子类中还可以定义自己特有的属性和操作。所以,子类的属性和操作是子类中的定义部分和其祖先类中的定义部分的总和。

​ 继承是类间的一种基本关系,是基于层次关系的不同类共享属性和操作的一种机制父类中定义了其所有子类的公共属性和操作,在子类中除了定义自己特有的属性和操作外还可以对父类(或祖先类)中的操作重新定义其实现方法,称为重例如,矩看是多边形的子类,在多边形类中定义了属性;顶点坐标序列,x移、旋转.1示、计算面积等。在矩形类中,可定义它自己的属性长和宽,还可以对操作“计算面积"重新定义。

​ 有时,人们定义一个类,这个类把另一些类组织起来,提供一些公共的行为,但并不需要使用这个类的实例,而仅使用其子类的实例。这种不能建立实例的类称为抽象类(abstract class),例如,图7.2中的交通工具就是一个抽象类。通常一个抽象类只定义这个类的抽象·操作,抽象操作是指只定义操作接口,其实现部分由其子类定义。如果一个子类只有唯一一个父类,这个继承称为单一继承。如果一个子类有一个以上的父类,这种继承称为多重继承。如图7.3所示的“水陆两栖交通工具”类既可继承“陆上交通工具”类,又可以继承“水上交通工具”类的特性。

4.消息

​ **消息(message)传递是对象间通信的手段,一个对象通过向另一个对象发送消息来请求其服务。**一个消息通常包括接收对象名、调用的操作名和适当的参数(如果有必要的话)。消息只告诉接收对象需要完成什么操作,但并不指示接收者怎样完成操作。消息完全由接收者解释,接收者独立决定采用什么方法完成所需的操作。

5,多态性和动态绑定

​ 多态性(polymorphism)是指同一个操作作用于不同的对象上可以有不同的解释,并产·生不同的执行结果。例如,“画”操作,作用在“矩形”对象上则在屏幕上画一个矩形,作用在“圆”对象上则在屏幕上画一个圆。也就是说,相同操作的消息发送给不同的对象时,每个对象将根据自己所属类中定义的这个操作去执行,从而产生不同的结果。

​ 与多态性密切相关的一个概念就是动态绑定(dynamic binding),动态绑定是指在程序运行时才将消息所请求的操作与实现该操作的方法进行连接。传统的程序设计语言的过程调用与目标代码的连接(即调用哪个过程)放在程序运行前(编译时)进行,称为静态绑定,而动态绑定则是把这种连接推迟到运行时才进行。在一般与特殊关系中,子类是父类的一个特例,所以父类对象可以出现的地方也允许其子类对象出现。因此,在运行过程中,当一个对象发送消息请求服务时,要根据接收对象的具体情况将请求的操作与实现的方法进行连接。

第八章 面向对象建模

8.1用况建模（了解，定义）

​ 用况建模是用于描述一个系统应该做什么的建模技术，用况建模不仅用于新系统的需求获取，还可以用于已有系统的升级。

​ 通过开发者和客户之间为导出需求规约而进行的交互过程来建立用况模型。用况模型主要成分有用况、执行者和系统。系统被视为一个提供用况的黑盒，系统如何做，用况如何实现、内部他们如何工作，这些对用况建模都是不重要的。系统的边界定义了系统所具有的功能。功能用用况来表示，每个用况指明了一个完整的功能。用况的主要目标如下：

• 确定和描述系统的功能要求。
• 给出清晰和一致的关于系统做什么的描述。
• 为验证系统所需要的测试提供基准。
• 提供从功能需求到系统的实际类和操作的跟踪能力。

人们可以通过更改用况模型，然后跟踪用况所影响到的系统设计和实现，使系统的修改和扩充简单化。

​ 任何一个涉及系统功能活动的人都会用到用况模型。对客户而言,用况模型指明了系统的功能,描述了系统能如何使用。用况建模时客户的积极参与是十分重要的,客户的参与铁模型能反映客户所希望的细节,并用客户的语言和术语来描述用况。对开发者而言,用况模型帮助他们理解系统要做什么,同时为以后的其他模型建模、结构设计、实现等提供依据。集成测试和系统测试人员根据用况来测试系统,以验证系统是否完成了用况指定的功能。

8.1.1用况建模步骤

1. 定义系统
2. 确定执行者
3. 确定用况
4. 描述用况
5. 定义用况间的关系
6. 确定模型

第九章 基于构件的软件开发

9.1基于构件的软件开发概述

基于构件的软件开发是指使用可复用的构件来开发应用软件的开发方法。通常也称其为基于构件的软件工程(CBSE)。

9.1.1构件（重点，要能写出其中一点定义）

1.定义

目前对构件一次尚无统一的定义，这里给出几种典型的定义。

• Pressman的定义：构件是某种系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某种清晰的功能。
• Brown的定义：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。
• 《计算机科学技术百科全书》中的定义：软件构件是软件系统中具有独立相对功能，可以明确辨识，接口由规约指定，与语境有明显依赖关系，可独立部署，且多由第三方提供的可组装软件实体。软件构件需承载有用的功能，并遵循某一种构建模型。可复用构件是指具有可复用价值的构件。

在基于构件的软件开发中经常会使用到的商用成品构件，是指由第三方开发的满足一定构建标准并且可以组装的软件构件。

2.构件的要素

Brown在其著作中指出,构件具有如下5个要素。

(1)规格说明

​ 规格说明建立在接口概念之上,构件应有一个关于它所提供的服务的抽象描述,作为服务提供方与客户方之间的契约。规格说明应包括定义可用的操作,特殊情况下构件的行为约束条件,以及客户与构件的交互等。

(2)一个或多个实现

​ 一个构件在符合规格说明的前提下,可以有一个或多个实现,例如,不同编程语言或不同算法的实现。构件的实现者可以选择任何一种合适的实现方法,但必须确保其实现是满足规格说明的。必要时,还需按某种构件标准进行包装。

(3)受约束的构件标

​ 准由于实现不同构件的程序语言可能不同,运行环境也可能不同,因此,构件必须符合某种标准,才能支持异质构件间的互操作(访问服务),目前常用的构件标准有Microsoft的CM/DCOM,Sun的EJB和OMG的CORBA.

(4)包装方法

​ 构件可以按不同的方式分组(称为包)来提供一套可替换的服务。通常从第三方获取的构件就是这些包,它们代表了系统中的功能单元。使用包时需要某种对包的注册机制。

(5)部署方法

​ 一个成品构件安装在运行环境中,通过创建构件的可执行实例,并允许与它进行交互来实现部署。一个构件可以部署多个实例,而每一个实例都是独立的,并在自己的进程或线程中执行。

3,构件描述模型

​ 构件模型是关于构件本质特征的抽象描述。目前,学术界与产业界已经提出了许多构件模型,本节介绍3C模型和REBOOT模型。

(1) 3C模型

​ 3C模型是在1989年的Reuse in Practice Workshop中由一些系统工程领域的专家提出的，是关于构件的一个指导性模型。

该模型由构件的3个不同方面的描述组成

(2) REBOOT模型

​ REBOOT(reuse based on object-oriented technology,基于面向对象技术的复用)构作模型是一种基于刻面(facet)的模型。刻面是在对领域进行分析的基础上得到的一组基本的描述特征。刻面可以描述构件实现的功能、所操作的数据、构件应用的周境或任何其他特征。通常刻面描述限制在不超过7或8个刻面。一个构件通常包括以下刻面。①抽象(abstraction):构件概念的抽象性描述。②操作(operation);构件所提供的操作的描述。③操作对象(operand):描述操作的对象。④依赖(dependency) :描述构件与外界的依赖关系。

4,常用的构件

标准为了将多个构件组装成一个应用系统,支持异质构件间的互操作,软件产业界出现了多种构件标准,其中最常用的构件标准有国际对象管理组织(OMG)的CORBA, MicrosetCOM/DCOM,Sun公司的EJB.

第十章敏捷软件开发

10.1敏捷软件开发方法概述

10.1.3敏捷方法综述（了解，这也是定义。重点）

​ 从20世纪90年代开始，逐渐产生了一大批敏捷软件开发方法。其中比较有影响的包括：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法、自适应软件开发等。

敏捷软件开发方法具有以下一些共同的特征：

1.致力于降低变化带来的成本

​ 敏捷方法提倡软件开发的适应性，这就意味着能够通过软件过程和方法来降低变更带来的代价。Kent beck认为，可以通过诸如增量和迭代、测试驱动开发、重构、简单设计等手段，”抚平“变更成本的曲线。

2.强调价值

​ 敏捷软件开发关注客户价值，并且强调快速的支付。通过增量和迭代的开发，敏捷软件开发方法可以在早期就交付最有价值、最重要的功能。而不必等到所有的开发完成。

​ 同时，敏捷软件开发基于价值来衡量工作流的各个环节，尽量消除不必要的文档和环节，从而消除开发过程中的浪费。

3.强调人的作用

​ 敏捷方法不仅仅强调适应性，更强调”人的因素“在成功的软件开发中的重要性。软件开发从本质上是从一种创造性的活动，只有充分激发每个人的能动性，才能更好地实现软件开发的目的。而经典的过程模型忽略人和人的差异，这对于充分发挥个人的价值是不利的。敏捷软件开发方法中重视给予团队相应的授权，信任，帮助建立自组织的团队。

4.使用增量和迭代的开发方式

​ 增量和迭代并不是敏捷软件开发的发明。一直以来就存在很多增量和迭代的软件开发模型。但是，敏捷软件开发强调每次迭代都产生真正可以运行的软件，这样更容易获得客户的反馈，便于做出及时的，正确的适应性改变。同时，由于使用增量和迭代的方法，可以在很短的时间间隔内交付软件增量，能够更快的满足客户的需求。

第十一章人界界面设计

11.4.3黄金原则（了解，三条原则需要写出）

1.让用户拥有控制权

​ 用户希望控制计算机，而不是被计算机控制，因此在设计人机界面的时候要遵循以下原则，

(1)交互模式的定义不能强迫用户进入不必要的或不希望的动作的方式

​ 例如,如果在字处理菜单中选择拼写检查,则软件将转移到拼写检查模式。如果用户希型在这种模式下进行一些文本编辑,则没有理由强迫用户停留在排写检查模式,用户应够几乎不需要做任何动作就进入或退出该模式。

(2)提供灵活的交互

​ 如允许用户通过键盘命令、鼠标移动、语音识别命令等方式进行交互,以适应不同用户的偏好。

(3)允许用户交互可以被中断和撤销

​ 在设计人机界面时,允许用户交互可以被中断和撤销。

(4)当技能级别增长时可以使交互流水化并允许定制交互

​ 用户经常发现他们重复地完成相同的交互序列。设计“宏”机制,使高级用户能定制界面,以方便交互。

(5)使用户隔离内部技术细节

​ 设计应允许用户与出现在屏幕上的对象直接交互。例如,某应用界面允许用户直接操纵屏幕上的某对象(如“拉伸”其尺寸)。

2,减少用户的记忆负担

要求用户记住的东西越多,与系统交互时出错的可能也越大,因此好的用户界面设计不应加重用户的记忆负担。下面是减少用户记忆负担的设计原则。

(1)减少对短期记忆的要求

​ 当用户涉及复杂的任务时,要求很多的短期记忆。界面设计应设法减少需要记住的过去的动作和结果。例如,可以通过提供可视的提示,使用户能识别过去的动作。

(2)建立有意义的默认值

​ 允许用户根据个人的偏爱,定义初始的默认值。例如,设置Reset选项,让用户重定义初始的默认值。

(3)定义直觉性的捷径

​ 当使用助忆符来完成某系统功能时(如用Alt+P激活打印功能),助忆符应以容易记忆的方式(如使用将被激活的任务的第一个字母)联系到相关的动作。

(4)界面的视觉布局应该基于真实世界的隐喻

​ 例如,一个账单支付系统应该使用支票本和支票登记隐喻来指导用户的账单支付过程。这使得用户能依赖已经很好理解的可视提示,而不是记住复杂难懂的交互序列。

(5)以不断进展的方式揭示信息

​ 层次式地组织界面,通过点击感兴趣的界面对象,逐层展开其详细信息。

3,保持界面一致

用户应该以一致的方式展示和获取信息,这意味着:所有可视信息的组织遵循统一的设计标准,所有屏幕显示都遵守该标准。输入机制被约束到有限的集合内,在整个软件系统中被一致地使用,同时从任务到任务的导航机制也被一致地定义和实现。保持界面一致性的设计原则包括以下内容。

(1)允许用户将当前任务放在有意义的语境中

​ 很多界面使用数十个屏幕图像来实现复杂的交互层次,提供指示器(如窗口题目、图形图符、一致的颜色)使用户能知道目前工作的语境。此外,用户应该能确定该任务来自何处以及到某新任务的变迁存在什么选择。

(2)在应用系列内保持一致性

​ 一组应用应该统一实现相同的设计规则,以保持所有交互的一致性。

(3)不要改变用户已经熟悉的用户交互模型

​ 除非有不得已的理由,一旦一个特殊的交互序列已经变成一个事实上的标准(如使用Alt+S来存储文件),则用户在其遇到的每个应用中均是如此期望的。改变其含义将导致混淆,让用户不知所措。

第十三章 软件测试

13.1.2软件测试的基本原则 （理解）

Davis提出了一组指导软件测试的基本原则：

• 所有的测试都应可追溯到客户需求。测试的目的是发现错误，而最严重的错误是那些导致程序无法满足需求的错误。
• 应该在测试工作真正开始前的较长时间就进行测试计划。从现代软件工程的眼光来看，测试计划可以在需求模型完成时就开始，测试用例可以在设计模型确定后立即开始。
• Pareto原则可用于软件测试。即测试中发现的80%的错误可能来自于20%的程序代码。这表明，如果测试模块A时发现的错误比测试模块B时发现的错误多，那么模块A中潜藏的错误可能仍比模块B中潜藏的错误多，此时不能放松对模块A的测试。
• 测试应该从”小规模“开始，逐步转向”大规模“。先测试单个模块，再测试集成的模块簇，最后测试整个系统。
• 穷举测试是不可能的。例如，测试一个包含五个分支的循环程序，其循环次数为20，那么，该程序就有$5^{20}$条不同的执行路径，要穷举测试的所有路径是不可能的。
• 为了达到最有效的测试，应由独立的第三方来承担测试。”最有效“指发现错误的测试可能性最高的测试。由于开发软件是一个创建软件的过程，开发者有成就感，而测试软件是一个发现软件的过程，测试者要千方百计从软件中找出错误，即证明软件中有错误。因此，由开发者或开发方来测试自己的软件，往往再心理上存在障碍，从而使测试不是最有效的。

还有以下一些其他的测试原则

• 在设计测试用例时,应包括合理的输入条件和不合理的输入条件。大量的实践表明,用户在使用软件时,常常因为不熟练或不小心,而输入一些非法的或不合理的数据。因此应测试非法的或不合理的数据是否会导致软件的失效。
• 严格执行测试计划,排除测试的随意性。不按测试计划进行的测试,常常不能保证测试的充分性。
• 应当对每一个测试结果做全面检查。不严格检查测试结果,会遗漏经测试发现的错误,从而白白浪费测试所付出的代价。
• 妥善保存测试计划、测试用例、出错统计和最终分析报告,为维护提供方便。因为在改正错误后或维护后要进行回归测试(regression testing) ,即全部或部分地重复使用已做过的测试用例,以确保该修改未影响软件的其他功能。
• 检查程序是否做了应做的事仅是成功的一半,另一半是检查程序是否做了不该做的事。
• 在规划测试时不要设想程序中不会查出错误。如果在测试前就认为程序中没有错误,测试时就不会全力以赴地找错误,从而使测试不充分。

13.4.2单元测试（了解）定义

单元测试又称模块测试，着重对软件设计的最小单元——软件构件或模块进行测试。

单元测试根据设计描述，对重要的控制路径进行单元测试，以发现构件或模块内部的错误。单元测试通常采用白盒测试，并且多个构件或模块可以进行测试。

1．单元测试的内容

单元测试的内容主要包括:接口、局部数据结构、边界条件、独立路径和错误处理路径。

(1)接口

​ 测试模块的接口主要是确保模块的输入输出参数信息是正确的。这些信息包括参数的个数、次序、类型等。

(2)局部数据结构

​ 测试模块的局部数据结构主要是确保临时存储的数据在算法执行的整个过程中都能维特其完整性。典型错误有:不合适的类型说明、不同数据类型的比较或赋值、文件打开和关闭的遗漏、超越数据结构的边界等。

(3)边界条件

​ 测试边界条件主要是确保程序单元在板限或严格的情况下仍能正确地执行。

(4)独立路径

​ 测试过程中遍历所有的独立路径就能确保模块中的所有语句都至少执行一次。程序执行的路径实际上体现了计算的过程,计算中常见的错误有:不正确的操作优先级、不同类型数据间的操作、不正确的初始化、不精确的精度、不正确的循环终止、不适当地修改循环变量、发散的迭代等。

(5)错误处理路径

​ 好的软件设计应该能预料可能发生的错误条件,并在错误真的发生时,能通过错误处理路径进行重定向处理或终止处理。单元测试应该对所有的错误处理路径进行测试。错误处理部分潜在的错误有:报错信息没有提供足够的信息来帮助确定错误的性质及其发生的位置、报错信息与真正的错误不一致、错误条件在错误处理之前就已引起系统异常、异常条件处理不正确等。

2,单元测试规程

​ 单元测试通常与编码工作结合起来进行。通常,模块本身不是一个独立的程序,因此在测试模块时必须为每个被测模块开发一个驱动(driver)程序和若干个桩(stub)模块。

​ 驱动程序接收测试输入数据,调用被测模块,把测试输入数据传送给被测模块,在被测模块执行后,驱动程序接收被测模块的返回数据,并打印相关的结果。

​ 桩模块的功能是替代被测模块调用的模块,接受被测模块的调用,验证入口信息,把控制和模拟结果(可使用测试用例中的预期结果)返回给被测模块。

驱动程序的程序结构如下:

• 数据说明;
• 初始化
• 输入测试数据;
• 调用被测模块;
• 输出测试结果;
• 停止。

桩模块的程序结构如下:

• 数据说明;
• 初始化；
• 输出提示信息(表示进入了哪个桩模块);
• 验证调用参数打印验证结果;
• 将模拟结果送回被测程序,
• 返回。

第十五章 软件维护与再工程

15.1软件维护

15.1.1软件维护概念（了解）

​ 软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程，国标GB/T 11457-2006 对软件维护给出如下定义：在交付以后，修改软件或部件以排除故障、改进性能或其他属性或适应变更了环境的过程。

1.软件维护分类（重点）

​ 对软件维护有两种常见的错误认识:一是认为软件维护是一次新的开发活动;二是认为软件维护就是改错。虽然软件维护可以看作是新开发活动的继续,但是这两种活动还是有着本质的差别。新开发活动要在一定的约束条件下从头开始实施**,而维护活动则必须在"现有系统的限定和约束条件下实施**。另一方面,维护活动可能发生在改正程序中的错误和缺陷,改进设计以适应新的软、硬件环境以及增加新的功能时。根据起因不同,软件维护可以分为纠错性维护、适应性维护、改善性维护和预防性维护4类。

人们把为了改正软件系统中的错误,使软件能满足预期的正常运行状态的要求而进行的维护叫做纠错性维护。

随着计算机的飞速发展,数据环境(数据库、数据格式、数据输人输出方储介质)或外流环境(新的软、硬件配置)可能发生变化,为了使软件适应这种变化而修改软件的过程叫做适应性维护。

当一个软件顺利地运行时,常常会出现第三项维护的活动：在软件的使用过程中用户往往会提出增加新功能或修改已有功能的建议,还有可能提出一些改进的意见。为了满足这类要求,需要进行改善性的维护。

计算机软件由于修改而逐渐退化.为了使计算机程序能够被更好地纠错、适应和增强,以提高软件的可维护性、可靠性等，为了使计算机程序能够更好的纠错、适应和增强，以提高软件的可维护性，为以后进一步改进软件打下良好基础而修改软件的活动,叫预防性维护。

• 通常,预防性维护定义为: “把今天的方法学用于昨天的系统以满足明天的需要。”也就是说,采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编制和测试。例如,代码结构调整,代码优化和文档更新等。

第四项维护活动在现代的软件业中还比较少。在维护阶段的最初一两年,纠错性维护的工作量较大。随着错误发现率急剧降低,并趋于稳定,就进入了正常使用期。然而,由于改造的要求,适应性维护和改善性维护的工作量逐步增加。

实践表明,在几种维护活动中,改善性维护所占的比重最大,来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50%。

在实践中,软件维护各种活动常常交织在一起,尽管这些维护在性质上有些重叠,但是还是有充分的理由区分这些维护活动。只有正确区分维护活动的类型才能够更有效地确定维护需求的优先级。

2、维护问题

软件维护过程是指在软件维护期间所采取的一系列活动。

软件的开发过程对软件的维护产生较大的影响。如果采用软件工程的方法进行软件开发,保证每个阶段都有完整且详细的文档,这样维护会相对容易,被称为结构化维护。

反之,如果不采用软件工程方法开发软件,软件只有程序而缺少文档,则维护工作将变得十分困难,被称为非结构化维护。在非结构化维护过程中,开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等,这样做是十分困难的,也容易产生误解。要弄清楚整个系统,势必要花费大量的人力和物力,对源程序修改产生的后果也难以估计。在没有文档的情况下,也不可能进行回归测试,很难保证程序的正确性。

在结构化维护的过程中,所开发的软件具有各个阶段的文档,对于理解和掌握软件的功能、性能、体系结构、数据结构、系统接口和设计约束等有很大的帮助。维护时,开发人员从分析需求规格说明开始,明白软件功能和性能上的改变,对设计文档进行修改和复查,再根据设计修改进行程序变动,并用测试文档中的测试用例进行回归测试,最后将修改后的软件再次交付使用。这种维护有利于减少工作量和降低成本,大大提高软件的维护效率。

与软件维护有关的大多数问题都可归因于软件定义和开发方法上的不足。软件开发时采用急功近利,还是放眼未来的态度,对软件维护影响极大。一般说来,软件开发若不严格遵循软件开发标准,软件维护就会遇到许多困难。下面列出和软件维护有关的部分问题:

1. 理解别人的代码通常是非常困难的,而且难度随着软件配置成分的缺失而迅速增加。
2. 需要维护的软件往往没有文档或文档资料严重不足或软件的变化未在相应的文档中反映出来。
3. 当软件要求维护时,不能指望由原来的开发人员来完成或提供软件的解释,由于维护持续时间很长,因此当需要解释软件的时候,往往开发人员已经不在附近了。
4. 绝大多数软件在设计时没有考虑到将来的修改问题。
5. 软件维护这项工作毫无吸引力。一方面是因为软件维护,看不到什么“创造性成果”,但工作量很大,更重要的是维护工作难度大,软件维护人员经常遭受挫折。上述种种问题在现有未采用软件工程思想开发的软件中,都或多或少存在。

3,维护成本

​ 软件维护的代价使生产率惊人下降。维护费用只不过是软件维护最明显的代价,其他一些隐性的代价将更为人们关注。其他无形的代价包括以下内容;

1. 维护活动占用了其他软件开发可用的资源,使资源的利用率降低。
2. 一些修复或修改请求得不到及时安排,使得客户满意度下降。
3. 维护的结果把一些新的潜在的错误引人软件,降低了软件质量。
4. 将软件人员抽调到维护工作中,使得其他软件开发过程受到干扰

用于维护的工作可以划分成:生产性活动(如分析评价、修改设计、编写程序代码等)和非生产性活动(如理解程序代码功能、解释数据结构、分析接口特点和性能界限等)。下面的公式给出了一个维护工作量的模型:M=p+Kerd

其中,M是维护的总工作量,p是生产性工作量,K是经验常数,c是软件的复杂程度,d是维护人员对软件的熟悉程度。

上述模型表明,如果软件开发没有运用软件工程方法学,而且原来的开发人员未能参与到维护工作之中,则维护工作量和费用将呈指数增加。

在软件维护中,影响维护工作量的因素主要有以下6种。

1. 系统的规模:系统规模越大,其功能就越复杂,软件维护的工作量也随之增大。
2. 程序设计语言:使用强功能的程序设计语言可以控制程序的规模。语言的功能越强,生成程序的模块化和结构化程度越高,所需的指令数就越少,程序的可读性也越好。
3. 系统年龄:老系统比新系统需要更多的维护工作量。因为多次的修改可能造成系统结构变得更加混乱,同时由于维护人员经常更换,程序将变得越来越难以理解,加之系统开发时文档不齐全,或在长期的维护过程中文档在许多地方与程序实现变得不一致,从而使维护变得十分困。
4. 数据库技术的应用;使用数据库,可以简单而有效地管理和存储用户程序中的数据,还可以减少生成用户报表的应用软件的维护工作量。
5. 先进的软件开发技术;在软件开发过程中,如果采用先进的分析设计技术和程序设计技术,如面向对用技术等,可减少大量的维护工作量。
6. 其他一些因素;如应用的类型、数学模型、任务的难度、if 套深度、下标数等,对维工作量也有影响,

15.1.3 软件可维护性 （理解）

​ 可维护性，是指理解、改正、调整和改进软件的难易程度。对软件可维护性影响的主要因素有：可理解性、可测试性、可修改性和可移植性。

1.主要影响因素

可理解性（重点）

​ **可理解性是指理解软件的结构、接口、功能和内部过程的难易程度。**提高软件可理解性的措施有：采用模块化的程序结构：书写详细正确的文档；采用结构化的程序设计；书写源程序的内部文档；使用良好的编程语言；0具有良好的程序设计风格等。

可测试性是指测试和诊断软件(主要指程序)中错误的难易程度。提高软件可测试性的antyeta:具n·措施有:采用良好的程序结构;书写详细正确的文档;使用测试工具和调试工具;保存以前1的测试过程和测试用例等。

**可修改性是指修改软件(主要指程序)的难易程度。**在修改软件时经常会发生这样的情况:修改了程序中某个错误的同时又产生新的错误(由程序的修改引起的);或者在程序中增加了某个功能后,导致原先的某些功能不能正常执行。这主要是因为程序中各成分之间存在着许多联系,当程序中某处修改时,这些修改可能会影响到程序的其他部分。如果一个程序的某个修改,其影响波及的范围越大,则该程序的可修改性就越差;反之,其可修改性越好。软件设计中介绍的设计准则和启发式规则都是影响可修改性的因素。通常一个可修改性好的程序应当是可理解的、通用的、灵活的、简单的。通用性是指程序适用于各种功能变化而无需修改。而灵活性是指能够容易地对程序进行修改。

**可移植性是指程序转移到一个新的计算环境的难易程度。**影响软件可移植性的因素有:信息隐蔽原则、模块独立、模块化、高内聚低耦合、良好的程序结构、不用标准文本以外的语句等。可移植性表明程序转移到一个新的计算环境的可能性的大小,或者表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度。一个可移植的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统的性能。通常对于软件可移植性的度量考虑如下因素;

1. 是否是用高级的独立于机器的语言来编写程序?
2. 是否采用广泛使用的标准化的程序设计语言来编写程序?是否仅使用了这种语言的标准版本和特性?
3. 程序中是否使用了标准的普遍使用的库功能和子程序?
4. 程序中是否极少使用或根本不使用操作系统的功能?
5. 程序在执行之前是否初始化内存?
6. 程序在执行之前是否测定当前的输入输出设备?
7. 程序是否把与机器相关的语句分离了出来,集中放在一些单独的程序模块中,并有说明文件?
8. 程序是否结构化?并允许在小一些的计算机上分段(覆盖)运行?
9. 程序中是否避免了依赖于字母数字或特殊字符的内部表示?

2,软件可维护性评审

​ 可维护性是所有软件都应该具备的基本特点,在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性。在每个开发阶段结束前的技术审查和管理复审中,可维护都是重要的审查指标。

3,提高可维护性的方法

为了延长软件的生存期,提高软件的可维护性具有决定性的意义。通常采用的方法有: .确定质量管理目标和优先级、规范化程序设计风格、选择可维护性高的程序设计语言、完善程序文档和进行软件质量保证审查。

第十六章 软件项目管理

16.1软件项目管理概述（了解）定义

项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制、旨在实现项目的特定目标的管理方法体系。其基本内容为：

1. 项目定义
2. 项目计划
3. 项目执行
4. 项目控制
5. 项目收尾

对软件工程项目进行项目管理也需要对上述五个方面的内容进行管理。

16.1.1 软件项目管理的关注点

​ 由于软件项目的特殊性，将项目管理技术用于软件项目管理上，其有效的项目管理集中于四个P上：人员People、产品product、过程process、项目project。

1.人员

​ 人员是软件工程项目的基本要素和关键因素，在对人员进行组织时，有必要考虑参与软件过程的人员类型。一把们来说可以分为以下5类。

(1)项目管理人员

​ 项目管理人员负责软件项目的管理工作,其负责人通常称为项目经理,项目经理除了要求掌握相应的软件开发担的应具备管理人员应有的技能。项目经理的任务就是要对项目进行全面的管理,具体表现在对项目目标要有一个全局的观点,制订项目计划,监腔项目进展,控制反馈,组建团队,在不确定环境下对不确定问题进行决策,在必要的时候进行谈判并解决冲突。

(2)高级管理人员

​ 高级管理人员可以是领域专家,负责提出项目的目标并对业务问题进行定义,这类业务问题经常会对项目产生较大的影响

(3)开发人员

​ 这类人员常常掌握了开发一个产品或应用所需的专门技术,可胜任包括需求分析、设计、编码、测试、发布等各种相关的开发岗位。

(4)客户

​ 客户是一组可说明待开发软件的需求的人,也包括与项目目标有关的其他风险承担者。

(5)最终用户

​ 最终用户指产品或应用提交后,那些与产品/应用进行交互的人。软件项目的组织就称为软件项目组,每一个软件项目组都有上述的人员参与。项目组的组织必须最大限度地发挥每个人的技术和能力。

2,产品

​ 在进行项目计划之前,应该首先进行项目定义,也就是定义项目范围,其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等。

​ 软件开发者和客户必须一起定义产品的目的和范围。一般情况下,该活动是作为系统工程或业务过程工程的一部分,持续到软件需求分析阶段的前期。其目的是从客户的角度定义该产品的总体目标,但不必考虑这些目标如何实现。软件范围定义了与软件产品相关的数据、功能和行为,及其相关的约束。软件范围包括以下几个方面

（1)周境(context)

​ 说明待建造的软件与其他相关系统、产品或环境的关系,以及相关的约束条件。

(2)信息目标

​ 说明目标系统所需要的输入数据及应产生的输出数据。(

3)功能和性能

​ 说明软件应提供的功能,从而完成输入数据到输出数据的变换,同时还要给出对目标软件的性能要求。

​ 软件项目范围必须是无二义的和可理解的。为控制其复杂性,必要时还需对问题进行分解。

​ 在确定了产品的目的和范围后,就要开始设计并选择备选的解决方案,选择的依据是由产品交付期限、预算、可用的人员、技术接口及各种其他因素所形成的约束。分解。

3,过程

​ 传统的项目管理有大项目一项目一活动一任务一工作包一工作单元等多种分解层次，对软件项目来说,强调的是对其进行过程控制,通常将项目分解为任务子任务等,其分需者则是基于软件工程的过程。

​ 软件过程提供了一个包含了任务的框架,软件项目中这些任发的全面计划,任务中包含了任务名、里程碑、工作产品和质量组成了软件开不同特征和项目需求,选择不同的软件过程,并可对这些框架软件項目的不同的软件过程,也存在少量的公共过程框架活动(framework a与然,对性活动(umbrella activities) 保护性活动(如软件质量保证、软件配置管理和测量等)独立于任何一个框架活动,并贯穿于整个软件开发过程。

公共过程框架活动可有以下几种

(1)客户交流

建立开发者和客户之间的有效需求诱导所需要的任务。

(2)计划

定义资源、进度及其他相关项目信息所需要的任务。(

3)风险分析

评估技术的及管理的风险所需要的任务。

(4)构造及发布

构造、测试、安装和提供用户支持(如文档及培训)所需要的任务。

(5)客户评估

基于对在工程阶段生产的或在安装阶段实现的软件表示的评估,获取客户反馈所需要的任务。

​ 软件项目组应该灵活地选择最适合当前项目的软件过程模型以及模型中所包含的活动和任务。对于一些以前已有开发类似项目经验的较小项目,可以采用类似项目的软件过程。的任务。对于一些需求不很明确的项目,可选择原型模型或螺旋模型。如果项目的开发时间较瓶,在规定的时间内难以完成所有的功能,则可选择增量模型。总之,项目组应根据项目的具体情况和特点,选择合适的软件过程模型。

4．项目

进行有计划和可控制的软件项目是管理复杂性的一种方式。

既然采用了项目这种方式,就有必要采用科学的方法及工具对项目基本内容进行管理。

Real提出了包含如下5个部分常识的软件项目方法

(1)明确目标及过程

​ 充分理解待解决的问题,明确定义项目目标及软件范围,为项目小组及活动设置明确现实的目标,并充分发挥相关小组的自主性。

(2)保持动力

​ 为了维持动力,项目管理者必须提供激励措施以保持人员变动为绝对最小的量,小组应该强调所完成的每个任务的质量,而高层的管理应该尽量不干涉项目小组的工作方式。

(3)跟踪进展

​ 针对每个软件项目,当每个任务的工作制品(如规约、源代码、测试用例集合等)作为质量保证活动的一部分而被批准(通过正式的技术评审)时,对其进展进行跟踪,并对软件过程和项目进行测量。

(4)做出聪明的决策

​ 本质上,项目管理者和软件小组的决策应该“保持其简单”。例如,采用成品构件(COTS)或采用标准方法等。

(5)项目总结

​ 建立一个一致的机制以从每个完成的项目中获取可学习的经验。对计划的和实际的进度进行评估,收集和分析软件项目度量,从项目组成员和客户处获取反馈,并记录所有发现的问题。

16.2软件度量

16.2.2 面向功能的度量（掌握）方法基础

​ Albrecht与1979年首次提出了面向功能的度量，它是一种针对软件的功能特性进行度量的方法，该方法主要考虑软件系统的“功能性”和“实用性”。他建议一种称为“功能点”的度量，功能点是基于软件信息域的特征（可直接测量）和软件复杂性计算的。

1.功能点度量（是什么，怎么弄？）

功能点的计算步骤如下。

1.计算信息域特征的值CT

分享到：