本文参考自 Software Engineering : A Practitioner’s Approach — 8th edition by Roger S. Pressman
3.1 process的4种通用型流程
4、process模型
秩序(order)与混乱(chaos)是软件流程的光谱的两个极端
4.1.0 code & fix
- 适合小型软件
4.1.1 Waterfall
- 需求是已知确定+固定的
- 一次成型，不能适应变化/更改
- 用户必须能耐心等到最后的阶段
- 后面的模块要等待前面模块完成
- 能见度高
- 码农容易定位当前的开发阶段
V-model （瀑布模型的变体）
4.1.2 Incremental Process Models
- 快速向用户提供基础功能
- 同时具备linear和parallel的特征
- 需要从一开始就可拓展
4.1.3 Evolutionary Process Models
- 需求未来会更改
- 要求尽快上线
Prototyping
- 第一个版本很可能又慢又大又难用
- 用户可以今早体验使用
- 程序员可以尽早写code
从Communication开始
- 用户可能觉得这个prototype已经够用了，从而要求尽快上线
- 实际上，目前的版本存在深层bug且不可维护
- 程序员可能会为了尽快交差而敷衍
- 因此，需要和客户约定好，这个prototype只是用来确认需求
Spiral Model
- 每一次循环都提供一个完整功能的软件
从Communication开始
- 第一个循环确认需求
- 第二个循环之后依次产生prototype
- 适合大型软件开发
- 在各个的阶段产生prototype
缺点
- 需要经常进行risk assessment
- 不确定需要多少个cycle
4.1.4 Concurrent models
- 任一时间都可以进行任一操作
- 任何时间都能modeling
- 任何时间就能communication
4.2 特殊process
- Component-Based Development
- 使用/购买第三方开发的Commercial off-the-shelf模块，直接拿来集成到现有的系统内
- Formal Methods Model
- 一个变体叫做cleanroom software engineering
- 不太主流
- 成本高，需要大量培训
- 难以与客户沟通
- 使用在性命攸关（医疗设备）+巨额损失（Amazon）系统
4.3 Unified process
- 集成传统的软件开发方法
- 使用UML描述requirements和design模型
以下5个阶段可能以concurrency的方式运行
5、Agile Development
| |价值驱动法 | 计划驱动法 | 正式法 | |
|---|---|---|---|
| 适用环境 | 低临界 | 高关键性 | 极端的危险 |
| 从业者 | 资深开发人员 | 初级开发者 | 资深开发人员 |
| 需求更改 | 需求经常变化 | 需求不经常改变 | 有限的需求 |
| 投入 | 少量的开发人员 | 大量的开发人员 | 可以建模的需求 |
| 团队风格 | 响应变化的文化 | 要求秩序的文化 | 极致的品质 |
敏捷软件开发宣言
- 个体和互动：高于流程和工具
- 工作的软件：高于详尽的文档
- 客户合作：高于合同谈判
- 响应变化：高于遵循计划
- agile不一定适应所有的项目、产品、人员、环境
- 但是，快速变化的（手机软件）市场使得“完全了解需求”变的不可能
- agile最大的优势是“适应变化”
5.2 Change的成本
- Agile可以平坦化传统的成本
- 尤其是在使用unit testing和pair programming的情况下
5.3 Agile的内容
- 最重要的是通过尽早和不断交付有价值的软件满足客户需要
- 客户和开发者在整个项目过程中应该始终朝夕在一起工作
- 在开发小组中面对面的交谈
- 可以工作的软件是进度的主要度量标准
- 测试是在每一次迭代（iteration）中完成的
- 开发一小部分软件，用户可以经常使用这些新的软件并验证其价值
对比其他的方法
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.
- 对比迭代方法
- 相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。
- 对比瀑布式开发
- 两者没有很多的共同点，瀑布模型是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
- 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
5.4 Extreme programming (XP)
- 结对编程
- 开发人员和客户之间当场交互
- 测试驱动的开发
- 测试用例在实际代码之前就被写出来
- 如果一段代码没有经过测试，就不能认为它可以工作
5.5 Scrum方法
- (Product) Backlog
- 本质上是一个关于需求的priority queue
- 可以随时插入新的需求并改变priority
- Sprint (Backlog)
- 正在进行中，不可更改
- 30天内对这些需求进行编程
- Scrum meetings
- 每天站立进行，每次15分钟
- 每个人讲自己的进展、困难、短计划
大项目区别于中小项目的特征
- 多子系统、多团队开发
- 与已有的系统对接
- 更多时间花在系统配置上，而不是写码
- 条条框框多，限制多
- 开发周期长
- 老板多，stakeholder 多
为什么敏捷开发不适合大项目？
- 客户无法介入所有细节
- 大项目不够 incremental
- agile 需要大量的 interaction
- 大项目可能分散在各个分公司
- 大项目需要 documentation
6、Human Aspects of 软件工程
6.1就讲了一些诚实负责抗压谨慎细致之类的事情
6.2 - 6.3主要讲团队建设
6.4 Team Structures
- 最传统的组织方式：chief programmer team，又叫做 closed paradigm
- 团队核心叫做 senior engineer / chief programmer
- 外加2到5个technical staff
- 还要有backup engineer作为chief的替补
chief programmer team
chief programmer 负责计划、协调统筹、审阅团队内所有的技术细节
一个技术超强的大神，在得到足够的帮助和支持后，可以比一群平庸的码农更快、更可靠的写程序。队伍里的交流成本得到了最小化。
首席程序员团队在极少数情况下可以说是有意义的。在这种情况下，你有一位近乎天才的人 - 比你的员工平均程序员的效率高得多。 但是一般来说，附近的天才人数远远少于渣渣，这限制了该技术的适用性。
6.5 Agile team
- 好的Agile团队应该是self-organizing的
- 不一定要固定的结构
- 近似 open paradigm 的概念
- 减少“计划”，各自想办法实现细节
- 每天交流，实现 incremental delivery of software
6.6 社交媒体
- email、微信和视频可以认为是面对面交流的替代品
- 但是，随着团队规模增加，社交媒体的功能越来越明显
- 如果团队在地理上分散，那么功能更明显
- 很多公司都使用博客/微博进行内部、外部交流
- 要注意保密和安全
6.7 云端开发
- 交流信息无需依赖具体的平台/硬件
- 但是，可能会增加安全、可靠性方面的复杂度
6.8 合作工具
- 很多软件开发环境都帮助团队里的成员进行合作
- 工具为团队提供很多的功能
- namespace
- 日历
- 模板
- metrics
- 讨论内容分析
- 追溯更改内容的过程
