什么是软件开发的核心问题？

按照软件工程鼻祖，《人月神话》作者 Brooks 在“没有银弹——软件工程中的根本和次要问题”一章中阐述的思想，软件开发的核心问题就是如何从概念上对一个复杂的业务系统进行建模。这个建模是含义广泛的，不仅仅包括对象建模，还包括数据建模、算法建模等等一系列的内容。总而言之是要先找到解决复杂问题的突破口（先要搞明白需要做什么，然后再考虑如何做）。至于采用什么表示方法（简单文本、UML 图、E-R 图）、采用什么高级语言、是否一定要用面向对象、使用什么开发工具都是次要的问题。
有些人每做一个新项目，不管三七二十一先画一大堆图出来。其实你看《编写有效用例》这本书中用到了很多图形吗（当然我不否认图形在有些场合的重要性）？很多时候可能你只需要把你的想法简单地在纸上画出来（一只铅笔、一张白纸，成本接近于 0）就足以帮助你理清思路了。如果你的想法都无法清晰地画在纸上，那么 ROSE 这样昂贵的工具就能帮助你了吗？还是你只能装装样子，否则混老板的工资于心不忍呢？
软件开发中，工具是非常重要的，完全有必要非常纯熟地掌握所使用的工具。但是一旦掌握以后，就应该进一步思考一些深层次的问题了。按照我的看法，开源软件解决了工具的问题，然而如果你一味依赖开源软件，而不去利用这些很好的基础解决复杂的问题（建造更加复杂的架构），那么等于是把你的明天拱手相送了。

我有很多计算机书，买的和从网上下载的。我把这些书分成两类：可以增加知识的，可以增加智慧的，并且优先阅读第二类书。几乎所有的书只要你买来都能增加你某方面的知识，但是第二类书可以使你变得更聪明。《人月神话》毫无疑问属于第二类书。你要问我读这本书的感受，我的感受就象是大热天踢球后喝了一杯清凉的饮料，套用一句广告词：“从这到这都舒服”。

我只因为《没有银弹》买了mmm，也只因为要给哥们送礼买了《建筑的永恒之道》。看过以后我总是想起一句话－－有工具的傻瓜，还是傻瓜。
也许我天生喜欢简单，而且绘画绝无一点天赋，而对于海拔之类的说法也觉得模糊，所以我也不喜欢《书写有效用例》，我想再简单一点，回到最早的usecase，刚出现actor时候的usecase。一支笔一张纸，连尺子都不用，就是文字文字，最多加上一个流程图。客户也不会问我什么是usecase，我也无须向他们解释这个怎么就泛化了，那个怎么就包含了。

呵呵，从维护概念完整性的角度（这是提高软件质量，降低软件成本的关键），软件工程方面的书最好还是少看一些，因为不同的专家、大师的想法差别是比较大的。我现在只看以前提到过的 8 位大师的著作。《人月神话》是软件工程史上最重要的一本书，很多软件开发过程的思想都受到《人月神话》的巨大影响（包括现在各种敏捷开发方法中常用的短周期迭代、快速原型法，都不是什么新鲜的概念，将近 20 年前 Brooks 就已经阐述过了）。从《人月神话》这本书中，我看不出以后的 CMM 和它有一脉相承的迹象，实际上我可以举出书中的很多段落证明 CMM 与 Brooks 的思想是相矛盾的。Brooks 的思想实际上更接近于 XP、TDD 和 FDD 这些敏捷开发方法（集中全部精力攻克核心问题！）。

为什么 Brooks 得了图灵奖，而创造出 CMM 或 RUP 的那些软件科学家（我承认这些专家确实也对软件工程做出了很大的贡献）没有得到图灵奖，有人想过吗？Brooks 的思想在软件业是为大家所公认的金科玉律，而 CMM、RUP 却还存在着广泛的争议。国外成熟的软件公司很少有邯郸学步似的完全照搬 CMM、RUP 的做法的。把建筑行业行之有效的建造过程和管理模式搬用到软件行业完全是一种误导。这里又引出了另外的一个问题：这些软件科学家真的了解建筑行业吗？

请教一下您指的这八位大师是谁？ 读你的post很有启发，在此表示感谢！

(1) 点击 "搜索"  --> 输入 "大师" --> 主题 "我最敬仰的 8 位软件宗师"

