以后我们做项目，一个纯粹完整的项目的先决条件？他们是否有1、清晰的目标 2、人力 3、材料 4、足够的时间 5、足够的技术
那么，既然已经具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？两个方面-交流，以及交流的结果-组织。他们无法相互交流，从而无法合作。当合作无法进行时，工作陷入了停顿。我们推测交流的缺乏导致了争辩，沮丧和群体猜忌。很快，部落开始分裂-大家选择了孤立，而不是相互争吵。
空间预算的多少和控制并不能使程序规模减小，为实现这一目标，他还需要一些创造性和技能。
计算机系统的硬件维护包括了三项活动-替换损坏的器件、清洁和润滑、修改设计上的缺陷。
软件维护不包括清洁、润滑和对损坏器件的修复。它主要包含对设计缺陷的修复。和硬件维护相比，这些软件变更包含了更多的新增功能，他通常是用户能察觉的。
不同用户需要不同级别的文档。某些用户仅仅偶尔使用程序，有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。
使用程序：每用户都需要一段对程序进行描述的文字。可是大多数文档只提供了很少的总结性内容，无法达到用户要求，就像是描绘了树木，形容了树叶，但却没有一幅森林的图案。为了得到一份有用的文字描述必须要有目的、环境、范围、实现功能和实用的算法、输入-输出格式、操作指令、选项、运行时间。
验证程序：除了程序的使用方法，还必须附带一些程序正确运行的证明，及测试用例。
每一份发布程序拷贝应该包括一些可以例行运行的小测试用例，为用户提供信心-他拥有了一份可信赖的拷贝，并且正确地安装到了机器上。
然后，需要得到更加全面的测试用例，在程序修改之后，进行常规运行。这些用例可以根据输入数据的范围划分成三个部分。
1、针对遇到的大多数常规数据和程序主要功能进行测试的用例。他们是测试用例的主要组成部分。
2、数量相对较少的合法数据测试用例，对输入数据范围边界进行检查，确保最大可能值、最小可能值和其他有效特殊数据可以正常工作。
3、数量相对较少的非法数据测试用例，在边界外检查数据范围边界，确保无效的输入能有正确的数据诊断提示。
修改程序：和一般用户一样，修改者迫切需要一切清晰明了的概述，不过这一次是关于系统的内部结构。那么这份概述的组成部分是什么呢？
1、流程图或子系统的结构图，对此以下有更详细的论述。
2、对所用算法的完整描述，或者是对文档中类似描述的引用。
3、对所有文件规划的解释。
4、数据流的概要叙述-从磁盘或者磁带中，获取数据或程序处理的序列--以及在每个处理过程完成的操作。
5、初始设计中，对已预见修改的讨论；特性、功能回调的位置以及出口；原作者对可能会扩充的地方以及可能处理方案的一些意见。另外，对隐藏缺陷的观察也同样很有价值。
流程图：流程图是被吹捧的最过分的一种程序文档。事实上，很多程序甚至不需要流程图，很少有程序需要一页纸以上的流程图。
流程图显示了程序的流程判断结构，他仅仅是程序结构的一个方面。当流程图绘制在一张图上时，他能非常优雅地显示程序的判断流向，但当它被分成几张时，也就是说需要采用经过编号的出口和连续符来进行拼装时，整体结构的概观就严重的被破坏了。
卓越的设计人员-关键的问题是如何提高软件行业的核心，一如既往的是-人员。