思维导图，【中级职称】项目集成管理工程师（新版教材） 第5章、软件工程
2024-09-11 23:07:03 0 举报AI智能生成
软件工程是项目集成管理工程师的重要组成部分，它涉及软件开发的各个方面，包括需求分析、设计、编码、测试和维护等。软件工程需要遵循一定的方法、规范和工具，以保证软件开发的质量和效率。 核心内容：软件工程包括需求分析、设计、编码、测试和维护等阶段。需求分析是了解用户需求，确定软件功能的过程；设计阶段涉及到软件架构和详细设计的制定；编码阶段是将设计转化为计算机语言的过程；测试阶段是对软件进行测试，确保其功能和性能满足用户需求；维护阶段是软件交付后的持续改进和更新。 文件类型：软件工程涉及到多种文件类型，如需求文档、设计文档、代码文档、测试文档和维护文档等。这些文档是软件开发的重要依据和参考，需要妥善管理和维护。 修饰语：软件工程需要遵循一定的方法、规范和工具，以保证软件开发的质量和效率。此外，软件工程还需要考虑用户的需求和期望，以及软件的可维护性和可扩展性等因素。
作者其他创作
大纲/内容
1、软件工程的定义
1.1、应用计算机科学、数学以及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。
IEEE定义：将系统的、规范的、可度量的工程化方法应用与软件开发、运行和维护的全过程以及上述方法的研究。
IEEE定义：将系统的、规范的、可度量的工程化方法应用与软件开发、运行和维护的全过程以及上述方法的研究。
1.2、软件工程的组成
方法
工具
过程
1.3、软件工程的目的：提高软件生产率、提高软件质量，降低软件成本
2、软件需求
2.1、用户对新系统在功能、行为、性能、设计约束等方面的期望。
2.2、需求层次
1、业务需求
2、用户需求
3、系统需求
2.3、质量功能的部署
1、一种将用户要求转化为软件需求的技术
2、目的：最大限度的提升软件工程中用户的满意度
3、需求分类
3.1、常规需求
应该做到的功能或性能
3.2、期望需求
应该具备的功能或性能
3.3、意外需求
范围外的功能或性能
2.4、需求的获取
2.4.1、确定和理解不同的项目干系人对系统的需求和约束的过程
2.4.2、方法
1、用户访谈
2、问卷调查
3、采样
4、情节串联版
5、联合需求计划
2.5、需求的分析
2.5.1、把杂乱无章的用户需求和期望转化为用户需求
2.5.2、特性
1、无二义性
2、完整性
3、一致性
4、可测试性
5、确定性
6、可跟踪性
7、正确性
8、必要性
2.5.3、推荐做法
1、对问题域进行抽象
2、将其分解为若干个基本元素
3、对元素之间的关系进行建模
2.5.4、结构化分析=SA
2.5.4.1、3层次模型
1、数据模型
2、功能模型
3、行为模型
2.5.4.2、DFD需求建模方法
1、4种基本元素
1.1、数据流
1.2、处理/加工
1.3、数据存储
1.4、外部项
2、步骤
2.1、明确目标，确定系统范围
2.2、建立顶层DFD图
2.3、构建第一层DFD分解图
2.4、开发DFD层次结构图
2.5、检查确认DFD图
2.5.4.3、数据字典的应用
1、一种用户可以访问的记录数据库和应用程序元数据的目录
2、5个部分
2.1、数据项
2.2、数据结构
2.3、数据流
2.4、数据存储
2.5、处理过程
2.5.5、面向对象分析-OOA
2.5.5.1、OOA模型
2.5.5.1.1、5个层次
1、主题层
2、对象类层
3、结构层
4、属性层
5、服务层
2.5.5.1.2、5个活动
1、标识对象
2、标识结构
3、定义主题
4、定义属性
5、定义服务
2.5.5.2、OOA基本原则
1、抽象：抽取共同的、本质性的特征，包括过程抽象和数据抽象
2、封装：把对象的属性和服务结合，尽可能隐蔽对象的内部细节
3、继承：一般类（父）与特殊类（子）的关系
4、分类：把具有相同属性和服务的对象划分为一类
5、聚合：又称为组装，把事务看成若干比较简单的事物组装体
6、关联：通过一个事物联想到另外的事物
7、消息通信：这一原则要求对象之间只能通过消息进行通信
8、粒度控制：考虑全局时，注意其大的组成部分，暂不考虑细节，考虑某部分的细节时则暂时撇开其余的部分
9、行为分析：由大量的事物所构成的问题域中，各种行为往往相互依赖，相互交织
2.5.5.3、OOA的基本步骤
1、确定对象和类
2、确定结构
3、确定主题
4、确定属性
5、确定方法
2.6、需求规格说明书
2.6.1、在需求分析阶段需要完成的文档，软件需求分析的最终结构
2.6.2、软件开发过程中最重要的文档之一，任何软件项目都不应该缺少
2.6.3、需求验证
2.6.3.1、需求评审
2.6.3.2、需求测试
2.7、需求变更
2.7.1、（已建议的）变更控制过程
1、识别出问题
2、问题分析和变更描述
3、变更分析和成本计算
4、变更实现
5、修改后需求
2.7.2、需求变更的策略
1、所有需求变更必须遵循变更控制过程
2、对于未获得批准的变更，不应该做设计和实现工作
3、应该由项目变更控制委员会决定实现哪些变更
4、项目分享承担者应该能够了解变更的内容
5、局不能从项目配置库中伤处或者修改变更请求的原始文档
6、每一个继承的需求变更必须能跟踪到一个经过核准的变更请求
2.7.3、变更控制委员会（CCB）
1、CCB是决策机构，不是作业机构
2、CCB决定项目是否能变更，但不提出变更方案
2.8、需求跟踪
2.8.1、方式
2.8.1.1、正向跟踪
检查SRS的每个需求是否能在后继工作成果中找到对应点
2.8.1.2、逆向跟踪
检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处
3、软件设计
3.1、结构化设计SA
3.1.1、概要设计
确定软件系统的结构
3.1.2、详细设计
为每个模型设计实现的细节
3.1.3、模块结构
3.1.3.1、SD设计四原则
1、信息隐藏与抽象
2、模块化
3、耦合
4、内聚
3.1.3.2、耦合7类型
1、非直接耦合
2、数据耦合
3、标记耦合
4、控制耦合
5、通信耦合
6、公共耦合
7、内容耦合
3.1.3.3、内聚7类型
1、功能内聚
2、顺序内聚
3、通信内聚
4、过程内聚
5、时间内聚
6、逻辑内聚
7、偶然内聚
3.1.4、系统结构图
3.1.4.1、两个目标
1、实现模块功能的算法要逻辑上正确
2、算法描述要简明易懂
3.1.4.2、基本步骤
1、分析并且确定输入/输出数据的逻辑结构
2、找出输入数据结构和输出数据结构中的对应关系的数据单元。
3、按一定的规则有输入、输出的数据结构导出程序结构
4、列出基本操作与条件，并把他们分配到程序结构图的适当位置
5、用伪代码写出程序
3.1.5、详细设计的表示工具
1、图形工具
2、表格工具
3、语言工具
3.2、面向对象设计OOD
3.2.1、基本思想
1、抽象
2、封装
3、可扩展性
3.1、集成
3.2、多态
3.2.2、3中类型
3.2.2.1、实体类
一定有属性但是不一定有操作
3.2.2.2、控制类
没有属性，但是一定有方法
3.2.2.3、边界类
既有属性也有方法
3.2.3、设计原则
1、单职原则
2、开闭原则
3、里氏替换原则
4、依赖倒置原则
5、接口隔离原则
6、组合重用原则
7、迪米特原则
3.3、统一建模语言
3.3.1、组合
3.3.1.1、构造块
1、事物
1.1、结构事物
1.2、行为事物
1.3、分组事物
1.4、注释事物
2、关系
2.1、依赖（Dependency）
2.2、关联（Association）
2.3、泛化（Generalization）
2.4、实现（Realization）
3、图
3.1、静态视图
3.1.1、用例图：行为图
3.1.2、对象图：结构图
3.1.3、组件图（构件图）：结构图
3.1.4、类图：结构图
3.1.5、部署图：结构图
3.1.6、包图：结构图
3.1.7、制品图：结构图，与部署图一起使用
3.1.8、组合结构图：结构图，描述结构化类的内部结构
3.2、动态视图
3.2.1、活动图：行为图
3.2.2、状态图：行为图
3.2.3、协作图（通信图）：行为图，强调消息流经的数据结构
3.2.4、序列图（顺序图）：行为图，强调消息的时间次序
3.2.5、交互概览图：行为图，活动图和顺序图的混合物
3.2.6、定时图：行为图，强调消息跨越不同对象或角色的时间
3.3.1.2、规则
3.3.1.3、公共机制
3.3.2、UML视图
1、逻辑视图
2、进程视图
3、实现视图
4、部署视图
5、用例视图
3.4、设计模式
3.4.1、创建型模式
1、工厂方法模式
2、抽象工厂模式
3、原型模式
4、单例模式
5、建造者模式
3.4.2、结构型模式
1、适配器模式
2、桥接模式
3、组合模式
4、装饰模式
5、外观模式
6、享元模式
7、代理模式
3.4.3、行为型模式
1、职责链模式
2、命令模式
3、解释器模式
4、迭代器模式
5、中介者模式
6、备忘录模式
7、观察者模式
8、状态模式
9、策略模式
10、模板方法模式
11、访问者模式
4、软件实现
4.1、软件配置管理
4.1.1、核心内容
4.1.1.1、版本控制
4.1.1.1、最主要功能
1、追踪文件的变更
2、并行开发
4.1.1.2、变更控制
1、目的：不是控制变更的发生，而是对变更进行管理，确保变更有序进行
2、引起变更因素
2.1、外部的变更要求
2.2、内部的变更要求
4.1.2、SCM活动顺序
4.1.2.1、软件配置管理计划
4.1.2.2、软件配置标识
4.1.2.3、软件配置控制
4.1.2.4、软件配置状态记录
4.1.2.5、软件配置审计
4.1.2.6、软件发布管理与交付
4.2、软件编码
4.2.1、需要考虑的四个方面
4.2.1.1、程序设计语言
4.2.1.2、程序设计风格
1、源程序文档化
2、数据说明
3、语句结构
4、输入/输出方法
4.2.1.3、程序复杂性度量
4.2.1.4、编码效率
1、程序效率
2、算法效率
3、存储效率
4、I/O效率
4.3、软件测试
4.3.1、概述
1、主要是发现软件的错误
2、重要的是软件测试要贯穿在整个软件开发过程中，保障整个软件开发的过程是高质量的
3、软件测试仍是发现软件错误（缺陷）的主要手段
4、软件测试的目的是验证软件是否满足规定的软件质量要求
4.3.2、测试方法
4.3.2.1、静态测试
1、桌前检查
2、代码走查
3、代码审查
4.3.2.2、动态测试
1、白盒测试（结构测试）
1.1、测试的方法有控制流测试、数据流测试和程序辨析测试等
1.2、最常见的技术是逻辑覆盖，主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。
2、黑盒测试（功能测试）
等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交实验法等
4.3.3、测试类型
4.3.3.1、单元测试
1、检查每个模块能否正确的实现设计说明中的功能、性能、接口和其他设计约束等条件，发现模块内可能存在的各种差错
2、技术依据是软件详细设计说明书
4.3.3.2、集成测试
1、白盒测试和黑盒测试结合的方法进行测试
2、技术依据是软件概要设计文档
4.3.3.3、确认测试
主要用于验证软件的功能、性能和其他特性是否与用户需求一致
4.3.3.4、系统测试
1、目的是在真实系统工作环境下，检测完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求
2、测试内容
2.1、功能测试
2.2、性能测试
2.3、健壮性测试
2.4、安装或反安装测试
2.5、用户界面测试
2.6、压力测试
2.7、可靠性及安全性测试
4.3.3.5、配置项测试
1、目的是检验软件配置项与SRS的一致性
2、技术依据是SRS
4.3.3.6、回归测试
目的是测试软件变更后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性
4.3.4、面向对象测试
3个明显特征
1、封装性
2、继承性
3、多态性
4.3.5、软件调试
1、根据错误迹象确定错误的原因和准确位置，并加以改正，主要依靠软件调试技术
2、软件调试策略
1、蛮力法
2、回溯法
3、原因排除法
5、部署交付
5.1、软件部署
5.1.1、主要特征
1、过程覆盖度
2、过程可变更性
3、过程间协调
4、模型抽象
5.1.2、部署模式
1、面向单机软件的部署模式
2、集中式服务器应用部署
3、基于微服务的分布式部署
5.2、（传统）软件交付
5.2.1、4步骤
1、诞生想法
2、变为产品/功能
3、交付使用
4、后期运维
5.2.2、3大问题
1、需求沟通效率低
2、测试工作比重大
3、运维时间被占和技术复杂
5.2.3、2个层面的困难
1、表现层问题
2、底层问题
5.3、持续交付
5.3.1、软件开发流程
1、需求阶段：使用用户故事
2、开发测试阶段：做到持续集成
3、运维阶段：保持开发环境和运维环境的统一
5.3.2、优势
1、能够有效的缩短部署上线时间
2、能够自动的、快速的提供反馈
3、让软件都处于可部署状态
4、能够简化部署步骤
5、能够称为一种可靠的、可预期的、可视化的过程
5.3.3、评价互联网公司的软件交付能力的两个指标
1、仅设计遗憾代码的改动需要花费多少时间才能部署上线
2、是否在以一种可重复、可靠的方式执行软件交付
5.4、持续部署
5.4.1、持续部署方案
1、Kubernetes+Docker
1.1、上手简单，轻量级框架，体积很小
1.2、集合性更好，能更容易对环境和软件进行打包复制和发布
2、Matrix
5.4.2、部署原则
1、部署包全部来自统一的存储库
2、所有的环境使用相同的部署方式
3、所有的环境使用相同的部署脚本
4、部署流程编排阶梯式晋级
5、整体部署由运维人员执行
6、仅通过流水线改变生产环境，防止配置漂移
7、不可变服务器
8、部署方式采用蓝绿部署或者金丝雀部署
5.4.3、部署层次
1、Build
2、Ship
3、Run
5.4.4、不可变服务器
1、容器部署继承和优化了虚拟机部署的优点
2、容器部署很好的解决了第三方依赖库的重构问题
5.4.5、蓝绿部署和金丝雀部署
1、蓝绿部署
在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中
2、金丝雀部署
当有新版本发布时，先让少量用户使用新版本，并观察新版本是否存在问题
5.5、部署和交付的新趋势
5.5.1、工作职责和人员分工的转变
5.5.2、大数据和云计算基础设施的普及与进步给部署带来的新的飞跃
5.5.3、研发运维的融合
6、软件质量管理
6.1、软件质量影响3因素
6.1.1、产品运行
1、正确性
2、健壮性
3、效率
4、完整性
5、可用性
6、风险
6.1.2、产品修改
1、可理解性
2、可维修性
3、灵活性
4、可测试性
6.1.3、产品转移
1、可移植性
2、可再用性
3、互运行性
6.2、软件质量保证
6.2.1、主要目标
1、事前预防工作
2、尽量在刚引入缺陷时将其捕获，而不是让缺陷扩散到下一个阶段
3、做鱼过程而非最终产品，有可能带来广泛影响与巨大收益
4、贯穿于所有的活动之中，而不是只集中于一点
6.2.2、主要任务
1、SQA审计与评审
2、SQA报告
3、处理不合格问题
7、软件过程能力成熟度
7.1、成熟度模型
7.1.1、治理
1、战略与治理
2、目标管理
7.1.2、开发与交付
1、需求
2、设计
3、开发
4、测试
5、部署
6、服务
7、开源应用
7.1.3、管理与支持
1、项目策略
2、项目监控
3、项目结项
4、质量保证
5、风险管理
6、配置管理
7、供应商管理
7.1.4、组织管理
1、过程管理
2、人员能力管理
3、组织资源管理
4、过程能力管理
7.2、成熟度等级
1级：初始级。软件过程和结果具有不确定性
2级：项目规范级。项目基本可按计划实现预期的结果
3级：组织改进级。在组织范围内能够稳定的视线预期的项目目标
4级：量化提升级。在组织范围内能够量化的管理和实现预期的组织和项目目标
5级：创新引领级。通过技术和管理的创新，实现组织业务目标的持续提升，引领行业发展
0 条评论
下一页
为你推荐
查看更多
