CSDN博客

img lee_j

人月神话读书笔记(六)

发表于2003/2/21 9:28:00  781人阅读

第九章 削足适履

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

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

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

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

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

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

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

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

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

 

第十章 提纲挈领

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

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

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

产品技术说明。

进度表。

资金预算。

工作空间分配。

人员组织。

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

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

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

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

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

 

第十一章 未雨绸缪

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

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

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

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

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

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

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

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

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

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

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

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

 

0 0

相关博文

我的热门文章

img
取 消
img