导图社区 系统架构设计师之开发方法
本章思维导图涵盖了系统架构设计师之开发方法的相关内容介绍，非常推荐大家点进来学习，内容实用干货满满。
系统架构设计师第2版最新内容-2023年，其他章节陆续发布中，请关注。重要章节会收取点费用，望支持。
系统架构设计师第2版最新版改版内容-2023年 其他章节陆续发布中，请关注。重要章节会收取点费用，望支持。
社区模板帮助中心，点此进入>>
互联网9大思维
组织架构-单商户商城webAPP 思维导图。
域控上线
python思维导图
css
CSS
计算机操作系统思维导图
计算机组成原理
IMX6UL(A7)
考试学情分析系统
软件开发方法
软件生命周期
可行性研究和计划
则将产生《可行性研究报告》和《软件开发计划》
需求分析
概要设计
详细设计
实现
编码
单元测试
集成测试
确认测试
使用和维护
软件维护的过程会贯穿整个软件的使用过程
结构化法
原型法
面向对象方法
面向服务方法
软件开发模型
瀑布模型
核心思想：
软件开发阶段划分明确，每个阶段之间都有明显的界线 阶段之间会有固定的文档或者源程序
V模型
瀑布模型中，最后的测试无法完全保证软件没有缺陷
针对瀑布模型的需求分析、总体设计、详细设计，提出了系统测试、集成测试、单元测试
缺点：
需求分析是一切活动的基础，一旦需求存在偏差，则会发生错误
难以适应变化
在所有阶段都结束后才能交付软件产品
产生一大堆文档，但是很多文档对用户都没有意义
演化模型
若干次瀑布模型的迭代 软件在这样的迭代过程只能够演化、完善
螺旋模型
结合了瀑布模型和演化模型
需求定义
风险分析
工程实现
评审
强调风险分析，在每一个“瀑布”开发之前，引入一个非常严格的风险识别、分析和控制
优点
适用于庞大而复杂、具有高风险的系统
支持用户需求的动态变化
缺点
需要丰富的风险评估经验和专业知识
过多的迭代会增加开发成本
增量模型
策略
增量发布
系统技术架构成熟、风险低的时候，可以采用增量的方式进行开发，将系统划分为若干个不同的版本，每一个版本都是一个完整的系统
每一个版本都是一个完整的版本
版本间的增量要均匀
针对一般需求进行快速实现，精确获取用户需求，或者验证架构的可用性
构件组装模型
经过需求分析定义的软件功能后，将对构件的组装结构进行设计，将系统划分为一组构件的集合，明确构件之间的关系
开发过程
设计构件组装
建立构件库
构建应用软件
测试与发布
系统扩展性增强
良好的构件更容易被重用，降低软件开发成本
开发任务更加灵活，可以独立开发构件
需要经验丰富的架构师
考虑软件重用度时，往往会对一些指标进行妥协
开发人员需要熟悉构件，增加学习成本
第三方构件的质量无法掌控
统一过程
二维模型
UP任何一个阶段的工作都不是绝对的，都是相互配合的，但每一个阶段都有侧重点
阶段
初始
界定系统范围、明确系统目标
业务建模、需求
细化
分析设计
抽象软件模型
设计软件架构
构建
系统构建
实施和测试
交付
重构、修改、测试、部署
UP核心工作流
业务建模
需求
实施
测试
部署
配置与变更管理
项目管理
环境
生命周期
目标里程碑
架构里程碑
能力里程碑
发布里程碑
特点
每一个阶段都可以进行需求、设计等活动
不同迭代方式的UP可以演变成演化模型或增量模型
更容易控制软件开发的风险
UP是一个迭代的开发模型，但UP本身并不属于敏捷方法。一般认为，未经裁剪的UP是一个重载过程
实际过程中可以对UP进行裁剪以适应各种规模的软件开发和团队
敏捷方法
极限编程
更短周期，更早的提供具体、持续的反馈信息
首先迅速生成一个总体计划，然后再整个项目开发过程中不断的发展它
依赖于自动测试程序监控开发进度，并及早捕获缺陷
依赖于口头交流、测试和源程序进行沟通
倡导持续的、演化式的设计
依赖于开发团队内部的紧密协作
尽可能达到程序员短期利益和项目长期利益的平衡
四大价值观
沟通
简单
反馈
勇气
12个最佳实践
计划游戏
小型发布
隐喻
简单设计
测试先行
重构
结对编程
集体代码所有制
持续集成
每周工作40小时
现场客户
编码标准
特征驱动开发
概念
迭代开发模型
FDD每一步都强调质量，不断交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息
弱化了过程在软件开发中的地位
三要素
人
过程
技术
角色定义
项目经理
开发组织者
首席架构设计师
负责系统架构的设计
开发经理
负责团队日常的开发
解决技术问题和资源冲突
主程序员
程序员
领域专家
对业务领域精通的人，一般由客户、系统分析员等担当
核心过程
开发整体对象模型
系统、完整的面向对象建模
构造特征列表
特征指细化的对客户有价值的功能
采用动作、结果和目标来描述特征
计划特征开发
特征设计
调整构建
scrum
定义
一个用于开发和维护复杂产品的框架
是一个增量的、迭代的开发过程
五个主要活动
产品待办事项列表梳理
产品待办事项范围大
需求变更多
优先级会变更
sprint计划会议
会议内容
在sprint中完成什么工作
产品代办事项数目由开发团队决定
怎么完成工作
每日scrum会议
上一日完成了什么
今日计划完成什么
有什么困难
sprint评审会议
sprint结束时，scrum团队和相关人员一起评审sprint的产出
展示当前产品增量的概况
sprint回顾会议
sprint结束后，scrum团队会聚在一起开sprint回顾会议 回顾团队在流程人机关系及工具方面做得如何
什么做得好
找出潜在的改进事项，为将来改进制定计划
水晶方法
透明水晶
经常交付
反思改进
渗透式交流
子主题
个人安全
指出问题时不会受到报复
焦点
明确首先做什么，然后安排时间，以平很好的心态开展工作
与专家用户建立方便的联系
配有自动测试、配置管理和经常集成功能的技术环境
开放式源码
程序开发人员在地域上分布很广
查错排障的高度并行性
ASD（adaptive software development）
三个非线性、重叠的开发阶段
猜测
合作
学习
软件重用
源码重用
架构重用
应用框架重用
业务建模的重用
文档及过程重用
软件服务的重用
基于架构的软件设计 ABSD
基础
功能分解
使用已有的基于模块的内聚和耦合技术
通过选择架构风格来实现质量和业务需求
软件模板的使用
ABSD方法
实际构件设计
基于架构的软件开发模型
需求获取
标识构件
生成类图
对类进行分组
把类打包成构件
需求评审
设计
提出架构模型
映射构件
把在架构需求阶段标识的构件映射到架构中
分析构件相互作用
产生架构
设计评审
文档化
复审
演化
需求变动归类
制定架构演化设计
修改、增加或删除构件
更新构件的相互作用
构件组装与测试
技术评审
产生演化后的架构
形式化方法
