目录
软件过程模型（软件开发模型）
软件过程模型也叫软件开发模型，是我们进行软件开发的时候需要遵循的一些思想和规范
瀑布模型
特点：严格区分阶段，每个阶段因果关系紧密相连，但是只适合需求明确的项目
缺点：
软件需求完整性、正确性很难确定
严格串行化、很长时间才能看到结果
瀑布模型要求每个阶段一次性完全解决该阶段的工作，这不现实。
原型模型
原型的思想就是构造一个简易系统，由他来获取需求。原型模式我们一般用在需求分析阶段
V模型
这个模式是强调测试贯穿始终的开发模型。
构件组装模型
优点：
容易扩展、重用、降低成本、安排任务更灵活
缺点：这个要求经验丰富的架构师、设计不好的构件难以重用、强调重用可能牺牲其他的指标（比如性能）、第三方构件质量难控制。
螺旋模型（原型+瀑布）
以快速原型为基础+瀑布模型，这个模型考虑了风险问题。
四个关键字：目标设定、风险分析、评审、开发和有效性验证
基于构件的软件工程（CBSE）
它该具备的特征：
可组装性：所有外部交互必须通过公开定义的接口进行
可部署性：构件总是二进制形式的，能作为一个独立实体在平台上运行
文档化：用户根据文档来判断构件是否满足需求
独立性：可以在没有其他特殊构件的情况下进行组装和部署
标准化：符合某种标准化的构件模型
构件的组装：
顺序组装：按照顺序调用已经存在的构件、可用两个已经有的构件来创造一个新的构件
层次组装：被调用构件的接口和调用构件的请求接口必须兼容
叠加组装：多个构件合并形成新构件、新构件整合原构件的功能、对外提供新的接口
快速应用开发模型（RAD）
多个模型拼装成的新的模型，瀑布模型有标准的开发流程、CBSD有构件的支撑。
统一过程（UP）/统一开发方法
主要用在大型软件开发应用里面
核心特点：用例驱动、以架构为中心、迭代和增量
四大阶段
初始：定义产品的业务模型、确定系统的范围
细化：设计及确定系统架构、制定工作计划以及资源要求
构造：开发剩余构件和应用程序功能、把这些构件集成为产品、并进行详细测试
移交：确保软件对最终客户是可用的，进行测试、制作产品的发布版本.
九大核心工作流
- 业务建模
- 需求
- 分析和设计
- 编码实现
- 测试
- 部署
- 配置和变更管理
- 项目管理
- 环境
敏捷开发方法
是通过迭代而来的
最开始是没有开发方法的，没有顺序、不可空
到了一定的时间出现了传统软件开发方法：预设姓的、以开发过程为本、整体分阶段
最后才出现了敏捷方法：适应性的，以人为本、增量迭代、小不快跑、适合小型项目
敏捷宣言
- 个体和交互胜过过程和工具，强调了人的重要性
- 可工作的软件胜过大量的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
敏捷方法-xp
四大价值观：沟通、简单、反馈、勇气
12条过程实践规则
敏捷方法-SCRUM
极限编程 -xp
价值观【交流、朴素、反馈、勇气】、近螺旋式的开发方法
水晶方法
提倡机动性的方法，拥有对不同类型项目非常有效的敏捷过程
SCRUM
侧重于项目管理
特征驱动开发方法（FDD）
这个方法认为有效的软件开发需要3要素【人、过程、技术】定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家
开放式源码
程序开发人员在地域上分部很广
ASD方法
核心就是三个非线性的、重叠的开发阶段：猜测、合作和学习
动态系统开发方法（DSDM）
倡导以业务为核心
逆向工程
实现级：包括程序的抽象语法树、符号表、过程的设计表示，这个是最接近代码层面的
结构级：包括反映程序分量之间相互依赖关系的信息、例如：调用图、结构图、程序和数据结构
功能级：包括反映程序段功能及程序段之间的关系的信息，例如数据和控制流模型
领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应的关系的信息，例如实体关系模型
与逆向工程相关的概念是：重构、设计恢复、再工程、正向工程
重构：在同一抽象级别上转换系统描述形式
设计恢复：借助工具从已有程序中抽象出有关数据设计、总计结构设计和过程设计等方面的信息
再工程：对现有系统的重新开发、包括逆向工程、新需求的考虑过程和正向过程的三个步骤
正向工程：不仅从现有的系统中恢复设计信息、而且使用该信息去改变或重构现有系统、以改善他的整体质量。
净室软件工程
净室：无尘室、洁净室、也就是一个受控污染级别的环境
使用盒结构规约或者形式方法进行分析和设计建模、并且强调将正确性验证、而不是测试，作为发现和消除错误的主要机制
使用统计的测试来获取认证被交付的软件的可靠性所必需的出错率信息。
技术手段主要四个方面
- 统计过程控制下的增量式开发：控制迭代
- 基于函数的规范和设计：盒子结构：定义三种抽象层次：行为视图（黑盒）——>有限状态机视图（状态盒）——>过程视图（明盒）
- 正确性验证：净室工程的核心
- 统计测试和软件认证：使用统计学原理、总体太大时必须采用抽样方法
缺点：
- 太理论化，正确性验证的步骤比较困难和耗时间
- 开发小组不进行传统的模块测试。这是不现实的
- 脱胎于传统软件工程、不可避免带有传统软件工程的一些弊端
![[Linux][Shell][Shell逻辑控制]详细讲解](https://i-blog.csdnimg.cn/direct/ba5e4f2636f447d7b6ce2f6960dd99ba.png)
