本章论述了传统瀑布开发模式的严重缺陷，强调了迭代开发、敏捷开发的优势和重要性
为适应软件开发领域充满变数和难以预测的固有特性，迭代式开发出现了；
迭代式开发的每次迭代成果都是以最终实际产品的一个子集为实现目标，通过迭代与迭代之间不断向用户、出资方和设计者，编码人员以及测试人员等这些产品受众处收集反馈信息（诸如需求、设计、编码等方面的变化和改进要求），将这些变化纳入到后续的迭代过程中加以适应和实现；这样，每次迭代都是在上次迭代成果基础上的一次有价值的改进和递增，渐进式地逼近最终的真实需求和产品；
UP(统一过程)是迭代演进式开发的一种，具体分为4个阶段（phrases）,inception,elaboration,construction,transition，每个阶段都包含了由固定时间间隔（一般不超过6周）的多次迭代，每次迭代都涵盖软件开发的几乎每个领域（discipline），如业务建模、分析、设计、编码、测试、部署、配置管理以及项目管理等等；
- inception，可行性研究阶段，并最终决定实施还是下马；
- elaboration，每次迭代从用例中挑选对整体结构有重要意义的、最具商业价值的以及高风险的少量加以分析，并实现和测试这些用例中的关键部分（场景？），多次迭代后初步形成最终系统的架构雏形，规避了高风险因素，识别了大部分需求和作用范围，同时对项目有了更实际的估计；
- construction，通过多次迭代逐步实现用例中其他低风险和相对简单的部分，并准备部署
- transition，beta测试和部署
- 每个阶段中迭代对不同领域的关注程度是不同的，例如：elaboration阶段的迭代会侧重于业务建模、分析、设计，而construction阶段的迭代则会偏重于实现和测试多一些；
- 前面迭代开发中所强调的对反馈的收集和对变化的适应在上述4个阶段的迭代中是贯彻始终的
敏捷建模：
- 必须建模
- 强调建模的意义是沟通和理解而非记录；
- 设计者即实现者；
- 团队设计
- 只对最复杂和困难的部分建模，简单直接的设计决定都延迟到编码时
- 同步设计不同的模型（比如同步设计某类的类图和序列图）
- 强调采用尽可能少但有价值的UP实践和工作制品；
- 采用敏捷建模；
- 需求和设计要在迭代和演进的过程中不断基于反馈去适应和实现；
- 没有详细的项目计划，只有大致的阶段计划（如里程碑，交付日期），但不包含具体演进到某个里程碑的具体步骤；只对下一个迭代做详细计划，且每次都基于上次迭代的反馈作出调整；
思考：
- UP中架构性和高风险用例的挑选不好拿捏，书中也不打算给出这方面的实例
- 敏捷建模对编码人员的要求变高了，要求有设计能力，更多的所谓“简单”设计权力都下放到了编码期间；同时，由于对设计文档角色的弱化和建模覆盖面的缩小，对代码的可读性有了更高的要求，同时是不是需要加强注释的规范化？有没有技术上的可行性？doxygen？
- 收集反馈在迭代式开发中至关重要，我们的pp和reqm／rd人员需要说服用户去适应这种变化
0 comments:
Post a Comment