软件工程导论期末复习提纲

第一章绪论

软件：是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。

软件工程：是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。软件危机：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。主要是两个问题：1. 如何开发软件，怎样满足对软件的日益增长的需求。2. 如何维护数量不断膨胀的已有软件。主要表现：1. 对软件开发成本和进度的估计不准确2. 用户不满意3. 软件质量不高、可靠性差4. 软件常常不可维护、错误难以改正5. 缺乏适当的文档资料6. 软件成本占系统总成本的比例逐年上升7. 软件开发速度跟不上计算机发展速度

产生软件危机的原因

1. 与软件本身的特点有关：软件不同于硬件，它是计算机系统的逻辑部件而不是物理部件。在写出程序代码并在计算机运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价。因此，管理和控制软件开发过程相当困难。

2. 软件不易于维护：（1）软件维护通常意味着改正或修改原来的设计，客观上使软件较难维护。（2）软件不同于一般程序，它的规模大，不易于维护。

3. 在软件开发过程中，或多或少地采用了错误的方法和技术。

4. 对用户需求没有完整准确的认识，就匆忙着手编写程序。

解决软件危机的途径：⑴研制新一代体系结构的智能计算机，以改变软件的实现方式，降低软件的复杂性。目前尚未研制成功。⑵采用工程化、规范化的开发方法来指导软件的开发：这就是产生“软件工程学”的背景，并在70年代形成了结构化分析、设计方法。⑶在求解方法上采用面向对象的软件设计方法。即在软件开发中，以客观世界的问题空间入手进行软件设计，以减少求解方法空间与客观世界问题空间存在的“鸿沟”。

“生命周期法”的起源：软件工程采用的“生命周期法”，就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后再逐步完成每个阶段的任务.

生命周期划分的原则：任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。

生命周期的划分：软件生命周期一般分为：软件定义（问题定义、可行性研究、需求分析）、软件开发（总体设计、详细设计、编码和测试）、软件使用与维护等三个时期八个阶段。问题定义：“要解决什么问题？”可行性研究：“上一个阶段所确定的问题是否有行得通的解决办法”目的：用最小的代价在尽可能短的时间内确定问题是否能够解决需求分析：“系统必须做什么”对待开发软件提出的需求进行分析并给出详细的定义、编写软件需求规格说明书、提交管理机构评审概要设计：把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应详细设计：对每个模块要完成的工作进行具体的描述，为源程序编写打下基础、编写设计说明书，提交评审。编码：把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”、写出的程序应当是结构良好、清晰易读的，且与设计相一致的软件测试：单元测试：查找各模块在功能和结构上存在的问题并加以纠正组装测试：将已测试过的模块按一定顺序组装起来，按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用软件维护改正性维护：运行中发现了软件中的错误需要修正适应性维护：为了适应变化了的软件工作环境，需做适当变更完善性维护：为了增强软件的功能需做变更

软件工程三要素:过程(为软件工程的过程和方法提供自动化或半自动化的工具支持)、方法(完成项目的技术手段（传统方法学、面向对象方法学）)和工具(为软件工程的过程和方法提供自动化或半自动化的工具支持)

软件工程釆用层次化的方法,每个层次都包括过程、方法、工具三要素.方法支撑过程和工具、过程和工具促进方法学的研究。将系统的、规范的、可量化的方法运用到软件工程的始终，渗透到软件工程的过程、方法和工具中。

传统方法学(生命周期方法学)原理: 采用结构化技术来完成软件开发的各项任务,并使用适当的软件工具或软件工程环境来支持结构化技术的运用,即把软件生命周期的全过程依次划分为若干阶段,然后顺序地完成每个阶段的任务。

