人月神话 :
1)如果全中国的50%软件开发人员都看人月神话的时候,中国软件行业会崛起。
2)当全中国10%软件开发人员都理解了50%以上的人月神话内容的时候,
中国软件行业会腾飞。
3)当全中国1%软件开发人员,完全理解书的内容并能跟人月神话作者讨论研究
问题时,中国软件行业才会步入世界领先的行列。
4)或我以上提出的百分比有点过大,所以或许也可能每个百分比都除以10或
100时,以上3点也都会实现吧。是的我们和他们的差距是这样的巨大。
中文版下载地址:http://www.umd123.com/d129/ebook2007/93.rar
假如有英文功底,建议您看英文原版。假如您看得懂PDF版,我敢肯定您会去
买正版书(不到30元人民币)。
----------------------------------------------------------
1.1 编程系统产品(Programming Systems Product)开发的工作量是供个人
1.2 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”,
□开发对其他人有用的东西的乐趣
□将可以活动、相互啮合的零部件组装成类似迷宫的东西,这个过程
□实际情况看起来要比这一点好一些:真正的权威来自于每次任务的完成
2.1 缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素
2.2 良好的烹饪需要时间,某些任务无法在不损害结果的情况下加快速度。
2.4 由于编程人员通过纯粹的思维活动来开发,所以我们期待在实现过程中
2.5 但是,我们的构思是有缺陷的,因此总会有bug。
2.6 我们围绕成本核算的估计技术,混淆了工作量和项目进展。人月是危险和
2.7 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
2.8 关于进度安排,我的经验是为1/3计划、1/6编码、1/4构件测试以及
2.9 作为一个学科,我们缺乏数据估计。
2.11 Brook法则:向进度落后的项目中增加人手,只会使进度更加落后。
2.12 向软件项目中增派人手从三个方面增加了项目必要的总体工作量:
3.2 Sackman、Erikson和Grand的数据显示经验和实际表现之间没有相互联系。
3.4 两个人的团队,其中一个项目经理,常常是最佳的人员使用方法。
3.5 对于真正意义上的大型系统,小型精干的队伍太慢了。
3.6 实际上,绝大多数大型编程系统的经验显示出,一拥而上的开发方法是
4.1 “概念完整性是系统设计中最重要的考虑因素”。
4.2 “功能与理解上的复杂程度的比值才是系统设计的最终测试标准”,
4.3 为了获得概念完整性,设计必须由一个人或者具有共识的小型团队来完成。
4.5 “如果要得到系统概念上的完整性,那么必须控制这些概念。
4.6 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强,
4.7 概念上统一的系统能更快地开发和测试。
4.8 体系结构(architecture)、设计实现(implementation)、
5.2 结构师如何成功地影响实现:
?□牢记是开发人员承担创造性的实现责任;
□结构师只能提出建议。
□时刻准备着为所指定的说明建议一种实现的方法,准备接受
5.3 第二个系统是人们所设计的最危险的系统,通常的倾向是过分地进行设计。
5.4 OS/360是典型的画蛇添足(second-system effect)的例子。[Windows
5.5 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。
第六章 贯彻执行
1. 问题:项目经理如何确保每个人听从、理解并实现结构师的决策?对于有多个结构师
的小组如何保持系统概念上的完整性。
2. 手册、或者书面规格说明,是一个非常必要的工具。手册是产品的外部规格说明,它
描述和规定了用户所见的每一个细节;同样的,它也是结构师主要的工作产物。
手册不但要描述包括所有界面在内的用户可见的一切,它同时还要描述用户看不见的事物。
后者是编程实现人员的工作范畴,而实现人员的设计和创造是不应该被限制的。体系结构
设计人员必须为自己描述的任何特性准备一种实现方法,但是他不应该试图支配具体的实
现过程。
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义,所以每条说明都
必须重复所有的基本要素,所以所有文字都要相互一致。
3. 规格说明中,形式化定义是精确的,它们倾向于更加完整;差异得更加明显,可以更
快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则,描
述阶段上或层次上的结构,以及提供例子。应同时包括形式化和记叙性定义两种方式。
4. 通过会议的方式,开发人员进行沟通和讨论问题。
5. 不同实现之间严格要求相互兼容。如果起初至少有两种以上的实现,那么定义会更加
整洁和规范。
6. 对于存有疑问的实现人员,应鼓励他们打电话询问相应的结构师,而不是一边自行猜
测一边工作。
一种有用的机制是由结构师保存电话日志。日志中,他记录了每一个问题和相应的回答。
每周,对若干结构师的日志进行合并,重新整理,并发布给用户和实现人员。这种机制很
不正式,但非常快捷和易于理解。
7. 在最后的分析中,用户是独立的监督人员。在残酷的现实使用环境中,每个细微缺陷
都将无从遁形。产品测试小组则是顾客的代理人,专门寻找缺陷。不时地,细心的产品测
试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方
面的原因,设立测试小组是使设计决策得以贯彻执行的必要手段,同样也是需要尽早着手
,与设计同时实现的重要环节。
--------------------------------------------------------
第七章 为什么巴比伦塔会失败
1. 项目人员之间的交流和沟通是项目能否顺利和成功的一个重要因素。
2. 缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。随着工作的
进行,许多小组慢慢地修改自己程序的功能、规模和速度,他们明确或者隐含
地更改了一些有效输入和输出结果用法上的约定。
团队如何进行相互之间的交流沟通:
清晰定义小组内部的相互关系和充分利用电话,能鼓励大量的电话沟通,从而
达到对所书写文档的共同理解。
常规项目会议。会议中,团队一个接一个地进行简要的技术陈述。这种方式非
常有用,能澄清成百上千的细小误解。
在项目的开始阶段,应该准备正式的项目工作手册。
3. 项目工作手册不是独立的一篇文档,它是对项目必须产出的一系列文档进
行组织的一种结构。
项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口
说明、技术标准、内部说明和管理备忘录。
4. 使用项目工作手册的原因:
技术说明几乎是必不可少的。如果某人就硬件和软件的某部分,去查看一系列
相关的用户手册。他发现的不仅仅是思路,而且还有能追溯到最早备忘录的许
多文字和章节,这些备忘录对产品提出建议或者解释设计。
正确的文档结构非常重要。事先将项目工作手册设计好,能保证文档的结构本
身是规范的。另外,有了文档结构,后来书写的文字就可以放置在合适的章节
中。
控制信息发布,确保信息能到达所有需要它的人的手中。
5. 团队组织的目的是减少不必要的交流和合作的数量。减少交流的方法是人
力划分和限定职责范围。当使用人力划分和职责限定时,树状管理结构所映出
对详细交流的需要会相应减少。
-----------------------------------------------------------
第八章 胸有成竹
1. 问题:系统编程需要花费多长时间?需要多少工作量?如何进行估计?
2. 工作量是规模的幂函数。
Portman的数据:工作花费的时间大约是估计的两倍。
Aron、Harr、OS/360的数据:生产率会根据任务本身的复杂度和困难程度表现出
显著差异。
Carbato的数据:对常用的编程语句而言。生产率似乎是固定的。这个固定的生产
率包括了编程中需要注释,并可能存在错误的情况。使用适当的高级语言,编程的
生产率可以提高5倍。
-----------------------------------------------------------
第九章 削足适履
1. 系统的空间规模:规模是软件系统产品用户成本中如此大的一个组成部分,开发
人员必须设置规模的目标,控制规模,考虑减小规模的方法。同任何开销一样,规模
本身不是坏事,但不必要的规模是不可取的。
2. 对项目经理而言,规模控制既是技术工作的一部分,也是管理工作的一部分。必
须研究用户和他们的应用,以设置将开发系统的规模。接着,把这些系统划分成若干
部分,并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内
变化,规模目标的设置是一件颇具技巧的事情,需要对每个可用方案有深刻的了解。
聪明的项目经理还会给自己预留一些空间,在工作推行时分配。
仅对核心程序设定规模目标是不够的,必须把所有的方面都编入预算。
在指明模块有多大的同时,确切定义模块的功能。
培养开发人员从系统整体出发,面对用户的态度。
3. 在速度不变的情况下,更多的功能意味着需要更多的空间。其中一个技巧是用功
能交换尺寸。设计人员必须决定用户可选项目的精细程度。
4. 考虑空间--时间的折衷。对于给定的功能,空间越多,速度越快。
项目经理可以做两件事来帮助他的团队取得良好的空间--时间折衷。一是确保他们在
编程技能上得到培训,而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使
用新语言或者新机器时,培训显得尤其重要。另一种方法是认识到编程需要技术积累,
需要开发很多公共单元构件。
5. 战略上的突破常来自数据或表的重新表达--这是程序的核心所在。数据的表现形
式时编程的根本。
------------------------------------------------------------
第十章 提纲挈领
1. 文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查
列表、状态控制,也可以作为汇报的数据基础。
2. 软件项目文档的内容:
目标。待完成的目标、迫切需要的资源、约束和优先级。
产品技术说明。
进度表。
资金预算。
工作空间分配。
人员组织。
3. 为什么要有正式的文档
首先,书面记录决策是必要的。人们能从令人迷惑的现象中得到清晰、确
定的决策。
第二,文档能作为同其他人沟通的渠道。项目经理的基本职责是使每个人
都向着相同的方向前进,所以他的工作主要是沟通,而不是做出决定。文
档能极大地减轻他的负担。
最后,文档可以作为数据基础和检查列表。通过周期性的回顾,他能清楚
项目所处的状态,以及哪些需要重点进行更改和调整。
项目经理的任务是制订计划,并根据计划实现。只有书面计划是精确和可
以沟通的。通过遵循文档开展工作,项目经理能更清晰和快速地设定自己
的方向。
----------------------------------------------------------
第十一章 未雨绸缪
1. 对于大多数项目,第一个开发的系统并不合用。可能太慢、太大,而且难以
使用,或者三者兼而有之。要解决所有的问题,除了重新开始以外,没有其他的
办法--即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成
,也可以一块块地实现。所有大型系统的经验都显示,这是必须完成的步骤。
-- 构建一个试验性的系统,然后抛弃它。
2. 一旦认识到实验性的系统必须被构建和丢弃,具有变更思想的重新设计不可
避免。
3. 为变化设计系统,包括细致的模块化、可扩展的函数、精确完整的模块间接
口设计、完备的文档。另外,还可能会采用包括调用队列和表驱动技术。
最重要的措施是使用高级语言和自文档技术,以减少变更引起的错误。采用编译
时的操作来整合标准说明,在很大程度上帮助了变化的调整。
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号,每个版本都应
该有自己的日程表和冻结日期。在此之后的变更属于下一个版本的范畴。
4. 为变更计划组织架构和团队。
5. 程序维护中的一个基本问题是 -- 缺陷修复总会以(20%--50%)的机率引入新
的bug。整个过程是前进两步,后退一步。作为引入新bug的一个后果,程序每条
语句的维护需要的系统测试比其他编程要多,成本非常高。
缺陷不能被彻底修复的原因:
首先,看上去很轻微的错误,似乎仅仅是局部操作上的失败,实际上却是系统级
别的问题。其次,维护人员通常不是编写代码的开发人员。
5. 使用能消除、至少是能指明副作用的程序设计方法,会在维护成本上有很大
的回报。设计实现的人员越少、接口越少,产生的错误也就越少。
6. 维护工作破坏系统的架构,增加了系统的混乱程度。随着时间的推移,系统
变得越来越无序,无法再成为下一步进展的基础。这时,系统的重新设计完全是
必要的。
系统软件开发是减少混乱度的过程,软件维护是提高混乱度的过程,即使是最熟
练的软件维护工作,也只是放缓了系统退化的进程。
-end