《RUP导论》笔记(一)

ξ 1.2 软件开发问题的症状和根本原因

 

☆ 失败项目的一些共同症状：

  ① 对于最终用户的需求理解得不够精确；

② 不能处理需求变更；

③ 模块之间不兼容；

④ 软件不易维护和扩展；

⑤ 对项目的严重缺陷发现较晚；

⑥ 软件质量低劣；

⑦ 软件性能让人无法接受；

⑧ 团队中人员按各自的开发方式工作，项目难以重构；

⑨ 一个不可靠的构造和发布过程。

 

☆ 失败项目的根本原因：

① 特别的需求管理；

② 模糊和不精确的交流；

③ 脆弱的架构；

④ 过度复杂；

⑤ 未检测出需求、设计和实现中的不一致；

⑥ 测试不足；

⑦ 对项目状况的评估过于主观；

⑧ 未解决存在的风险；

⑨ 无法控制变化的传播；

⑩ 自动化程度不足。

 

ξ 1.3 最佳的软件实践

 

☆ 软件开发最佳实践：

 ① 迭代开发：传统软件开发常使用瀑布模型，它将项目生命周期划分为需求分析阶段、设计阶段、编码和单元测试阶段、子系统测试阶段和系统测试阶段。该模型将项目开发各个阶段线性排列一直到项目结束，在项目交付使用前，很难拿出看得见的东西与用户沟通，而我们在开发系统的时候，往往是：“在看到东西之前，用户也不知道自己要的是什么东西”。瀑布模型的危害还表现为可能掩盖项目中存在的真正风险，而当你发现时已经太晚了。

迭代开发可以提供的解决软件开发问题的方案：

⑴ 可以在生命周期早期发现严重的需求理解错误，这是还可以修正这些错误；

⑵ 这种方法允许并鼓励用户反馈信息，从而抽取出系统的真正需求；

⑶ 这种方法使开发团队将注意力集中到项目中最关键的问题上，并屏蔽掉那些分散他们对项目中真正风险的注意力的问题。

⑷ 持续的、迭代的测试可以为项目状况给出客观的评估；

⑸ 需求、设计和实现中的不一致能够在早期被发现；

⑹ 在整个项目的生命周期中可以更加平均地分配整个团队，尤其是可以平均分配测试团队的工作量；

⑺ 团队可以在过程中总结经验教训，不断地改善开发过程；

⑻ 在整个生命周期中，项目相关人员可以通过具体证据来了解项目情况。

 

 ② 管理需求：需求在软件开发的生命周期中是具有动态性的。管理动态需求应至少包含三项活动：

  ⑴ 抽取、组织系统所需要的功能和约束并将其文档化；

  ⑵ 估计需求的变化并评估这些变化所带来的影响；

  ⑶ 跟踪并记录所做出的权衡和决定。

管理需求可以提供的解决软件开发问题的方案：

⑴ 在需求管理中构造原则性方法；

⑵ 人员之间的交流建立在已定义的需求之上；

⑶ 区分需求优先级，并进行过滤与跟踪；

⑷ 可以对功能和性能做出客观的评估；

⑸ 不一致性会尽早检测出来；

⑹ 借助适当的工具支持，使用与外部文档的自动连接，可以为系统的需求、属性和轨迹提供库支持。

 

③ 应用基于构件的架构

 使用基于构件的架构可以提供的解决软件开发问题的方案：

   ⑴ 构件有利于创建灵活性强的架构；

   ⑵ 模块化可以清晰地分离出系统中易于变化的元素；

   ⑶ 通过应用标准化的框架和商业上可获取的构件使复用更加容易；

   ⑷ 构件为配置管理提供一个非常自然的基础；

   ⑸ 可视化建模工具为基于构件的开发提供自动化的支持。

 

④ 为软件建立可视化模型

为软件建立可视化模型可以提供的解决软件开发问题的方案：

   ⑴ 通过用例和场景可以无二义性地详细说明行为；

⑵ 通过模型可以无二义性地理解软件设计；

⑶ 暴露出非模块化的和不灵活的架构；

⑷ 必要时可以隐藏细节；

⑸ 无二义性地设计可以更容易地反映出不一致性；

⑹ 高质量的应用程序应从好的设计开始；

⑺ 可视化建模工具提供对UML建模的支持。

 

⑤ 对软件的质量进行持续的验证

对软件的质量进行持续的验证可以提供的解决软件开发问题的方案：

  ⑴ 对于项目状况的评估是客观而非主观的，因为我们评价的是测试结果而非书面文档；

⑵ 这个客观的评估可以暴露出需求、设计和实现中的不一致；

⑶ 测试和验证工作关注的是高风险区域，因此增加了这些区域的质量水平和效率；

⑷ 可以尽早发现缺陷，从根本上降低修复他们的代价；

⑸ 自动化测试工具提供了对功能、可靠性和性能的测试。

 

⑥ 控制需求变更

控制需求变更以提供的解决软件开发问题的方案：

  ⑴ 定义需求变更的工作流，且需求变更的工作流是可重复的；

⑵ 变更请求使交流更加清晰；

⑶ 独立的工作空间减少了并行工作的团队成员之间的相互干扰；

⑷ 变更率统计表为客户评估项目状况提供了很好的度量；

⑸ 工作空间包含了所有制品，这样有利于保持一致性；

⑹ 变更的传播是可评估和可控制的；

⑺ 可以在一个健壮的、可定制的系统中维护变更。

 

ξ 1.4 小结

 

第一章看完，提出了六点软件开发的最佳实践。

第一是迭代开发，要做到从需求到发布的小增量迭代开发，必须要借助一些工具，比如版本控制工具、每日构建工具、自动化测试工具以及完善的缺陷跟踪机制，否则开发将陷入混乱无序的状态。

第二是动态需求管理，这里着重强调动态两个字，因为一个软件系统的开发，从头到尾，需求不变的情况几乎从来没有过。可以说第六点控制软件的变更和第二点是一个意思。正确评估需求变动对系统的影响，控制变动的传播。

对于第三点，我还是持保留意见的。面向构件的开发像空中楼阁一样，目前还看不到什么成熟的应用，COM晦涩复杂，从来就没有流行过；EJB最近更是备受质疑，事实也证明EJB2的技术并不怎么成功。一个应用确实应该有一个良好的基础框架，但不一定是面向构件的，模块化也确实是很好的思路，但粒度是否应该控制在构件一级，个人表示怀疑。

第四为建模，没什么好说的，上UML就可以了。

第五为对软件的质量进行持续的验证，在迭代开发中，每次迭代都应该进行严格的测试，确保本次迭代中测试发现的缺陷最终都被关闭。质量验证至少包含三个方面：对代码质量的验证、确保性能满足要求以及实现与需求保持一致。

 

归纳一下，到目前为之，我对RUP最佳软件实践的理解应该是：小增量迭代开发、动态需求管理、良好的基础框架、UML建模和持续的质量验证。