软件的生存周期及其开发模型：一、瀑布模型：优点：通过设置里程碑，明确每阶段的任务与目标。可为每阶段制定开发计划，进行成本预算，组织开发力量。通过阶段评审，将开发过程纳入正确轨道。严格的计划性保证软件产品的按时交付。缺点：缺乏灵活性，不能适应用户需求的改变。开始阶段的小错误被逐级放大，可能导致软件产品报废。返回上一级的开发需要十分高昂的代价。随着软件规模和复杂性的增加，软件产品成功的机率大幅下降。适应范围：它主要适应于小规模和需求较为稳定的的软件开发。瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如操作系统、编译系统、数据库管理系统等系统软件的开发。应用有一定的局限性。二、快速原型模型：基本思想：在获取一组基本的需求定义后，利用高级软件工具的可开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改的过程，应用系统的“最初版本”就逐步演变为系统的“最终版本”。三、增量模型：一种非整体开发的模型。根据增量的方式和形式的不同，分为基于瀑布模型的渐增模型和基于原型的快速原型模型。使用增量模型开发模型时,把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能完成特定的功能。第一个增量构件往往提供最核心的功能。注意：在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产生工作软件。四、螺旋模型：在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模型。模型、优点、缺点：瀑布模型、文档驱动、系统可能不满足客户的需求；快速原型模型、关注满足客户需求、可能导致系统设计差、效率低，难于维护；增量模型、开发早期反馈及时，易于维护、需要开放式体系结构，可能会设计差、效率低；螺旋模型、风险驱动、风险分析人员需要有经验且经过充分训练

第二章可行性分析

可行性分析就是解决一个项目是否有可行解以及是否值得去解的问题。该阶段的主要任务就是用最小的代价在尽可能短的时间内确定问题是否能够得到解决。主要任务：具体地说，分析员应从下面三个方面对项目做出可行性分析：（1）技术可行性：使用现有的技术能实现这个系统吗?（2）经济可行性：这个系统的经济效益能超过它的开发成本吗?（详细在后面介绍成本/效益分析）（3）操作可行性：系统的操作方式在该用户组织内行得通吗?必要时还应该进一步从法律、社会效益等更广泛的角度研究每种解法的可行性。计算成本/效益分析

“可行性报告”中最主要的内容是：(1)项目的背景：问题描述、实现环境和限制条件等(2)管理概要与建议：重要的研究结果(结论)、说明、劝告和影响等(3)推荐的方案(不止一个)：候选系统的配置与选择最终方案的原则(4)简略的系统范围描述：分配元素的可行性(5)经济可行性分析结果：经费概算和预期的经济效益等(6)技术可行性(技术风险评价)：技术实力分析、已有的工作及技术基础和设备条件等等(7)法律可行性分析结果描述(8)可用性评价：汇报用户的工作制度和人员的素质，确定人机交互功能界面需求(9)其他项目相关的问题：如可能会发生的变更等等可行性研究报告由系统分析员撰写，交由项目负责人审查，再上报给上级主管审阅。在可行性研究报告中，应当明确项目“可行还是不可行”，如果认为可行，接下来还要制定项目开发计划书。

第三章软件需求分析

需求分析：准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用<需求规格说明书> 规范的形式准确地表达用户的需求。任务：确定对系统的综合要求、分析系统的数据要求、导出系统的逻辑模型、修正系统开发计划。

确定对系统的综合要求：1. 功能需求：这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能2. 性能需求：性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求3. 可靠性和可用性需求：可靠性需求定量地指定系统的可靠性4. 出错处理需求：这类需求说明系统对环境错误应该怎样响应5. 接口需求：接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求6. 约束：设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台7. 逆向需求：逆向需求说明软件系统不应该做什么8. 将来可能提出的要求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。分析系统的数据要求：分析系统的数据要求，这是软件需求分析的一个重要任务。分析系统的数据要求通常采用建立数据模型的方法（ER图—考点、数据字典、层次方框图、Wariner图等工具）导出系统的逻辑模型：综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。修正系统开发计划：根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。

需求获取的常用方法：1.客户访谈：发放调查表和情景分析2. 面向数据流自顶向下求精：数据字典、数据流图3.简易的应用规格说明：面向团队需求收集法4.快速建立原型：要点：建立用户看的见得功能、快速、易修改

需求建模：所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。模型化或模型方法是通过抽象、概括和一般化，把研究的对象或问题转化为本质（关系或结构）相同的另一对象或问题，从而加以解决的方法。

需求分析的模型（结构化分析）：数据模型ER图；功能模型数据流图P41；行为模型状态转换图

数据字典(DD，DataDictionary)DD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解。数据词典是结构化分析方法中采用的表达数据元素的工具。它对数据流图中所有自定义的数据元素、数据结构、数据文件、数据流等进行严密而精确的定义。

加工说明:在数据流图中，每一个加工框中只是简单地赋予了一个加工名，这显然不能表述加工的全部内容。一个软件系统的功能就是由这些加工的协同配合才得以实现的。因此，需求分析中必须对每一个加工进行说明。描述加工逻辑的工具：结构化语言:介于自然语言和形式语言之间的语言特点：无确定语法、可分层、嵌套

