人月神话读书笔记(六)

原创 2003年02月21日 09:28:00

第九章 削足适履

1.  系统的空间规模:规模是软件系统产品用户成本中如此大的一个组成部分,开发
人员必须设置规模的目标,控制规模,考虑减小规模的方法。同任何开销一样,规模
本身不是坏事,但不必要的规模是不可取的。

2.  对项目经理而言,规模控制既是技术工作的一部分,也是管理工作的一部分。必
须研究用户和他们的应用,以设置将开发系统的规模。接着,把这些系统划分成若干
部分,并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内
变化,规模目标的设置是一件颇具技巧的事情,需要对每个可用方案有深刻的了解。
聪明的项目经理还会给自己预留一些空间,在工作推行时分配。

仅对核心程序设定规模目标是不够的,必须把所有的方面都编入预算。

在指明模块有多大的同时,确切定义模块的功能。

培养开发人员从系统整体出发,面对用户的态度。

3.  在速度不变的情况下,更多的功能意味着需要更多的空间。其中一个技巧是用功
能交换尺寸。设计人员必须决定用户可选项目的精细程度。

4.  考虑空间--时间的折衷。对于给定的功能,空间越多,速度越快。

项目经理可以做两件事来帮助他的团队取得良好的空间--时间折衷。一是确保他们在
编程技能上得到培训,而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使
用新语言或者新机器时,培训显得尤其重要。另一种方法是认识到编程需要技术积累,
需要开发很多公共单元构件。

5.  战略上的突破常来自数据或表的重新表达--这是程序的核心所在。数据的表现形
式时编程的根本。

 

第十章 提纲挈领

1.  文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查
列表、状态控制,也可以作为汇报的数据基础。

2.  软件项目文档的内容:

目标。待完成的目标、迫切需要的资源、约束和优先级。

产品技术说明。

进度表。

资金预算。

工作空间分配。

人员组织。

3.  为什么要有正式的文档

首先,书面记录决策是必要的。人们能从令人迷惑的现象中得到清晰、确
定的决策。

第二,文档能作为同其他人沟通的渠道。项目经理的基本职责是使每个人
都向着相同的方向前进,所以他的工作主要是沟通,而不是做出决定。文
档能极大地减轻他的负担。

最后,文档可以作为数据基础和检查列表。通过周期性的回顾,他能清楚
项目所处的状态,以及哪些需要重点进行更改和调整。

项目经理的任务是制订计划,并根据计划实现。只有书面计划是精确和可
以沟通的。通过遵循文档开展工作,项目经理能更清晰和快速地设定自己
的方向。

 

第十一章 未雨绸缪

1.  对于大多数项目,第一个开发的系统并不合用。可能太慢、太大,而且难以
使用,或者三者兼而有之。要解决所有的问题,除了重新开始以外,没有其他的
办法--即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成
,也可以一块块地实现。所有大型系统的经验都显示,这是必须完成的步骤。
 -- 构建一个试验性的系统,然后抛弃它。

2.  一旦认识到实验性的系统必须被构建和丢弃,具有变更思想的重新设计不可
避免。

3.  为变化设计系统,包括细致的模块化、可扩展的函数、精确完整的模块间接
口设计、完备的文档。另外,还可能会采用包括调用队列和表驱动技术。

最重要的措施是使用高级语言和自文档技术,以减少变更引起的错误。采用编译
时的操作来整合标准说明,在很大程度上帮助了变化的调整。

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

4.  为变更计划组织架构和团队。

5.  程序维护中的一个基本问题是 -- 缺陷修复总会以(20%--50%)的机率引入新
的bug。整个过程是前进两步,后退一步。作为引入新bug的一个后果,程序每条
语句的维护需要的系统测试比其他编程要多,成本非常高。

缺陷不能被彻底修复的原因:

首先,看上去很轻微的错误,似乎仅仅是局部操作上的失败,实际上却是系统级
别的问题。其次,维护人员通常不是编写代码的开发人员。

5.  使用能消除、至少是能指明副作用的程序设计方法,会在维护成本上有很大
的回报。设计实现的人员越少、接口越少,产生的错误也就越少。

6.  维护工作破坏系统的架构,增加了系统的混乱程度。随着时间的推移,系统
变得越来越无序,无法再成为下一步进展的基础。这时,系统的重新设计完全是
必要的。

