- 手册或者书面规格说明，是一个非常必要的工具，尽管光有文档时不够的。手册是产品的外部规格说明，他描述和规定了用户所见的每一个细节；同样的，它也是结构是主要的工作产物。（62）
- 手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。（62）
- 一句古老的格言警告说：”绝不要携带两个时钟出海，带一个或三个。“同样的原则也适用于形式化和记叙性定义。如果同时具有两种方式，则必须以一种作为标准，另一种所谓辅助描述，并照此明确的进行划分。（64）
- 所以必须特别指出形式化定义仅仅用于外部功能，说明它们是什么。（65）
- 形式化定义是一种设计实现。反之，设计实现也可以作为一种形式化定义的方法。（65）
- 作为一种定义，实现体现了更多的内容：它不但描述了系统必须做什么，同时还声明了自己到底做了些什么。（65）
- 关于实际使用标准是形式化描述还是记叙性文字这一点而言，使用实现作为形式化定义特别容易引起混淆，特别是在程序化的仿真中。另外，当实现充当标准是时，还必须防止对实现的任何修改。（66）
- 我们把会议分成两个级别：周例会和年度大会——这实际上是一种非常有效的方式。（66）
- 在大多数计算机项目中，机器和手册之间往往会在某一天出现不一致，人们通常会忽略手册。因为与机器相比，手册更容易改动，并且成本更低。然而，当存在多重实现时，情况就不是这样。这事，如实地遵从手册更新及其所造成的延迟和成本的消耗，比根据机器调整手册要低。（69）
- 显然，对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜测一边工作，这是一项很基本的措施。（69）
- 项目经理最好的朋友就是他每天要面对的对手——独立的产品测试机构/小组。（70）
- 那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。（75）
- 那么，团队如何进行相互之间的交流沟通呢？通过所有可能的途径。
非正式途径。清晰定义小组内不得相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解。
会议。常规项目会议。回忆中，团队一个接一个的进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。
工作手册。在项目的开始阶段，应该准备正式的项目工作手册。（76）
- 项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。（76）
- 技术说明几乎是必不可少的。（77）
- 事先将项目工作手册设计好，能保证文档的结构本身是规范的，而不是杂乱无章的。另外，有了项目结构，后来书写的文字就可以放置在合适的章节中。（77）
- 工作手册的实时更新是非常关键的。（78）
- 在文件中，记录修订日起记录和标记变更标识条。每个用户可以从一个显示终端（打印机太慢了）来查阅。每日维护的变更小结以“后进先出”（LIFO）的方式保存，在一个固定的地方提供访问。（79）
- 当编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。这种方法的先决条件时精确和完整地定义所有接口。（79）
- 团队组织的目的是减少所需的交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。（80）
- 减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。（80）
- 首先，需要指出的是，仅仅通过对编码部分的估计，然后应用上述比率，是无法得到对整个任务的估计的；第二， 必须声明的是，构建独立小型程序的数据不是用语编程系统产品。（88）
- 工作量=常数*指令的数量^1.5（88）
- 对常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。
使用适当的高级语言，编程的生产率可以提高5倍。（94）
- 由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，就像硬件开发人员会设立元器件数量目标，控制元器件的数量，想出一些减少零件的方法。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。（98-99）
- 对项目经理而言，规模控制即使技术工作的一部分，也是管理工作的一部分。他必须研究用户和用户需求，以设置待开发系统的规模。接着，把这些系统化分成若干部分，并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。聪明的项目经理还会给自己预留一些空间，在工作推行时分配。（99）
- 和指定驻留空间预算一样，应该制定总体规模的预算；和制定规模预算一样，应该制定后台存储访问的预算。
在指明模块有多大的同时，确切定义模块的功能。
培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能（100）
- 空间预算的多少和控制并不能使程序规模减小，为实现这一目标，它还需要一些创造性和技能。（101）
- 其中一个技巧是用功能交换尺寸；第二个技能是考虑空间——时间的折衷。（101）
- 由于缺乏空间而绞尽脑汁的编程人员，常常能通过从自己的代码中挣脱出来，回顾、分析实际情况，仔细思考程序的数据，最终获得非常好的结果。实际上，数据的表现形式是变成的根本。（103）
- 慢慢的，他逐渐认识到这些文档的某些部分包含和表达了一些管理方面的工作。每份文档的准备工作是集中考虑，并使各种讨论意见明朗化的主要时刻。如果不这样，项目往往会处于无休止的混乱状态中。文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查列表、状态控制，也可以作为汇报的数据基础。（108）
- 为了进行市场预测，首先需要制定产品性能说明和确定假设的价格。从市场预测得出的数值，连同从设计得出的组件单元的数量，决定了生产的估计成本，进而可以得到每个单元的开发工作量和固定的成本。这些成本又决定了价格。（109）
- 这种相似性不是偶然的——任何管理任务的关注焦点都是时间、地点、人员、项目内容和资金。（110）
- “设计系统的组织架构收到产品的约束限制，生产出的系统是这些组织结构沟通结构的映射。”（111）
- 首先，书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出；第二，文档能够作为同其他人的沟通渠道。项目经理会不断发现，许多理应被普遍认同的策略，完全不为团队的去一些成员所知；最后，项目经理的文档可以作为数据基础和检查列表。（111）
- 如果已开始就认识到它们的普遍性和重要性，那么就可以将文档作为工具有好的利用起来，而不会让它成为令人厌烦的繁重任务。通过遵循文档开展工作，项目经理能更清晰快速地设定自己的方向。（112）
时间： 2024-10-15 20:52:56