判定表:描述多条件、多目标动作的形式化工具判定树:由条件1、条件2得到结果

第四章软件设计

软件设计分为两个阶段：(1)概要设计(总体设计)确定软件的结构以及各组成成分(子系统或模块)之间的相互关系。分为：系统设计阶段，确定系统的具体实现方案；结构设计阶段，确定软件结构。设想供选择的方案、选取合理的方案、推荐最佳方案、功能分解、设计软件结构、设计数据库、制定测试计划、书写文档、审查和复查(2)详细设计确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档。

软件设计遵循的原则：模块化（模块是数据说明、可执行语句等程序对象构成并执行相对独立功能的逻辑实体，它可以单独命名而且可以实现按名访问。例如，过程、函数、子程序、宏等等都可以看作模块。模块化是指把大型软件按照规定的原则划分为一个个较小的，相对独立但又相关的模块。模块化是一种“分而治之，各个击破”式的问题求解方式，它降低了问题的复杂程度，简化了软件的设计过程）、抽象（软件系统进行模块设计时，可有不同的抽象层次。抽象是人类特有的一种思维方法，其原理是从事物的共性中抽取出所关注的本质特征而暂时忽略事物的有关细节）、逐步求精（为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。事实上，可以把它看做是一项把一个时期内必须解决的种种问题按优先级排序的技术）、信息隐藏和局部化（模块所包含的信息，不允许其它不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息。目的：提高模块的独立性，减少修改或维护时的影响面。把关系密切的软件元素物理地放得彼此靠近。优点：可维护性好、可靠性好、可理解性好）、模块独立（所谓模块独立性是指模块完成它自身规定的功能而与系统中其它的模块保持一定的相对独立。含义：模块完成独立的功能、符合信息隐蔽和信息局部化原则、模块间关联和依赖程度尽量小）

模块独立性的度量:模块独立性取决于模块的内部和外部特征。SD方法提出的定性的度量标准：模块之间的耦合性、模块自身的内聚性。耦合是模块之间的互相连接的紧密程度的度量。内聚是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量。模块独立性比较强的模块应是高内聚低耦合的模块。耦合由低到高依次：无直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。耦合是影响软件复杂程度和设计质量的重要因素。目标：建立模块间耦合度尽可能松散的系统如何降低模块间耦合度：(1) 尽量使用数据耦合、少用控制耦合、限制公共耦合的范围、坚决避免使用内容耦合!!(2) 降低接口的复杂性模块的内聚性类型:偶然内聚(巧合内聚):模块内各部分间无联系0分......功能内聚10分功能内聚模块仅包括为完成某个功能所必须的所有成分。(模块所有成分共同完成一个功能，缺一不可)内聚性最强内聚与耦合密切相关，同其它模块强耦合的模块意味者弱内聚，强内聚模块意味着与其它模块间松散耦合.设计目标：力争强内聚、弱耦合!!耦合、内聚与模块独立性关系:耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。

启发规则：1.改进软件结构提高模块独立性2.模块规模应该适中3.深度、宽度、扇出和扇入都应适当。其中，扇入：表明有多少个上级模块直接调用它，扇入越大则共享该模块的上级模块数目越多。越多越好，但不能作死。扇出：是一个模块直接控制或调用的模块数。扇出过大意味着模块过分复杂，需要控制和协调过多的下级模块。不大不小正好。深度：表示软件结构中控制的层数，它能粗略的标志一个系统的大小和复杂程度。宽度：是软件结构内同一个层次上的模块总数的最大值。

4.模块的作用应该在控制域之内：模块的作用域是受该模块内一个判定影响的所有模块的集合。

5.力争降低模块结构的复杂程度

6.设计单入口、单出口的模块

7.模块功能应该可以预测

面向数据流的设计方法：数据流图可分为两种类型：变换型数据流：信息沿输入通路进入系统；进入系统的信息通过变换中心；经加工处理以后再沿输出通路离开软件系统；当数据流图具有这些特征时，这种信息流就叫做变换流。事务型数据流：当数据流经过一个具有“事务中心”特征的数据处理时，它可以根据事务类型从多条路径的数据流中选择一条活动通路。

这种具有根据条件选择处理不同事务的数据流，就是事务型数据流，简称事务流。

详细设计：工具：程序流程图、盒图【用方框图代替传统的流程图(1)顺序型(2)选择型（If–then–else）(3)多分支选择型(CASE型)(4) WHILE重复型(先测试循环)(5)UNTIL重复型(后测试循环)(6)并行结构】、