(2) 论坛提问的智慧--> "三、使用论坛搜索功能"

不错不错，读dlee和robbin的贴子，每次都感觉说出了自己心里想的东西，有中心心相应的感觉，希望继续！

软件开发的核心问题？

我自己的回答是人.

这里面包括很多, 人, team, 公司等等, 从一个人到一群人, 不管是开发软件的人也好, 使用软件的人也好,都是由人为主体的.  而其他不敢是工具也好,还是方法也好, 不都是人在操作和使用吗.

^_^  一家之言.

这正是《人件》中所阐述的思想，我们以后会另开一个线索讨论《人件》中所关注的问题。国外资深的开发人员都读过《人月神话》和《人件》这两本书。国内的开发人员却不屑于读这些“没有用处”的书，而只对一些“神奇”的工具感兴趣（那些追捧 .Net 的文章很少能达到 robbin 文章的深度）。一些软件企业的管理者，更是不读书、不学习（那是我手下人的事情）、刚愎自用、好大喜功（昨天我卖机器很成功，今天做软件肯定也没有问题！？）。从企业高层到开发人员对于思考深层问题的漠视直接导致管理水平的低下，产品质量的低劣。以前我们嘲笑西方人只注重工具和各种奇技淫巧，却不知道人家早就不是这个层次了，而我们显然还停留在只注重工具和奇技淫巧的层次上。

软件开发可以说是因人成事，没有合适的人，你就别指望能做和别人相同的事情（没有金刚钻，就别揽瓷器活。假设给你 100 个开发人员，一年时间，你有把握开发出 JBoss 一类产品吗？我是说与 JBoss 一样好用，你不仅开发出来，还要能卖得出去，别人喜欢用）。张三程序员即使水平很差，如果参与过大量开发，一旦跑掉了，他的工作也不是随便找来一个李四程序员短期内就可以胜任的，所以所谓即插即用的“软件蓝领”纯粹是一个谎言。尊重人才，人尽其用是软件企业首先要解决的问题，也是关系到企业生死存亡的大事。

以下是我给自己制订的近期读书计划：
《人月神话》，已读完。
《人件》，尚未读完。
《测试驱动开发》，尚未读完。
《Java Modeling in Color with UML》，尚未开始。
《特征驱动开发方法》，尚未读完。
《分析模式》，尚未读完。
《数据挖掘——概念与技术》，尚未读完。

创造出自精湛的技艺，精炼、充分和快速的程序也是如此。技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高。这种战略上突破有时是一种新的算法，如快速傅立叶变换，或者是将比较算法的复杂度从n2降低到n log n。

更普遍的是，战略上突破常来自数据或表的重新表达——这是程序的核心所在。

你说的有一定的道理，但是不是普遍规律。这就象对象建模和算法哪个更重要一样，两者并不矛盾，但是真正需要一个高深算法来解决问题的场合并不多。大多数场合软件结构（设计模式、框架、体系结构）方面的问题才是最重要的问题。以前我也曾多次强调基础知识的重要性，但是 robbin 和 potian 所阐述的商业软件开发要以对象建模为主我是完全同意的。最有效率的开发方式是自上而下的开发方式（当然需要考虑建立快速的反馈，这是另外一个问题），先解决好全局性质的问题，然后再解决局部问题。算法的优化可以认为是一个局部问题（我说的是普遍规律，不排除在某些领域（如数据挖掘、人工智能、神经网络、机器学习、etc. ）中算法的突破造成了全局性改变的情况）。
不要轻易把一些看似矛盾的观念对立起来。以人为本正是为了创造一个更好的环境使程序员能够集中精力深入思考一些深层问题，提高自己的技艺，所以两者是相辅相成的。
什么时候需要过程？5 个人以下的小团队沟通量很小，不需要过程也可以完成项目。但是对于复杂的大型项目，不可避免地要增加人力。5 个人以上甚至 10 个人以上的团队，一个注重实效的开发过程是项目成功的关键。过程的目的就是用来改善沟通和保证概念完整性的，敏捷只是其所达到的效果而不是主要目的。软件工程中的开发过程近几年经历了一个很大的转变，就是从以过程为中心，只重过程不重结果的重量级开发过程发展到以人为中心，注重沟通和结果的轻量级开发过程。