chapter1
- 概念 软件 = 程序+数据+文档
软件是计算机系统中与硬件相互依存的另一部分。包括程序 数据 相关文档的完整集合
1. 能够完成预定功能和性能的可执行指令(program
2. 使得程序能够适当地操作信息的数据结构(data)
3. 描述程序的操作和使用的文档(document)
- 软件危机
- 定义:软件在开发和维护中遇到的一些列问题
- 如何开发软件 如何维护数量不断膨胀的已有软件
- 表现
- 进度难以控制
- 需求在开发初期不明确
- 文档资料不完整、不合格
- 可维护性差
- 价格昂贵
- 原因: 客户 软件开发人员 管理人员 方法和工具
- 软件工程
研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件。即把工程化应用到软件上 - 软件生存周期 计划、分析、设计、实现、测试、集成、交付、维护
- 计划:确定待开发系统的总体目标和范围,研究系统的可行性和可能的解决方案,对资源、成本及进度进行合理的估算
- 分析:分析、整理和提炼所收集到的用户需求,建立完整的分析模型,编写成软件需求规格说明和初步的用户手册
- 设计:决定软件怎么做:软件体系结构 数据结构用户界面和算法
- 实现:编码
- 测试:对软件进行测试
- 运行和维护
- 软件工程三要素
- 工具(系统)
- 方法(技能)
- 开发过程(框架)
- 软件过程
- 瀑布
- 特点:
- 自上而下,相互衔接的固定次序
- 上一阶段的变换结果是下一阶段变换的输入,相邻的两个阶段具有因果关系
- 问题:
- 各个阶段完全固定 产生大量文档,增加了工作量
- 线性的开发模型,增加了风险
- 早期的错误等后期测试才能发现
- 特点:
- RUP 中心思想:用例驱动 架构为中心 迭代和增量
- 扩展的iconix
- 愿景 业务建模 需求分析 健壮性分析 关键设计 最终设计 实现
- scrum
- 四个会: 计划会 每日立会 评审会 反思会
- 瀑布
- 统一建模语言 UML
chapter2 踏上iconix软件过程之路
- 需求工程
通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持
- 需求开发:需求调查 需求分析 需求定义
- 需求管理:需求确认 需求跟踪 需求变更控制
- 愿景
- 找到软件项目的老大:要改善的组织中最有权力的干系人
- 得到老大对项目的期望(愿景)
- 描述出愿景的度量指标
chapter3 业务建模
- 把视角从软件系统转向客户组织,站在客户角度看问题
- 步骤:
1. 明确为谁服务:选定愿景要改进的组织
2. 要改进的组织是什么现状:业务用例图 现状业务序列图
3. 如何改进:改进业务序列图 - 从外部看,组织是价值的集合,用业务用例图来建模;从内部看,组织是系统的集合,用业务序列图来建模
- 业务用例图:从高层次了解组织的业务构成,组成:业务执行者 业务组织 业务用例
- 业务执行者:在组织之外与组织交互的人群或组织
- 业务用例:组织为业务执行者提供的价值
- 业务序列图:从细节上了解组织的业务流程
- 以面向对象的思想看业务流程
- 组成:业务执行者 业务工人 业务实体
- 作用
- 识别业务对象
- 确定业务对象间的职责,协作及交互顺序
- 通过序列图来了解现状,为业务的优化提供依据
- 业务序列图和改进业务序列图的价值
- 业务序列图展现现有业务流程,为优化提供直接依据
- 改进业务序列:模拟出新系统的出现对组织现行业务流程造成的影响,评估新系统的可行性或提前进行相应的准备工作
现状:业务专家的介绍
改进:老大的痛处和愿景;业务专家的抱怨;需求分析师的经验和智慧
chapter4 需求分析,用例分析法
- 主流分析方法:原型法 用例法
- 域建模
- 意义:统一术语
- 步骤:
- 根据需求文档,提取出名词和名词短语
- 排除列表中重复、相似的术语
- 排除超出系统范围的术语(系统范围外和系统本身)
- 画出第一版域模型图
- 整理第一版域模型
- 域建模间的关系:泛化 关联
- 域模型 不等于 数据模型
- 系统用例
-
步骤
- 绘制系统用例图
- 确定系统边界
- 识别系统执行者
- 识别系统用例
- 确定用例之间的关系
- 编写系统用例描述
- 更新域模型
- 绘制系统用例图
-
从业务组织转向新系统
-
组成:系统主执行者 系统副执行者 系统边界 系统用例 用例关系
-
用例关系
- 泛化
- 包含
- 扩展
-
用例描述
- 组成:干系人利益 基本路径 扩展路径 业务规则
- 主语只能是执行者或系统
- 非功能性需求rups
可靠性 可用性 性能 可支持性
-
chapter5 健壮性分析
- 优点
- 帮助完善用例分析结果;
- 完善域模型,
- 向需求分析走向系统设计做过度
- 三种元素
边界类 实体类 控制器类 - 交互规则
- 执行者只可以和边界对象通话
- 边界和控制器互相对话(名词 动词)
- 控制器和控制器相互通话(动词 - 动词)
- 控制器和实体对象相互通话
- 步骤
- 创建一个空的健壮性图
- 将用例描述关联到健壮性图上
- 从基本路径的第一句开始画健壮性图
- 贯穿整个用例基本路径,一次一个句子,画执行者、适当的边界对象和实体对象以及控制器和各元素之间的连线
- 将每一个扩展路径画在健壮性图上,并以红色标示出
chapter6 关键设计
- 步骤
- 将现有的域模型直接作为第一版静态类模型
- 基于用例描述和健壮性分析结果,画出每个用例的序列图
- 整理静态类图和序列图
- 关键设计复核,迭代更新用例图、类图和序列图
chapter7 详细设计
- 三层体系结构
- 用户界面层
- 业务逻辑层
- 数据访问层
chapter8 敏捷开发
-
敏捷宣言
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合作谈判
- 响应变化 胜过 遵循计划
虽然右项也有价值,但认为左项具有更大的价值
-
敏捷 = 理念 + 优秀实践 + 具体应用
理念:核心思想 value + team + adapting
1. value:聚焦客户价值 消除浪费
2. team:激发团队潜能,加强协作
3. 不断调整以适应(Adapting)变化
优秀实践:敏捷的经验积累
具体应用:能够结合自身灵活应用
chapter9 scrum敏捷过程一
-
scrum是一个增量的、迭代的敏捷开发过程
-
迭代式开发的好处
- 通过将高技术风险的需求在早期迭代里实现,有助于尽早暴露问题和及时消除风险
- 通过提供功能渐增的产品,持续从客户获得反馈,根据反馈及时调整,使得最终产品更加符合客户的需要
- 通过小批量减少排队,提供更灵活、快速的交付能力
- 平滑 人力资源的使用,避免出现瓶颈
-
scrum敏捷开发过程
- 项目整个开发周期包括若干个小的迭代周期,每个迭代周期称为一个sprint
- 使用产品backlog来管理项目的需求,产品backlog是一个按照商业价值排序的需求列表,体现形式通常为用户故事(userstory)
- 团队从产品backlog中挑选最有商业价值的需求,经过sprint计划会议上的分析、讨论和估算得到任务列表,称为sprint backlog
- 在每个迭代结束时,scrum团队将交付潜在可交付的产品增量
-
敏捷人员组成:
- PO:产品负责人
- SM:敏捷教练
- T:开发团队
- Stakeholders:干系人
-
四个会:计划会 每日立会 评审会 反思会
-
敏捷团队:po sm team
chapter10 scrum敏捷过程二
-
产品backlog 产品backlog是需求动态管理的载体
-
pbi的deep特征
- 详略得当
- 涌现的
- 做过估算
- 排列了优先级
-
燃尽图:
-
scrum组成
- 三个角色: 产品负责人 敏捷教练 团队
- 四个会议:迭代计划会议 每日立会 迭代评审会议 迭代回顾会议
- 三个产物:Product Backlog , Sprint Backlog, 燃尽图
-
scrum特点
- 适于在不确定性高的环境中开发复杂产品
- 简洁有效
- 项目信息对所有干系人高度透明
- 便于快速发现问题,促使团队和组织持续改进
-
请简述Scrum软件过程中有哪些角色,及其职责?
- PO(Product Owner 产品负责人)、职责:
(1)代表利益相关人(如用户、Marketing、 管理者等),对产品投资回报负责
(2)确定产品发布计划
(3)定义产品需求并确定优先级
(4) 验收迭代结果,并根据验收结果和需求变 化刷新需求清单和优先级
- Scrum Master(Scrum教练)、职责:
(1)辅导团队正确应用敏捷实践
(2)引导团队建立并遵守规则
(3)保护团队不受打扰
(4)推动解决团队遇到的障碍
(5)激励团队
- Team(开发团队),职责:
(1)负责估计工作量并根据自身能力找出最佳 方案去完成任务且保证交付质量
(2)向PO和利益相关人演示工作成果(可运行 的软件)
(3) 团队自我管理、持续改进
- PO(Product Owner 产品负责人)、职责:
chapter11 敏捷工程实践
用户故事
- 用户故事:作为一个XXX客户,我需要XXX功能,能够带来XXX好处。 (角色 功能 价值)
- 用户故事的3c原则
- 卡片:作为XX,我希望XXX,这样可以XXX
- 对话:不描述到细节,由团队通过持续对话细化,激发大家的深度理解
- 确认:有明确的验收标准
- invest标准
- 独立性
- 可协商
- 有价值
- 可估算
- 短小
- 可测试
- 测试驱动开发TDD
- 定义:以测试为编程的中心,它要求在编写任何代码之前,首先编写定义代码功能的测试用例,编写的代码要通过用例,并不断进行重构优化
- 要求TDD要求测试可以完全自动化运行
- 关键:
1. 测试代码和源代码一样需要简介,可读性好
2. 测试用例的设计要保证完备,覆盖被测单元的所有功能
3. 每个测试用例尽量保持独立,减少依赖,提高用例的可维护性
4. 当功能单位较大时,为降低难度,可分解为多个更小的功能单位,并逐一用tdd实现 - 好处
1. 和代码同步增长的自动化测试用例,能为代码构筑安全网
2. 保证代码重构质量
3. Tdd有助于开发人员优化代码设计
4. 提高代码可测试性