PAD图【基本控制结构:(1)顺序结构(2)选择结构(3)重复结构(先测试循环)(后测试循环)(4) 多分支选择型(CASE型)】、判定表、判定树、过程设计语言

面向数据结构的设计方法：复杂度计算：McCabe方法P137（1）流图中的区域数等于环形复杂度（2）流图G的环形复杂度V(G)=E-N+2,其中E是流图中边的条数，N是结点数（3）流图G的环形复杂度V(G)=P+1，其中P是流图中判定结点的数目

第七章软件测试

软件测试：(1) 测试是程序的执行过程，目的在于发现错误(2) 一个好的测试用例在于极可能发现至今未发现的错误(3) 一个成功的测试是发现了至今未发现的错误的测试步骤：1.模块测试：把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案，目的是保证每个模块作为一个单元能正确运行，所发现的往往是编码和详细设计的错误。2.子系统测试：把经过单元测试的模块放在一起形成一个子系统来测试，模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口。3.系统测试：把经过测试的子系统装备成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。发现的往往是软件设计中的错误，也可能发现需求说明中的错误。与子系统测试成为集成测试。4.验收测试：把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但它是在用户积极参与下进行，且可能主要使用实际数据进行测试。目的是验证系统确实能够满足影虎的需要，发现的往往是系统需求说明书中的错误，又称确认测试。5.平行测试：同时运行新开发出来的系统和将被它取代的旧系统，以便比较两个系统的处理结果。方法：黑盒测试、白盒测试。黑盒测试：这种方法是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。白盒测试：此方法把测试对象看作一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。单元测试的测试重点：模块接口、局部数据结构、重要的执行通路、出错处理通路、边界条件。集成测试的策略：自顶向下集成（需要设计装模块）、自底向上集成（设计驱动模块）。不同集成测试策略的比较：自顶向下测试方法的主要优点是不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，并且能在早期发现上层模块的接口错误。缺点是需要存根程序，可能遇到与此相联系的测试困难，底层关键模块中的错误发现较晚，并且用这种方法在早期不能充分展开人力。自底向上测试方法的优缺点与之相反。确认测试：Alpha和Beta 测试Alpha测试：由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。Beta测试：由软件的最终用户们在一个或多个客户场所进行，开发者通常不在测试现场，因此Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户记录在测试过程中遇到的一切问题，并定期把问题报告发给开发者。开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。白盒测试：主要方法为逻辑覆盖、控制结构测试。其中，逻辑覆盖有：语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖、路径覆盖（重点）语句覆盖：语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。判定覆盖：判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。条件覆盖：条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。判定－条件覆盖：判定－条件覆盖就是设计足够的测试用例，使得判断中所有可能取值至少执行一次，每个判断中的每个条件的可能取值至少执行一次。黑盒测试：主要发现功能不正确或遗漏、界面错误、性能错误等。主要方法：等价类划分、边界值分析、错误推测法。等价类划分：等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。等价类的划分有两种不同的情况：①有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。②无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。例：输入值是学生成绩，范围是0～100有效等价类：①0≤成绩≤100无效等价类：①成绩<0，②成绩>100

边界值分析：经验表明，处理边界情况时程序最容易发生错误。例如，许多程序错误出现在下标、纯量、数据结构和循环等等的边界附近。因此，设计使程序运行在边界情况附近的测试方案，暴露出程序错误的可能性更大一些。

软件可靠性：是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。

软件可用性：是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。

估算平均无故障时间的方法：估计错误总数的两个方法(1) 植入错误法: 根据发现的错误中原有的和植入的两种错误的比例，来估计程序中原有错误的总数ET。2) 分别测试法：加上标记，然后根据测试过程中发现的有标记错误和无标记错误的比例，估计程序中的错误总数，则这样得出的结果比用植入错误法得到的结果更可信一些。

第八章维护

软件维护是软件生命周期的最后一个阶段，它处于系统投入生产性运行以后的时期中，因此不属于系统开发过程。基本任务是保证软件在一个相当长的时期能够正常运行。所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。软件维护包括下述4项活动：诊断和改正错误的过程：改正性维护、为了和变化了的环境适当地配合而进行的修改软件的活动：适应性维护、为了满足在使用软件的过程中用户的建议和改进意见而作的维护：完善性维护，所占比例最大、为了给未来的改进奠定更好的基础而修改软件：预防性维护

