软件开发的增量模型
“软件工程学”（成高学士学位专业课）考试大纲
软件工程学是成人高等教育软件工程专业学士学位考试计划中的一门专业课程，该课程重点要求学生学习与软件开发和维护有关的四个方面的主要内容——过程与模型、方法与技术、工具与环境、标准与规范等。本课程的主要任务是使应考者掌握软件工程的基本概念、基本原理、实用的开发方法和技术；了解软件工程各领域的发展动向；如何用工程化的方法开发软件项目，以及在开发过程中应遵循的流程、准则、标准和规范等。本考试大纲主要由课程要求、考核要点、参考教材和样卷四部分组成。
一、课程要求
通过软件工程学课程的学习，要求学生切实掌握软件工程的基本思想、基本概念、基本方法，能够应用相应的图形表示工具进行小型项目的开发，特别是实用方法与技术的应用。具体要求如下：
1．从总体上了解软件工程的产生、软件生产发展史、软件生存周期、各种方法和生存周期模型、软件工程面临的问题。
2．系统掌握软件开发最基本的内容：可行性研究和软件计划、需求分析、概要设计、详细设计、编码、测试、维护，系统掌握这些阶段的目标、任务、特点、步骤和文档。
3．掌握增量模型的基本内容、基本思想、运行机制、开发过程和步骤。
4．掌握结构化方法的基本思想，开发过程和步骤，应遵循的原则和准则，能够应用相应的图形表示工具开发小型软件项目。
5．初步掌握面向对象方法的基本思想、基本概念、基本模型，面向对象分析、面向对象设计、面向对象实现的任务、内容和步骤，能够应用相应的图形工具。
6．了解Jackson方法的基本思想、开发过程和步骤、能够应用相应的图形表示工具。
7．了解软件工程的质量保证中的各种基本概念和方法，了解软件工程管理中的思想和方法，了解软件开发环境与工具。
二、考核要点
（一）第1章绪论
本章总体要求是：从总体上了解软件工程的基本概念和内容、软件工程过程和生存期的基本概念和内容、软件开发的各种方法和生存周期模型等。本章考核要求如下：（1）软件工程的产生
①软件的特点，要求达到识记层次。
②软件生产的发展，要求达到识记层次。
③软件危机的产生、表现、原因，要求达到领会层次。
④软件工程的定义、性质、目标、内容、面临的问题，要求达到领会层次。
（2）软件工程过程和软件生存周期
①软件工程过程概念，要求达到识记层次。
②软件生存周期概念，要求达到识记层次。
（3）软件生存周期模型、方法和工具
①软件生存周期模型的定义、重要性、作用和准则，要求达到识记层次。
②瀑布模型、增量模型、螺旋模型、喷泉模型、变换模型、基于知识的模型等，要求达到识记层次。
③软件开发目标、软件开发方法的作用和重要性，要求达到识记层次。
④结构化方法、Jackson方法、维也纳方法、面向对象方法，要求达到识记层次。
⑤软件开发工具的重要性、软件开发环境和计算机辅助软件工程，要求达到识记层次。
（二）第2章软件可行性研究与项目开发计划
本章总体要求是：深刻理解可行性研究的必要性、掌握可行性研究的任务及可行性研究均具体步骤、了解系统流程图的作用及符号表示、理解可行性研究报告与项目开发计划的内容等。本章考核要求如下：
（1）可行性研究
①可行性研究的任务，要求达到识记层次。
②可行性研究的具体步骤，要求达到领会层次。
（2）系统流程图
①系统流程图中的各步骤要求达到识记层次。
（3）成本——效益分析
①投资回收率、回收期和纯收入要求达到识记层次。
（4）项目开发计划
①项目开发计划包含的内容要求达到识记层次
（三）第3章软件需求分析
本章总体要求是：深刻理解需求分析阶段的概念及任务、熟练掌握面向数据流的分析方法——结构化分析方法、深刻理解数据流图和数据字典的作用及应用、掌握几种加工逻辑的描述方法。本章考核要求如下：
（1）需求分析的任务
①需求分析的概念，要求达到识记层次。
②需求分析的基本任务，要求达到领会层次。
（2）结构化分析方法
①结构化分析方法中的分析步骤，要求达到领会层次。
（3）数据流图
①数据流图中的符号、画数据流图注意的事项，要求达到领会层次。
②分层的数据流图，要求达到简单应用层次。
（4）数据字典
①数据字典的作用、数据字典中的条目，要求达到识记层次。
②数据字典的定义，要求达到简单应用层次。
（5）加工逻辑的描述
①结构化语言、判定表（树）的构成，要求达到领会层次。
②结构化语言、判定表（树）描述，要求达到简单应用层次。
（6）IDEF方法
①IDEF0的图形表示，要求达到领会层次。
②建立功能模型的基本方法，要求达到领会层次。
（四）第4章软件概要设计
本章总体要求是：深刻理解软件设计的基本任务和基本原理；熟练掌握结构化设计方法；深刻理解模块化、抽象、信息隐敝、模块独立性等概念；明确度量模块独立性的标准——耦合性与内聚性。本章考核要求如下：
（1）软件概要设计的基本任务
①软件设计、概要设计和详细设计，要求达到识记层次。
②软件设计的基本任务，要求达到领会层次。
（2）软件设计的基本原理
①模块化、抽象、信息隐蔽、模块独立性、内聚性和耦合性等概念，要求达到领会层次。
②内聚性、耦合性的划分，要求达到领会层次。
（3）软件结构优化准则
①软件结构、模块的影响范围、模块的控制范围，要求达到领会层次。
②软件结构设计的优化准则，要求达到领会层次。
（4）面向数据流的设计方法
①变换流和事务流，要求达到识记层次。
②将变换流或事务流类型的数据流图，转换成软件结构，要求达到简单应用层次。
（5）基于IDEF0图的设计方法
①IDEF0图的设计方法，要求达到领会层次。
（6）HIPO图表示软件结构
①HIPO图，要求达到领会层次。
（五）第5章软件详细设计
本章总体要求是：能熟练地使用详细设计描述方法来设计模块中的算法及程序的逻辑结构、理解Jackson方法的概念，学会使用Jackson方法设计输入输出数据结构和程序结构。本章的考核要求如下：
（1）详细设计的基本任务
①详细设计的基本任务，要求达到领会层次。
（2）结构化程序设计方法
①结构化程序设计的基本要点，要求达到识记层次。
（3）详细设计描述法
①流程图、PAD图及过程设计语言，要求达到简单应用层次。
（4）Jackson方法
①Jackson方法，要求达到简单应用层次。
（六）第6章软件编码
本章总体要求是：掌握几种常用的程序设计语言的特点、领会程序设计中应注意的问题，、注重培养良好的编程风格。本章的考核要求如下：
（1）程序设计语言的特点及选择
①几种常用的程序设计语言的特点。要求达到识记层次。
（2）程序设计风格
①程序设计风格，要求达到领会层次。
（七）第7章软件测试
本章总体要求是：掌握测试阶段的任务、测试方法及测试步骤；深刻理解白盒、黑盒测试技术；深刻理解测试过程中单元测试、集成测试、确认测试的任务及采用的方法；掌握调试程序的方法。本章的考核要求如下：
（1）软件测试的目的及原则
①软件测试的目的，要求达到识记层次。
（2）测试方法
①白盒法、黑盒法，要求达到领会层次。
（3）测试用例的设计
①逻辑覆盖、等价类划分、边界值分析、错误推测、因果图，要求达到识记层次。
②逻辑覆盖中各种覆盖之间的区别，要求达到领会层次。
③用白盒法、黑盒法设计测试用例，要求达到简单应用层次。
（4）测试过程
①单元测试、集成测试、确认测试、渐增式、非渐增式，要求达到识记层次。
②单元测试的内容及方法、集成测试的方法、渐增式及非渐增式测试的区别、自顶向下及自底向上结合模块的步骤、三种测试与软件开发各阶段之间的关系，要求达到领会层次。
（5）调试
①调试，要求达到识记层次。
②归纳法和演绎法，要求达到领会层次。
（八）第8章软件维护
本章总体要求是：要掌握软件维护的内容、特点、方法、技术、文档；了解软件维护的各种困难、软件维护的特点、软件维护的文挡；理解软件维护的内容、维护任务的实施、维护的副作用；深刻理解如何提高软件可维护性。本章的考核要求如下：
（1）软件维护的内容
①校正性维护、适应性维护、完善性维护和预防性维护，要求达到领会层次。
（2）软件维护的特点
①结构化维护与非结构化维护、维护的困难性和软件维护的费用，要求达到识记层次。
（3）软件维护任务的实施
①软件维护的组织、维护的流程、维护的技术及维护的副作用，要求达到识记层次。
（4）软件可维护性
①可维护性的定义，要求达到领会层次。
②可维护性的度量，要求达到领会层次。
③提高可维护性的方法，要求达到领会层次。
（九）第9章软件开发的增量模型
本章的总体要求是：了解增量模型的基本思想、特点；了解模型的分类和各种模型的表示；了解快速原型的基本原理；理解快速原型的开发技术、构造原型的建议和开发环境；深刻理解快速原型开发过程和步骤。本章的考核要求如下：
（1）概述
①瀑布模型的局限性，要求达到识记层次。
②增量模型的基本思想、分类，要求达到识记层次。
（2）渐增模型
①增量构造模型，要求达到领会层次。
②演化提交模型，要求达到领会层次。
（3）快速原型模型
①快速原型模型的基本思想，要求达到识记层次。
②快速原型模型表示，要求达到识记层次。
（4）快速原型开发技术和开发环境
①构造原型的建议和开发环境，要求达到领会层次。
（5）增量模型的评价
①原型的作用、原型使用建议、原型的优点及原型存在的问题，要求达到识记层次。（十）第10章面向对象的方法
本章总体要求是：掌握面向对象的基本思想、基本概念、基本原理；掌握三种模型的基本概念和构造方法；掌握面向对象的分析、面向对象的设计、面向对象的实现的过程；了解传统开发方法的各种局限性；了解面向对象语言、面向对象技术、面向对象开发方法的发展过程；理解面向对象分析、面向对象设计、面向对象实现的内容、方法和步骤；深刻理解对象、类、类的层次结构、方法和消息的实质，深刻理解对象模型、动态模型、功能模型的元素、结构和构造方法。本章的考核要求如下：
（1）面向对象概述
①传统开发方法存在的问题，要求达到识记层次。
②面向对象的概念，要求达到识记层次。
③面向对象的开发方法，要求达到识记层次。
（2）面向对象的模型
①对象模型中对象和类、关联、类的层次结构，要求达到领会层次。
②对象图，要求达到简单应用层次。
③动态模型中的事件、状态、行为等概念，要求达到领会层次。
④状态图，要求达到简单应用层次。
⑤功能模型，要求达到领会层次。
（3）面向对象的分析
①面向对象分析过程，要求达到领会层次。
②建立对象模型，要求达到简单应用层次。
③建立动态模型，要求达到简单应用层次。
④建立功能模型，要求达到简单应用层次。
（4）面向对象的设计
①面向对象设计的准则，要求达到领会层次。
②面向对象设计的启发规则，要求达到领会层次。
③系统设计，要求达到识记层次。
④对象设计，要求达到识记层次。
（5）面向对象实现
①程序设计语言，要求达到识记层次。
②类的实现，要求达到领会层次。
④面向对象的测试，要求达到识记层次。
（十一）第11章软件质量与质量保证
本章总体要求是了解软件质量的定义；理解软件质量的度量与评价、软件质量保证的基本概念；理解软件质量度量模型、软件复杂性、软件可靠性、设计质量的评审和程序质量评审的具体内容和软件容错技术的概念；理解软件复杂性的几种常用度量方法，以及软件质量度量模型；了解实现容错软件的一般方法和容错软件的实现过程；理解使用软件质量度量模型、软件复杂性度量模型、软件可靠性模型、容错软件设计过程与软件评审的方法对保证软件质量所起的作用。本章的考核要求如下：
（1）概述
①软件质量的定义，要求达到领会层次。
②软件质量的度量与评价，要求达到识记层次。
③软件质量保证，要求达到识记层次。
（2）质量度量模型
①McCall质量度量模型，要求达到领会层次。
②ISO质量度量模型，要求达到领会层次。
（3）软件复杂性
①软件复杂性的基本概念。要求达到识记层次。
②软件复杂性的度量方法，要求达到识记层次。
（4）软件可靠性
①软件可靠性定义，要求达到识记层次。
②软件可靠性指标，要求达到识记层次。
③软件可靠性模型，要求达到识记层次。
（5）软件评审
①软件评审要求达到识记层次。
（6）软件容错技术
①容错软件定义，要求达到识记层次。
②容错的一般方法，要求达到领会层次。
③容错软件的设计过程，要求达到识记层次。
（十二）第12章软件工程管理
本章总体要求是：了解软件产品的各种特点与软件工程管理的内容、软件项目计划内容、软件开发成本估算、软件项目进度安排和软件配置管理等概念；理解软件开发成本估算的
COCOCM模型和Putnan估算模型；软件项目进度安排中的软件开发任务的并行性，Gantt 图与工程网络图：文档的作用与分类；深入理解软件项目计划的重要性及各个环节之间的联系，软件工程标准化的意义。本章的考核要求如下：
（1）软件工程管理概述
①软件产品的特点，要求达到识记层次。
②软件工程管理的重要性，要求达到识记层次。
③软件工程管理的内容，要求达到识记层次。
（2）软件项目计划
①软件项目计划概念，要求达到领会层次。
②软件项目计划内容，要求达到领会层次。
③制定软件工程规范，要求达到领会层次。
④软件开发成本估算，要求达到领会层次。
⑤风险分析，要求达到识记层次。
⑥软件项目进度安排，要求达到领会层次。
⑦软件质量保证，要求达到简单应用层次。
（3）软件配置管理
①基线概念，要求达到识记层次。
②软件配置项，要求达到领会层次。
③版本控制，要求达到领会层次。
④变更控制，要求达到领会层次。
（4）软件工程标准化与软件文档
①软件工程标准化的意义，要求达到识记层次。
②软件工程标准的层次，要求达到识记层次。
③文档的作用与分类，要求达到领会层次。
（十三）第13章软件开发环境
本章总体要求是：了解软件开发环境概念、软件开发环境的分类、软件工具、软件工具分类、工具间集成、计算机辅助软件工程CASE的基本概念；理解软件环境的特点和分类、软件工具的分类与评价，工具间集成性与灵活性，CASE的分类与生命周期。理解集成化，CASE生存周期，软件工程环境；软件工程方法的研究在软件开发中的作用。本章的考核要求如下：
（1）软件开发环境
①软件开发环境概论，要求达到识记层次。
②软件开发环境的分类，要求达到识记层次。
（2）软件工具
①软件工具的基本概念与特点，要求达到识记层次。
②软件工具的分类，要求达到领会层次。
（3）计算机辅助软件工程（CASE）
①CASE的定义、分类、集成等概念，要求达到识记层次。
②CASE的生存期和工作台，要求达到领会层次。
三、参考教材
1．《软件工程导论（第5版）》，张海潘编著，清华大学出版社，2008年2月
2．《软件工程（第二版）》，齐治昌、谭庆平等著，高等教育出版社，2004年04月3．《软件工程原理与应用》，陈世鸿编著，武汉大学出版社，2000年1月
四、样卷
一、单项选择题（本大题共20小题，每小题1分，共20分）
在每小题列出的四个备选项中只有一个是符合题目要求的，请将其代码填写在题后的括号内。错选、多选或未选均无分。
1．在软件生存周期中，时间最长的阶段是（）
A．需求分析B．详细设计
C．编码D．维护
2．以下最适合于面向对象的软件开发的软件生存周期模型是（）
A．瀑布模型B．增量模型
C．螺旋模型D．喷泉模型
3．以下不．适用于需求分析的工具是（）
A．数据流图B．判定表
C．PAD图D．数据字典
4．以下几种模块内聚类型中，内聚性最低的是（）
A．时间内聚B．逻辑内聚
C．顺序内聚D．功能内聚
5．系统流程图中符号的名称是（）
A．联机存储B．处理
C．磁盘D．文档
6．数据流图中的每个加工至少有（）
A．一个输入流或一个输出流B．一个输出流
C．一个输入流D．一个输入流和一个输出流
7．HIPO图是软件工程中的一种描述工具，采用HIPO图进行描述的阶段是（）A．可行性分析B．需求分析
C．概要设计D．详细设计
8．Jackson方法是软件开发过程中常用的方法，使用Jackson方法可以实现（）A．从数据结构导出程序结构B．从数据流图导出初始结构图
C．从模块结构导出数据结构D．从模块结构导出程序结构9．过程设计语言(PDL)，又称为（）
A．伪码B．高级程序设计语言
C．中级程序语言D．低级程序设计语言
10．单元测试阶段主要涉及的文档为（）
A．需求设计B．编码和详细设计
C．详细设计D．概要设计
11．软件维护会产生副作用，下面选项中不属于
．．．维护副作用的是（）
A．编码副作用B．测试副作用
C．文档副作用D．数据副作用
l2．以下不．适合作为科学工程计算的语言是（）
A．Pascal B．C
C．Fortran D．Prolog
l3．PAD图为下列哪个方面提供了有力的工具（）
A．系统分析B．软件的自动化生成
C．自动分析数据D．测试软件
14．结构化软件设计是（）
A．面向数据结构的B．面向数据库的
C．面向数据流的D．面向对象设计的
15．在McCall软件质量度量模型中，面向软件产品修改的质量因素为（）A．可用性B．完整性
C．适应性D．互操作性
16．汽车是一种交通工具，汽车类和交通工具类之间的关系是（）
A．一般具体B．has a
C．整体部分D．组成
l7．Westinghouse公司于1992年公布了l3类软件工具分类标准和该类的范例工具以及
例子，下面说法错误
．．的是（）
A．代码生成程序属于编码和单元测试工具
B．桌面出版系统属于文档工具
C．数据库管理系统属于需求追踪工具
D．计划和进度属于项目管理工具
18．对McCabe度量法，叙述错误
．．的是（）
A．McCabe度量法是一种基于程序控制流的复杂性度量法
B．McCabe度量法以图论为工具，用图的环路作为程序复杂性的度量值
C．McCabe度量法将简单IF语句和赋值语句的复杂性同等看待
D．McCabe复杂性度量也称为环路度量
19．瀑布模型本质是一种（）
A．顺序迭代模型B．线性顺序模型
C．线性迭代模型D．非线性模型
20．对于使用原型的建议，下面说法错误
．．的是（）
A．开发周期很长的项目，可通过原型开发来缩短开发周期
B．系统的使用可能变化较大，不能相对稳定，而原型模型具有适应变化的机制
C．缺乏开发工具，或对原型的可用工具不了解的时候宜使用原型
D．用户对系统的需求较为模糊，对某种要求缺乏信心时宜使用原型
二、填空题（本大题共10小题，每小题2分，共20分）
请在每小题的空格中填上正确答案。错填、不填均无分。
21．为了支持软件人员开发和维护活动而使用的软件一般是指____________。
22．在IDEF0方法中，一个活动可以无输入，但必须至少有一个__________。
23．在软件结构的设计中，各个模块之间要力求降低耦合性，提高____________。
24．在类的层次结构中，通常上层类称为父类或超类，下层类称为__________。
25．数据流图(DFD)一般可分为变换型和__________两类。
26．软件维护的内容包括校正性维护、适应性维护、_________和预防性维护。
27．软件的生产经历了三个阶段，分别是程序设计时代、程序系统时代和__________。
28．渐增模型是瀑布模型的变种，分为两类：增量构造模型和__________。
29．状态图反映了_____________的关系。
30．软件项目管理过程一个关键的活动是__________，它是软件开发工作的第一步。
三、名词解释题（本大题共5小题，每小题3分，共15分）
31．软件开发方法
32．耦合性
33．多态性
34．软件质量保证
35．确认测试
四、简答题（本大题共4小题，每小题5分，共20分）
36．简述可行性研究的目的和任务。
37．什么是模块化？软件结构设计的优化准则是什么？
38．简述详细设计的基本任务。
39．简述软件测试的任务、目的与类型。
五、应用题(本大题共2小题，其中40小题l0分，4l小题15分，共25分)
40．某个程序的伪码如下(前面的标号只用于标明语句顺序，不参与程序运行)：
1：START
2：IF L1 THEN
3：S1
4：DO WHILE L2
5：S2
6：IF L3 THEN
7：S3
ELSE
8：S4
9：END IF
10：END DO
EISE
11：S5
12：END IF
13：STOP
（1）试将其转换成PAD图（5分）
（2）计算程序的环路复杂性（5分）
41．某服装贸易公司的销售子系统功能如下：
（1）公司提供多种类别服装，所有类别的服装通过各个地区的分公司进行销售；
（2）公司接收分公司的订单，检验订单，若有库存就供货，则修改库存，给仓库开备货单，并且将订单留底；若库存不足，则进行缺货登记。
（3）根据缺货记录将缺货通知单发给采购部，以便采购。
（4）根据采购部门的进货通知单处理进货，即修改库存，并从缺货记录中取出缺货订单进行供货处理。
试采用结构化分析方法画出该公司销售管理系统的分层DFD(画出顶层、0层、1层图)。
几种常见的测试模型汇总
几种比较常见的测试模型汇总： V模型 V模型最早是由Paul Rook在２０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。Ｖ模型反映出了测试活动与分析设计活动的关系。从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。 V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。 但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。 W模型（也叫双V模型）
W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发 阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代 表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型 有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。 X模型 X模型是由Marick提出的，他的目标是弥补V模型的一些缺陷，例如：交接、经常性的集成等问题。 X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试， 此后将进行频繁的交接，通过集成最终合成为可执行的程序。右上半部分，这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。 但V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这大概是X模型的一个不足之处。而且由于X模型从没有被文档化，其内容一开始需要从V模型的相关内容中进行推断，因为它还没有完全从文字上成为V 模型的全面扩展。
软件开发模型介绍与对比分析
常用的软件开发模型 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。 1. 瀑布模型-最早出现的软件开发模型 1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型的软件过程如图所示）
软件工程考试题库
软件工程概述 一单项选择 1．软件生命周期一般包括：软件开发期和软件运行期，下述（D）不是软件开发期所应包含的内容。 A需求分析B结构设计C程序编制D软件维护 2．软件是一种逻辑产品，它的开发主要是（A）。 A研制B拷贝C再生产D复制 3．以文档作为驱动，适合于软件需求很明确的软件项目的生存周期模型是（C）。 A喷泉模型B增量模型C瀑布模型D螺旋模型 4．在软件生存周期中，（B）阶段必须要回答的问题是“要解决的问题是做什么？”。 A详细设计B可行性分析和项目开发计划C概要设计D软件测试 5．软件产品与物质产品有很大区别，软件产品是一种（C）产品 A有形B消耗C逻辑D文档 6．（C）把瀑布模型和专家系统结合在一起，在开发的各个阶段上都利用相应的专家系统来帮助软件人员完成开发工作。 A原型模型B螺旋模型C基于知识的智能模型D喷泉模型 7．(B)阶段是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。 A概要设计B详细设计C编码D测试 8．下列软件开发模型中，适合于那些不能预先确切定义需求的软件系统的开发的模型是（A）。 A原型模型B瀑布模型C基于知识的智能模型D变换模型 9．下列软件开发模型中，以面向对象的软件开发方法为基础，以用户的需求为动力，以对象来驱动的模型是（C）。 A原型模型B瀑布模型C喷泉模型D螺旋模型 10．下列软件开发模型中，支持需求不明确，特别是大型软件系统的开发，并支持多种软件开发方法的模型是（D）。 A原型模型B瀑布模型C喷泉模型D螺旋模型 11．软件特性中，使软件在不同的系统约束条件下，使用户需求得到满足的难易程度称为（C）。 A可修改性B可靠性C可适应性D可重用性 12．软件特性中，一个软件能再次用于其他相关应用的程度称为（B）。 A可移植性B可重用性C容错性D可适应性 13．软件特性中，（A）是指系统具有清晰的结构，能直接反映问题的需求的程度。 A可理解性B可靠性C可适应性D可重用性 14．软件特性中，软件产品交付使用后，在实现改正潜伏的错误、改进性能、适应环境变化等方面工作的难易程度称为（B）。 A可理解性B可维护性C可适应性D可重用性 15．软件特性中，软件从一个计算机系统或环境移植到另一个上去的难易程度指的是（C）. A可理解性B可修改性C可移植性D可重用性 16．软件特性中，在给定的时间间隔内，程序成功运行的概率指的是（D）。 A有效性B可适应性C正确性D可靠性 17．软件特性中，允许对软件进行修改而不增加其复杂性指的是（A）。 A可修改性B可适应性C可维护性D可移植性 18．软件特性中，多个软件元素相互通讯并协同完成任务的能力指的是（B）。 A可理解性B可互操作性C可维护性D可追踪性 19．软件特性中，根据软件需求对软件设计、程序进行正向追踪，或根据程序、软件设计对软件需求进行逆向
软件工程——软件开发过程中用到的各种图
软件工程——软件开发过程中用到的各种图 一、宏观导图 导图说明：我们的软件开发中用到的各种图型工具都是为了辅助我们更好的理解开发的阶段或者过程。上图是根据软件过程中各个阶段所需要用到的各种图的一个小结。下面是各种图的简介和示例。 二、谈细节： 1、问题定义阶段（规划阶段）： UC图:（ Use Creat 图）它是 BSP（ business system planning ）法中常用的子系统划分工具。
2、可行性分析 2.1系统流程图：是描述系统物理模型的一种传统工具。它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。
3、需求分析： 3.1 DFD图（Data Flow Diagram):从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程.建立系统的功能模型。 3.2 ERD（Entity-Relationship Diagram)图：当数据量很大并且数据间关系复杂时对于数据的分析就得用到它来刻画系统数据模型
3.3 IPO（input process output）图描述了输入数据、处理数据、输出数据之间的关系。 3.4 STD（State Transition Diagram）图：刻画系统响应外部事件的过程。为系统的行为建模。
面向数据结构的几个图形工具： 3.5 层次方框图：用来展示数据的层次结构 3.6 warnier图：和层次方框图一个意思，不过她能描述的手段比层次图更加丰富。
软件工程复习题及答案
2006-2007-2软件工程复习 一、单项选择题（20选10） 1. 结构化分析的主要描述手段有( B )。 A. 系统流程图和模块图 B. ＤＦＤ图、数据词典、加工说明 C. 软件结构图、加工说明 D. 功能结构图、加工说明 2. 用于表示模块间的调用关系的图叫（ D ）。 A．PAD B．SC C．N-S D．HIPO 3. 在（ B ）模型中是采用用例驱动和架构优先的策略，使用迭代增量建造方法，软件“逐渐”被开发出来的。 A．快速原型 B. 统一过程 C．瀑布模型 D. 螺旋模型 4. 常用的软件开发方法有面向对象方法、面向( A )方法和面向数据方法。 A. 过程 B. 内容 C. 用户 D. 流程 5 从工程管理的角度来看，软件设计分两步完成( D )。 A. ①系统分析②模块设计 B. ①详细设计②概要设计 C. ①模块设计②详细设计 D. ①概要设计②详细设计 6. 程序的三种基本结构是（ B ）。 A. 过程、子程序、分程序 B．顺序、条件、循环 C．递归、堆栈、队列 D．调用、返回、转移 7. 程序的三种基本结构是（ B ）。 A. 过程、子程序、分程序 B．顺序、条件、循环 C．递归、堆栈、队列 D．调用、返回、转移 8. SD方法衡量模块结构质量的目标是（ C ）。 A. 模块间联系紧密，模块内联系紧密 B. 模块间联系紧密，模块内联系松散 C. 模块间联系松散，模块内联系紧密 D. 模块间联系松散，模块内联系松散 9．为提高软件测试的效率，应该（ C ）。 A．随机地选取测试数据 B．取一切可能的输入数据作为测试数据 C．在完成编码后制定软件测试计划 D．选择发现错误可能性大的数据作为测试数据 10．( D )测试用例发现错误的能力较大。 A.路径覆盖 B.条件覆盖 C.判断覆盖 D.条件组合覆盖 11．软件需求分析应确定的是用户对软件的( A )。 A. 功能需求和非功能需求 B. 性能需求 C. 非功能需求 D. 功能需求 12．下列各种图可用于动态建模的有（ C ）。 A．用例图 B. 类图 C. 序列图 D. 包图 13．软件过程模型有瀑布模型、( B )、增量模型等。 A. 概念模型 B. 原型模型 C. 逻辑模型 D. 物理模型 14．面向对象的分析方法主要是建立三类模型，即( D )。 A. 系统模型、ER模型、应用模型 B. 对象模型、动态模型、应用模型 C. Ｅ-Ｒ模型、对象模型、功能模型 D. 对象模型、动态模型、功能模型 15．测试的分析方法是通过分析程序（ B ）来设计测试用例的方法。 A．应用范围 B.内部逻辑 C.功能 D.输入数据 16. 软件工程是研究软件( B )的一门工程学科。 A. 数学 B. 开发与管理 C. 运筹学 D. 工具 17. 需求分析可以使用许多工具，但（ C ）是不适合使用的。 A．数据流图 B.判定表 C.PAD图 D.数据字典 18．划分模块时，一个模块内聚性最好的是( A )。 A. 功能内聚 B. 过程内聚 C. 信息内聚 D. 逻辑内聚 19．软件可移植性是用来衡量软件的（ D ）的重要尺度之一。 A．效率 B. 质量 C. 人机关系 D. 通用性 20．软件配置管理是在软件的整个生存周期内管理（ D ）的一组活动。 A．程序 B.文档 C.变更 D.数据 二、判定题（20选10） 1统一过程是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。（×） 2当模块中所有成分结合起来完成一项任务，该模块的内聚是偶然内聚。（×） 3SD方法衡量模块结构质量的目标是模块间联系松散，模块内联系紧密（√） 4当模块中所有成分结合起来完成一项任务，该模块的内聚是功能内聚。（√） 5在进行需求分析时，就应该同时考虑软件的可维护性问题。（√） 6需求分析可以使用许多工具，但数据流图是不适合使用的。（×）
软件开发模型介绍与对比分析
常用的软件开发模型 任务的结构框 架。软件开发包括需求、设 段。 软件开发 模型能清晰、直观地表达软 计、编码和测试等阶段，有 时也包括维护阶 件开发全过程，明确规定了 要完成的主要活 动和任务，用来作为软 件项目工作的基础。对于不同的软件 系统，可以采用不同的开 理方法和手段 等，以及允许采用不同的软件工 具和不同的软件工程环境。 1. 瀑布模型 -最早出现的软件开发模型 1970 年温斯顿 ?罗伊斯( Winston Royce )提出了著名的 “瀑布模型 ”，直到 80 年 代早期，它一 直是唯一被广泛采用的软件开发 模型。 瀑布模型 核心思想是按工序将问题化简 ，将功能的实现与设计分开 ，便于分工协 作，即采 用结构化的分析与设计方法将逻 辑实现与物理实现分开。将 软件生命周期划 分为制定计划 、需求分析、软件设计、程序编写、软件测试和运行维 护等六个基本活 动，并 且规定了它们自上而下 、相互衔接的固定次序 ，如同瀑布流水，逐级 下落。从 本质来讲，它是一个软 件开发架构，开发过程是通过一系列 阶段顺序展开的，从系统 需求分析开始 直到产品发布和维护，每个阶段都会产 生循环反馈，因此，如果有信息 未被覆盖或者 发现了问题， 那么 最好 “返回 ”上一个 阶段并进行适当的修改 ，开发进程 从一个阶段 “流动 ”到下一个阶段， 这也是瀑布开发名称的由来。 瀑布模型是最 早出现的软件开发模型，在软件工程中占有重要的地位 ，它提供了 软件开发的基 本框架。其过程是从上一项 活动接收该项活动的工作对象作 为输入，利 用这一输入实 施该项活动应完成的内容给出该 项活动的工作成果， 并 作为输出传给下 一项活动。同 时评审该项活动的实施，若确认 ，则继续下一项活动；否则返 回前面， 甚至更前面的 活动。对于经常变化的项目而 言，瀑布模型毫无价值。(采用瀑布模型 的软件过程如 图所示) 软件 开发模型 (Software Development Model) 是指软件开发 全部过程、活动和 发方法、使用不同的程序设计语言以及各 种不同技能的人员参与工作 、运用不同的管
常见的软件开发模型
常见的软件开发模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。 1.软件开发模型是对软件过程的建模，即用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，好比工厂的流水线。 2.软件开发模型能清晰、直观地表达软件开发全部过程，明确规定要完成的主要活动和任务，它用来作为软件项目工作的基础。 3.软件开发模型应该是稳定和普遍适用的 软件开发模型的选择应根据： 1.项目和应用的特点 2.采用的方法和工具 3.需要控制和交付的特点 软件工程之软件开发模型类型 1.边做边改模型 2.瀑布模型 3.快速原型模型 4.增量模型 5.螺旋模型 6.喷泉模型 边做边改模型（Build-and-Fix Model） 国内许多软件公司都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改. 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改； （2）忽略需求环节，给软件开发带来很大的风险； （3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
瀑布模型（Waterfall Model） 1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子. 快速原型模型（Rapid Prototype Model） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。 快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。 增量模型（Incremental Model） 又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各
常见的软件质量模型
常见的软件质量模型 关于软件质量模型，业界已经有很多成熟的模型定义，比较常见的质量模型有McCall 模型、Boehm 模型、FURPS 模型、Dromey 模型和 ISO9126 模型。 ?Jim McCall 软件质量模型（1977 年） ?Barry W. Boehm 软件质量模型（1978 年） ?FURPS/FURPS+ 软件质量模型 ?R. Geoff Dromey 软件质量模型 ?ISO/IEC 9126 软件质量模型（1993 年） ?ISO/IEC 25010 软件质量模型（2011 年） Jim McCall 软件质量模型（1977 年） Jim McCall 的软件质量模型，也被称为 GE 模型（General Electrics Model）。其最初起源于美国空军，主要面向的是系统开发人员和系统开发过程。McCall 试图通过一系列的软件质量属性指标来弥补开发人员与最终用户之间的沟壑。 McCall 质量模型使用 3 中视角来定义和识别软件产品的质量： 1.Product revision (ability to change). 2.Product transition (adaptability to new environments). 3.Product operations (basic operational characteristics).
McCall 模型通过层级的要素、标准和指标来详述这 3 个视角定义（产品修改、产品转移、产品运行）。 ?11 Factors (To specify)：描述软件的外部视角，也就是客户或使用者的视角。 ?23 Criterias (To build)：描述软件的内部视角，也就是开发人员的视角。 ?Metrics (To control)：定义衡量指标和方法 下图中，左侧为 11 个质量要素，右侧为 23 个质量标准。
常用软件开发模型比较分析
常用软件开发模型比较分析 2007-09-26 20:21 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③ 以形式化开发方法为基础的变换模型（T ransformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。
图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下且呈线性图式的，因此瀑布模型存在严重的缺陷。 ① 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。 ② 在软件开发前期末发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。 ③ 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。 1.2.2 螺旋模型螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这
软件开发模型的优缺点和适用范围
软件开发模型的优缺点和适用范围 软件开发模型大体上可以分为三种类型。第一种是以软件需求完全确定为前提的瀑布模型；第二种是在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如原型模型、 螺旋模型等；第三种是以形式化开发方法为基础的的变换模型。时间中经常将几种模型组合使用， 以便充分利用各种模型的优点。 1. 瀑布模型 瀑布模型也称软件生存周期模型。它在软件工程中占有重要地位，它提供了软件开发的基本框架，这比依靠“个人技艺”开发软件好得多。它有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。 瀑布模型的缺点：一是个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；二是由于开发模型是线性的用户只有等到整个过程的末期才能见到开发成果，从而卡增加了开发的风险；三是早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重后果。 2. 原型模型 原型模型的主要思想：先借用已有系统作为原型模型，通过“样品”不断改进， 使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反 馈，使开发出的软件能够真正反映用户的需求。 原型模型的特点：开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。缩短了开发周期，加快了工程进度。降低成本。 原型模型的缺点：当告诉用户，还必须重新生产该产品时，用户是很难接受的。 这往往给工程继续开展带来不利因素。不宜利用原型系统作为最终产品。 3. 螺旋模型 螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版 本。 螺旋模型的优点： 1）设计上的灵活性，可以在项目的各个阶段进行变更。 2）以小的分段来构建大型系统，使成本计算变得简单容易。 3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向及项目的可控性。 4）随着项目推进，客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。 5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
常见软件开发模型
常见软件开发模型 模型优点缺点 瀑布模型文档驱动系统可能不满足客户的需求 快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于 维护 增量模型开发早期反馈及时，易于维护需要开放式体系结构，可能会设计差、 效率低 螺旋模型风险驱动风险分析人员需要有经验且经过充分 训练 瀑布模型(Waterfall Model ) 1970年Winston Royce 提岀了著名的“瀑布模型“，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型中，如图所示，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、
软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如 同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，开发的风 从而增加了险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 快速原型模型（Rapid Prototype Model ） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么； 第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速 原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真 正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速 建立原型，随之迅速修改原型，以反映客户的需求。
!软件工程练习题3
一、选择题 1.软件是一种（）产品。 A．有形 B.逻辑C．物质 D.消耗 2.与计算机科学的理论研究不同，软件工程是一门（） A．理论性B．工程性C．原理性D．心理性 3.软件工程学科出现的主要原因是（） A．计算机的发展B．其他工程学科的影响力 C．软件危机的出现D．程序设计方法学的影响 4.软件生存周期模型有多种，下列选项中，（）不是软件生存周期的模型。 A．螺旋模型B．增量模型C．功能模型D．瀑布模型 5.软件开发模型是指软件开发的全部过程、活动和任务的结构框架。主要的开发模型有瀑布模型、 演化模型、螺旋模型和喷泉模型。螺旋模型将瀑布模型和演化模型相结合，并增加了[A ]，它建立在[B ]的基础上，沿着螺线自内向外每旋转一圈，就得到[B ]的一个版本。喷泉模型描述了[C ]的开发模型，它体现了这种开发方法创建软件的过程所固有的[D ]和 [E ]的特征。 供选择的答案： A：（1）系统工程（2）风险分析（3）设计评审（4）进度控制 B：（1）模块划分（2）子程序分解（3）设计（4）原型 C：（1）面向对象（2）面向数据流（3）面向数据结构（4）面向事件驱动 D：（1）归纳（2）推理（3）迭代（4）递归 E：（1）开发各阶段之间无“间隙”（2）开发各阶段分界明显（3）部分开发阶段分界明显（4）开发过程不分阶段 您的选择是: 【A 】【B 】【C 】【D 】【E 】 6.目前存在若干种软件生存周期模型，例如瀑布模型、增量模型、螺旋模型等。其中规定了由前至 后、相互衔接的固定次序的模型是（） A．瀑布模型B．增量模型C．螺旋模型D．喷泉模型 7.软件生命周期包括可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、（）维 护等活动。 A．应用B．测试C．检测D．以上都是 8.准确地解决“软件系统必须做什么”是（）阶段的任务。 A．分析阶段B．设计阶段C．编码阶段D．测试阶段 9.研究开发所需要的成本和资源是属于可行性研究中的（）研究的一方面。 A.技术可行性 B. 经济可行性 C. 社会可行性 D. 法律可行性 10.需求分析（）。【】 A．要回答“软件必须做什么”B．可概括为“理解、分析、表达”六个字 C．要求编写需求规格说明书D．以上都对 11.瀑布模型中软件生命周期划分为八个阶段：问题定义、可行性研究、需求分析、总体设计、详细 设计、编码、测试和运行、维护。这八个阶段又可归纳为三个大的阶段：计划阶段、开发阶段和（）阶段。
常用软件开发模型
常用软件开发模型比较分析 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ①以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ②在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③以形式化开发方法为基础的变换模型（Transformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型 瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。 图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，
常用软件开发模型比较分析
1.2 常用软件开发模型比较分析 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（S piral Model）。 ③ 以形式化开发方法为基础的变换模型（Transformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型 瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。
空间维： 把MIS的实体（系统）划分为若干个子系统。按垂直方向如分解为战略决策与计划，管理控制和执行处理三个层次；再按水平方向分解，如划分为：生产管理，材料管理，财会管理等子系统。 常用方法： 把系统按空间维分成若干个子系统，分期开发子系统，子系统的开发再遵循时间维的分解，按开发工程分步骤开发。 1.2.2 螺旋模型 螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如图1-4所示。 图1-4 采用螺旋模型的软件过程 螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。 螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，
软件开发过程规范
软件开发过程规范 版本 <1.0> 修订历史纪录
目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (3) 2.技术过程规范部分 (3) 2.1 概述 (3) 2.2 业务建模阶段 (4) 2.3 需求阶段 (5) 2.4 分析设计阶段 (6) 2.5 实现阶段 (7) 3.管理过程规范部分 (7) 3.1 概述 (7) 3.2 接受项目 (8) 3.3 重新评估项目范围和风险（对于较大项目） (8) 3.4 制定开发计划 (8) 3.5 迭代开发管理 (9) 3.6 监控项目的实施 (9) 3.7 结束项目 (10)
软件开发过程规范 1. 前言 1.1 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 1.2 对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 1.3 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 1.4 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 1.5 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。 1.6 开发过程划分 开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求建模；而后的迭代则侧重于分析设计和编码。 2. 技术过程规范部分 2.1 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。
软件过程模型的优缺点对比
软件过程模型的比较 瀑布模型 瀑布模型（经典生命周期）提出了软件开发的系统化的、顺序的方法。其流程从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。 优点： 1. 强调开发的阶段性，各阶段具有顺序性和依赖性 2. 强调早期调研和需求分析，推迟编码实现的观点 3. 提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导 缺点： 1. 文档驱动，用户无法及时了解产品的情况 2. 依赖早期调研和需求分析，很难适应在许多项目开始阶段必然存在的不确定 性。 3. 流程单一，必须要完成前一阶段的任务，才能进行下一阶段，开发过程中的 成功经验无法用于本产品。 4. 测试在后期引入，对于系统存在的重大缺陷，如果在可执行程序评审之前没 有被发现，将可能造成重大损失。 5. 组织庞大，人员闲置。 适用范围：需求确定，工作能够采用线性的方式完成的软件。 增量过程模型 增量过程模型包括增量模型、RAD 模型。 （一）增量模型增量过程模型以迭代的方式运用瀑布模型，把软件产品作为一系列的增量构 件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量往往是核心功能。 优点： 1.能在较短的时间内向用户提交可完成部分工作的产品。 2.逐步增加产品功能可以使用户有充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。 3. 规避技术风险 4. 可并行开发构件，加快开发的进度 缺点：
1. 没有考虑软件的整体质量和长期的可维护性。 2. 大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工 具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。 3. 由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计 适用范围：项目在既定的商业要求期限之前不可能找到足够的开发人员； （二）RAD 模型 RAD 模型是一种侧重于短暂的开发周期的增量软件过程模型，它是瀑布模型的“高速”变体，通过基于构建的构建方法实现快速开发。开发团队能够在非常短的时间内创造出“全功能系统” 优点： 1．开发速度快，质量有保证。 2．对信息系统特别有效。 缺点： 1. 对于大型的可伸缩的项目，RAD 需要大量的人力资源来创建多个相对的独立 的RAD 团队 2. 如果开发者和用户没有为短时间内急速完成整个系统做好准备，RAD 项目将 会失败。 3. 如果一个系统不能合理的模块化，RAD 构件建立会有很多问题。 4. 如果系统需求是高性能，并且需要通过调整构件接口的方式来提高性能，不 能采用RAD 模型 5. 技术风险很高的情况下 适用范围：1、不适合技术风险很高的开发，不适合系统需求是高性能，并且需要通过调整构件接口的方式来提高性能的产品开发。 2、适用于工期紧张，又可细分功能，还要有合适的构件 演化过程模型 演化过程模型包括原型开发，螺旋模型，协同开发模型。 （一）原型开发从需求收集开始，开发者和客户在一起定义软件的总体目标，标识已知的需 求并且规划出需要进一步定义的区域。然后是“快速设计”，它集中于软件中那些对客户可见的部分的表示，这将导致原型的创建，并由客户评估并进一步精化待开发软件的需求。逐步调整原型使其满足客户的需求，这个过程是迭代的。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统（虽然这个系统不带有任何质量的保证），所以客户和开发者都比较喜欢这种过程模型（对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质
软件工程复习资料整理
第一章软件工程介绍 软件工程的概念 IEEE对软件工程的定义: （1）将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。 （2）在（1）中所述方法的研究。 过程、方法和工具 过程：为了获取高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 方法：各项任务的技术方法，回答“怎么做”的问题。 工具：为运用方法而提供的自动或半自动的软件工程支撑环境 软件工程层次图 软件危机与软件工程的关系、产生的原因及其表现 软件工程的提出： 软件工程主要是针对20世纪60年代的软件危机而提出的 软件危机定义：软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 产生软件危机的原因： 客观原因： 软件缺乏“可见性”，管理和控制其开发过程相对困难 软件大多规模庞大，而复杂性随规模以指数速度上升 主观原因： 错误的认识和做法 忽视软件需求分析的重要性—急于求成，仓促上阵 认为软件开发就是写程序—编程只占全部工作量的10%--20%，软件配置主要包括程序、文档和数据 轻视软件维护—维护费用占总费用的55%--70%
软件神话一些错误认识 管理神话： 我们已经有了一本写满软件开发标准和规程的宝典。它无所不包，囊括了我们可能问到的所有问题 如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度 如果将一个软件外包给另一家公司，则我们可以完全放手不管。 用户神话： 有了对项目目标的大概了解，便足以开始编写程序，我们可以在之后的项目开发过程中逐步了解细节。 虽然项目需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变化从业者神话： 当我们完成程序并将其交付使用之后，我们的任务就完成了。 直到程序开始运行，才能评估其质量 对于一个成功的软件项目，可执行程序是惟一可交付的成果。 软件工程将导致我们产生大量无用文档，并因此降低工作效率。 第二章过程模型 掌握五个最基本的框架活动： 将整个软件过程再进一步细分为各个相对独立的功能块，即过程框架。（以工作开展的时间为线索）。 五个最基本的框架活动： 沟通：与客户之间的交流与写作 策划：为后续的软件工程工作制定计划 建模：包括分析和设计 构建：编码和测试 部署：软件交付用户，用户对其进行评估并反馈意见。 了解典型的普适性活动 适用于任何一个框架活动： 软件项目跟踪和控制；风险管理；软件质量保证；正式技术评审；测量；软件配置管理；可复用管理；工作产品的准备和生产