因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

对于协调的问题，还是需要使用分解的技术，这在后续的章节中会继续进行讨论。在这里，可以认为整个系统必须具备概念上的完整性，要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。总的说来，上述的角色分工和技术是可行的，在实际工作中，具有非常高的效率。

易用性实际上需要设计的一致性和概念上的完整性。

产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖结构师一样。

概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。实际工作被划分成体系结构、设计实现和物理实现，但这并不意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系统将会开发得更快，所需要的测试时间将更少。同工作的水平分割相比，垂直划分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅提高。

想要成功，结构师必须 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配； 时刻准备着为所指定的说明建议一种实现的方法， 同样准备接受其他任何能达到目标的方法； 对上述的建议保持低调和平静； 准备放弃坚持所作的改进建议；

规格说明的风格必须清晰、完整和准确。

这些会议在手册冻结的前夕召开。出席人员不仅仅包括体系结构小组和编程人员、实现人员的结构代表，同时包括编程经理、市场和实现人员，由 System/360 的项目经理主持。议程典型地包括大约 200 个条目， 大多数条目的规模很小， 它们列举在会议室周围的图表上，每个不同的声音都有机会得到表达。然后，会制订出决策，加上出色的计算机化文本编辑工作（许多优秀员工的卓越的工作成果） 。每天早晨，会议参与人员会在座位上发现更新了的手册说明，记录了前一天的各项决定。 这些“收获的节日”不仅可以解决决策上的问题，而且使决策更容易被接受。每个人都在倾听，每个人都在参与，每个人对复杂约束和决策之间的相互关系有了更透彻的理解。

交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。

对大型项目而言，这种导向和缺乏沟通是最大的危险。在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。在这种监督机制之外，是实现人员自身的态度问题。 培养开发人员从系统整体出发、 面向用户的态度是软件编程管理人员最重要的职能。

开发人员交付的是用户满意程度，而不仅仅是实际的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应该有自己的日程表和冻结日期，在此之后的变更属于下一个版本的范畴。

一个接一个的研究显示，非常卓越的设计者产生的成果更快、更小、更简单、更优雅，实现的代价更少。卓越和一般之间的差异接近于一个数量级。

我的第一项建议是每个软件机构必须决定和表明，杰出的设计人员和卓越的管理人员一样重要，他们应该得到相同的培养和回报。不仅仅是薪资，还包括各个方面的认可——办公室规模、安排、个人的设备、差旅费用、人员支持等——必须完全一致。

《没有银弹》中声称和断定，在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高（引自 1986年的版本） 。

1990年Brad Cox的一篇非常出色的论文 《这就是银弹》（There Is a Silver Bullet） ，有说服力地指出重用和交互的构件开发是解决软件根本困难的一种方法。我由衷地表示赞同。

《没有银弹》提出了全力解决复杂性问题的方法，这种方法可以在现实中取得十分乐观的进展。它倡导向软件系统增加必要的复杂性：
‰ 层次化，通过分层的模块或者对象。
‰ 增量化，从而系统可以持续地运行。

E.1 软件系统可能是人类创造中最错综复杂的事物 （从不同类型组成部分数量的角度出发） 。
E.2 软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。

Parnas 的模块信息隐藏定义是研究项目中的第一步， 它是面向对象编程的鼻祖。 Parnas把模块定义成拥有自身数据模型和自身操作集的软件实体。 它的数据仅仅能通过它自己的操作来访问。第二步是若干思想家的贡献：把 Parnas 模块提升到抽象数据类型，从中可以派生出很多对象。抽象数据类型提供了一种思考和指明模块接口的统一方式，以及容易保证实施的类型规范化访问方法。

网盘下载

友情价：免费官网报价：点击查看

查看如下隐藏内容里的“提取码”：