软件设计最困难的部分是什么

  郑州软件公司今天和大家谈谈郑州软件开发设计中最困难的部分是什么   

        有篇闲聊专栏提到了一个主题叫（专栏H：需求分析书中最重要的信息是什么？
       
        不知道大家还记得答案吗？这里想谈一个类似的问题——设计最难的部分是什么？
   
        请朋友们花一分钟想一下这个问题，或是我们把原来的问题简化一下，改成『设计软件最困难的部分是什么？j是如何捕捉与撰写需求？如何套用设计模式？如何设计软件架构？如何用UML画出漂漂亮亮吓死人不偿命的图？如何写程序？如何测试？还是如何拼酒（问业务就知道最后一项技能对于接项目的重要性）?
       
        一分钟差不多到了，公布答案，这个答案在《设计原本》这本书中已经有提到（英文版第22页）：
   
        设计最难的地方在于：决定要设计什么东西？(The hardest part of design is deciding what to design.)

        

        假设大家先暂时同意作者Frederick Brooks在_f弓中的说法，那么，重点在后面的几句话：
   
        我逐渐意识到，过去我为客户所提供的最有用的服务就是帮助他决定什么是他真正想要的。(Then,slowly,I came to realize that the most useful service l was performing for my client was helping him decide what he really wanted.)
   
        晟近，这一段话让Teddy看了更有感觉，为什么呢？因为最近Teddy在思考未来的职业规划，有人可能看上Teddy的Scrum与敏捷实践这方面的经验，有人可能觉得Teddy的软件架构设计能力应该还不错，也有人看上Teddy上过CMMI课程而想找一
个懂CMMI的项目经理（此人一定没看过Teddy的博客）o其实，Teddy最近也一直在]问自己同样的问题：Teddy能够做什么？
   
        前面引用自Frederick Brooks的这段话，  r抽象化(abstraction)j做得真好，一言以j蔽之，可以代表Teddy的心声（至少内心希望是这样啦）。
    
        既然设计最难的地方在于决定要设计什么东西，那是不是代表厂需求定义j很重要？是可以这么说。
        因此，是不是要回归到传统软件开发流程： 需求分析一架构分析一设计一写程序一测试
     
        所以，在项目开始实施之前要把所有的需求都找出来？

      

        Brooks很好心地告诉乡民们，不不不：
        设计与决定设计目标（也就是需求）的过程都应该是迭代式的。在项目开始之前就畿够确定完整需求是一种例外情况，而不是常态o(Not only is the design processiterative; the design-gold-setting process is itself iterative.…knowing complete
product requirements up front is a quite rare exception, not the norm.)
   
        看到这里，Brooks就被Teddy 看穿（看破手脚）了，这根本是另类的敏捷方法代言人啊！
    
         对一个软仵项日来讲，定义需求的确是一件不容易的事，尤其是要处理的问题 (prOblem domain)本身就非常复杂时，单单r要设计什么(what t(designn process)]，要弄清楚就够花时间了。然而，更难的还在后面，由于设计流程(design process)J与“清楚要设计什么的流程”(design-gold-setting process)j都是非常繁复的（就是要跑个好次序，一步一步地来，才能把设计以及到底要设计什么搞懂），所以软件开发才会经常 地被弄得很乱。
   
        前面这段话有点玄，请多看两次。
        由于需求随着时间越来越清楚，换句话说，需求随着时间一直在变（由模糊变清袭或是由错误变正确）。相对地，设计本身因为需求变了所以也要变。因此，如果软件没有设计好（或是说项目没有带好），那么在这r需求与设计的爱恨情仇交互作用
  下，最终的产品就不容易成功。