非结构化维护：如果软件配置的唯一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难。而且对程序代码所做的改动的后果是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试。非结构化维护付出代价高昂。结构化维护：如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。结构化维护能减少精力浪费并且能提高维护的总体质量。

软件可维护性的因素：可理解性、可使用性、可测试性、可移植性、可修改性、效率、可靠性可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度。可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。可测试性表明论证程序正确性的容易程度。程序越简单，证明其正确性就越容易。而且设计合理的测试用例，取决于对程序的全面理解。可修改性表明程序容易修改的程度。可移植性表明程序转移到一个新的计算环境的可能性的大小。或者它表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度。效率表明一个程序能执行预定功能而又不浪费机器资源的程度。从用户观点出发，可使用性定义为程序方便、实用、及易于使用的程度。一个可使用的程序应是易于使用的、能允许用户出错和改变，并尽可能不使用户陷入混乱状态的程序。

第13章软件项目管理

所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。为了估算项目的工作量和完成期限，首先需要估算软件的规模。主要部分：估算软件规模、工作量估算、进度计划、人员组织、质量保证、软件配置管理等。

估算软件规模方法：代码行技术：依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。功能点技术：依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。功能点技术定义了信息域的5个特性：输入项数(Inp)：用户向软件输入的项数，这些输入给软件提供面向应用的数据。输出项数(Out)：软件向用户输出的项数，它们向用户提供面向应用的信息。查询数(Inq)：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。主文件数(Maf)：逻辑主文件的数目。外部接口数(Inf)：机器可读的全部接口的数量，用这些接口把信息传送给另一个系统。

工作量估算：常用模型：静态单变量模型：E = A + B × (ev) C动态多变量模型：E=(LOC×B0.333/P)3×(1/t)4 （数字均为指数）

进度计划：掌握最早时刻和最迟时刻P317最早时刻EET：该事件可以发生的最早时间。最迟时刻LET：在不影响竣工时间的前提下，该事件最晚可以发生的时刻。最早时刻的计算：事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。计算最早时刻EET使用下述3条简单规则：考虑进入该事件的所有作业；对于每个作业都计算它的持续时间与起始事件的EET之和；选取上述和数中的最大值作为该事件的最早时刻EET。最迟时刻的计算：事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。按惯例，最后一个事件(工程结束)的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。计算最迟时刻LET使用下述3条规则：考虑离开该事件的所有作业；从每个作业的结束事件的最迟时刻中减去该作业的持续时间；选取上述差数中的最小值作为该事件的最迟时刻LET。

人员组织：民主制程序员组（已跪）、主程序员组（已跪）、现代程序员组（ing）实际的“主程序员”应该由两个人共同担任：一个技术负责人，负责小组的技术活动，参与全部代码审查工作，因为他要对代码的各方面质量负责；一个行政负责人，负责所有非技术性事务的管理决策，不可以参与代码审查工作，因为他的职责是对程序员的业绩进行评价。行政组长应该在常规调度会议上了解每名组员的技术能力和工作业绩。

质量保证：技术复审的必要性：正式技术复审的显著优点是，能够较早发现软件错误，从而可防止错误被传播到软件过程的后续阶段。正式技术复审是软件质量保证措施的一种，包括走查（walkthrough)和审查（inspection）等具体方法。走查的步骤比审查少，而且没有审查正规。走查：走查组由4~6名成员组成。走查组组长引导该组成员走查文档，力求发现尽可能多的错误。走查组的任务仅仅是标记出错误而不是改正错误，改正错误的工作应该由该文档的编写组完成。走查的时间最长不要超过2小时，这段时间应该用来发现和标记错误，而不是改正错误。走查主要有下述两种方式：参与者驱动法、文档驱动法。审查：综述，由负责编写文档的一名成员向审查组综述该文档。准备，评审员仔细阅读文档。审查，评审组仔细走查整个文档。返工，文档的作者负责解决在审查报告中列出的所有错误及问题。跟踪，组长必须确保所提出的每个问题都得到了圆满的解决。软件配置管理：软件配置管理是在软件的整个生命期内管理变化的一组活动。具体地说，这组活动用来：①标识变化；②控制变化；③确保适当地实现了变化；④向需要知道这类信息的人报告变化。

基线是一个软件配置管理概念，有助于我们在不严重妨碍合理变化的前提下控制变化。IEEE把基线定义为：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。

能力成熟度模型：CMM是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述，是用于评价软件机构的软件过程能力成熟度的模型。