系统软件开发是减少混乱度的过程,软件维护是提高混乱度的过程,即使是最熟
练的软件维护工作,也只是放缓了系统退化的进程。

 

人月神话读书笔记

1964-1965:  IBM操作系统OS/360的经理1974: 查珀尔希尔,北卡罗来纳 Frederick P. Brooks,Jr写了此书。1994:20年后再版,修正了一些观点 几个谬误1)所...
  • wqf363
  • wqf363
  • 2007年01月28日 14:06
  • 1079

人月神话读书笔记(16)----没有银弹

没有银弹由于软件的复杂性,一致性,变化性和不可见性,解决软件危机的银弹并不存在。摘要 所有软件活动包括: 根本任务,即打造构成抽象软件实体的复杂概念结构; 次要任务,即使用编程语言表达这些抽象实体,...
  • liujianli
  • liujianli
  • 2016年07月26日 16:38
  • 412

《六顶思考帽》读书笔记

《六顶思考帽》读书笔记读 大学的时候,就曾一口气读完了《六顶思考帽》,当时的想法只是说尽可能地多读点书,增长见识,没有什么读书技巧和章法可言。出来工作了时间紧张没有那么多时间,才开始探究如何高效地读...
  • u011570492
  • u011570492
  • 2016年11月12日 10:55
  • 1135

人月神话读书笔记(2)-人月神话

第二章 人月神话(The Mythical Man-Month) 美食的烹调需要时间;片刻等待,更多美味,更多享受。 在众多软件项目中缺乏合理的进度安排是造成软件项目滞后的主要原因。造成这种灾难的原因...
  • zhouree
  • zhouree
  • 2009年06月01日 17:34
  • 244

人月神话解读与感受

在研究生期间我们的课程设置中有一门必修课程是软件工程,其中有一个作业是读人月神话并写一篇读后感。虽然我本科的专业是偏向于网络工程,并且我们也开设过软件工程这门课。但是对于像我这样的二流选手,在本科期间...
  • DaveBobo
  • DaveBobo
  • 2016年04月11日 17:45
  • 3538

人月神话读书笔记(2)----人月神话

人月神话缺乏合理的进度安排是造成项目滞后的最主要原因,导致这种灾难如此普通的原因有: 1. 对估算技术缺乏有效的研究; 2. 估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆; 3...
  • liujianli
  • liujianli
  • 2016年07月13日 16:43
  • 160

人月神话读书笔记之二人月神话

人月神话说明了不能单纯地按照人月的模式进行工作量的估计。 第一,在项目开发过程中会存在很多沟通交流的成本。第二,很多问题的解决不是单纯靠人力解决的,有些问题是不能够再分解的任务和功能...
  • xuqiaobo
  • xuqiaobo
  • 2017年04月18日 10:36
  • 89

《人月神话》阅读心得

巴比伦塔的失败启示 ——《人月神话》读后感 12330227 计应2班 吕顺   初读人月神话,我就深深地被其中所涉及到的软件开发中遇到的各种难题和解决对策所折服。坐着布鲁克斯用一种高瞻远瞩的视角详细...
  • lv0525
  • lv0525
  • 2015年05月17日 18:57
  • 437

《人月神话》经典观点整理(之一):哪些过时了,哪些还有效?

下面的文章是第一章和第二章的主要观点,后续章节的我回头再发。看这篇文章能够迅速了解Brooks的思想。   另外一个需要大家仔细考虑的就是,Brooks的《人月神话》是在几十年前写的,在软...
  • joeyon
  • joeyon
  • 2015年03月06日 11:28
  • 963

【书评】人月不必再相望,嫦娥已然在身旁——人月神话(40周年纪念版)

参与活动主题《人月神话(40周年纪念版)再版 扒一扒你遇到过最NB开发项目》有奖活动,三重惊喜,有奖试读&作者互动@关注有礼!为什么是《人月神话》?这本书在业界真的很名,几乎无人不知,然而我却只知其名...
  • testcs_dn
  • testcs_dn
  • 2015年06月21日 15:17
  • 2921
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:人月神话读书笔记(六)
举报原因:
原因补充:

(最多只允许输入30个字)