软件是计算机系统中与硬件子系统相互依存的另一个子系统，是一个包含程序及其文档资料的完整集合，提供了用户与硬件子系统之间的接口。
（1）软件固有的特性
● 复杂性
● 抽象性
● 依赖性
● 软件使用特性
（2）软件生产特性
● 软件开发特性
● 软件产品形式的特性
● 软件维护特性
是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。
（1）软件生产率低。
（2）软件产品常常与用户要求不一致。
（3）软件规模的增长，带来了复杂度的增加。
（4）不可维护性突出。
（5）软件文档不完整、不一致。
（1）软件独有的特点给开发和维护带来困难。
（2）软件人员的错误认识。
（3）软件开发工具自动化程度低。
软件工程是指导计算机软件开发和维护的工程学科。
它强调按照软件产品的生产特性，采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前最好的技术结合起来，以便经济地开发出高质量的软件并有效地维护它。
软件工程的目标是基于软件项目目标的成功实现而提出的，主要体现在以下几方面。
● 软件开发成本较低。
● 软件功能能够满足用户的需求。
● 软件性能较好。
● 软件可靠性高。
● 软件易于使用、维护和移植。
● 能按时完成开发任务，并及时交付使用。
从历史上讲，软件工程的作用：是为了克服上个世纪60年代出现的软件危机,这种危机表现为软件开发的成本大、进度慢、维护难和质量得不到保障。
从当前来讲，软件工程的作用：就是告诉人们怎样去开发软件和管理软件。具体地讲，它表现在与软件开发和管理有关的人和事身上。
从软件项目团队来讲，软件工程的作用在于：在规定的时间内，按照规定的成本，完成预期质量目标（软件的功能、性能和接口达到需求报告标准）的软件。
从软件企业本身来讲，软件工程的作用在于：持续地规范软件开发过程和软件管理过程，不断地优化软件组织的个人素质和集体素质，从而逐渐增强软件企业的市场竞争实力。
从软件发展进程来讲，软件工程的作用在于：克服软件危机，控制软件进度，节约开发成本，提高软件质量。
软件产品从提出、实现、使用维护到停止使用退役的过程称为软件生命周期
。也就是说，软件产品从考虑其概念开始，到该软件产品不能使用为止的整个时期都属于软件生命周期。
可行性研究、项目计划、需求分析、总体设计、详细设计、编码实现（包括单元测试、集成测试、确认测试）、系统运行和维护。这几个阶段又可以归纳为3个阶段，即软件定义阶段，软件开发阶段和软件运行维护阶段。
**问 题 定 义 ：**在问题定义阶段，应该清楚：“知道要解决什么问题”。
**可行性研究：知道要解决的问题，**在这个阶段应该清楚“用什么办法解决这个问题”，保证在技术上、经济上、法律上是行得通的。
需 求 分 析 ：确定软件的功能和性能。知道用户的需求是什么，怎么依据需求开发。
总 体 设 计 ：设计软件的总体结构，将一个大系统按照功能设计成小模块，每个模块完成一个相对独立的小功能。
详细设计：对每个模块设计具体的算法和数据结构，可以包括具体细节，类似于工程设计中的施工图纸。详细设计有时也称模块设计。
**编码及单元测试：这个阶段的主要任务是根据详细设计的结果，用一种程序设计语言，编写正确的源程序，并且对每段程序进行严格测试。**要求源程序容易理解、容易维护。
综合测试：通过测试使软件系统达到用户的要求。最基本的集成测试和确认测试。集成测试是在把模块连接成系统的过程中，每连接若干个模块都进行必要的测试。确认测试是根据用户使用说明书，在用户的参与下对软件系统进行测试。
软件维护：软件投入运行后，进行维护，通常有四类维护活动：改正性维护、适应性维护、完善性维护、预防性维护。
瀑布：
特征：
1.阶段间的顺序性和依赖性
顺序性：只有等前一阶段的工作完成以后，后一阶段的工作 才能开始；前一阶段的输出文档，就是后 一阶段的输入文档。
依赖性: 只有前一阶段有正确的输出时，后一阶段才可能有正 确的结果。
2.推迟实现的观点
瀑布模型在编码以前安排了分析阶段和设计阶段，并且明确宣布，这两个阶段都只考虑目标系统的逻辑模型，不涉及软件的物理实现。把逻辑设计与物理设计清楚地划分开来，尽可能推迟程序的物理实现，这是瀑布型软件开发的一条重要的指导思想。
3.质量保证的观点
为了保证质量，瀑布型软件开发在各个阶段坚持了两个重要的做法：
每一阶段都要完成规定的文档。没有完成文档，就没有完成该阶段的任务。
每一阶段都要对完成的文档进行复审，以便尽早发现问题，消除隐患。
优点：
缺点：
为了克服瀑布模型的问题，可以在需求阶段或设计阶段平行地进行几次快速建立原型的工作。
原型：快速建立起来的可以在计算机中运行的程序。
模型的本意在初步需求分析之后，马上向客户展示一个软件产品原型(样品)，对客户进行培训，让客户试用，在试用中收集客户意见，根据客户意见立刻修改原型，之后再让客户试用，反复循环几次，直到客户确认为止。
原型开发后，可以获得更为清晰的需求反馈信息，既可以消除风险或减少不确定性，又可以采用平行瀑布模型方式。在瀑布模型的各阶段间转换时，可以适当并行扩展各阶段的开发工作。（特点）
原型模型-快速原型模型：
是首先快速建立一个能反映用户需求的、可以在计算机上运行的原型系统，并让用户在计算机上运行、认识该系统。
快速原型模型的优点:
可以得到比较良好的需求定义，容易适应需求的变化;有利于开发与培训的同步;费用低、开发周期短且对用户更友好。
快速原型模型的缺点:
用户随意的需求变化，使得用户容易产生误解，认为系统很容易被构造和修改。;
开发人员为了快速构造原型，可能会采用不合适的系统、语言和算法等，造成软件质量低下，适应性差，维护困难。
准确的原型设计比较困难。部分开发资源浪费，打击程序员信心。
原型模型-进化式原型模型（高度动态迭代和动态循环）
特点：
进化式模型将软件的需求细节定义、产品开发和有效性验证放在同一个工作进程中交替或并行运作，因此，在获得了软件需求框架以后，就可以进入到软件的开发中。
进化式原型模型通过不断发布新的软件版本而使软件逐步完善，因此，特别适合于那些用户急需的软件产品开发。
优点：
快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。它能够快速的向用户交付可以投入实际运行的软件成果，能够很好的适应软件用户对需求规格的变更。
缺点：
对于大型的项目，进化式原型缺乏有效的管理规程。快速变更可能会损伤软件的内部结构，使其缺乏整体性和稳定性。同时，文档也有可能跟不上软件的变更速度。
缺点：
进化式模型虽然可以加快开发进程，但不能像瀑布模型那样提供明确的里程碑管理，随着开发过程中版本的快速更新，项目管理、软件配置管理也会变得比较复杂，管理者难以把握开发进度。因此，对于大型的项目，进化式原型缺乏有效的管理规程。
开发过程中软件版本的快速变更可能会损伤软件的内部结构，使其缺乏整体性和稳定性。同时，文档也有可能跟不上软件的变更速度。
原型模型-增量式原型模型（增量模型是瀑布模型与原型进化模型的综合）
在整体上按照瀑布模型的流程实施项目开发，而在实际创建中，则把软件系统按照功能分解为许多增量构件，并以构件为单位逐个的创建与交付，直到全部增量构架创建完毕，并都被集成到系统中交付使用。（特点）
优点：
**有利于需求的逐步明确，能够有效的适应用户需求的变更。**开发初期的需求定义只用来确定软件的基本结构。
有利于用户更早的使用系统，获得后续构件的需求经验。
有利于开发者积累开发经验，有利于技术复用。
有利于从总体上降低软件项目的技术风险。
缺点：
对软件设计有更高的技术要求。
要求体系结构具有很好的开放性与稳定性。
构件之间具有相当好的功能独立性，接口简单。
需要良好的项目管理、控制和监视。
模型的本意：
螺旋模型将瀑布模型和快速原型模型结合起来，强调了其它模型所忽视的风险分析，特别适合于大型复杂的系统。
螺旋模型基本做法是在瀑布模型的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
特点：
螺旋模型将瀑布模型与原型模型结合起来，加入风险分析，并且具备了四个方面的活动：
（1） 制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2） 风险分析──分析所选方案，考虑如何识别和消除风险；
（3） 实施工程──实施软件开发；
（4） 客户评估──评价开发工作，提出修正建议。
优点：
有助于软件的重用和提高软件质量；
减少过多的因测试所浪费资金的风险；
防止人员变动、资金不能一次到位所引起软件开发的流产；
适用于内部开发大型软件项目
缺点：
多次迭代，若迭代效率不高，则迭代次数会过多，增加开发成本并推迟交付时间；
不能表达维护过程，维护过程需要另一个周期；
需要非常丰富的风险评估经验和专业知识，要求开发队伍水平较高，否则会带来更大风险。
喷泉模型(Fountain Model)认为，软件开发过程自下而上的各阶段是相互重叠和多次反复进行的，就像喷泉中的水喷上去，又可以落下来，所以叫做喷泉模型。
各个开发阶段没有特定的次序要求，而且可以交互进行，在每个开发阶段中，还可以随时补充其它任何开发阶段中的遗漏。
特点：
喷泉模型是一种以用户需求驱动的模型，主要用于描述面向对象的软件开发过程。
由于各阶段的活动之间无明显界线，所以喷泉模型也称为“喷泉无间隙性模型”。
优点：
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间。
缺点
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息。
简述什么是软件生命周期。根据国家标准《计算机软件开发规范》，软件生命周期主要包括哪几个阶段?
答:软件从被提出、形成到开始运行维护，到结束运行的这一段时间，即软件的概念的形成到不再适使用这个软件的这一段时间叫做软件生命周期。国家标准GB8566-1988《计算机软件开发规范》将软件生命周期划分为几个阶段:可行性研究、工程计划、需求分析、总体设计、详细设计、编码实现（包括单元测试、集成测试、确认测试)、系统运行和维护。这几个阶段又可以归纳为3个阶段，即软件定义阶段，软件开发阶段和软件运行维护阶段。
瀑布模型有哪些特点?对于里程碑，你有哪些认识?
答:1970年 W.Royce最早提出瀑布模型。答:瀑布模型的特点:**(1)．线性化模型结构: (2)．各阶段具有里程碑特征:(3)．基于文档的驱动;(4).严格的阶段评审机制。**其中的里程碑是指瀑布模型中的阶段只能逐级到达、不能跨越:每个阶段都有明确的任务，都需要产生确定的成果。由于瀑布模型是一种线性模型，要求工程严格按规程推进，必须等到所有开发工作全部完成以后才能获得可以交付的软件产品。因此，瀑布模型不太适用于用户需求经常变更的软件工程。
瀑布模型是一种基于里程碑的阶段过程模型，它所提供的里程碑式的工作流程，为软件工程按规程管理提供了便利。例如，按阶段制订工程计划，分阶段进行成本核算，进行阶段性的评审等。这为提高软件产品质量提供了有效保证。
四选一：
1、业务需求
反映了组织机构或客户对系统、产品高层次的目标需求
2、用户需求
关于软件的一系列想法的集中体现，涉及软件功能、操作方式、界面风格，用户机构的业务范围、工作流程、用户对应用软件的展望。用户需求特点如下：
①直接来源于用户
②需要以文档的形式提供给用户审查
③可以把用户需求理解为用户对软件的合理请求
④是为用户管理层撰写的
3、系统需求
是比用户需求更具有技术特性的需求陈述。
经济可行性、技术可行性、操作与管理可行性、社会可行性等
技术可行性分析
分析现有的技术条件和技术水平是否能够达到系统实现
的要求。
经济可行性分析
分析系统所带来的经济效益是否能够超过系统的开发和维护成本。
管理可行性分析
■ 企业领导对项目支持的态度；
■ 项目直接相关人员的支持态度和配合水平；
■ 现行业务处理是否规范；
■ 新的业务处理流程和方法能否被接受。
环境可行性分析
■ 是否有可能违反国家法律；
■ 是否符合行业要求；
■ 外界环境变化可能对系统产生的影响；
■ 网络环境对客户产生的影响。
研究资料法
问卷调查法
用户访谈
实地观察法
**是一种用来表示信息流程和信息交换过程的图解方法，它把系统看成是由数据流联系的各种功能的组合。**在需求分析中用它来建立现存或目标系统的数据处理模型，当数据流图用与软件需求分析时，这些处理或者转换，在最终生成的程序中将是若干个程序功能模块。
是结构化分析的另一个有力的工具，是关于数据信息的集合，是数据流图中所有元素的定义的集合。
用来表示系统的模块划分与层次分解关系，表示模块的调用关系、模块间数据流与控制流的传递关系以及模块与外界或数据存储的信息接口的规范化图形，是结构化系统设计的一种重要的图表描述工具。
结构化语言、判定树、判定表
适用范围：
判定树适用于10-15种行动的一般复杂程度的决策。有时可将判定表转换成判定树，便于用户检查。
判定表适合于5-6个条件的复杂组合。虽然判定表也适用于很多数目的行动或条件组合，但数目庞大时使用并不方便。
如果一个判断包含了一般顺序执行的动作或循环执行的动作，则最好用结构化语言表达。
以结构化的方式进行系统定义的分析方法。
对象设计则是决定在实现过程中使用的类和关联的全部定义,以及用于实现操作的各种方法的算法和 接口。
1.简述什么是需求分析?需求分析的任务是什么?
答:需求分析:开发人员准确地理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的需求规格说明的过程。
基本任务:⑴问题识别:双方确定对问题的综合需求，这些需求包括功能需求，性能需求，环境需求，用户界面需求:分析与综合，导出软件的逻辑模型:编写文档:包括编写"需求规格说明书"∵,"初步用户使用手册"∵,“确认测试计划”,“修改完善软件开发计划”
3.需求工程包含哪些内容时，如何写好需求规格说明?
答:**需求工程指应用工程化方法、技术和规格来开发和管理软件的需求。**需求工程的目标是获取高质量的软件需求。需求工程突出了工程化原则，强调以系统化、条理化和重复化的方法进行软件需求的相关活动，从而增强管理性和降低需求开发的成本。需求工程由需求开发活动和需求管理过程组成。一个好的需求规格说明应符合以下要求:1）正确性。每一项需求都必须准确地陈述其要开发的功能。即需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，这是软件系统真正需要完成可达到的。2）完整性。需求规格说明应该包括软件要完成的全部任务，每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施，不能遗漏任何必要的需求信息。3）**必要性。每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。4）划分优先级。给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。5）无二义性。对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的语言表达出来。**6）可验证性。需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。
**软件设计就是把需求规格说明书里归纳的需求转换为可行的解决方案，并把解决方案反映到设计说明书里面。**软件设计就是要解决怎么做的问题。软件设计是根据软件的开发需求来进行数据设计、体系结构设计、接口设计、构件设计和部署设计，在软件设计中包含概要设计和详细设计这两个阶段
软件设计分成两个阶段进行，首先是概要设计阶段(总体设计），用于取得软件系统的基本框架；然后是详细设计，用于确定软件系统的内部细节
概要设计的任务：
建立目标系统的总体架构
给出每个功能模块的功能描述、数据接口描述和调用关系，规定设计限制、外部文件及全局数据定义
设计数据库及数据结构
编写文档 编写概要设计说明书、用户手册等
(1)制定规范：目标原则、管理规则、编制标准、编码形式、接口规约
(2)体系结构设计：元素描述、相互作用、集成模式、模式约束
(3)软件结构设计：模块层次
(4)公共数据结构设计：公共数据变量的数据结构和作用范围、IO文件结构、表结构、视图结构及数据完整性等
(5)安全性设计：权限管理、日志管理、加密、操作校验等设计
(6)故障处理设计
(7)编写文档
(8)概要设计评审：需求确认、接口确认、模块确认、风险性、实用性、可维护性、质量等。
详细设计的任务：设计出程序的“蓝图”，也就是定义模块的算法细节，并用某种形式描述出来
详细设计的工具：程序流程图、PAD图、盒图、过程设计语言、判定表、判定树
自顶向下逐层把系统划分成若干模块的过程。对于整个系统来说，模块是可组合、分解和更换的单元。
模块的独立性是指不同模块之间的相互联系应尽可能的少，应尽可能减少公共的变量和数据结构，一个模块应尽可能在逻辑上独立，有完整单一的功能
耦合
模块间的联系多的耦合度强，少的耦合度弱
内容耦合是耦合程度最高的一种形式
内聚
内聚性是模块内部各成分之间的联系
模块内部各成分联系越紧，其内聚性越强，系统越容易理解和维护
用来表示系统的模块划分与层次分解关系，表示模块的调用关系、模块间数据流与控制流的传递关系以及模块与外界或数据存储的信息接口的规范化图形，是结构化系统设计的一种重要的图表描述工具。
也称为H图，用于描述软件结构上的分层调用关系，**作用类似于模块结构图，但不涉及调用时的数据流、控制流等附加信息。**它是一个表示软件系统结构的有效工具
HIPO图是H图和IPO图上结合形成的，获得模块间的调用关系以及调用时传递的信息
概要设计的任务和步骤是什么？
任务：
根据需求分析阶段所产生的软件需求规格说明书，建立目标系统的总体结构。1.建立目标系统的总体架构2.给出每个功能模块的功能描述3.设计数据库及数据结构4.编写文档
步骤：
1.制定规范2.体系结构设计3.软件结构设计。4。公共数据结构设计5.安全性设计6.故障处理设计7.编写文档。8.概要设计评审。
如何理解模块的独立性？用什么指标来衡量模块的独立性？
理解：
指不同模块之间的相互联系应该尽可能的少，应尽可能减少公共的变量和数据结构；一个模块应该尽量可能在逻辑上独立，有完整单一的功能。
指标：
模块之间的耦合度和一个模块的内聚性。
详细设计的主要任务：
详细设计的工具：程序流程图、PAD图、盒图、过程设计语言、判定表、判定树
特点：
1.封装:对外只暴露最小完整可用接口，隐藏内部实现细节。2.继承，可以让子类被视作一个父类。3，多态：多态指的是一个对象可以体现出多种形态。”
优点：
1、易维护
采用面向对象思想设计的结构，可读性高，由于继承的存在，即使改变需求，那么维护也只是在局部模块，所以维护起来是非常方便和较低成本的。
2、质量高
在设计时，可重用现有的，在以前的项目的领域中已被测试过的类使系统满足业务需求并具有较高的质量。
3、效率高
在软件开发时，根据设计的需要对现实世界的事物进行抽象，产生类。使用这样的方法解决问题，接近于日常生活和自然的思考方式，势必提高软件开发的效率和质量。
4、易扩展
由于继承、封装、多态的特性，自然设计出高内聚、低耦合的系统结构，使得系统更灵活、更容易扩展，而且成本较低。
一种可视化的语言，用于系统描述的语言
Or
**是统一建模语言，是一种可视化的面向对象建模语言，**是一种用来对真实世界物理进行建模的标准标记，用图形方式表现典型的面向对象系统的整个结构
用例图
从用户角度描述系统功能，是从用户所能观察到的系统功能的模型图，用例是系统中的一个功能单元
类图
以类为中心来组织的，类图中的其他元素或属于某个类型或与类相关联。并且描述系统中类的静态结构，还表示类之间的联系
对象图
类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类
顺序图
用来表示用例中的行为顺序，显示对象之间的动态协作关系，强调对象之间信息发送的顺序，同时显示对象之间的交互。
协作图
用于描述对象间的协作关系，协作图和顺序图类似，显示对象间的动态协作关系。
状态图
是一个类对象所可能经历的所有历程的模型图
活动图
描述了一组顺序的或并发的活动，是状态图的一个变体
用于构建用例的数据模型
关联
包含
拓展
依赖
关联
聚合
组合
继承
XXXXX
答：x1，x2，x3是用例中的角色。X1可通过UC4和UC1与系统进行交互。Uc2是Uc4的可选部分，而Uc5是Uc4的必选部分。
软件重用，是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括程序代码
、测试用例
、设计文档、设计过程、需求分析
文档甚至领域知识。通常，可重用的元素也称作软构件
，可重用的软构件越大，重用的粒度越大。
考虑可复用性
考虑类库和开发环境
还要考虑为用户学习面向对象分析、设计和编程技术所能提供的培训服务
考虑在使用面向对象程序设计语言期间能提供的技术支持
能提供给开发人员使用的工具、开发平台和发布平台
对机器性能和内存的需求
集成已有软件的容易程度
软件维护是指在软件运行/维护阶段对软件产品所进行的修
改就是所谓的维护。根据维护工作的性质，软件维护的活动
改正性维护
为了识别和纠正
软件错误、改正软件性能上的缺陷、排除实施中的误使
用，应进行的诊断和改正错误的过程。例如，改正性维护
可以是改正原来程序中开关使用的错误；解决开发时未能
测试各种可能情况带来的问题等。
适应性维护
随着信息技术的飞速发展，软件运行的外部环境（新的
硬、软件配置）或数据环境（数据库、数据格式、数据输入
/输出方式、数据存储介质）可能发生变化，为了使软件适
应这种变化，而修改软件的过程叫做适应性维护（adaptive
maintenance）。例如，需要对已运行的软件进行改造，以
适应网络环境或已升级改版的操作系统要求。
完善性维护
为了满足新的功能与性能要求，需要修改或再开发软件，
以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护
（perfective maintenance）。例如，完善性维护可能是修
改一个计算工资的程序，使其增加新的扣除项目；缩短系统
的应答时间，使其达到特定的要求等。
预防性维护
预防性维护（preventive maintenance）是指把今天的
方法学用于昨天的系统以满足明天的需要。也就是说，采
用先进的软件工程方法对需要维护的软件或软件中的某一部
分（重新）进行设计、编码和测试。
所谓程序修改的副作用是指因修改软件而造成的错误或其他不希望发生的情况
1．修改代码的副作用
在使用程序设计语言修改源代码时，都可能引入新的
错误。例如，删除或修改一个子程序、删除或修改一个标
号、删除或修改一个标识符、改变程序代码的时序关系、
改变占用存储的大小、改变逻辑运算符、修改文件的打开
或关闭、改进程序的执行效率，以及把设计上的改变翻译
成代码的改变、为边界条件的逻辑测试做出改变时，都容
易引入错误。
2．修改数据的副作用
在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。修改数据的副作用是修改软件信息结构导致的结果。例如，在重新定义局部的或全局的常量、重新定义记录或文件的格式、增大或减小一个数组或高层数据结构的大小、修改全局或公共数据、重新初始化控制标志或指针、重新排列输入/输出或子程序的参数时，容易导致设计与数据不相容的错误。数据副作用可以通过详细的设计文档加以控制。
3．修改文档的副作用
对数据流、软件结构、模块逻辑或任何其他有关特性进
行修改时，必须对相关技术文档进行相应修改。如果对可
执行软件的修改不反映在文档里，会产生文档的副作用。
例如，对交互输入的顺序或格式进行修改，如果没有正确
地记入文档中，可能引起重大的问题。过时的文档内容、
索引和文本可能造成冲突，引起用户业务的失败和不满。
因此，必须在软件交付之前对整个软件配置进行评审，以
减少文档的副作用。
（1）按模块把修改分组；
（2）自顶向下地安排被修改模块的顺序；
（3）每次修改一个模块；
（4）对于每个修改了的模块，在安排修改下一个模块之
前，要确定这个修改的副作用，可以使用交叉引用
表、存储映象表、执行流程跟踪等。
软件与明确的和隐含的定义的需求相一致的程度
软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化的过程，目的在于对此加以理解、预测、评估、控制和改善。
软件配置项（Software Configuration Item，SCI）是指软件工程中产生的信息项（文档、报告、程序、表格数据），是配置管理的基本单位。描述计算机程序的文档（包括技术文档和用户文档）。
SCI的具体形态有两种形式。
又称进度管理，是指为保证项目各项工作及项目总任务按时完成所需要的一系列的工作与过程。
又叫横道图、条状图(Bar chart)。甘特图内在思想简单，基本是一条线条图，横轴表示时间，纵轴表示活动(项目)，线条表示在整个期间上计划和实际的活动完成情况。它直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。
网络图是由作业（箭线）、事件（又称节点）和路线三个因素组成的。网络图是用箭线和节点将某项工作的流程表示出来的图形。
