【IT168 技术文章】

    在一个软件系统的开发过程中，我们会经常碰到以下情况：

    对用户的需求理解错误(反映在我们通信企业，很多时候表现为对协议或规范的需求理解不准确)。我们对需求的表示，就是用需求文档，用户很难对我们的需求文档提出建设性的一件或者是发现文档中的错误。而且就是系统的开发人员很多时候也是无法从需求文档里获取足够的信息，只好去问写文档的人或知道的人。

    无法应对经常变化的需求，在软件开发过程中，需求可能经常在变，原因可能是用户本身需求的变化，也可能是我们对需求的理解在发生变化，但结果是每次需求变化会带来软件系统的开发延迟，最糟糕的情况是推倒了重来。

    模块适应性差，单独的模块在整合前都运行正确，但一旦整合，系统变得极其不稳定，甚至根本就无法工作。

    系统难以维护或扩展。系统的框架设计人员，没有软件架构的概念，导致软件架构的非常脆弱，系统当然难以维护或扩展。

    严重的项目缺陷到项目进展了很长时间才被发现。

    软件系统质量低劣。生活中，但我们掏钱买东西时，不光要求便宜，还要求质量高，常常对着日本的电子产品发出感叹，不比不知道，一比我们的产品质量。。。。软件作为特殊的产品，低劣的质量就如生活中伪劣产品，要被人骂的。

    难以接受的软件性能。

    项目管理混乱，项目成员对软件产品的修改随意，经常导致系统的不可重见性。

    编译和发布过程不可信赖。

    所以我们的很多软件项目，长期面临着”产品质量低下”，:”进度延误”，”费用超支”等问题。

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

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

    需求管理不够充分。

    交流方式的不准确性和不严密性。

    脆弱的软件架构。

    难以理解的复杂。

    需求、设计和实现的不一致性。÷ w 没有充分的产品测试。

    不客观的项目状态评估。

    瀑布开发导致的风险性没有及时解决。

    不受控的变更管理。

    缺乏有效的自动辅助工具，整个软件生命周期中没有很好的利用工具。

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

    迭代式开发

    管理需求

    使用组件构架

    可视化建模

    持续不断的验证质量

    管理变更

    如何使用这些经验呢?我们的建议是使用OOAD With UML，结合Rational公司的”统一软件开发过程(RUP)”。下面将介绍采用OOAD With UML，结合Rational公司的”统一软件开发过程(RUP)”如何解决我们在软件开发中常碰到的问题。

    OOAD、UML、ROSE如何贯穿六大成功经验

    首先我们来分析一下，六大成功经验是如何解决上面提出的问题的。