1.题型
软件工程：
选择题（25题，每题1分），
填空题（20分，每空2分），
简答题（5题，每题5分），
综合题（3题，共30分）
2.知识点
知识点：
1、软件设计对模块间的耦合与模块的内聚有何原则。
设计时尽量使用高内聚，低耦合模块。
高内聚：尽量使用内聚度高的模块；中内聚也可；低内聚很坏，不要采用。
低内聚：偶然内聚，逻辑内聚，时间内聚
中内聚：过程内聚，通信内聚
高内聚：顺序内聚，功能内聚；
低耦合：尽量使用数据耦合，少用控制耦合和标记耦合，限制公共环境耦合的范围，完全不用内容耦合。
2、耦合有哪些类型，各有何特点？
耦合的类型
• 内容耦合 强
• 公共耦合 ¦
• 控制耦合 ¦
• 标记耦合 ↓
• 数据耦合 弱
数据耦合：模块彼此间通过参数交换信息，交换的信息仅仅是数据。
标记耦合：若两个模块间传递的参数中至少有一个是数据结构，如字符串或记录，并且在模块中仅用到该数据结构中的部分元素，则称这两个模块之间存在标记耦合。
控制耦合：一个模块向另一个模块传递控制信息，接收信息的模块的动作根据信息值进行调整。
控制耦合是中等程度的耦合，它增加了系统的复杂程度。在把模块适当分解之后通常可以用数据耦合代替它。
公共耦合：
•两个模块共享全局的数据区域，称他们为公共耦合。
•不要使用全局变量
耦合的复杂程度随耦合模块的个数而变化，随个数的增加显著增加。
两个模块的公共耦合有两种可能：
(1) 一个模块往公共环境送数据，另一个模块从公共环境取数据。这是数据耦合的一种形式，是比较松散的耦合。
(2) 两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。
内容耦合
•内容耦合的三种情况:
•一个模块修改另一个模块的语句 (Lisp 具有此种能力)
•一个模块引用或者修改另一个模块内部的数据
•一个模块不通过正常入口而跳转到另一个模块的内部
3、常用软件过程有哪几种，各有何特点？
#1瀑布模型
1. 阶段间具有顺序性和依赖性
这个特点有两重含义：
①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
②前一阶段的输出文档就是后一阶段的输入文档。
2. 推迟实现的观点
对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。
3. 质量保证的观点
每个阶段都应坚持两个重要做法：
（1） 每个阶段都必须完成规定的文档。
（2） 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
#2快速原型模型
是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
快速原型模型是不带反馈环的，这正是这种过程模型的主要优点： 软件产品的开发基本上是线性顺序进行的。
#3增量模型
把软件产品作为一系列的增量构件来设计、编码、集成和测试。
增量模型的优点：
能在较短时间内向用户提交可完成部分工作的产品；
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品
维护时期反馈环很小。
#4 螺旋模型
螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险，在每个阶段之前都增加了风险分析过程的快速原型
#5喷泉模型
喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。
各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。
优点：
提高开发效率
缩短开发周期
缺点：难于管理
4、瀑布模型分为哪几个阶段。
5、结构化程序设计方法的发展过程。
• 经典的结构程序设计：只允许使用顺序、IF-THEN-ELSE型分支和DO-WHILE型循环这3种基本控制结构；
• 扩展的结构程序设计：除了上述3种基本控制结构之外，还允许使用DO-CASE型多分支结构和DO-UNTIL型循环结构；
• 修正的结构程序设计：除上述结构以外，还允许使用LEAVE(或BREAK)结构。
6、流程图与N_S图如何使用。###
7、可行性研究应该从哪几个方面进行。
探索若干种可供选择的主要解法(即系统实现方案)。从下述三方面研究每种解法的可行性：
(1) 技术可行性，使用现有的技术能实现这个系统吗?
(2) 经济可行性，这个系统的经济效益能超过它的开发成本吗?
(3) 操作可行性，系统的操作方式在这个用户组织内行得通吗?
8、数据流图的基本符号有哪几种？
如图2.4(a)（见书31页）所示，数据流图有四种基本符号：正方形(或立方体)表示数据的源点或终点；圆角矩形(或圆形)代表变换数据的处理；开口矩形(或两条平行横线)代表数据存储；箭头表示数据流，即特定数据的流动方向。
注意，数据流与程序流程图(参看本书第5章)中用箭头表示的控制流有本质不同，千万不要混淆。
在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件（无法表示分支条件或循环）。
处理并不一定是一个程序。一个处理框可以代表一系列程序、单个程序或者程序的一个模块；它甚至可以代表用穿孔机穿孔或目视检查数据正确性等人工处理过程。
一个数据存储也并不等同于一个文件，它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等；数据可以存储在磁盘、磁带、磁鼓、主存、微缩胶片、穿孔卡片及其他任何介质上(包括人脑)。
数据存储和数据流都是数据，仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运动中的数据。
通常在数据流图中忽略出错处理，也不包括诸如打开或关闭文件之类的内务处理。
数据流图的基本要点是描绘“做什么”而不考虑“怎样做”。
有时数据的源点和终点相同，如果只用一个符号代表数据的源点和终点，则至少将有两个箭头和这个符号相连(一个进一个出)，可能其中一条箭头线相当长，这将降低数据流图的清晰度。另一种表示方法是再重复画一个同样的符号(正方形或立方体)表示数据的终点。
有时数据存储也需要重复，以增加数据流图的清晰程度。为了避免可能引起的误解，如果代表同一个事物的同样符号在图中出现在n个地方，则在这个符号的一个角上画（n-1）条短斜线做标记。
除了上述4种基本符号之外，有时也使用几种附加符号。图2.4(b)给出了这些附加符号的含义。
9、面向数据流的设计方法如何进行？
详见50122可行性研究 2.4.2 例子
10、Jackson方法有何特点？
分析输入输出数据的逻辑结构，列出所有操作和条件，用伪代码表示程序
Jackson结构程序设计方法基本上由下述5个步骤组成。
(1) 分析并确定输入数据和输出数据的逻辑结构，并用Jackson图描绘这些数据结构。
(2) 找出输入数据结构和输出数据结构中有对应关系的数据单元。
(3) 用下述3条规则从描绘数据结构的Jackson图导出描绘程序结构的Jackson图。
① 为每对有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构图的相应层次画一个处理框
② 根据输入数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框。
③ 根据输出数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框。
(4) 列出所有操作和条件(包括分支条件和循环结束条件)，并且把它们分配到程序结构图的适当位置。
(5) 用伪码表示程序。
Jackson方法中使用的伪码和Jackson图是完全对应的，下面是和3种基本结构对应的伪码。
11、白盒测试与黑盒测试各有何特点？
白盒测试技术：用白盒方法测试软件时设计测试数据的典型技术。
黑盒测试技术：用黑盒方法测试软件时设计测试数据的典型技术。
白盒测试
设计测试方案是测试阶段的关键技术问题。
测试方案：
•包括测试目的（预定要测试的具体功能），
•应该输入的测试数据和预期的结果。
测试用例：
•由测试输入数据及与之对应的输出结果组成。
•测试用例设计的好坏直接决定了测试的效果和结果。因此在软件测试活动中最关键的步骤就是设计有效的测试用例。（因为不可能进行穷尽的测试）
•测试用例可以针对黑盒测试设计用例，也可以针对白盒测试设计用例。
主要用于软件验证。
用程序设计的控制结构导出测试用例。
黑盒测试
黑盒测试着重测试软件功能。
• 黑盒测试不能取代白盒测试，是与白盒测试互补的测试方法，用于发现白盒测试不易发现的错误。
• 黑盒测试发现的错误类型：
①功能不正确或遗漏了功能；
②界面错误；
③数据结构错误或外部数据库访问错误；
④性能错误；
⑤初始化和终止错误。
白盒测试主要用于测试过程的早期，
黑盒测试主要用于测试过程的后期。
黑盒测试也称为功能测试,它着眼于程序的外部特征,而不考虑程序的内部逻辑结构。测试者把被测程序看成一个黑盒,不用关心程序的内部结构。黑盒测试是在程序接口处进行测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试主要采用的技术有:等价分类法、边界值分析法、错误推测法和因果图等技术。
白盒测试是测试者了解被测程序的内部结构和处理过程,对程序的所有逻辑路径进行测试,在不同点检查程序状态,确定实际状态与预期状态是否一致。白盒测试主要采用的技术有：路径测试技术和事务处理流程技术，对包含有大量逻辑判断或条件组合的程序采用基于逻辑的测试技术。
白盒测试：按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作
黑盒测试：在程序接口进行的测试，只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性。
白盒测试的方法：逻辑覆盖、控制结构测试
黑盒测试的方法：等价划分、边界值分析、错误推测
12、总体设计有何特点？
总体设计任务
• 系统方案设计
划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等，但是每个物理元素仍然处于黑盒子级。
• 体系结构设计
设计软件的结构，确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。
13、模块的作用域与控制域
模块的作用域应该在控制域之内
• 模块的作用域：受该模块内一个判定影响的所有模块的集合。
• 模块的控制域：模块本身以及所有直接或间接从属于它的模块的集合。
例如，在图5.2中模块A的控制域是A、B、C、D、E、F等模块的集合。
模块A的控制域一定是其下模块BCDEF，作用域可能纠缠到G，当然这样是不合适的
受判定影响的模块应在做出判定的那个模块的控制域之内。
图5.2 模块的作用域和控制域
14、模块的扇入、扇出、模块图的深度、宽度？
深度、宽度、扇出和扇入都应适当
• 深度：表示软件结构中控制的层数。
能粗略地标志一个系统的大小和复杂程度。如果层数过多，应考虑管理模块是否过分简单，能否适当合并。
• 宽度：软件结构内同一个层次上的模块总数的最大值。
宽度越大系统越复杂。对宽度影响最大的因素是模块的扇出。
• 扇出：是一个模块直接控制(调用)的模块数目。
扇出过大意味着模块过分复杂，需要控制和协调的下级模块过多；扇出过小(例如总是1)也不好。
通常是3或4(上限是5～9)。
扇出太大：缺乏中间层次，应适当增加中间层次的控制模块。
扇出太小：把下级模块进一步分解成若干个子功能模块，或者合并到它的上级模块中去。
分解或合并模块应符合问题结构，不能违背模块独立原理。
• 扇入：表明有多少个上级模块。扇入越大则共享该模块的上级模块数目越多，这是有好处的。
好的软件结构通常顶层扇出比较高，中层扇出较少，底层模块有高扇入。
系统的模块结构呈现为“葫芦形”。
15、PAD图如何使用
PAD是问题分析图(problem analysis diagram) 。
它用二维树形结构的图来表示程序的控制流。
图6.5给出PAD图的基本符号。
图6.5 PAD图的基本符号
PAD图的主要优点如下：
(1) 使用PAD符号设计的程序必然是结构化程序。(2) PAD图所描绘的程序结构十分清晰。
最左面的竖线是程序的主线，即第一层结构。
随着程序层次的增加，PAD图逐渐向右延伸。
每增加一个层次，图形向右扩展一条竖线。图中竖线的总条数就是程序的层次数。
(3) PAD图表现的程序逻辑，易读、易懂、易记。
程序从图中最左竖线上端的结点开始执行，自上而下，从左向右顺序执行，遍历所有结点。
(4) 容易将PAD图转换成高级语言源程序，这种转换可用软件工具自动完成。
(5) 即可表示程序逻辑，也可描绘数据结构。
(6) 支持自顶向下、逐步求精方法的使用。
开始时可以定义一个抽象的程序，随着设计的深入，使用def符号逐步增加细节，直至完成详细设计，如图6.6所示。
图6.6 使用PAD图提供的定义功能来逐步求精的例子
示例
16、软件的可靠性如何定义
软件可靠性：是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
随着运行时间的增加，运行时出现程序故障的概率也将增加，可靠性随着给定的时间间隔的加大而减少。
按照IEEE的规定
错误：是由开发人员造成的软件差错（bug）。
故障：是由错误引起的软件的不正确行为。
17、程序设计语言有哪三种类型，各有何特点？
机器语言：由“0”和“1”组成的指令序列交由计算机执行的语言，可直接被计算机执行
汇编语言：汇编语言编码需要把软件设计翻译成机器操作的序列
高级语言：与具体计算机无关，不针对具体计算机系统。高级语言程序可以在多种计算机上编译后执行，可以直接、有效地控制计算机硬件，易于产生速度快、容量小的高效率目标程序，高级语言写程序比用汇编语言写程序生产率可以提高好几倍
18、软件调试方法有哪些？
调试的目标：是寻找软件错误的原因并改正错误。一般说来，有下列途径可以采用：
•试探法
•回溯法
•对分查找法
•归纳法
•演绎法
1.试探法
分析错误征兆，猜测发生错误的大概位置，然后利用有关的调试技术进一步获得错误信息。这种策略往往是缓慢而低效的。
2. 回溯法
•首先检查错误征兆，确定最先发现错误的位置，然后人工沿程序的控制流往回追踪源程序代码，直到找出错误根源或确定故障范围为止。
•回溯法对于小程序而言是一种比较好的调试策略。但是对于大程序，其回溯的路径数目会变得很大，以至使彻底回溯成为不可能。
•回溯法的另一种形式是正向追踪，即使用插入打印语句的方法检查一系列中间结果，以确定最先出现错误的地方。
3.对分查找法
在程序的中点附近输入某些变量的正确值(如利用赋值语句或输入语句)，然后观察程序的输出。若输出结果正确，则说明错误出现在程序的前半部分；否则，说明程序的后半部分有错。对于程序中有错的那部分再重复使用这个方法，直到把错误范围缩小到容易诊断的程度为止。
4.归纳法
归纳法：是从个别推断全体，即从线索(错误征兆)出发，通过分析这些线索之间的关系而找出故障。这种方法主要有以下四个步骤：
①收集已有的使程序出错与不出错的所有数据。
②整理这些数据，以便发现规律或矛盾。
③提出关于故障的若干假设。
④证明假设的合理性，根据假设排除故障
5.演绎法
•演绎法是从一般原理或前提出发，经过删除和精化的过程，最后推导出结论。
•用演绎法排错时，首先要列出所有可能造成出错的原因和假设，然后逐个排除，最后证明剩下的原因确实是错误的根源。演绎法排错主要有以下四个步骤：
①设想所有可能产生错误的原因。
②利用已有的数据排除不正确的假设。
③精化剩下的假设。
④证明假设的合理性，根据假设排除故障。
19、白盒测试与黑盒测试各有哪些方法？
白盒测试的主要方法
• 逻辑驱动测试（逻辑覆盖）
• 基本路径测试
黑盒测试技术：
•等价划分
•边界值分析
20、面向对象的软件开发中，多态性、继承性如何理解？
多态性
在面向对象的软件技术中，多态性是指子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。即，在类等级的不同层次中可以共享(公用)一个行为(方法)的名字，然而不同层次中的每个类却各自按自己的需要来实现这个行为。
多态性机制不仅增加了面向对象软件系统的灵活性，进一步减少了信息冗余，而且显著提高了软件的可重用性和可扩充性。
继承性
简单来说就是使子类的对象拥有父类的全部属性和行为，同时可以增添自己的所特有的属性和行为。这样可以节省写共同具有的属性和方法代码的时间，有利于代码的复用，这就是继承的基本思想。软件的代码使用继承思想可以缩短软件开发的时间，复用那些已经定义好的类可以提高系统和软件的性能，减少系统和软件在使用过程中出现错误的几率。一个类可以是其他类的父类，为其他类提供属性和行为，也可以是其他类的子类，继承父类的属性和方法，子类的实例都是父类的实例，但不能说父类的实例是子类的实例。
21、什么是软件危机？
软件危机：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。
22、软件工程方法学的三要素及分类？
软件工程方法学包含3个要素：
方法、工具和过程。
方法：是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；
工具：是为运用方法而提供的自动的或半自动的软件工程支撑环境；
过程：是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。
1. 传统方法学
传统方法学：也称为生命周期方法学或结构化范型。
它采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务。
这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。
目前，传统方法学仍然是人们在开发软件时使用得十分广泛的软件工程方法学。
此外，要全面了解面向对象方法学，先要了解传统方法学。
传统方法学优点（生命周期方法学或结构化范型）
把软件生命周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；
在每个阶段结束之前都从技术和管理两个角度进行严格的审查，保证了软件的质量，特别是提高了软件的可维护性。
总之，采用生命周期方法学可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。
2. 面向对象方法学
当软件规模庞大，或者对软件的需求是模糊的，或软件需求会随时间而变化的时候，使用传统方法学开发软件往往不成功。
此外，使用传统方法学开发出的软件，维护起来仍然很困难。
原因：
这种技术要么面向行为(即对数据的操作)，要么面向数据，把数据和操作人为地分离成两个独立的部分，自然会增加软件开发与维护的难度。
面向对象方法学具有下述4个要点。
(1) 把对象(object)作为融合了数据及在数据上的操作行为的统一的软件构件。用对象分解取代了传统方法的功能分解。
(2) 把所有对象都划分成类(class)。
(3) 父类与子类的继承关系。
把若干个相关类组成一个层次结构的系统，下层派生类自动拥有上层基类中定义的数据和操作。
(4) 对象彼此间仅能通过发送消息互相联系。
对象的所有私有信息都被封装在该对象内，不能从外界直接访问，这就是通常所说的封装性。
面向对象方法学优点
面向对象方法学的出发点和基本原则，是尽量模拟人类习惯的思维方式，从一般到特殊，从特殊到一般，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程。传统方法学强调自顶向下顺序地完成软件开发的各阶段任务。事实上，人类认识的过程，是一个渐进的过程，经过多次反复才能逐步深化。
运用面向对象方法学的开发软件，最终的软件产品由许多较小的、基本上独立的对象组成，降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作。
软件重用。对象是相对独立的实体，容易在以后的软件产品中重复使用。
继承性和多态性，进一步提高了面向对象软件的可重用性。
23、实体联系图如何绘制？ ###
详见50123需求分析 3.4
24、需求分析阶段应该使用哪几种模型对系统进行建模?
根据结构化分析准则，需求分析过程应该建立3种模型，它们分别是数据模型、功能模型和行为模型。
数据模型
实体－联系图，描绘数据对象及数据对象之间的关系，用于建立数据模型。
功能模型
数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有变化数据的功能，是建立功能模型的基础。
行为模型
3.6节状态转换图（状态图），指明作为外部事件结果的系统行为。描绘了系统的各种行为模式(称为“状态”)和在不同状态间转换的方式。是行为建模的基础。
25、软件维护有哪些类型？
四种维护类型：
改正性维护
适应性维护
完善性维护
预防性维护
1.改正性维护
在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。
这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。
为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程。
2.适应性维护
在使用过程中，外部环境、数据环境可能发生变化。
外部环境（新的硬、软件配置）
数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）
适应性维护：为使软件适应这种变化，而去修改软件的过程。
3.完善性维护
•在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。
•完善性维护：
为了满足上述要求，需要修改或再开发软件而进行的完善性的维护活动。以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。
•完善性维护不一定是救火式的紧急维修，可以是有计划、有预谋的一种再开发活动。
4.预防性维护
•预防性维护：
为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的维护活动。
•预防性维护的定义：
采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试的过程。
国外的统计数字表明：
完善性维护占全部维护活动的50%～66%，
改正性维护占17%～21%，
适应性维护占18%～25%，
其他维护活动只占4%左右。
完善性维护占了几乎一半的工作量。
可见：
大部分维护工作是改变和加强软件，不是纠错。
26、利率的计算（计复利，不计复利） ###
P本金和利息
S利率
n年
R利息
非复利：第n年本金和利息 P=A*S%*n+A
复利：第n年本金和利息 P=A*（1+S%）n
27、软件测试的任务、目的和类型
测试的正确定义是：“为了发现程序中的错误而执行程序的过程”。
软件测试的目标
G.Myers给出了关于测试的一些规则，这些规则也可以看作是测试的目标或定义。
(1) 测试是为了发现程序中的错误而执行程序的过程；
(2) 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
(3) 成功的测试是发现了至今为止尚未发现的错误的测试。
测试是在精心控制的环境下执行程序，以发现程序中的错误，给出程序可靠性的鉴定。
软件测试准则
（1） 所有测试都应该能追溯到用户需求。
软件测试的目标是发现错误，最严重的错误是导致程序不能满足用户需求。
（2） 应该远在测试开始之前就制定出测试计划。
在完成需求模型时，就着手制定测试计划，
在建立了设计模型后，就开始设计详细的测试方案。
（3） 应该从“小规模”测试开始，并逐步进行“大规模”测试。
先测试单个程序模块，再测试集成模块，最后在整个系统中寻找错误。
（4） 应该由独立的第三方从事测试工作。
软件工程师不能承担全部测试工作，主要承担模块测试工作。
（5） 穷举测试是不可能的。
穷举测试：把程序所有可能的执行路径都检查一遍的测试。
即使是一个中等规模的程序，其执行路径的排列数也十分庞大。因此，测试只能证明程序中有错误，不能证明程序中没有错误。
类型
•黑盒测试：指在软件界面上进行的测试。一般用来证实软件功能的可操作性；证实能很好的接收输入，并正确地产生输出；以及证实对外部信息完整性的保持。
•白盒测试：对程序细节进行严密检验，对软件的逻辑路径进行测试。
28、逻辑覆盖测试中如何设计测试用例？
详见50126实现 7.6.1
29、如何由程序流程图得到流图，如何计算环形复杂度。 ###
详见50125详细设计 6.5
30、简单流程图的设计（如：累加和、阶乘等） ###
31、软件项目管理中的人员组织方式有哪几种？
现有的软件项目组的组织方式很多，通常，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看法和喜好。下面介绍3种典型的组织方式。
民主制程序员组
民主制程序员组的一个重要特点是，小组成员完全平等，享有充分民主，通过协商做出技术决策。因此，小组成员之间的通信是平行的，如果小组内有n个成员，则可能的通信信道共有n(n-1)/2条。
程序设计小组的人数不能太多,否则组员间彼此通信的时间将多于程序设计时间。此外,通常不能把一个软件系统划分成大量独立的单元,因此,如果程序设计小组人数太多,则每个组员所负责开发的程序单元与系统其他部分的界面将是复杂的,不仅出现接口错误的可能性增加,而且软件测试将既困难又费时间。
一般说来，程序设计小组的规模应该比较小,以2～8名成员为宜。如果项目规模很大,用一个小组不能在预定时间内完成开发任务,则应该使用多个程序设计小组,每个小组承担工程项目的一部分任务，在一定程度上独立自主地完成各自的任务。系统的总体设计应该能够保证由各个小组负责开发的各部分之间的接口是良好定义的,并且是尽可能简单的。
小组规模小,不仅可以减少通信问题,而且还有其他好处。例如,容易确定小组的质量标准,而且用民主方式确定的标准更容易被大家遵守;组员间关系密切,能够互相学习等等。
民主制程序员组通常采用非正式的组织方式，也就是说，虽然名义上有一个组长，但是他和组内其他成员完成同样的任务。在这样的小组中，由全体讨论协商决定应该完成的工作，并且根据每个人的能力和经验分配适当的任务。
民主制程序员组的主要优点是，组员们对发现程序错误持积极的态度，这种态度有助于更快速地发现错误，从而导致高质量的代码。
民主制程序员组的另一个优点是，组员们享有充分民主，小组有高度凝聚力，组内学术空气浓厚，有利于攻克技术难关。因此，当有难题需要解决时，也就是说，当所要开发的软件的技术难度较高时，采用民主制程序员组是适宜的。
如果组内多数成员是经验丰富技术熟练的程序员,那么上述非正式的组织方式可能会非常成功。在这样的小组内组员享有充分民主,通过协商,在自愿的基础上作出决定,因此能够增强团结、提高工作效率。但是,如果组内多数成员技术水平不高,或是缺乏经验的新手,那么这种非正式的组织方式也有严重缺点： 由于没有明确的权威指导开发工程的进行,组员间将缺乏必要的协调,最终可能导致工程失败。
为了使少数经验丰富、技术高超的程序员在软件开发过程中能够发挥更大作用，程序设计小组也可以采用下一小节中介绍的另外一种组织形式。
主程序员组
美国IBM公司在20世纪70年代初期开始采用主程序员组的组织方式。采用这种组织方式主要出于下述几点考虑：
(1) 软件开发人员多数比较缺乏经验；
(2) 程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；
(3) 多渠道通信很费时间，将降低程序员的生产率。
主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行。这种组织方式类似于外科手术小组的组织： 主刀大夫对手术全面负责，并且完成制订手术方案、开刀等关键工作，同时又有麻醉师、护士长等技术熟练的专门人员协助和配合他的工作。此外，必要时手术组还要请其他领域的专家（例如，心脏科医生或妇产科医生）协助。
上述比喻突出了主程序员组的两个重要特性：
（1） 专业化。该组每名成员仅完成他们受过专业训练的那些工作。
（2） 层次性。主刀大夫指挥每名组员工作，并对手术全面负责。
当时，典型的主程序员组的组织形式如图13.5所示。该组由主程序员、后备程序员、编程秘书以及1~3名程序员组成。在必要的时候，该组还有其他领域的专家协助。
图13.5 主程序员组的结构
主程序员组核心人员的分工如下所述：
（1） 主程序员既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分（或复杂部分）的详细设计，并且负责指导其他程序员完成详细设计和编码工作。如图13.5所示，程序员之间没有通信渠道，所有接口问题都由主程序员处理。主程序员对每行代码的质量负责，因此，他还要对组内其他成员的工作成果进行复查。
（2） 后备程序员也应该技术熟练而且富于经验，他协助主程序员工作并且在必要时（例如，主程序员生病、出差或“跳槽”）接替主程序员的工作。因此，后备程序员必须在各方面都和主程序员一样优秀，并且对本项目的了解也应该和主程序员一样深入。平时，后备程序员的工作主要是，设计测试方案、分析测试结果及独立于设计过程的其他工作。
（3） 编程秘书负责完成与项目有关的全部事务性工作，例如，维护项目资料库和项目文档，编译、链接、执行源程序和测试用例。
注意，上面介绍的是20世纪70年代初期的主程序员组组织结构，现在的情况已经和当时大不相同了，程序员已经有了自己的终端或工作站，他们自己完成代码的输入、编辑、编译、链接和测试等工作，无须由编程秘书统一做这些工作。典型的主程序员组的现代形式将在下一小节介绍。
虽然图13.5所示的主程序员组的组织方式说起来有不少优点，但是，它在许多方面却是不切实际的。
首先，如前所述，主程序员应该是高级程序员和优秀管理者的结合体。承担主程序员工作需要同时具备这两方面的才能，但是，在现实社会中这样的人才并不多见。通常，既缺乏成功的管理者也缺乏技术熟练的程序员。
其次，后备程序员更难找。人们期望后备程序员像主程序员一样优秀，但是，他们必须坐在“替补席”上，拿着较低的工资等待随时接替主程序员的工作。几乎没有一个高级程序员或高级管理人员愿意接受这样的工作。
第三，编程秘书也很难找到。专业的软件技术人员一般都厌烦日常的事务性工作，但是，人们却期望编程秘书整天只干这类工作。
我们需要一种更合理、更现实的组织程序员组的方法，这种方法应该能充分结合民主制程序员组和主程序员组的优点，并且能用于实现更大规模的软件产品。
现代程序员组
民主制程序员组的一个主要优点，是小组成员都对发现程序错误持积极、主动的态度。但是，使用主程序员组的组织方式时，主程序员对每行代码的质量负责，因此，他必须参与所有代码审查工作。由于主程序员同时又是负责对小组成员进行评价的管理员，他参与代码审查工作就会把所发现的程序错误与小组成员的工作业绩联系起来，从而造成小组成员出现不愿意发现错误的心理。
解决上述问题的方法是，取消主程序员的大部分行政管理工作。前面已经指出，很难找到既是高度熟练的程序员又是成功的管理员的人，取消主程序员的行政管理工作，不仅解决了小组成员不愿意发现程序错误的心理问题，也使得寻找主程序员的人选不再那么困难。于是，实际的“主程序员”应该由两个人共同担任： 一个技术负责人，负责小组的技术活动；一个行政负责人，负责所有非技术性事务的管理决策。这样的组织结构如图13.6所示。技术组长自然要参与全部代码审查工作，因为他要对代码的各方面质量负责；相反，行政组长不可以参与代码审查工作，因为他的职责是对程序员的业绩进行评价。行政组长应该在常规调度会议上了解每名组员的技术能力和工作业绩。
图13.6 现代程序员组的结构
在开始工作之前明确划分技术组长和行政组长的管理权限是很重要的。但是，即使已经做了明确分工，有时也会出现职责不清的矛盾。例如，考虑年度休假问题，行政组长有权批准某个程序员休年假的申请，因为这是一个非技术性问题，但是技术组长可能马上否决了这个申请，因为已经接近预定的项目结束日期，目前人手非常紧张。解决这类问题的办法是求助于更高层的管理人员，对行政组长和技术组长都认为是属于自己职责范围内的事务，制定一个处理方案。
由于程序员组成员人数不宜过多，当软件项目规模较大时，应该把程序员分成若干个小组，采用图13.7所示的组织结构。该图描绘的是技术管理组织结构，非技术管理组织结构与此类似。由图可以看出，产品开发作为一个整体是在项目经理的指导下进行的，程序员向他们的组长汇报工作，而组长则向项目经理汇报工作。当产品规模更大时，可以适当增加中间管理层次。
图13.7 大型项目的技术管理组织结构
把民主制程序员组和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法，如图13.8所示。这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。这种组织方式对于适合采用民主方法的那类问题（例如，研究性项目或遇到技术难题需要用集体智慧攻关）非常有效。尽管这种组织方式适当地发扬了民主，但是上下级之间的箭头（即管理关系）仍然是向下的，也就是说，是在集中指导下发扬民主。显然，如果程序员可以指挥项目经理，则只会引起混乱。
图13.8 包含分散决策的组织方式
32、软件项目规模的估计有几种方法？
估算软件规模
13.1.1 代码行技术
代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。当有以往开发类似产品的历史数据可供参考时，用这种方法估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。
为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值,和之后，再用下式计算程序规模的估计值：
L= 
(13.1)
用代码行技术估算软件规模时，当程序较小时常用的单位是代码行数（LOC），当程序较大时常用的单位是千行代码数（KLOC）。
代码行技术的主要优点是，代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。代码行技术的缺点是： 源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。
13.1.2 功能点技术
功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。
1. 信息域特性
功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。下面讲述这5个特性的含义。
（1） 输入项数： 用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。
（2） 输出项数： 软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。
（3） 查询数： 查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。
（4） 主文件数： 逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。
（5） 外部接口数： 机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。
2. 估算功能点的步骤
用下述3个步骤，可估算出一个软件的功能点数（即软件规模）。
（1） 计算未调整的功能点数UFP
首先，把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。
然后，用下式计算未调整的功能点数UFP： UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf
其中，ai(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1（见书297页）所示。
(2) 计算技术复杂性因子TCF
这一步骤度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，在表13.2（见书297页）中列出了全部技术因素，并用Fi(1≤i≤14)代表这些因素。根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI：
DI=
技术复杂性因子TCF由下式计算：
TCF=0.65+0.01×DI
因为DI的值在0~70之间，所以TCF的值在0.65~1.35之间。
（3） 计算功能点数FP
用下式计算功能点数FP：
FP=UFP×TCF
功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。
33、能力成熟度模型中成熟度有哪5个等级，各有何特点？
能力成熟度的5个等级从低到高依次是：
初始级（又称为1级），
软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是经过定义的（即没有一个定型的过程模型），项目能否成功完全取决于开发人员的个人能力。
可重复级（又称为2级），
软件机构建立了基本的项目管理过程(过程模型),可跟踪成本、进度、功能和质量。已经建立起必要的过程规范，对新项目的策划和管理过程是基于以前类似项目的实践经验，使得有类似应用经验的软件项目能够再次取得成功。达到2级的一个目标是使项目管理过程稳定，从而使得软件机构能重复以前在成功项目中所进行过的软件项目工程实践。
处于2级成熟度的软件机构的过程能力可以概括为，软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复以前成功实践的项目环境。软件项目工程活动处于项目管理体系的有效控制之下，执行着基于以前项目的准则且合乎现实的计划。
已定义级（又称为3级），
软件机构已经定义了完整的软件过程（过程模型），软件过程已经文档化和标准化。所有项目组都使用文档化的、经过批准的过程来开发和维护软件。这一级包含了第2级的全部特征。
在第3级成熟度的软件机构中，有一个固定的过程小组从事软件过程工程活动。当需要时，过程小组可以利用过程模型进行过程例化活动，从而获得一个针对某个特定的软件项目的过程实例，并投入过程运作而开展有效的软件项目工程实践。同时，过程小组还可以推进软件机构的过程改进活动。在该软件机构内实施了培训计划，能够保证全体项目负责人和项目开发人员具有完成承担的任务所要求的知识和技能。
处于3级成熟度的软件机构的过程能力可以概括为，无论是管理活动还是工程活动都是稳定的。软件开发的成本和进度以及产品的功能和质量都受到控制，而且软件产品的质量具有可追溯性。这种能力是基于在软件机构中对已定义的过程模型的活动、人员和职责都有共同的理解。
已管理级（又称为4级）
软件机构对软件过程（过程模型和过程实例）和软件产品都建立了定量的质量目标，所有项目的重要的过程活动都是可度量的。该软件机构收集了过程度量和产品度量的方法并加以运用，可以定量地了解和控制软件过程和软件产品，并为评定项目的过程质量和产品质量奠定了基础。这一级包含了第3级的全部特征。
处于4级成熟度的软件机构的过程能力可以概括为，软件过程是可度量的，软件过程在可度量的范围内运行。这一级的过程能力允许软件机构在定量的范围内预测过程和产品质量趋势，在发生偏离时可以及时采取措施予以纠正，并且可以预期软件产品是高质量的。
优化级（又称为5级）
软件机构集中精力持续不断地改进软件过程。这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。在这样的机构中，可以获得关于软件过程有效性的统计数据，利用这些数据可以对新技术进行成本/效益分析，并可以优化出在软件工程实践中能够采用的最佳新技术。这一级包含了第4级的全部特征。
这一级的软件机构可以通过对过程实例性能的分析和确定产生某一缺陷的原因，来防止再次出现这种类型的缺陷；通过对任何一个过程实例的分析所获得的经验教训都可以成为该软件机构优化其过程模型的有效依据，从而使其他项目的过程实例得到优化。这样的软件机构可以通过从过程实施中获得的定量的反馈信息，在采用新思想和新技术的同时测试它们，以不断地改进和优化软件过程。
处于5级成熟度的软件机构的过程能力可以概括为，软件过程是可优化的。这一级的软件机构能够持续不断地改进其过程能力，既对现行的过程实例不断地改进和优化，又借助于所采用的新技术和新方法来实现未来的过程改进。
一些统计数字表明，提高一个完整的成熟度等级大约需要花18个月到3年的时间，但是从第1级上升到第2级有时要花3年甚至5年时间。这说明要向一个迄今仍处于混乱的和被动的行动方式的软件机构灌输系统化的方式，将多么困难。
附录
一、单项选择（每题2分，共30分）
1、总体设计目的是确定整个系统的（ ）。
A、规模 B、测试方案
C、费用 D、功能及模块结构
2、模块在同一段时间内完成各种初始化工作，这属于（ ）。
A、偶然内聚 B、逻辑内聚
C、时间内聚 D、过程内聚
3、开发软件所需高成本和产品的低质量之间有着尖锐的矛盾,这种现象称( )
A. 软件工程 B. 软件周期
C. 软件危机 D. 软件产生
4、软件详细设计的主要任务是确定每个模块的（ ）
A、算法和使用的数据结构 B、外部接口
C、功能 D、编程
5、软件结构图的形态特征能反映程序重用率的是（ ）
A、深度 B、宽度
C、扇入 D、扇出
6、为了提高模块的独立性，模块内部最好是（ ）
A、逻辑内聚 B、时间内聚
C、功能内聚 D、通信内聚
7．程序的三种基本控制结构是 。
A 过程、子程序、和分程序
B 顺序、选择和循环
C 递归、堆栈和队列
D 调用、返回和转移
8．可行性研究要进行一次 需求分析。
A．详细的 B.全面的 C.简化的，压缩的 D.彻底的
9．（ ）产生软件危机的原因主要与两个方面的问题有关：
A.软件在计算机中很难识别，存在磁盘中也看不到。
B.软件设计对人的智商要求很高，也要求很高的资金投入。
C.软件产品本身的特点与其它工业产品不一样，而且在软件的开发和维护过程中用的方法不正确。
D.软件很难理解，硬件也很复杂。
10．（ ）软件开发瀑布模型中的软件定义时期各个阶段依次是：
- 可行性研究，问题定义，需求分析。
- 问题定义，可行性研究，需求分析。
- 可行性研究，需求分析，问题定义。
- 以上顺序都不对。
11．（ ） 可行性研究主要从以下几个方面进行研究：
- 技术可行性，经济可行性，操作(社会)可行性。
- 技术可行性，经济可行性，系统可行性。
- 经济可行性，系统可行性，操作可行性。
- 经济可行性，系统可行性，时间可行性。
12． ( ) 耦合是对软件不同模块之间互连程度的度量。各种耦合按从强到弱排列如下：
- 内容耦合，控制耦合，数据耦合，公共环境耦合。
- 内容耦合，控制耦合，公共环境耦合，数据耦合。
- 内容耦合，公共环境耦合，控制耦合，数据耦合。
- 控制耦合，内容耦合，数据耦合，公共环境耦合。
13．（ ） 在详细设计阶段所使用到的设计工具是：
- 程序流程图，PAD图，N-S图，判定表，判定树.
- 数据流图，Yourdon 图，程序流程图，PAD图，N-S图，HIPO图。
- 判定表，判定树，数据流图，系统流程图，程序流程图，PAD图，N-S图。
- 判定表，判定树，数据流图，系统流程图，程序流程图，层次图。
14.（ ） 按照软件工程的原则，模块的作用域和模块的控制域之间的关系是：
A.模块的作用域应在模块的控制域之内。
B.模块的控制域应在模块的作用域之内。
C.模块的控制域与模块的作用域互相独立。
D.以上说法都不对。
15. 1960年底Dijkstra提倡的（ ）是一种有效的提高程序设计效率的方法。
A) 标准化程序设计
B) 模块化程序设计
C) 多道程序设计
D) 结构化程序设计
二、填空题（每空2分，共12分）
1. 模块的独立程度可以由两个定性标准度量，这两个标准分别称为（ 内聚 ）和（ 耦合 ）。
2．总体设计的第二项任务是设计软件的结构，即确定（ 功能和模块结构）。
3．如果模块内所有元素都使用同一个输入数据和产生同一个输出，称为（ 通信 ）内聚。
4．数据流程图按照信息流的类型主要分为（ 事务流 ）、（ 变换流 ）两种。
三、名词解释（每题6分，共24分）
1、软件工程
详见5011软件工程_软件工程学概述
概括地说，
软件工程：是指导计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
人们曾经给软件工程下过许多定义，下面给出两个典型的定义。
1968年在第一届NATO会议上曾经给出了软件工程的一个早期定义：“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。”
这个定义不仅指出了软件工程的目标是经济地开发出高质量的软件，而且强调了软件工程是一门工程学科，它应该建立并使用完善的工程原理。
1993年IEEE进一步给出了一个更全面更具体的定义：“软件工程是： ①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件； ②研究①中提到的途径。”
2、模块
详见50124总体设计
模块： 是由边界元素限定的相邻程序元素（例如，数据说明，可执行的语句）的序列，而且有一个总体标识符代表它。按照模块的定义，过程、函数、子程序和宏等，都可作为模块。
3．软件生命周期
一个软件从定义、开发、使用和维护，直到最终被废弃，要经历一个漫长的时期。通常把软件经历的这个漫长的时期称为生命周期。
4．数据流图
数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。
数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此是分析员与用户之间极好的通信工具。
四、简答（每题10分，共20分）
1、怎样衡量模块的独立性,对内聚及耦合应遵循哪些原则？
模块独立程度的度量标准：内聚和耦合。
耦合：模块间互相依赖(连接)的紧密程度；
内聚：模块内部各个元素彼此结合的紧密程度。
设计时尽量使用高内聚，低耦合模块。
• 高内聚：尽量使用内聚度高的模块；中内聚也可；低内聚很坏，不要采用。
低内聚：偶然内聚，逻辑内聚，时间内聚
中内聚：过程内聚，通信内聚
高内聚：顺序内聚，功能内聚；
• 低耦合：尽量使用数据耦合，少用控制耦合和标记耦合，限制公共耦合的范围，完全不用内容耦合。
2．常用的软件过程模型有哪些？
#1瀑布模型
1. 阶段间具有顺序性和依赖性
这个特点有两重含义：
①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
②前一阶段的输出文档就是后一阶段的输入文档。
2. 推迟实现的观点
对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。
3. 质量保证的观点
每个阶段都应坚持两个重要做法：
（1） 每个阶段都必须完成规定的文档。
（2） 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
#2快速原型模型
是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
快速原型模型是不带反馈环的，这正是这种过程模型的主要优点： 软件产品的开发基本上是线性顺序进行的。
#3增量模型
把软件产品作为一系列的增量构件来设计、编码、集成和测试。
增量模型的优点：
能在较短时间内向用户提交可完成部分工作的产品；
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品
维护时期反馈环很小。
#4 螺旋模型
螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险，在每个阶段之前都增加了风险分析过程的快速原型
#5喷泉模型
喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。
各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。
优点：
提高开发效率
缩短开发周期
缺点：难于管理
三、设计题（本题14分）
求阶乘的C语言源程序如下：
#include<stdio.h> int main(){ int jc.i; jc=1; i=1; While(i<=10){ jc=jc*i; i=i+1; } Printf(“The result is %d”,jc); }
试绘制求阶乘算法的流程图及N-S图。
