• 对用户的需求理解错误(反映在我们通信企业，很多时候表现为对协议或规范的需求理解不准确)。我们对需求的表示，就是用需求文档，用户很难对我们的需求文档提出建设性的一件或者是发现文档中的错误。而且就是系统的开发人员很多时候也是无法从需求文档里获取足够的信息，只好去问写文档的人或知道的人。
• 无法应对经常变化的需求，在软件开发过程中，需求可能经常在变，原因可能是用户本身需求的变化，也可能是我们对需求的理解在发生变化，但结果是每次需求变化会带来软件系统的开发延迟，最糟糕的情况是推倒了重来。
• 模块适应性差，单独的模块在整合前都运行正确，但一旦整合，系统变得极其不稳定，甚至根本就无法工作。
• 系统难以维护或扩展。系统的框架设计人员，没有软件架构的概念，导致软件架构的非常脆弱，系统当然难以维护或扩展。
• 严重的项目缺陷到项目进展了很长时间才被发现。
• 软件系统质量低劣。生活中，但我们掏钱买东西时，不光要求便宜，还要求质量高，常常对着日本的电子产品发出感叹，不比不知道，一比我们的产品质量。。。。软件作为特殊的产品，低劣的质量就如生活中伪劣产品，要被人骂的。
• 难以接受的软件性能。
• 项目管理混乱，项目成员对软件产品的修改随意，经常导致系统的不可重见性。
• 编译和发布过程不可信赖。
  所以我们的很多软件项目，长期面临着”产品质量低下”，:”进度延误”，”费用超支”等问题。

如何解决这些问题？OOAD能帮我们忙吗？

上面这些问题，相信是在我们以前的软件开发项目中经常可以目睹和经历的，平时大家对这些问题深恶痛绝，都希望自己参与的软件系统质量能够很好，但是质量往往是被软件开发人员挂在嘴边的事情，却很少去动，去解决这些问题。要找到好的解决办法，我们先来大师们是如何分析这些问题的原因。大师们分析下来，出现上面问题，原因如下：

• 需求管理不够充分。
• 交流方式的不准确性和不严密性。
• 脆弱的软件架构。
• 难以理解的复杂。
• 需求、设计和实现的不一致性。÷ w 没有充分的产品测试。
• 不客观的项目状态评估。
• 瀑布开发导致的风险性没有及时解决。
• 不受控的变更管理。
• 缺乏有效的自动辅助工具，整个软件生命周期中没有很好的利用工具。
  

针对以上现象以及对这些问题的分析，大师们总结了六大解决问题的经验。

• 迭代式开发
• 管理需求
• 使用组件构架
• 可视化建模
• 持续不断的验证质量
• 管理变更

注：其中打”√”,表示能够解决。

二、 管理需求

高效管理需求是一个成功软件项目的必备条件。在OOAD With UML,可以用Use Case高效地对需求进行管理，而且还可以保证需求与实现的一致性。在OOAD中通过下述方法，可以较早地发现需求中地错误。

• 对问题域(业务)进行详细分析，OOAD中采用业务建模的方法来帮助系统分析师去理解和捕获用户(广义的)的需求。(需借助工具来完成)
• 与用户/客户对需求的理解保持一致，防止对需求的歧义理解。OOAD中通过采用标准建模语言UML的方法来消除歧义。(需借助工具来完成)
• 对用户和系统的交互进行建模。(需借助工具来完成)
• 建立需求基线和需求变更控制流程。(这需要借助工具来帮助完成)
• 维护需求的可跟踪性，OOAD中，用用例来管理需求时，通过流程和工具来保证用例与分析设计和实现的一致性。
• 使用迭代开发过程。
  上面讲的是在OOAD中可以通过哪些方法来尽早发现需求中的问题，下面将列举出通过管理需求可以解决以及如何解决大师们分析的导致问题的根本原因。

三、 使用基于组件的构架

软件系统的开发中，架构设计师或称系统总体设计员，设计系统框架时，没有很好的架构设计思想和能力，只是在功能上达到了暂时的需求，这样一旦需求发生变化，原来的框架就变得非常不稳定。这样的构架是极其脆弱的，就像没有采用钢筋水泥的高层楼房，扩展性差，难维护。再做类似的系统，可重复利用的价值几乎没有。然而在OOAD设计中，尤其是RUP中，非常强调软件构架的重要性，RUP的核心观念就是”用例驱动，以构架为中心，迭代和增量”。软件系统中，架构设计师的是如此影响整个软件系统，以至于对架构设计师的要求很高，据Rational人员讲，在爱立信最年轻的架构设计师当年36岁(成为架构设计师师)。在OOAD中一个好的架构可以给我们带来:

• 一个好的架构不仅要满足需求，并且要是灵活的和基于组件的。
• 一个灵活的构架具有如下优势:
  ·大大地提高了可维护性和可扩展性。
  ·能充分利用重用，缩短开发周期和开发资金。只有良好地架构，才能够很好地去重用以前的组件。
  ·能指导项目组的工作划分。一个良好的构架，对开发人员的分工安排具有很大的指导意义。比如在OMC-R中，应用服务器课题主要是负责OMC-R架构中的Business Services层，而系统支撑层主要负责OMC-R架构中的Business Deliver层，OMT主要是OMC-R架构中的应用层，同样在每个课题组内部项目组的成员分工与OMC-R的架构是紧密相关的。
  ·封装了对硬件和系统的依赖性，使其它模块与系统无关。
• 一个基于组件的构架具有如下优势:
  ·重用或定制现有的组件，这就要求在我们平时的工作中，能形成一些组件库，一是利于好的劳动成果共享，二是避免重复性劳动。
  ·可以选择成千上万的商业组件，加快开发进度，同时可以降低对人员的需求和要求。不能因为在一个项目中需要用到某样东西，就去招个人来，这样开发成本会上涨，而且增加了开发风险。
  ·对现有软件的改进，比较方便。
  使用基于组件的构架，可以解决在软件开发中如下问题。