这一章，作者谈到了做过程和做工程的不同。工程是以最短的时间和精而少的人力做出高效、可靠且对人类有用的东西，而过程是来创造这个东西。即使过程很重要，但注重过程也不是目的，目的是实现功能和客户的需求。然而因工程庞大，很多人都在探索的时候都迷失了方向。
其实在把实现方法分割成实现过程，虽然提升了效率，也产生了弊端。最重要的信息，由于中间的一些人要权衡一些东西，在取舍和传递的时候很可能遗漏或变质了不少。客户和编程人员之间夹杂了那么多部门，反之编程人员实现的东西却要给客户直接使用，难免的，客户会觉得哪里哪里少了什么。夸张的，或不夸张的，之间的种种真的就像书中造秋千一样，结果与期望相差甚远。
过程是提供方便的途径，是必须走的，但不一定要这么走，也就不是死模型。我感觉要灵活的应对。也有可能是我说的轻松吧。
有的时候，我们真的要完全按照客户的需求走。不是为了更好的实现某个功能而忘了本质，有可能这个功能很好，实现的很巧妙，客户可能需要，但经常使用的模块却不是很令人舒心。这样，就应该调整重心。
哎，我现在还是站在用户的角度上看待应用的。有时候理解，有时候也无奈。什么免费软件上都会有很对与vip，广告，代理挂钩的地方，其中并不是必需的需求。但实现的价值确实公司和员工的需求。也只能平常心吧，大公司购买的系统就不会给人家插广告了不是？我想说需求也不是被排在第一位的位置。
关于模型的陈述，我感觉作者还是倾向于瀑布模型，以为它更贴近于本质。其实我也看不懂他说的是啥，但能听其中的道理，学什么不都是本质好吗？条条框框的，在哪里都是能模仿的。
工程，在个人的层次上还谈不到。工程是管理人员在一定层次上向下组织的。而个人的作用就是服从安排和完成相应的任务，扮演弹性角色。这样就应该能在一定程度上避免大家迷路吧。之所以这么说，是因为工程本来就是因作业量大，参加人员多而产生的。在一开始不也是不需要工程的吗？同样，身为初学者的我们code也不需要工程。
但我们在学，专业知识还没有学多精，就已经在练习和“同事”，“客户”交流了。也没见我们学过一个要求中到底什么才是实现的目的。有人可能会想，你傻吗，要求你还看不懂？那目前“工程”还小呢，为啥还要一步步的“摆”出来呢？我懂，是为了以后工程大的时候更清晰的理解。那实现的目的呢？就不会增多吗？虽然我也想不到练习理解目的的方法，但可能这就是大家从侧重目的转向侧重过程的原因——我侧重过程的习惯了。更何况，实现目的是客观的——我们用不到，过程是主观的——我们碰的着。