张海藩版本 软件工程导论教材 简洁考试重点

xmind版本更好

软件危机 软件危机概念 是指在计算机软件的开发和维护过程中所遇到的一系列严重问题 软件危机典型表现： ①对软件开发成本和进度的估计常常很不准确。②用户对“已完成的”软件产品不满意的情况。③软件产品的质量往往达不到要求。④软件通常是很难维护的。⑤软件通常没有适当的文档资料。⑥软件成本在计算机系统总成本中所占的比例逐年上升。⑦软件开发生产率提高的速度，远远不能满足社会对软件产品日益增长的需求。 软件危机包含的问题： 如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。 软件危机的原因： 客观原因 软件是逻辑部件，缺乏可见性；规模庞大，复杂性随着程序规模增加以指数速度上升 主观原因 忽视软件需求分析的重要性；认为软件开发就是写程序；轻视软件维护 软件危机的消除途径： 树立对计算机软件的正确认识 软件是程序、数据及相关文档的完整集合；程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当的处理信息的数据结构；文档是开发、使用和维护程序所需要的图文资料。 采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来，经济地开发出高质量的软件并有效地维护它。 应该积极开发和使用计算机辅助软件工程（CASE）工具。

软件工程 软件工程概念 软件工程是指导计算机软件开发和维护的一门工程学科，该学科的目的是生产出能按期交付的、在预算范围内的、满足用户需求的、质量合格的软件产品。 软件工程基本原理 ①用分阶段的生命周期计划严格管理；②坚持进行阶段评审；③实行严格的产品控制；④采用现代程序设计技术；⑤结果应能够清楚的审查；⑥开发小组的人员应该小而精；⑦承认不断改进软件工程实践的必要性。 软件工程方法学 概念 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（也称为范形） 三要素 方法 方法是完成软件开发的各项任务的技术方法 工具 工具是为运用方法而提供的自动的或半自动的软件工程支撑环境 过程 过程是为了获得高质量的软件所需完成的一系列任务的框架，它规定了完成各项任务的工作步骤 软件工程方法学 传统方法学（结构化范形）、面向对象方法学（面向对象范形）

