软件工程 (8)
软件工程 第八章 面向对象的设计方法
第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。
如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
为完成这一转换过程，设计人员必须处理以下任务：（1）针对分析模型中的用例，设计实现方案。
实现方案用UML交互图表示。
（2）设计技术支撑设施。
在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。
这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。
例如，数据的持久存储服务、安全控制服务和远程访问服务等。
在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。
（3）设计用户界面。
（4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。
此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。
面向对象的软件设计过程如图8-1-1所示。
图8-1-1 面向对象的软件设计过程第一节设计用例实现方案UML 的交互图（顺序图、协作图）适于用例实现方案的表示。
因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。
该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。
一、顺序图顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。
在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。
顺序图中的对象一般以“对象名：类名”的方式标识，但也可以仅采用缩写形式“对象名”或者“：类名”。
软件工程自考题模拟8
软件工程自考题模拟8(总分：100.00，做题时间：90分钟)一、单项选择题(总题数：20，分数：40.00)1.下列关于需求规约的作用说法错误的是______（分数：2.00）A.需求规约是软件开发者和客户之间一份相关的技术合同书√B.对于项目的其余大多数工作，需求规约是一个管理控制点C.对于产品/系统的设计，需求规约是一个正式的，受控的起始点D.需求规约是创建产品验收测试计划和用户指南的基础解析：[考点] 本题主要考查的知识点为需求规约的作用。
需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现，并不是客户与开发者之间的相关技术合同。
2.下列描述中，不属于程序流程图优点的是______（分数：2.00）A.历史最悠久，使用最广泛B.容易表示数据结构√C.支持程序的三种基本控制结构D.直观清晰，易于使用解析：[考点] 本题主要考查的知识点为程序流程图。
程序流程图是一种历史最悠久，使用最广泛的设计工具，对控制流程的描绘直观，便于初学者掌握。
在程序流程图中，使用顺序、选择和循环三种基本控制结构。
但是它不是一种逐步求精的工具，也不易表示数据结构。
3.数据字典是软件需求分析阶段所采用的最重要工具之一，其最基本的功能是______（分数：2.00）A.数据定义√B.数据通讯C.数据库设计D.数据维护解析：4.以下说法错误的是______（分数：2.00）A.组合是聚合的一种特殊形式B.在一个组合中，一个链所连接的对象构成的任何元组，必须都属于同一个整体类的对象C.在一个组合中，组合末端的多重性可以超过1 √D.如果整体类的实例和部分类的实例具有相同的生命周期，那么这样的聚合称为组合解析：5.不属于在单元测试期间需要考虑的模块特征的是______（分数：2.00）A.模块接口B.局部数据结构C.重要的执行路径D.测试用例√解析：6.调试的目的是为了______（分数：2.00）A.证明软件符合设计要求√B.发现软件中的错误和缺陷C.改善软件的功能和性能D.发掘软件的潜在能力解析：[考点] 本题主要考查的知识点为调试。
软件工程课件之第8章维护第6版张海潘编著
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例
软件工程心得体会8篇
软件工程心得体会8篇（经典版）编制人：__________________审核人：__________________审批人：__________________编制单位：__________________编制时间：____年____月____日序言下载提示：该文档是本店铺精心编制而成的，希望大家下载后，能够帮助大家解决实际问题。
文档下载后可定制修改，请根据实际需要进行调整和使用，谢谢!并且，本店铺为大家提供各种类型的经典范文，如工作总结、工作计划、调研报告、演讲致辞、合同协议、条据文书、规章制度、教学资料、作文大全、其他范文等等，想了解不同范文格式和写法，敬请关注!Download tips: This document is carefully compiled by this editor. I hope that after you download it, it can help you solve practical problems. The document can be customized and modified after downloading, please adjust and use it according to actual needs, thank you!Moreover, our store provides various types of classic sample essays, such as work summaries, work plans, research reports, speeches, contract agreements, documents, rules and regulations, teaching materials, complete essays, and other sample essays. If you would like to learn about different sample formats and writing methods, please pay attention!软件工程心得体会8篇心得体会让我明白了自我反思的重要性，只有不断反思才能不断进步，生活是一本永不停歇的教科书，在其中我们可以通过不断的尝试和反思，积累丰富的心得体会，本店铺今天就为您带来了软件工程心得体会8篇，相信一定会对你有所帮助。
软件工程课件(全)
03
识别项目中的关键路径，确保项目按计划进 行
04
及时调整项目计划，应对项目变更和不确定 性
风险管理策略制定
识别项目中的潜在风险， 包括技术风险、市场风险、 资源风险等
制定相应的风险应对策略 和措施，如风险规避、减 轻、转移和接受等
评估风险的概率和影响程 度，制定风险优先级列表
监控风险状态，及时调整 风险管理计划
质量改进
根据质量评估结果，制定相应的改进措施， 如优化性能、增强安全性等。
经验教训总结
对测试过程中遇到的问题进行总结，形成经 验教训，为后续项目提供参考。
06
项目管理与团队协作
项目计划制定与监控
01 制定详细的项目计划，包括项目目标、范围 、时间表、资源需求、成本估算等
02 设立项目里程碑，对项目进度进行阶段性监 控
开发方向。
持续集成和测试
03
迭代增量模型强调持续集成和测试的重要性，以确保每个迭代
周期都能交付高质量的软件产品。
03
需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领 域专家等进行沟通，收集原始
需求。
需求分类
将收集到的需求按照功能、性 能、安全、易用性等方面进行 分类。
需求筛选
去除重复、模糊、不切实际的 需求，确保需求的准确性和可 行性。
处理变更请求
根据实际情况，决定是否接受变更请求，并 制定相应的实施计划。
跟踪和验证变更
对实施的变更进行跟踪和验证，确保变更的 正确性和完整性。
04
系统设计与实现
系统架构设计
分层架构
将系统划分为表示层、业务逻辑层和数据访问层，实现高内聚、 低耦合的设计。
软件工程 第8章 软件维护
8.4.2 软件可维护性的度量
3. 可测试性 4. 可修改性 5. 可移植性 6. 效率 7. 可使用性 8. 间接度量可维护性的方法
8.4.2 软件可维护性的度量
8. 间接度量可维护性的方法
(1) 了解问题的时间； (2) 行政管理拖延的时间； (3) 收集维护工具的时间； (4) 分析问题的时间； (5) 改变规格说明的时间； (6) 具体的改错或修改的时间； (7) 局部测试时间； (8) 整体测试时间； (9) 维护重审时间； (10) 总体恢复时间。
8.4 软件的可维护性
8.4.1 影响可维护性的因素 软件的可维护性可以简单定义为：纠正软件系统出现 的错误和缺陷,以满足新的要求, 能够被理解、被校正、 被修改或被改善的难易程度。可维护性不但与采用的 分析设计方法和开发人员的技术熟练程度有关，更重 要的是与软件项目的管理技术关系密切。软件的可维 护性成为软件开发阶段各个时期的关键目标。
8.1 软件维护的种类
完善性维护 50％
预防性维护5％
改正性维护 20％
适应性维护 25％
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明，有代表性的软件开发组织用于校正性 维护、适应性维护、完善性维护及预防性维护的费用 占其开发总金额的70％至80％。 很多软件机构被束缚在维护工作上，这是软件维护所 带来的无形支出。
8.2.3 非结构化维护
无说明或者文档资料太少由于没有采用定义良好的软 件项目管理过程来开发软件，软件项目管理的缺陷导 致的叫“非结构化维护”,这会使软件维护付出较高的 代价.
8.2.4 结构化维护
存在完整的软件系列文档，那么维护任务就从分析设 计文件开始，确定软件的重要结构特性、功能特性和 接口特性，确定所要求的修改或校正可能产生的影响， 并且计划采用何种维护处理方法，修改设计并进行复 审，编制出新的源程序，利用文档中的信息进行回归 测试，然后重新交付软件。这种维护过程就叫做“结 构化维护”
软件工程第8章详细设计
WHILE Q
F
G N
例2:以下是两个程序流程图，试用PAD图表示。
开始 在工资档案中读一条记录
是文件结束位置吗?Y
N 计 算 工 资 档 案 各 项 基 本 数 据 之 和 并 存 入 pay
num ＝ 当 前 职 工 号
在 奖 金 发 放 表 中 查 找 职 工 号 与 num 相 同 的 记 录
五种基本控制结构：
示例
程序流程图的规定符号
1）顺序型结构 顺序结构由带箭头的控制线依次连接几个处理方框构成。
处理1 处理2 处理n
…
例题
2） 选择型结构 选择型结构是流程图中最为常用的结构，其结构构造有两种，一种是条件选择结构又称为IF-
THEN-ELSE结构，使用菱形表现逻辑判定条件，条件结果决定选择两个处理方框中的一个。
种条件组合相对应的动作。
所有条件
条件组合矩阵
所有可能的 动作列表
与每种条件组合 所对应的动作表
国内乘客 头等舱 残疾乘客 行李≤30kg
免费 (W-30)*2 (W-30)*3 (W-30)*4 (W-30)*6 (W-30)*8 (W-30)*12
TTTTFFFF
TFTFTFTF
FFTTFFTT
TF F F F F F F F
找到了吗?
N
显示错误
Y 计 算 各 项 奖 金 总 和 并 存 入 bonus
应 发 工 资 ＝ pay＋ bonus
读下一条记录
结束
在工资档案中读一条记录
是文件结束位置吗?
计 算 工 资 各 项 基 本 数 据 之 和 并 存 入 pay
num ＝ 当 前 职 工 号
在 奖 金 表 中 查 职 工 号 与 num 相 同 的 记 录
软件工程名词解释
1．软件测试(第8 章) 2．静态测试(第8 章) 3．动态测试(第8 章) 4．黑盒测试(第8 章) 5．白盒测试(第8 章) 6．语句覆盖(第6 章) 7．判定覆盖(第6 章) 8．条件覆盖(第6 章) 9．判定/条件覆盖(第6 章) 10．条件组合覆盖(第6 章) 11．路径覆盖(第6 章) 12．测试用例(第8 章) 13．驱动模块(第6 章) 14．桩模块(第6 章) 15．单元测试(第8 章) 16．集成测试(第8 章) 17．确认测试(第8 章) 18．渐增式测试(第8 章) 19．非渐增式测试(第8 章) 20．调试(第9 章) 21．人的因素的含义(第11 章) 22．基线(第12 章) 23．软件配置管理(第12 章24．软件配置项(第12 章) 25. 软件概要设计(第5 章) 26. 模块(第5 章) 27. 模块化(第5 章) 28. 抽象(第5 章) 29. 信息隐蔽(第5 章) 30. 模块独立性(第5 章) 31. 耦合性(第5 章) 32. 无直接耦合(第5 章) 33. 数据耦合(第5 章) 34. 标记耦合(第5 章) 35. 控制耦合(第5 章) 36. 公共耦合(第5 章) 37. 内容耦合(第5 章) 38. 内聚性(第5 章) 39. 偶然内聚(第5 章) 40. 逻辑内聚(第5 章) 41. 时间内聚(第5 章) 42. 通信内聚(第5 章) 43. 顺序内聚(第5 章) 44. 功能内聚(第5 章) 45. 软件结构图(第5 章) 46. 结构化设计(第5 章) 47. 变换流(第6 章) 48. 事务流(第6 章) 49. JSP (第6 章) 50. JSD (第6 章)答案：1. 软件测试指为了发现软件中的错误而执行软件的过程。
它的目标是尽可能多地发现软件中存在的错误，将测试结果作为纠错的依据。
2. 静态测试指被测试的程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
《软件工程》判断题汇总及答案
判断题：1.软件就是程序，编写软件的关键是编写程序。
2.可行性研究阶段要进行一次大大压缩简化了的系统分析和设计的过程。
3.需求管理主要是对需求变化的管理，及如何有效控制和适应需求的变化。
4.数据流图表示了软件系统对数据的算法处理过程，即系统的物理模型。
5.需求分析的主要方法有SD法、OOA法及HIPO法等。
6.没有Do-case、Do-until形结构，就不能实现某些结构化程序，从而降低了程序的运行效率。
7.用面向对象方法分析、设计、实现软件，仍属线性的瀑布开发模型。
8.文档是影响软件可维护性的决定因素。
9.软件是指用程序设计语言（如PASCAL ,C,VISUAL BASIC 等）编写的程序，软件开发实际上就是编写程序代码。
10. 软件模块之间的耦合性越弱越好。
11. 软件开发小组的组成人员的素质应该好，而人数则不宜过多。
12. 总体设计的基本目的就是回答："概括地说，系统应该如何实现？"这个问题。
13. 文档只起备忘录的作用，可以在软件开发完成后再整理生成。
14. 结构化软件开发的方法的工作模型是螺旋模型。
15. 总体设计的基本目的就是回答："概括地说，系统应该如何实现？"这个问题。
16. 瀑布模型的最大优点是将软件开发的各个阶段划分得十分清晰。
1．N 2.Y 3. Y 4.N 5.N 6.Y 7.N 8.Y9.N 10.Y 11.Y 12. Y 13. N 14.N 15.Y 16.Y判断题：1.在面向对象的软件开发方法中，每个类都存在其相应的对象，类是对象的实例，对象是生成类的模板。
2.过程描述语言可以用于描述软件的系统结构。
3.继承性是父类和子类之间共享数据结构和消息的机制，这是类之间的一种关系。
4.快速原型模型可以有效地适应用户需求的动态变化。
5.在面向对象的需求分析方法中，建立动态模型是最主要的任务。
6.集成测试主要由用户来完成。
7.确认测试计划应该在可行性研究阶段制定8.白盒测试无需考虑模块内部的执行过程和程序结构，只要了解模块的功能即可。
软件工程概论_8_面向对象需求分析
• 一.面向对象分析模型的组成结构 • 二.面向对象分析模型描述工具 • 三.面向对象分析的基本过程
• 四. 面向对象分析方法
• 五. 小结
一.面向对象分析模型的组成结构
数据模型
属性、操作、协作者
功能模型
类/对象 模型
对象关系模型
使用实例
对象-行为模型
行为模型
二.面向对象分析模型描述工具
1. 用例图
2．面向对象建模 （1）建模与模型 建模是将问题域的解空间定义成一种模型，以帮助系统分析 人员更好地理解问题。 模型是为了理解问题而对问题所做出的一种抽象，而且是对 问题的一种无歧义的描述。模型由一组图示符号和组织这些 符号的规则组成。利用它们来定义和描述问题域中的术语和 概念。 建模的目的主要是为了减少复杂性。 （2）面向对象模型
2) 面向对象分析的五个层次 面向对象分析由五个主要活动组成，即确定类-＆-对象、识别 结构、识别主题、定义属性和定义服务(方法)。对于一个复杂 问题的面向对象的模型可用五个层次表示：类-＆-对象层、结 构层，主题层、属性层和服务层，见图3.3.8。
主题层 subject level 类-＆-对象层object 结构层 structure 属性层 attribute 服务层 serves
•使用具有确切含义的名词。
• 尽量使用能表示类的含义的日常用语作名字，不要使用空洞的或含 义模糊的词作名字。例如，“库房”比“房屋”或“存物场所”更确切。
•必要时用名词短语作名字。
• 为使名字的含义更准确，必要时用形容词加名词或其他形式的名词 短语作名字。例如，“最小的领土单元”、“储藏室”、“公司员工”等 都是比较恰当的名字。
签定保险单 销售统计
客户
软件工程随堂练习(习题)
软件工程随堂练习一、选择题1.软件工程是（）。
A、是结构化程序设计的指导方法B、是软件开发技术和软件工程管理学为内容的学科C、是指导计算机软件开发和维护的工程学科D、是指导软件开发的工程方法。
2.软件工程中的各种方法是完成软件工程项目的技术手段，它们支持软件工程的（）阶段。
A.各个B. 前期C.中期D.后期3.原型方法是用户和设计者之间的一种交互过程，选用于（）系统。
A. 需求确定的B. 需求不确定性较高的C. 管理信息D. 决策支持4.要将一个复杂的系统分析清楚，常用方法是结构化分析方法，结构化分析方法就是（）。
A、面向数据流自顶向下逐步求精的方法B、由内向外进行分析的方法C、先局部后整体的分析方法D、使用IPO图形工具分析的方法5.概要设计过程是（）A. 先确定系统的实现方案，然后在结构设计阶段中确定软件的模块结构B. 确定软件的模块结构，再设计出系统的所有程序和数据文件C. 设计出系统的HIPO 图并对所有模块进行描述D. 规划出系统的后期设计总体结构6.程序的三种基本结构是（）。
A、过程，子程序，分程序B、顺序，选择，循环C、递归，堆栈，队列D、调用，返回，转移7.结构化程序设计的一种基本方法是（）。
A、筛选法B、递归法C、归纳法D、逐步求精法8.软件维护的四类维护活动是：（）A.改正性维护，适应性维护，完善性维护和预防性维护。
B.适应性维护，完善性维护，抢救性维护和辅助性维护。
C.改正性维护，适应性维护，完善性维护和辅助性维护。
D.适应性维护，完善性维护，抢救性维护和预防性维护。
9.软件开发瀑布模型中的软件定义时期各个阶段依次是：（）A.可行性研究，问题定义，需求分析。
B.问题定义，可行性研究，需求分析。
D.以上顺序都不对。
10.在软件生存周期中，工作量所占比例最大的阶段是( )阶段。
A．需求分析 B．设计 C．测试 D．维护11.一个软件产品开发完成投入使用后，常常由于各种原因需要对它做适当的变更，通常把软件交付使用后所做的变更称为( )。
《软件工程》试题及参考答案(第8套)
电计系软件工程专业20 –20 学年度期《软件工程》试题(第8套)第一部分选择题一、单项选择题（本大题共20小题，每小题1分，共20分）在每小题列出的四个备选项中只有一个是符合题目要求的，请将其代码填写在题后的括号内。
错选、多选或未选均无分。
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、软件生命周期中所花费用最多的阶段是(D)A、详细设计B、软件编码C、软件测试D、软件维护8、因计算机硬件和软件环境的变化而作出的修改软件的过程称为 ( )A.校正性维护B.适应性维护C.完善性维护D.预防性维护9、一个模块内部各程序都在同一数据结构上操作，这个模块的内聚性称为( ) 。
A、时间内聚B、功能内聚C、信息内聚D、过程内聚10、结构化设计又称为( )A、概要设计B、面向数据流设计C、面向对象设计C、详细设计11. 协作图反映收发消息的对象的结构组织，它与（）是同构的。
A 用例图B 类图C 活动图D 时序图12.黑盒测试在设计测试用例时，主要需要研究( )A.需求规格说明与概要设计说明B.详细设计说明C.项目开发计划D.概要设计说明与详细设计说明13.CMM提供了一个框架，将软件过程改进的进化步骤组织成5个成熟度等级。
软件工程导论 第8章 维护
应该注意，上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。
软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
8．1 软件维护的定义
所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。 因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。
8．2 软件维护的特点
8．2．1 结构化维护与非结构化维护差别巨大
1.非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。
软件工程吴迪第八章课后答案
软件工程吴迪第八章课后答案HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】软件工程课后答案《软件工程》作业及答案1-1什么是软件危机?它有哪些典型表现?为什么会出现软件危机?答:软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。
软件危机典型表现：对软件开发成本和进度的估计常常很不准确。
用户对“已完成的”软件系统不满意的现象经常发生。
软件产品的质量往往靠不住。
软件常常是不可维护的。
软件通常没有适当的文档资料。
软件成本在计算机系统总成本中所占的比例逐年上升。
软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
产生软件危机的原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。
软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。
管理和控制软件开发过程相当困难。
软件是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
目前相当多的软件专业人员对软件开发和维护还有不省糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这是使软件问题发展成软件危机的主要原因。
1-2假设你是一家软件公司的总工程师，当你把图给手下的软件工程师们观看，告诉他们及早发现并改正错误的重要性时，有人不同意你的观点，认为要求在错误进入软件之前就清除它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢?”你怎么反驳他?1-3什么是软件工程?它有哪些本质特性?怎样用软件工程消除软件危机?答:软件工程是指导计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。
《软件工程》第八章 软件维护与再工程
软件可维护性－主要影响因素
可移植性：指程序转移到一个新的计算环境的难易 程度。
影响软件可移植性的因素有：信息隐蔽原则；模块 独立；模块化；高内聚低耦合；良好的程序结构； 不用标准文本以外的语句等
一个可移植的程序应具有结构良好、灵活、不依赖 于某பைடு நூலகம்具体计算机或操作系统的性能
软件可维护性－主要影响因素
软件维护的概念－维护成本
其它一些因素：如应用的类型、数学模型、 任务的难度、IF嵌套深度、索引或下标数等， 对维护工作量也有影响
软件维护的过程－维护组织
维护组织结构图
软件维护的过程－维护组织
系统监督员一般都是对程序(某一部分)特别熟 悉的技术人员。 在维护人员对程序进行修改的过程中，由配 置管理员严格把关，控制修改的范围，对软 件配置进行审计 。 维护管理员、系统监督员、修改控制决策机 构等，均代表维护工作的某个职责范围 。
如果已经开始保存维护记录，可以对维护工作做 一些定量度量，至少可以从如下7方面进行评价：
每次程序运行平均失败的次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所必需的程序 变动数； 维护过程中增加或删除源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护请求表的平均周转时间； 不同维护类型所占的比例；
软件维护的过程－维护记录
软件修改报告指明：为满足维护申请报告提 出的需求所需的工作量、本次维护活动的类 别、本次维护请求的优先级、本次修改的背 景数据。在拟定进一步维护计划前，软件修 改报告要提交给修改决策机构，供进一步规 划维护活动使用 保存维护记录的第一个问题就是哪些数据值 得保存？
软件维护的过程－维护评价
软件维护的概念－维护问题
(科创学院) 自考综合题 复习使用 软件工程复习题第八章
重庆科创职业学院历年真题/综合题（仅供复习）软件工程复习题(第八章)一、选择题1.CMMI是一个过程改善框架，其关注相应的质量支撑点，来帮助组织开发和维护相应的产品和服务，从而提高质量。
下列选项中，哪一项不是质量支撑点。
【D】A.人员B.规程和方法C.工具D.技术二、填空题1.所谓过程改善，是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果。
2.CMMI是由一些过程域组成，过程域有自己的专用目标和共用目标，每个专用目标和共用目标都有包括相应的专用实践和共同实践，每个专有实践中有典型工作产品和子实践，每个共同实践中，也有自己子实践和共用实践的精化。
3.CMMI模型中，共有22个过程域，分为四类，分别是：项目管理类、工程类、支持类、过程管理类。
4.为了改善开发过程和维护过程的组织，CMMI引入了两种类型的”等级”一个称为能力等级、另一个称为成熟度等级5.CMMI中，针对每一个过程域设定了6个能力等级分别是：0级：未完成级、1级：已执行级、2级：已管理级、3级：已定义级、4级：已定量管理级、5级：持续优化级。
6.所谓成熟度等级，是指达到预先定义的一组过程域所有目标的一种过程改善等级。
由预先定义的一个过程域集及其相关的一些专用实践和共用实践组成7.在CMMI中，应用于一个组织过程改善的成熟度等级有5个，分别是：1级：初始级，2级：已管理级、3级：已定义级、4级：已定量管理级、5级：持续优化级。
8.成熟度等级是用于表征组织对一组过程域的改进，而能力等级是用于表征组织对单个过程域的改进9.三、简答题1.简述CMMI模型的模型部件及部件间的关系2.简述能力等级与成熟度等级之间的区别与联系3.简述专用实践与共用实践的关系。
软件工程(第四版)习题及解答9-8
第1章
一、判断题
1× 2 √ 3× 4√ 5× 6√ 7√ 8× 9√10×
二、选择题
1-5CADDD6-10ADAAD11-15AAADA
三、简答题
1、软件包括程序、数据及其相关文档的完整集合。其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能够正确地处理信息的数据结构；文档是与程序开发、维护和使用有关的图文资料。软件包括程序,程序只是软件的一部分。
1、
“学生管理系统”的顶层图案={学号+姓名+性别+年龄+专业+班级}
成绩库=学号+课程号+分数
课程库=课程号+课程名+学分
学生信息=学号+姓名+性别+年龄+专业+班级
考试成绩=学号+课程号+分数
学号=”00001”...”99999”
姓名=2{汉字}4
系统目标和范围说明书
1．项目名称：X航运公司机票预订系统。
2．背景：目前，由旅客人工到航运公司排队购票，费时、费力、管理工作量大、手续繁琐效率低，制约了公司业务的发展。
3．项目目标：建立一个网络化的机票预订系统。
4．项目范围：软件开发费用不超过X万元。
5．初步设想：建议在系统中完成安排航班、打印取票通知、打印票务账单、打印机票等主要功能。
（3）系统流程图
第3章
一、判断题
1√ 2 × 3√ 4 × 5√ 6× 7× 8√
二、选择题
1-5 BACDB 6-10 ABDAA 11-15 BABDB 16-20 ADCDB
三、简答题
1、需求分析的基本任务是要准确地理解旧系统、定义新系统的目标，为了满足用户需要，回答“系统必须做什么”的问题，即确定系统必须完成哪些工作，对新系统提出完整、准确、清晰、具体的要求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第8章 用例驱动
8.1 用例驱动开发概述 8.2 为什么使用用例 8.3 确定客户需要什么 8.4 需求工作流 8.5 领域模型 8.6 业务模型 8.7 补充需求 8.8 初始需求 8.9 初始需求：考勤系统实例研究 8.10 继续需求流：考勤系统实例研究 8.11 修订需求：考勤系统实例研究 8.12 测试工作流：考勤系统实例研究 8.13 需求规格说明书 8.14 小结 习题８
第8章 用例驱动
知识点 需求工作流，领域模型，业务模型，建模技术。
难点 如何将理论与实践结合。
基于工作过程的教学任务 通过本章学习，了解为什么使用用例，学习用例驱动开
发的基本概念；确定客户需要什么，掌握需求工作流的基本 过程；理解领域模型、业务模型对需求的作用，掌握相关的 建模技术；以考勤系统为例，全面展示需求工作流的工作过 程；了解考勤系统的测试工作流。
第8章 用例驱动
8.1 用例驱动开发概述
在需求工作流中，开发者必须确定什么样的软件是客户 想要的。因此，需求捕获有两个目标：发现真正的需求，并 以适合于用户、客户和开发人员的方式加以描述。“真正的 需求”是指在实现时可以给用户带来预期价值的需求，但是， 很多客户不知道他们需要什么．
第8章 用例驱动
第8章 用例驱动
需求 分析 设计 实现 测试
用例模型 分析模型 设计模型 实施模型 实现模型 测试模型
图8-1 统一过程从需求到测试的一系列工作流
第8章 用例驱动
用例常用于捕获软件系统(尤其是基于构件的系统)的需 求。用例不只是捕获需求的工具，还能够驱动整个开发过程。 在寻找和确定类、子系统和接口时，在寻找并确定测试用例 时，在规划开发迭代和系统集成时，用例都将作为主要输入。 对每次迭代，用例驱动完成一整套工作流(从需求捕获，经 过分析、设计和实现，最后到测试)，并将这些不同的工作 流集成在一起。
第8章 用例驱动
开发人员设计类和用例实现，以便更充分地应用相关的 产品和技术(如对象请求代理、图形用户界面、构造工具和 数据库管理系统等)来实现系统。根据子系统对设计类进行 分组，并定义子系统间的接口。开发人员还要进一步建立实 施模型，其中包括定义在计算节点上的系统的物理结构，以 验证用例能够实现并能在节点上运行。
第8章 用例驱动
设计模型具有下面的特点： 设计模型是有层次的，也包括跨层次的关系，这些关 系在UML中很常见：关联、泛化和依赖等； 用例实现是协作的构造型，协作表示类元在做某件事 情(如实现用例)时如何参与和扮演角色； 设计模型是实现的蓝图，设计模型的子系统和实现模 型的构件之间存在直接的映射关系。
“以适合于用户、客户和开发人员的方式”主要是指对需求 的最后描述必须能够让用户和客户理解，但是，即便客户真 正了解他们需要什么，也有可能很难精确地把其想法传达给 开发者，因为大多数客户的计算机知识不如开发团队的成员。 这也是需求工作流的难点之一。
第8章 用例驱动
系统通常有多种用户，每种用户都是一个参与者，参与 者使用系统与用例进行交互，用例是系统向参与者提供某些 有价值结果而执行的动作序列，即某种功能，参与者和用例 构成用例模型。
在分析和设计期间，用例模型经分析模型转化为设计模 型。简单地说，分析模型和设计模型都是由类元(Classifier) 和说明如何实现用例的集合组成的。类元是一种描述行为和 结构特征的模型元素，它具有属性和操作，可以用状态图描 述，有的还可以实例化、参与协作等。类元的种类包括类、 行为、构件、数据类型、接口、节点、信号、子系统以及用 例。其中，类是最常见的类元。
பைடு நூலகம்
第8章 用例驱动
统一过程(UP)的核心思想是用例驱动、以构架为中心的 迭代和增量开发。图8-1描述了统一过程中的一系列工作流 和模型。从机器解释的角度看，实现模型是最形式化的，而 用例模型的形式化成分最少。也就是说，部分实现模型可以 通过编译和连接成为可执行代码，而用例模型主要用自然语 言来描述。
第8章 用例驱动
开发人员以用例模型为输入来创建分析模型。用例模型 中的每个用例都实现为分析模型中的用例实现，用例和用例 实现的依赖性支持需求和分析之间的无缝可跟踪性。通过对 用例进行处理，开发人员可以确定参与实现用例的类，例如， “取款”用例可以通过分析“取款”类、“账户”类、“分 配”类及其他无需在此标识的类来实现。开发人员将用例中 定义的职责分配为类的职责，因此“账户”类包括诸如“从 账户上提取一定数额的现金”的职责。这样，就可以得到一 个类的集合，合在一起就能实现用户所需的用例。
第8章 用例驱动
8.2 为什么使用用例
在软件开发中，很常见的问题是许多客户不知道他们需 要什么，进一步来讲，即便客户真正了解他们需要什么，也 有可能很难精确地把这些想法传达给开发者，因为大多数客 户的计算机知识不如开发团队的成员。对开发人员来说，对 软件产品及其功能进行形象化描述已经很难了，对并不精通 软件工程的客户来说则更加困难。
第8章 用例驱动
分析模型也是一种模型，是需求的详细规格说明，可作 为设计模型的切入点。分析模型可能是暂时的，只存在于前 几次迭代中，然而，在某些情况下，尤其对于大型、复杂系 统，分析模型会存在于系统的整个生命周期。这种情况下， 分析模型的用例实现与设计模型中相应的用例实现之间存在 一种无缝的跟踪依赖关系，分析模型中每个元素都可以从实 现它的设计模型元素中跟踪到。
开发人员把设计好的类实现为实现模型中的构件(源代 码)集合，能够产生(即编译和连接)如DLL、JavaBeans和 ActiveX等可执行代码，用例有助于开发人员确定实现和集 成构件的次序。
第8章 用例驱动
在测试工作流期间，测试人员验证系统确实能够实现用 例描述的功能并满足系统需求。测试模型包含测试用例，测 试用例是测试数据集，定义了输入、运行条件和结果的集合。 许多测试用例直接从用例得到。因此，在测试用例和相应的 用例之间存在跟踪依赖关系，这意味着测试人员将验证系统 能够做用户需要的事，即能够执行用例。