软件工程之设计（好软件系列三）

看过之前的好软件系列文章“软件工程之需求管理，软件工程之QA管理”，想必大家都知道，软件工程关注的更多的是如何判断软件过程中各环节的好坏，更多的是“听或看”软件工艺水平，而非这些软件环节的具体内容。但针对软件工程中的设计来说，可能就没那么简单了。要说清楚这个问题，还得说说软件设计的理念。

       一个好软件的设计很重要，这个无庸质疑。那么设计很重要到底重要在哪？有人说设计重在可复用，可拓展，性能好，维护方便。这些和OO中几个特性一样理论化。只能说是设计的基本职责。否则要不直接写代码就得了，还要设计干嘛？就象需求过程中，文字表达清晰没有二义性，功能点拆分需要清晰，要有流程图，要有界面原型，非功能性说明等特性一样，这些都只是过程中的基本职责，没什么特别的。放眼到一个软件工程的角度来看，需求，设计，开发，测试，QA，CM，项目管理，UI用户体验。这些环节哪个才是最重要的？貌似好象都很重要。所以设计的重要性体现不应该只是那些基础功能。

       记得早期看设计方面的几本书《道法自然》，《敏捷软件开发》等。这些书讲的很多OO设计模式，而重点阐明设计思想的背后就是软件设计中非常重要的理念----“自然”。从需求过度到设计的自然，以及从设计过度到需求的自然，从设计到开发的自然，和从开发到设计的自然。所有的软件从业人员都听过“编程修养”一词，然而编程修养到底是什么？很多解释，也说不清楚。个人理解，编程修养和设计的理念“自然”相若。讲究解决一个问题用一个最合理自然的方式，寻求到答案。很多时候写程序，做设计会发现A方式也行，B方式也行。那么究竟A方式好，还是B方式好？这就取决于编程修养高低了，是“境界”问题。如果还停留在一个软件能不能实现的基础上，那么基本可以断定这位软件兄弟还处于入门状态。

       回到软件工程的角度，在这些环节中设计的重要性在哪呢？个人理解就在于自然，在于如何保证需求和设计一致？以及如何保证设计和开发一致？在软件设计的过程中，相信都会碰到需求不清晰，前后矛盾等问题，这个时候做的就是系统分析过程（注意和需求分析还是有些不同）。而系统分析过程发现需求问题，不就是在帮助完善需求吗？很自然的一个过程。那么需求分析过程，有没办法帮助完善设计呢？当然也有。举例来说，做需求的时候，系统支持表格导入excel功能，未来此处功能将直接走接口。需求分析过程中，发现此处数据量很大？需求的未来演化功能和数据量的提示，均对后续设计产生重大影响。

       在CMMI中，需求和设计过程中的唯一产物就是需求跟踪矩阵这个东东了，这是个麻烦的东西，也是个好东西。麻烦是因为在具体落实的时候，将需求文档列表和设计文档列表，甚至开发，测试都绑定在一起，且跟随文档变化的时候也需要同步维护这个矩阵，比较繁琐。而这个只是个保障性的作用，并不是必需的。所以真正项目实施过程中，这种文档维护繁琐挑战着项目经理的耐性，尤其当项目经理实施项目遇见困难的时候。但需求跟踪矩阵它却真正尝试解决保证需求和设计一致的问题，凸显软件设计环节的重要性。至少从表面上看，它保证了所有的需求都被设计覆盖了。至于具体有没有真正意义上实现自然的保障，这不是CMMI体系去关注的。

       但在软件工程中却需要关注具体如何自然的去保障需求和设计的一致性。个人理解，在软件工程中，需求和设计一致性的保障重点是解决怎么从需求自然的过渡到设计，自然的过渡到开发。强调的是需求分析、系统分析过程。现在看的比较多的情况是需求人员直接就写需求规格说明书了，做设计的直接就出了PD表结构了。根本没有体现出需求分析，也没有体现出系统分析，那如何保障一致性呢？在研究了需求方面的一些知识后，确实发现很多书在需求过程中有这块的内容。OO里强调需求建模，即构建领域模型，然后过渡到类模型，最后才到PD数据表结构。对于设计怎么到代码，其实现在很多IDE（eclipse中嵌入设计模式，类图等插件，PD里面就集成有用例和类图等）就解决了一些问题。而对于这个体系的理解和构建，才是软件工程中设计的重要意义。而需求跟踪矩阵只是所体现出来的一个表象而已。当然技术体系不一定要按OO方式来进行，关键是要有这个过程才是最重要的。

       CMMI体系落地过程，个人觉得最难的就是在于设计环节的把控了，目前针对这块的改造真正考验一个项目流程制作者的水平。因为这个流程的制定需要结合软件工程中，需求，设计，开发的工艺去推进。并且和现在流行语言JAVA,PHP,C等有密切关系。这块处理不好，CMMI体系总感觉笨重，不太实用。而适当的裁剪和变通处理，才能真正让CMMI发挥出威力。（关于流程改进一块后续在博客中会有专篇讨论）