人月神话读书笔记(六)

2008-04-10 02:48:28来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

第九章 削足适履

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

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

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

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

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

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

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

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

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

第十章 提纲挈领

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

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

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

产品技术说明。

进度表。

资金预算。

工作空间分配。

人员组织。

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

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

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

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

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

第十一章 未雨绸缪

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

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

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

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

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

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

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

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

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

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

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

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

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:没头没尾--项目开发笔记:如何编写最外层用例?!

下一篇:软件需求说明书应包括的内容