软件生命周期 定义： 一个软件从定义、开发、使用和维护，直到最终被废弃，所经历的漫长的时期。 阶段 软件定义 问题定义 可行性研究 目的 用最小的代价在尽可能短的时间内确定问题是否能够解决 研究每种解法可能性的方面 技术可行性、经济可行性、操作可行性 研究过程 复查系统规模和目标；研究目前正在使用的系统；导出新系统的高层逻辑模型；进一步定义问题；导出和评价供选择的解法；推荐行动方针；草拟开发计划；书写文档提交审查 系统流程图 概念 系统流程图是概括的描述物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件（程序、文档、数据库、人工过程等） 数据流图（OFD） 数据流图是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，他只是描绘数据在软件中流动和被处理的逻辑过程。 数据字典 概念 关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合 定义数据的方法 基本类型 顺序、选择、重复、可选 符号 等价于、定义为 = 连接两个分量、和 + 从方括弧内列出的若干个分量中选择一个、或，通常用 | 隔开供选择的分量 [ ] 重复花括号内的分量 ｛｝ 圆弧括号里的分量可有可无 （） 用途 作为分析阶段的工具，在数据字典中建立一组严密一致的定义很有助于改进分析员和用户之间的通信。 成本/效益分析 成本估计 代码行技术、任务分解技术、自动估计成本技术 需求分析 概念 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确的回答“系统必须做什么”这个问题 需求分析的任务 确定对系统的综合要求 功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、逆向需求、将来可能提出的需求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划 与用户沟通获取需求的方法 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型 实体-联系图 通常使用实体-联系图（ER图）来建立数据模型，相应的可把用ER图描绘的数据模型称为ER模型。ER图中包含了实体（即数据对象）、关系和属性三种基本成分，使用矩形框代表实体、用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体（或关系）的属性，并用直线把实体（或关系）与其属性连接起来。 状态转换图（状态图） 通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。 层次方框图 用树形结构的一系列多层次的矩形框描绘数据的层次结构 IPO图 输入、处理、输出图的简称 验证软件需求正确性的方面 一致性、完整性、现实性、有效性 软件开发 总体设计 设计过程 设想供选择的方案、选取合理的方案、推荐最佳方案、功能分解、设计软件结构、设计数据库、制定测试计划、书写文档、审查和复审 设计原理 模块化 把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集合起来构成一个整体，可以完成指定的功能满足用户的需求。 抽象 抽出事物的本质特征而暂时不考虑他们的细节 逐步求精 为了能集中精力解决主要问题而尽量推迟对问题细节的考虑 信息隐藏 在设计软件模块时应该使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说是不能访问的。 局部化 把一些关系密切的软件元素物理地放得彼此靠近 模块独立 模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。模块的独立程度可以由两个定性标准度量，这两个标准分别称为内聚和耦合。 耦合 概念 耦合是对一个软件结构内不同模块之间互连程度的度量，耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。 数据耦合 两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据。数据耦合是低耦合。 控制耦合 传递的信息中有控制信息（尽管有时这种控制信息以数据的形式出现）。控制耦合是中等程度耦合 特征耦合 把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素。 公共环境耦合 两个或多个模块通过一个公共数据环境相互作用。 内容耦合 ①一个模块访问另一个模块的内部数据；②一个模块不通过正常入口而转到另一个模块的内部；③两个模块有一部分程序代码重叠（只可能出现在汇编程序中）；④一个模块有多个入口（这意味着一个模块有几种功能） 设计原则 尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合 内聚 概念 内聚标志着一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。 低内聚 偶然内聚 如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的。 逻辑内聚 一个模块完成的任务在逻辑上属于相同或相似的一类（例如一个模块产生各种类型的全部输出） 时间内聚 一个模块包含的任务必须在同一段时间内执行（例如模块完成各种初始化工作） 中内聚 过程内聚 一个模块内的处理元素是相关的，而且必须以特定次序执行 通信内聚 模块中所有元素都使用同一个输入数据和（或）产生同一个输出数据 高内聚 顺序内聚 一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行（通常一个处理元素的输出数据作为下一个处理元素的输入数据） 功能内聚 模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚 启发规则 改进软件结构提高模块独立性（力求降低耦合，提高内聚）；模块规模应该适中；深度、宽度、扇出和扇入都应适当；模块的作用域应该在控制域之内；力争降低模块接口的复杂程度；设计单入口单出口的模块；模块功能应该可以预测； 描绘软件结构的图形工具 层次图、HIPO图、结构图 详细设计 结构程序设计 概念 结构程序设计是一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口单出口的控制结构 分类 经典的结构程序设计 只使用顺序、IF_THEN_ELSE型分支和DO_WHILE型循环这三种基本控制结构 扩展的结构程序设计 除了三种基本控制结构之外，还允许使用DO_CASE型多分支结构和DO_UNTIL型循环结构 修正的结构程序设计 再允许使用LEAVE（或BREAK）结构 过程设计的工具 程序流程图；盒图（N-S图）；PAD图；判定表；Jackson图（步骤） 环形复杂度计算 流图中线性无关的区域数；流图中边的条数 - 节点数 + 2；判定节点数目 + 1 编码和单元测试 综合测试 集成测试 验收测试 软件维护 四类维护活动 改正性维护 适应性维护 完善性维护 预防性维护

软件过程 瀑布模型 特点 阶段间具有顺序性和依赖性；推迟实现的观点；质量保证的观点 优点 强迫开发人员采用规范的技术方法；严格的规定了每个阶段必须提交的文档；每个阶段结束前必须正视进行严格的技术审查和管理复审 缺点 最终开发出的软件产品不能真正满足用户的需求 快速原型模型 特点 “快速原型”是快速建立起来的、可在计算机上运行的程序，它所完成的功能往往是最终的软件产品所能完成功能的子集。 优点 通常能满足用户的真实需求；软件产品的开发过程基本上是线性顺序过程 螺旋模型 风险驱动的螺旋模型适用于内部开发的大型软件项目，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。