## 软件工程介绍 《 国家软件工程术语规范》 文档模板 1. 网上找规范文档 2. 信息管理工程师的软考标准 3. 真实项目的需求分析 项目说明书 1. 可行性分析 2. 需求分析 3. 概要设计 4. 详细设计 5. 测试报告 先确定一个项目，再根据项目去做文档。具体以文档形式体现出来，做完了又返回到文档，完全以文档去做。 1. 航天、金融等文档规范。 2. 软考标准 3. 真实项目，如智慧校园 面向对象：把系统变成人。 业务 程序：能够完成预定功能和性能的可执行指令序列 数据：能够适当地处理信息的数据结构 文档：开发、使用和维护程序所需要的图文资料 软件定义 在计算机系统的支持下，能够完成特定功能和性能的程序、数据和相关文档的完整集合。 计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必须的数据。 程序只是软件的一部分。 按功能分类、按工作方式分类 软件危机 1. 如何开发软件 2. 如何维护软件 3. 软件生产能力和业务发展需求不相适应的现象； 4. 就是弱的软件生产能力和强的业务发展需求之间的矛盾 典型表现： 1. 对软件开发成本和进度的估计不准确 2. 软件开发的成败建立在个人能力基础上 3. 用户对“已完成”软件系统不满意 4. 软件产品质量不可靠 5. 软件常常不可维护 6. 软件没有适合的文档资料 7. 软件成本上升 8. 软件开发生成率提高到速度跟不上计算机应用迅速普及深入的趋势 原因： 1. 软件本身的特点有关 2. 软件开发维护方法不正确 消除软件危机的方法 1.对计算机软件有正确的认识 软件使一种抽象的，逻辑实体。 软件工程 知道计算机软件开发和维护的工程学科 1. 采用工程的概念、原理、技术和方法来开发和维护软件 2. 它将经过时间考验而证明正确的管理技术和当前能够得到最好的技术方法结合起来 3. 强调使用生存周期方法学和结构化技术 本质特性： 1. 软件工程关注于大型程序的构造 2. 软件工程的中心课题是控制复杂性 3. 软件经常变化 4. 开发软件的效率非常重要 5. 和谐地合作 6. 软件必须有效地支持它的用户 软件工程的基本原理 1. 用分阶段的生命周期计划严格管理 2. 阶段评审 3. 产品控制 4. 采用现代程序设计技术 5. 清楚地审查 6. 开发小组少而精 7. 承认不断改进软件工程实践的必要性 软件工程方法学（范型） 在软件生命周期全过程中使用的一整套技术方法的集合称为软件工程方法学 三要素：方法、工具和过程 分类： 1. 结构化方法学/传统方法学 结构化分析SA,结构化设计SD,结构化程序设计SP 采用结构化技术 把软件生命周期的全过程依次划分为若干个阶段 每一阶段的开始和结束都有严格标准 前一阶段的结束标志就是后一阶段的开始标准 每一阶段结束前需严格审查和复审 软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量 2. 面向对象方法学 面向对象分析OOA,面向对象设计OOD,面向对象程序设计OOP 用对象分解取代传统方法的功能分解 把所有对象划分成类，每个类都定义了一组数据和操作 按照父类和子类的关系，把若干相关类组成一个层级结构的系统 对象间之恶能通过发送消息互相联系 软件生命周期 三个时期，八个阶段 软件生命周期由软件定义、软件开发和运行维护3个时期组成。 **软件定义时期** 问题定义 1. 沟通：项目启动化 2. 需求获取 弄清楚客户要解决什么问题 可行性研究 对上一阶段所确定的问题有行得通的解决办法吗？ 进行一次大大压缩和简化了的系统分析和设计过程，也就是在较抽象的高层次上进行分析和设计的过程。 输出《可行性研究报告》 确定软件开发的可行性。 需求分析 为了解决这个问题，目标系统必须做什么。经过用户确认的系统逻辑模型，体现用户需求，输出《需求规格说明书》 **软件开发时期** 概要设计/总体设计 软件设计的一条基本原理是：程序应该模块化 一个程序应该由若干个规模适中的规模按合理的层次结构组织而成。 另一项任务是设计程序的体系结构（软件结构），也就是确定程序由哪些模块组成以及模块间的关系。 输出《总体设计说明书》 详细设计 详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构，输出《详细设计说明书》 编码和单元测试 写出正确的容易理解、容易维护的程序模块。将详细设计用语言实现。 综合测试 最基本的测试是集成测试和验收测试。 所谓集成测试是是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。 所谓验收测试则是按照规格说明书的规定，由用户对目标系统进行验收。 通过对软件测试结果的分析可以检测软件的可靠性；反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。 **软件维护时期** 软件维护/运行和维护 每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。 软件过程 在整个软件生命周期的系统开发、运行和维护过程所实施的全部过程、活动和任务的结构框架。通常用价格软件过程模型来描述。 瀑布模型 将软件生命周期的各项活动工会低挡位按固定顺序而连接的若干工作阶段。 瀑布模型是以文档驱动、适合于软件需求确定的软件项目开发。 1. 阶段间具有顺序性和依赖性 2. 推迟实现的观点 3. 质量保证的观点 快速原型模型 快速原型模型是不带反馈环的 用户介入早，通过迭代完善用户需求，应用快速开发工具 增量模型 每次迭代完成一个增量，可用于OO开发 它分批地逐步向用户提交产品，整个软件产品被分解成多个增量构件（普i不模型） 螺旋模型 典型迭代模型，重视风险分析，可用于OO开发 喷泉模型 典型OO过程模型，体现迭代和v无缝的特性 构建集成模型 ## 可行性分析 针对...问题 改变...方法 改进了... 可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。 可行性研究的任务 首先进一步分析和澄清问题定义 2. 到处系统模型 3. 1. 物理模型：系统流程图SFD 2. 逻辑模型：数据流图DFD、数据字典DD 探索解法： 根据逻辑模型探索若干可供选择解法 研究可行性： 1.技术可行性 经济可行性 操作可行性 可行性研究过程 1. 复查系统规模和目标 2. 研究目前正在使用的系统 3. 导出新系统的过曾逻辑模型 4. 进一步定义问题 5. 导出和评价可控选择的解法 6. 推荐行动方针 7. 草拟开发计划 8. 书写文档提交审查 结果：《可行性研究报告》 1. 系统概述 2. 可行性研究 3. 拟定开发计划 4. 结论意见 系统流程图： 概括地描绘物理系统的图。表达数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。 数据流图和数据字典共同构成系统的逻辑模型适用于结构化分析阶段，包括需求分析 数据流图 描绘信息流和数据从输入到输出过程所经受的变换的图 没有具体物理部件 只需考虑基本逻辑功能 系统逻辑功能的图形表示 基本符号 正方形，代表数据的终点或者源点 原型：表示加工，代表变换数据 数据存储：数据加工的数据所存储的地方 数据流：代表数据流向和路径 附加符号 与、或、异或 步骤：自顶向下、逐层细化 数据字典：是关于数据的信息集合，即对数据流图中包含的所有元素的定义的集合 内容：数据流、数据流分量、数据存储、处理 组成方式：顺序、选择、重复、可选 成本效益分析 代码行技术 任务分解技术 ## 需求分析 **用户提出的需求分析**（本质层面） - 关注的是 **要解决什么问题**（Problem） - 例如：“我需要一种方式，让团队成员能随时看到项目进度，避免重复工作。””智能车系统一定挥动智能车“ - 这是 **问题域** 的分析，涉及用户痛点、业务目标、使用场景等。 **软件工程中的需求分析**（文档或实施层面） - 往往表现为 **系统应具备什么功能、界面、交互流程**（Solution） - 例如：“系统要有项目管理页面、任务列表页面，点击任务可跳转到详情页……””用户点击这个会跳转到哪里“ - 这是 **解决方案域** 的规格描述，是一个功能清单或界面跳转逻辑。 - 至于这个功能怎么用，不是我们软件工程师的工作 定义 image-20251022165308929 编码能力下降，编码质量反而提升 两方面的需求分析： 1. 应用层次，类似数据流图 2. 计算机层次，数据流图映射到计算机去 数据流理好（业务模型） 数据建模 算法 软件工程的需求分析不是用户的需求 而是”系统必须做什么“。系统最终呈现出来的样子。 用户的需求： 1. 描述性需求。用户需要的问题描述。 2. 根本性需求：用户认知下对软件系统的预期表现。这一点很重要。 但用户描述的往往是不完整的。 不要从用户的角度，用户提出”增加一个新功能“，不是就”增加一个新功能“ 你是做软件的，你写的是给工程师看的。 系统不等于用户需要的功能。 我们的系统展现出来的样子。系统的功能≠用户提出的功能 准则是保证我们需求分析的质量。 数据模型 功能模型 - 跟数学做应用题一样 行为模型 - 智能化时代，人机交互模型 - 人跟机器互相合作抽象出来的一种行为模型 细节展示 系统需求不是功能需求 #### 需求分析概念 系统必须做什么，生成需求规格说明书 为什么要进行需求分析？ 需求分析是软件开发的前提和基础；必须了解用户需求 需求分析是最终目标软件系统验收的标准 需求分析能避免或者尽早剔除早期的错误。确定对系统的综合要求 遵守下述准则： 1. 必须理解并描述问题的欣喜域 2. 必须定义软件应完成的功能 3. 必须描述作为外部事件结果的软件行为 4. 必须对描述信息、功能和行为的模型进行分解 层次分析 需求分析的任务 确定对系统的综合要求 - 功能需求 - 性能需求 - 可靠性和可用性需求 - 出错处理需求 - 接口需求 - 约束 - 逆向需求 - 将来可能提出的要求 - 一个软件最多支持五年 计算机提供了工具，不是问题本身 研究行业的人最厉害，结合起来更厉害 比如说财务管理系统，既要有专业的财务人员，也需要理解系统的计算机人员 医疗系统，既要有医生，也要有计算机 系统讲究如何去实现 原则上非常简单， 元素级——数据的最低级别 可重用的软件构件，一定是要可用的。不能说从头开始的。必须是可重用的。 形式化规格说明和原型环境。 对你讲的这句话有非常严格的逻辑要求。 形式化最好用数学公式来说明，画图也可。 最好画一下示意图”形式化“ 需求分析是一个翻译与建模的过程，软件系统的功能点。 情景分析技术：演示目标系统行为、用户容易理解 用户描述的需求和软件工程师根据用户的需求整合后的需求 如果要得出会议结果，怎么得出意见一致的？找些论文，是有方啊的 在汇报工作的时候。 在其他专业，搞心理学，智能家居的，会把访谈做到很精细。 它们会根据什么数学计算得出“意见一致”。 数据信息整合的越高级越好。 不同的专业要积累不同的数据。 虚拟仿真的技术。——原型环境 目标产出：需求分析规格说明书，这个规格就是标准 事件表达式是什么？发生某件事情 分析系统的数据要求 1. 建立数据模型 2. 描绘数据结构：层次方框图、Warnier图、IPO图 导出系统的逻辑模型：数据字典、数据流图、实体联系图、状态转换图 修正系统的开发计划 与用户沟通获取需求的方法 1. 访谈 2. 面向数据流自顶向下求精 3. 简易的应用规格说明书 4. 快速建立软件原型 分析建模与规格说明 模型：为了理解事物而对事物左处的一种抽象，是对事物的一种无歧义的书面描述 模型分类： 1. 数据模型 实体-联系图 2. 功能模型 数据流图 3. 行为模型 状态转换图 软件需求规格说明 实体-联系图 建立数据模型 用于描述数据流图中的数据存储数据存储及其之间的关系。尸体练习图可以作为用户与分析员之间有效的交流工具。 实体：描述的数据对象 属性：数据对象的性质 联系：交互方式 表示方式 数据模型：一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，且与实现方法无关 数据对象：对软件必须理解的符合信息的抽象 属性：属性定义了数据对象的性质 联系：数据对象彼此之间相互连接的方式 状态转换图STD：通过描绘系统的状态及引起系统状态转换的事件来表示系统的行为 实时系统 状态：状态是任何可以被观察到的系统行为模式，状态规定了系统对事件的响应方式 事件：事件是在某个特定时刻法神的事情，就是引起系统做动作或转换状态的控制信息。 初态：实心圆 终态：同心圆，内为实心 状态：圆角矩形 层次方框图 用树形结构的一系列矩形框描绘数据的层次结构 优点：随着数据结构的逐步精细，对数据结构的描绘也越来越详细 可以表明信息的逻辑组织，可以表明某类信息出现的条件或者是否重复出现 IPO图 输入、处理、输出 验证软件需求 一致性： 完整性： 现实性： 有效性： 验证软件需求的方法 验证一致性 验证现实性 验证完整性和有效性 用于需求分析的软件工具 PSL:问题陈述语言 PSA:问题陈述分析程序 ## 概要设计 系统=软件的结构 整体性组成 总体设计的目的“系统应该如何实现”这个问题，产出《总体设计说明书》 总体设计阶段重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块间的关系。 划分出组成系统的物理元素 解决方案≠实现方案 软件工程的总体设计是偏程序、代码的。比如， 任何一个语言。 设计过程 1.系统设计阶段：确定系统的具体实现步骤 1. 设想供选择的方案 2. 选择合理的方案 3. 推荐最佳方案 结构设计阶段：确定软件结构 1. 功能分解 2. 设计软件结构 3. 设计数据库 4. 制定测试计划 5. 书写文档 6. 审查和复审 设计原理 模块化 模块：是由边界元素限定的相邻程序元素的序列，而且有一个总体标识符代表它。模块是构成程序的基本构件。 模块化：把程序划分成独立命名且可以独立访问的模块，每个模块完成一个子功能，是软件应该具备的唯一属性。 抽象：把相似的方面集中和概括起来，暂时忽略它们之间的差异。 逐步求精：逐步求精是软件工程技术的基础，为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。 Miller法则：自顶向下。 信息隐藏和局部化 信息隐藏：一个模块内包含的信息对于不需要这些信息的模块来说是不能访问的 局部化：把一些关系密切的软件元素物理地放得彼接近。 模块独立性： 开发具有独立功能而且和其它模块之间没有过多 相互作用的模块，就可以做到模块独立。 模块独立的概念上模块化、抽象。信息因此和局部化概念的直接结果。 质量标准是耦合和内聚，软件设计目标是高内聚、低耦合。 耦合： 耦合是对于一个软件结构内不同模块间互连程度的度量。 耦合度越高，说明相互依赖越紧密，模块独立性越弱。 1. 完全独立 2. 数据耦合——交互的信息仅仅是数据。低耦合。 3. 特征/标记耦合——数据结构作为参数传递，而被调用的模块只需要部分。 4. 控制耦合——传递的参数中有控制信息，中等程度。 5. 外部耦合——共享一个全局的变量 6. 公共耦合——两个或多个通过一个公共的环境 7. 内容耦合——直接发生联系 内聚：衡量模块内部各个元素结合的紧密程度 定义：用来度量一个模块内部各个元素彼此结合的紧密程度。内聚度越高，紧密程度越高 低内聚： 偶然内聚：一个模块内部即使有关系，也是很松散的 逻辑内聚：一个模块在逻辑上相同或者相似 时间内聚：必须在同一个时间段内执行 中内聚： 过程内聚：元素相关，并且以特定次序执行 通信内聚：模块中所有元素使用同一个输入数据和或产生一个输出数据 高内聚： 顺序内聚：一个模块内的处理元素和同一个功能密切相关，并且处理必须顺序执行 功能内聚：属于一个整体，完成一个单一的功能 启发规则 1. 改进软件结构提高模块独立性 通过模块分解或合并 2. 模块规模应该适中 3. 深度、宽度、扇出、扇入应适当 深度：软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度 宽度：软件结构内同一个层次上的模块总数的最大值 扇入：有多少个上级模块调用它 扇出：一个模块之际控制的模块数目 软件结构通常顶层删除较高，中层删除较少，底层模块有高扇入，平均扇出为3或4 1. 模块的作用域应该在控制域之内 指受该模块内一个判定影响的所有模块的集合——逻辑关系 控制域：这个模块本身以及所有直接或者间接从属于它的模块的集合——无厘山关系 受判定影响的模块因该都从属于做出判定的哪个模块，最好局限于做出判定的哪个模块本身及他的直属下级模块。 划分模块时，作用于关于应该处于控制域的范围之内 力争降低模块的接口的复杂程度 设计单入口单出口的模块 1. 力争降低模块接口的复杂程度 信息传递简单并且和模块功能一致。 1. 设计单入口单出口的模块 不要使用内容耦合 1. 模块功能应该可以预测 描绘软件结构的图形工具 1. 层次图和HIPO图 2. 结构图 面向数据流动设计方法 结构化设计方法SD是面向数据流动设计方法， 以结构化分析SA产生的数据流图为基础，将数据流图DFD按一定的步骤映射成软件结构图SC 1. 变换流 ​ 由输入、变换和输出三部分组成 1. 事物流 ​ 根据输入数据的类型在多个事物中选择一个执行 1. 设计过程 信息流与控制流 尽量以信息流作为核心 ### 详细设计 详细设计的目标是确定应该怎样具体实现所要求的系统 详细设计阶段的任务是为软件层次图或结构图SC中的每一个模块确定采用的算法、数据结构、外部接口和用户界面，并用某种选定的表达工具给出清晰的描述 详细设计的结构基本决定了最终程序的质量。 《详细设计说明书》 结构化程序设计 如果一个程序的代码块仅仅通过顺序、选择、循环这三种基本控制结构进行链接，并且每个代码块之呢个一个入口和出口。 保证程序代码的易读性。 尽可能少的使用GOTO语句 人机界面设计 设计问题 系统响应时间 用户完成某个控制动作到软件给出预期的响应之间的这段时间 长度 易变性 用户帮助设施 集成 附加 出错信息处理 命令交互 置用户于规则之下 减少用户的记忆负担 保持界面一致 设计过程 设计指南 一般交互 信息显示 数据输入 过程设计工具 程序流程图 用同意规定的标准符号描述程序运行具体步骤的图形表示 盒图N-S图 功能域明确 不能任意控制转移 很容易确定局部和全程数据的作用域 容易表现嵌套关系和模块的层次结构 PAD图 二位树形结构的图利表示程序的控制流，自上而下，从左往右 判定表 能够清晰地表示复杂的条件组合域应作动作之间的对应关系 左上部所有条件 左下部所有可能做的动作 右上部表示各种条件组合的一个矩阵 右下部是和每种条件组合相对应的动作 判定树 过程设计语言伪代码PDL 算法设计和加工细节的过程描述语言，是由正文形式表示数据和处理过程的设计工具 关键字的固定语法 自然语言的自由语法 数据说明的手段 模块定义和调用的技术，提供各种接口描述模式 为什么要进行可维护性复审？ 在完成每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。 不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。 如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满 Jackson图 从左到右阅读的树状层次结构图，上下层是组成关系，既能表示数据结构也能表示程序结构 根据程序流程图计算复杂度 流图中线性无关的取余数 E-N+2 P+1 UML体系 顺序图(用例，构件) 流程图：功能、模块 预防性维护 反复多次地修改啊程序的尝试，与不可见的设计及源代码“顽强战斗”，以实现所要求的修改 通过仔细分析程序尽可能多地掌握程序内部工作细节，以便有效修改它。 用软件工程方法重新设计、重新编码和测试那些需要变更的软件部分 以软件工程方法学为知道，对程序全部重新设计编码和测试 体系结构和数据结构 文档不全 修改也没有完整的记录 自动化时代、智能化时代 计算机辅助设计与指导 预防性维护 维护一行源代码的代价，可能是最初开发该源代码代价的14-40倍 重新设计软件体系结构 现有的程序版本可作为软件原型使用 用户具有较多使用该软件的经验，因此，能够很容易地高清晰变更需求和变更的范围 利用逆向工程和再工程的工具，可以使一部分工作自动化 在完成 软件再工程过程 文档重构 逆向工程 数据 静态数据 动态数据 体系结构不是功能而是系统 数据、体系结构和处理过程的设计信息 代码重构 先后先用重构工具分析源代码 判定表、环形复杂度、测试用例、 在问题定义阶段有什么 存在什么问题可能导致的结果 从项目管理。详细设计