节奏

1．  首先判断作者是否为内容的利益相关者，比如所介绍产品的出品方，如果是，那么文章为最低价值。

2．  非利益相关者为作者，那么文章中是否有确定性概念出现，如果没有，则是一个小说类故事，文章为次低价值。

3．  有确定性概念，那么文章中是否存在命题，如果没有，则为教育类文章，文章为中等价值。

4．  文章存在命题，那么文章中是否存在逻辑完整的模式，如果没有，则为批判性文章，价值为中上。

5．  文章中存在逻辑完整模式，那么逻辑是否正确，证据是否充分，如果不是，则为探索性解决问题文章，价值上等。

6．  文章逻辑正确，证据充分，则为经验性解决问题文章，顶级价值，或者称之为“知识性”文章。

摘要：规模测量是利用一套标准来对不同的软件项目进行评估，给出软件项目的规模，这样才可以对软件开发团队的效率进行评估，同时为软件价值分析和风险管理提供了必要的基础。目前软件规模的测量更多的目的是建立一个软件组织或者整个软件行业的一个基准，还不能用来作为单个项目开发计划的唯一基础，项目开发计划还需要依赖于开发人员的预估。　查看全文

摘要：开发就是将用户需求编程成为可执行代码的过程，可以从良好的设计开始，也可以从需求直接开始。它是整个过程中最没有争议的阶段，因为显然它是必须的，不过目前有降低它的重要性的趋势，也就是开发员蓝领化，不过本人并不接受，最好的方式是开发员既作设计同时也进行开发　查看全文

摘要：为什么需要设计？ 第一个答案是软件产品必须易用，必须让 学习所需资源/使用节省资源<1 而要保持软件产品的易用，那么必须首先保证概念完整性（Conceptual Integrity），也就是整个系统存在内在一致的逻辑性；【4】49页 第二个答案是软件生产的效率要求我们能够复用，既能复用以前的软件，也能被以后的软件复用； 第三个答案是软件维护的成本要求我们能够尽量的标准化，提供良好的可读性； 第四个答案是软件开发参与人员知识背景完全不同，需要一个良好的框架能共同协作；　查看全文

摘要：需求是开发存在的意义，同时也是软件开发不确定性最大的领域，虽然往往被忽视。需求处理过程主要是把涉众（包括出资人和最终用户）的想象性要求转变为软件开发中可控的、可传递的需求。 这里就是起点，也就是构想，我们要从这里出发，到达我们的目的地，系统。　查看全文

摘要：目的是把自己在开发中所经历的经验记录下来，使用理性、系统化的方式，从构想一直到设计、开发、测试完成，指出其中真实的情况，以及可能的应对措施。 焦点是对资源进行预估，控制开发的成本。　查看全文

至于为什么很多的中国企业都是这个玄化的过程，作者也可以给出一个解释，作者感觉这和中国的历史观有点关系，中国历史对于人的玄化是源远流长的，那怕稍微有点名气的人都会被归结为生而有异，比如有雷电出现等等。今天的中国人虽然已经不相信这些东东了，但是内核还是没变，不信看看名人访谈，一般名人最终的论证都是自己异于别人，不管是不可思议的吃苦精神，还是不可思议的好运气，少有认为自己是依赖于某种正确的认识才成功的 。

有志青年们经常看央视2套的“对话”，看了那么多名人的经验介绍，却发现自己一旦实践，就困难重重，很是郁闷啊，什么原因呢？因为那些经验基本上都是逻辑不完整的，名人们或多或少的隐去了关键环节，就像武林秘笈少了很多页，照着练岂不走火入魔？何况其中假的部分也不少啊。

附录：On Demand游戏（内含技术内容，不喜欢的读者尽可不读）

发起人：IBM

核心内容：“要什么有什么”

核心技术：Web Service SOA架构 ESB（企业服务总线）

要求（来自IBM相关红皮书）：使用Web Service 接口描述语言定义企业内部所有的信息构件；使用SOA架构提供注册和调用这些标准接口的功能，形成服务总线；基于企业级别应用的质量要求，该总线还应该满足高灵活性、高可靠性、高……等等性，所以需使用以下软件：

IBM Websphere MQ

IBM Event Broker

IBM Message Broker

IBM Websphere Application Server

……..

作者评论：

Web Service和SOA架构都是公开国际标准，国内企业还可以玩一下，不过后面的高…..等等性就比较难搞了，如果把列出来的软件都开发出来，估计已经提前破产了。但是我们可以把高….等等性放到一边，想想TCP/IP的例子，用这些新的技术去恰当的满足用户的需求，这样就换成了中国象棋，就有得玩了。

实话实说：

IBM这个游戏目前更多的是一种营销策略，因为它并没有一个统一的软件提供类似于下面的调用：

  ESB esb = new ESB();

  Service service = esb.find(“service”);

  service.getSomething();

同时管理和屏蔽掉其它软件。所以On Demand更多的还只是存在于PPT上而已。所以由大厂商引导的所谓趋势，一般是企业营销的延伸而已，可能有借鉴意义，但是将它就认同成方向，就多少有点幼稚了。

 

 

软件牛人的不存在是因为计算平方定律的影响，当软件复杂程度上升时，它需要的计算量是按照平方比上升的，这很快会超越人的计算能力。

软件蓝领也是不存在的，目前软件最终的形成还是依赖于终端控制者，我们还没有多少有效的方法让软件的终端控制者变成一个搬运工，虽然目前有一些努力，比如OMG的MDA等等，但结果很值得怀疑。目前的软件外包也是基于地区工资差异，并非终端控制者的权力被剥夺。所以善于管理血汗工厂的包工头以及只愿意出钱然后看结果的老板要失望了，二十年内软件业还不太适合他们。

所以我们应该丢掉这种幻想，跨入到自己先前不熟悉的区域，而不是坐等产业发展到某一天，会自动进入自己熟悉的区域。