人月神话读书笔记.docx
- 文档编号:26524432
- 上传时间:2023-06-20
- 格式:DOCX
- 页数:16
- 大小:34.49KB
人月神话读书笔记.docx
《人月神话读书笔记.docx》由会员分享,可在线阅读,更多相关《人月神话读书笔记.docx(16页珍藏版)》请在冰豆网上搜索。
人月神话读书笔记
人月神话读书笔记
第一篇:
人月神话读书笔记 人月神话这本书几年前就听别人说是本很经典的软件开发方面的书,这本书的成功之处在于他思想的前卫性,以至于不只是软件行业的人在读。
现在终于找到读他的理由了,可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程,为什么留到最后读人月神话呢?
主要是因为我觉得一本能够流传30年还被人们津津乐道的书,肯定是本学要好好细读的书,所以留到了最后。
按照前两篇读书笔记的惯例,前面几段是一些我读书时的感受和收获,还有一些对内容的评价。
从这本书的内容来看,对于一个项目经理来说肯定会有更大的收获,这本书主要是针对软件开发管理方面的内容,这主要原因可能是因为作者以前就是项目的管理者,他是站在管理者的角度写的。
即便这样,对于一个从来没有参与过真实项目开发,更没有领导过团队的我还是有一定的吸引力,这本书中我最喜欢的就是前四章(焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计)和没有银弹这章。
这本书里面为了论证某一观点,会举出许多实际的项目作为证据,这一点非常好,事实胜于雄辩嘛!
这些例子也许对于作者那个年代的人来说很好理解,但是放在30年后来看这些例子又有些陈旧和难懂了。
另外,从文中我发现作者非常注重文档,一个优质的文档就是项目成功的保证,这一点与传统的软件工程很相似,但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1.编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2.编程行业的一些内在固有苦恼:
l将做事方式调整到追求完美,是学习编程的最困难部分。
l由其他人来设定目标,并且必须依靠自己无法控制的事物。
l真正的权威来自于每次任务的完成。
l任何创造性活动都伴随着枯燥艰苦的劳动,编程也不例外l人们通常期望项目在接近结束时(bug、工作时间)能收敛得快一些,然而软件项目的情况却是越接近完成,收敛得越慢。
l产品在即将完成时总面临着陈旧过时的威胁。
人月神话1.缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来影响还大。
2.良好的烹饪需要时间,某些任务无法在不损害结果的情况下加快速度。
3.我们的构思是有缺陷的,因此总会有bug。
4.我们围绕成本核算的估计技术,混淆了工作量和项目进展。
人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。
5.在若干人员中分解任务会引发额外的沟通工作量--培训和相互沟通。
6.关于进度安排,作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
7.因为我们对自己的估计技术不确定,所以在管理和客户的压力下,我们常常缺乏坚持的勇气。
8.brook法则:
向进度落后的项目中增加人手,只会使进度更加落后。
9.向软件项目中增派人手从三个方面增加了项目必要的总体工作量:
任务重新分配本身和所造成的工作中断;培训新人员;额外的相互沟通。
外科手术队伍1.同样有两年经验而且在受到同样的培训的情况下,优秀的专业程序员的工作效率是较差程序员的十倍。
关于这一条我在极限编程里看到,sackman和humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。
2.小型、精干队伍是最好的。
这一点在软件工艺和极限编程里都得到了充分的体现。
3.两个人的团队,其中一个项目经理,常常是最佳的人员使用方法。
4.对于真正意义上的大型系统,小型精干的队伍太慢了。
5.实际上,绝大多数大型编程系统的经验显示出,一拥而上的开发方法是高成本、速度缓慢、不充分的,开发出的产品无法进行概念上的集成。
6.一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法,既能获得由少数头脑产生的产品完整性,又能得到多位协助人员的总体生产率,还彻底地减少了沟通的工作量。
图1是10人的程序开发队伍沟通模式。
图110人程序开发队伍沟通模式贵族专制、民主政治和系统设计1.概念完整性是系统设计中最重要的考虑因素。
2.为了获得概念完整性,设计必须由一个人或者具有共识的小型团队来完成。
3.对于非常大型的项目,将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
4.纪律、规则对行业是有益的。
外部的体系结构规定实际上是增强,而不是限制实现小组的创造性。
5.体系结构、设计实现、物理实现的许多工作可以并发进行。
画蛇添足1.尽早交流和持续沟通能使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。
2.结构师如何成功地影响实现:
i.牢记是开发人员承担创造性的实现责任;结构师只能提出建议。
ii.听取开发人员在体系结构上改进的建议。
3.第二个系统是人们所设计的最危险的系统,通常的倾向是过分地进行设计。
关于这一点也许是正确的,但是这是一个回避不了的问题,如果没有开发第二个系统经验的人,就不可能有开发第三个系统经验的人了。
贯彻执行1.即使是大型的设计团队,设计结果也必须由一个或两个人来完成,以确保这些决定是一致的。
2.必须明确定义体系结构中与先前定义不同的地方,重新定义的详细程度应该与原先的说明一致。
3.出于精确性的考虑,我们需要形式化的设计定义,同样,我们需要记叙性定义来加深理解。
4.允许体系结构师对实现人员的询问做出电话应答解释是非常重要的,并且必须进行日志记录和整理发布。
5.项目经理最好的朋友就是他每天要面对的敌人--独立的产品测试机构/小组。
为什么巴比伦塔会失败?
1.巴比伦塔项目的失败是因为缺乏交流,以及交流的结果的组织。
2.因为左手不知道右手在做什么,从而进度灾难、功能的不合理和系统缺陷纷纷出现。
由于对其他人的各种假设,团队成员之间的理解开始出现偏差。
3.团队应该以尽可能多的方式进行相互之间的交流:
非正式、常规项目会议,会上进行简要的技术陈述、共享的正式项目工作手册。
胸有成竹1.仅仅通过对编码部分的估计,然后乘以任务其他部分的相对系数,是无法得出对整项工作的精确估计的。
2.构建独立小型程序的数据不适用于编程系统项目。
3.程序开发与程序规模成指数增长趋势。
4.当使用适当的高级语言时,程序编制的生产率可以提高5倍。
削足适履这一章主要是要解决项目投资与磁盘空间和内存之间的矛盾,但是这个矛盾在电脑硬件发展到现在的层次已经可以忽略掉了。
提纲挈领1.软件项目的要求:
目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。
2.即使是小型项目,项目经理也应该在项目早期规范化上述的一系列文档。
这一章强调文档重要性,但并没有将一些教条主义的道理让你相信文档的重要性,而是给项目经理给出了实实在在的操作步骤。
未雨绸缪1.对于大多数项目,第一个开发的系统并不合用。
它可能太慢、太大,而且难以使用,或者三者兼而有之。
系统的丢弃和重新设计可以一步完成,也可以一块块地实现。
这是个必须完成的步骤,如果将开发的第一个系统丢弃原型发布给用户,可以获得时间,但是它的代价很高。
对于用户,使用极度痛苦;对于重新开发的人员,分散了精力;对于产品,影响了声誉,即使最好的再设计也难以挽回名声。
2.用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
3.软件产品易于掌握的特性和不可见性,导致了它的构建人员面临着永恒的需求变更。
4.目标和开发策略上的一些正常变化无可避免,事先为它们做准备总比假设它们不会出现要好得多。
5.对于一个广泛使用的程序,其维护总成本通常是开发成本的40%或更多。
6.维护成本受用户数目的严重影响。
用户越多,所发现的错误也越多。
7.campbell指出了一个显示产品生命期中每月bug数的有趣曲线,它先是下降,然后攀升。
8.缺陷修复总会以(20-50)%的机率引入新的bug。
9.在每次修复之后,必须重新运行先前所有的测试用例,从而确保系统不会以更隐蔽的方式被破坏。
10.同样,设计实现的人员越少、接口越少,产生的错误也就越少。
11.所有修改都倾向于破坏系统的架构,增加了系统的混乱程度。
即使是最熟练的软件维护工作,也只是放缓了系统退化到不可修复混乱的进程。
干将莫邪项目经理应该制订一套策略,以及为通用工具的开发分配资源,与此同时,他还必须意识到专业工具的需求。
祸起萧墙1.一天一天的进度落后比起重大灾难,更难以识别,更不容易防范和更加难以弥补。
2.根据一个严格的进度表来控制项目的第一个步骤是制订进度表,进度表由里程碑和日期组成。
3.里程碑必须是具体的、特定的、可度量的事件,能进行清晰能定义。
4.如果里程碑定义得非常明确,以致于无法自欺欺人时,程序员很少会就里程碑的进展弄虚作假。
另外一面1.对于软件编程产品来说,程序向用户所呈现的面貌与提供给机器识别的内容同样重要。
2.即使对于完全开发给自己使用的程序,描述性文字也是必须的,因为它们会被用户和作者所遗忘。
3.文档能在整个软件开发的生命周期对程序员克服懒惰和进度的压力起促进激励作用,但向编程人员成功地灌输对待文档的积极态度是一件困难的事情。
4.为了使文档易于维护,将它们合并至源程序是至关重要的,而不是作为独立文档进行保存。
没有银弹人狼的传说可能有人听过也可能没听过,人狼是一种具有人和狼两种特征的恐怖生物,而银弹是消灭它的一种最有效的子弹,如果看过《吸血鬼传说》也许就能和容易的理解这一点。
作者将软件开发比作人狼,而将提高软件开发效率的方法比作银弹。
作者预言未来十年,想要试图通过寻找一种有效地银弹将软件开发效率提高一个甚至几个数量级,这种银弹不可能出现。
没有银弹这篇文章里作者列举出了当时一些非常先进的技术或思想理念,例如ada和其他高级编程语言、面向对象编程、人工智能、专家系统、”自动”编程、图形化编程、程序验证、环境和工具、工作站等。
虽然这些先进技术在一定程度上提高了软件开发的效率,但是始终没有达到银弹的效果。
距离作者的预言已经过去有20多年了,纵观现在的软件开发领域,虽然新技术层出不穷,但是还是没有一种银弹能够让软件开发产生一次革命。
焦油坑依然存在软件工程的焦油坑在将来很长一段时间内会继续困扰着人们。
由于软件系统多变性和错综复杂性,这个行业只能是一步一个台阶的往上爬,而出现银弹的希望在我们可以想象的时间范围内是非常渺茫的。
我们将长期与焦油作斗争。
第二篇:
《人月神话》读书笔记第1章焦油坑这一章分成两个部分:
?
程序(program)、程序产品(programmingproduct)、编程系统(programmingsystem)、编程系统产品(programmingproductsystem)的概念?
程序员的工作性质比较有意思的是第一部分的四个概念。
在作者的眼中,程序就是一堆代码,任何人可以宣称自己会编程,但是编程得到的只是程序,而不是产品。
程序要成为程序产品,需要有明确的输入、功能和输出,经过完备的测试,具备合格的文档,使之功能可靠,维护易行。
编程系统是从系统的角度来看待功能完整的程序模块,要求程序要具备语法和语义精确的接口,能够与其他的程序进行流畅的交互。
相比程序产品来说,不仅仅要严格测试程序自身的输入、处理、输出,还要测试与不同程序之间的交互,因为很多bug其实是隐含在不同功能模块的交互过程中。
另外编程系统还要考虑程序之外的软硬件运行环境。
呵呵,只有经过了集成测试之后才能称之为编程系统。
最高级的形式是编程系统产品,从书中的表述来看,就是编程系统+各类文档,文档是为了后续维护和升级方便而准备的。
智力产品如果没有说明书真是一场噩梦啊,之前我们经历过的不少系统到了后续维护的时候发现文档补齐,维护人员真是伤透脑筋,最后问题太多了索性就提议推倒重做。
可以说如果是文档齐备一点,我们公司很多系统的寿命是可以更长的。
第2章人月神话第三篇:
人月神话笔记人月神话读书笔记
(一)第一章焦油坑表面上看起来好像没有任何一个单独的问题会导致困难,每个都能被解决,但是当它们相互纠缠和积累在一起的时候,团队的行动就会变得越来越慢。
对问题的麻烦程度,每个人似乎都会感到惊讶,并且很难看清问题的本质。
不过,如果我们想解决问题,就必须试图先去理解它。
--清楚地解释系统开发的困难所在。
这,就是编程。
一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。
对于许多人而言,其中的乐趣远大于苦恼。
而本书的剩余部分将试图搭建一些桥梁,为通过这样的焦油坑提供一些指导。
--本书的目的第二章人月神话1.在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还大。
导致灾难的原因是:
首先,我们对估算技术缺乏有效的研究。
第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作。
第四,对进度缺少跟踪和监督。
第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。
2.系统开发过程中,乐观主义并不应该是理所应当的。
在单个任务中,“一切都将运转正常”的假设在时间进度上具有可实现性。
因为所遇的延迟是一个概率分布曲线,“不会延迟”仅具有有限的概率,所以现实情况可能会像计划安排的那样顺利。
然而大型的编程工作,或多或少包含了很多任务,某些任务间还具有前后的次序,从而一切正常的概率变得非常小,甚至接近于无。
3.成本的确随开发产品的人数和时间的不同,有着很大的变化,进度却不是如此。
因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
它暗示着人员数量和时间是可以相互替换的。
因为软件开发本质上是一项系统的工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。
从而,添加更多的人手,实际上是延长了,而不是缩短了时间进度。
4.在时间进度中,顺序限制所造成的影响,没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。
对于任务的进度安排,以下是作者使用了很多年的经验法则:
1/3计划1/6编码1/4构件测试和早期系统测试(单元测试)1/4系统测试5.如果发现项目的实际进度滞后于预计的进度,项目经理最好的办法是重新安排进度,而不是增加项目人手。
6.项目的时间依赖于顺序上的限制,人员的数量依赖于单个子任务的数量。
从这两个数值可以推算出进度时间表,该表安排的人员较少,花费的时间较长(唯一的风险是产品可能过时)。
相反,分派较多的人手,计划较短的时间,将无法得到可行的进度表。
总之,在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。
第三章外科手术队伍1.对于效率和概念的完整性来说,最好由少数干练的人员来设计和开发,而对于大型系统,则需要大量的人手,以使产品能在时间上满足要求。
如何调和这两方面的矛盾呢?
--本章要解决的问题2.mills的建议:
外科医生(首席程序员):
定义功能和性能技术说明书,设计程序,编制源代码,测试以及书写技术文档。
副手:
主要作用是作为设计的思考者、讨论者和评估人员。
管理员:
控制财务、人员、工作地点安排和机器,充当组织中其他管理机构的接口。
编辑:
根据外科医生的草稿或者口述的手稿,进行分析和重新组织,提供各种参考信息和书目,对多个版本进行维护以及监督文档生成的机制。
两个秘书程序职员:
维护编程产品库中所有团队的技术记录。
工具维护人员:
保证所有基本服务的可靠性,以及承担团队成员所需要的特殊工具(特别是交互式计算机服务)的构建、维护和升级责任。
测试人员:
各个功能设计系统测试用例的对头,同时也是日常调试设计测试数据的助手。
负责计划测试的步骤和为测试搭建测试平台。
语言专家:
寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。
3.当进行大系统开发时:
要有一个系统结构师从上至下地进行所有的设计。
要使工作易于管理,必须清晰地划分体系结构设计和实现之间的界线,系统结构师必须一丝不苟地专注于体系结构。
第四章贵族专制、民主政治和系统设计1.概念一致性在系统设计中,概念完整性应该是最重要的考虑因素。
也就是说为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。
2.功能与理解上复杂程度的比值才是系统设计的最终测试标准。
但是功能本身或者易于使用都无法成为一个好的设计评判标准。
3.简洁和直白来自概念的完整性。
每个部分必须反映相同的原理、原则和一致的折衷机制。
在语法上,每个部分应使用相同的技巧;在语义上,应具有同样的相似性。
因此,易用性实际上需要设计的一致性和概念上的完整性。
4.概念的完整性要求设计必须由一个人,或者非常少数互有默契的人员来实现。
5.系统的体系结构(architecture)指的是完整和详细的用户接口说明。
体系结构必须同实现仔细地区分开来。
6.作者不认为只有结构师才有好的创意。
新的概念经常来自实现者或者用户。
然而系统的概念完整性决定了使用的容易程度。
不能与系统基本概念进行整合的良好想法和特色,最好放到一边,不予考虑。
如果出现了很多非常重要但不兼容的构想,就应该抛弃原来的设计,对不同基本概念进行合并,在合并后的系统上重新开始。
7.概念的完整性的确要求系统只反映唯一的设计理念,用户所见的技术说明来自少数人的思想。
实际工作被划分成体系结构、设计实现和物理实现,但这并不意味着该开发模式下的系统需要更长的时间来创建。
经验显示恰恰相反,整个系统将会开发得更快,所需要的测试时间将更少。
同工作的水平分割相比,垂直划分从根本上大大减少了劳动量,结果是使交流彻底地简化,概念完整性得到大幅提高。
第五章画蛇添足1.本章的目标:
结构设计师要避免向系统中添加很多不实际的功能(避免画蛇添足)。
2.尽早交流和持续沟通能使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。
3.面对估算过高的难题,结构师有两个选择:
削减设计或者建议成本更低的实现方法--挑战估算的结果。
后者是固有的主观感性反应。
此时,结构师是在向开发人员的做事方式提出挑战。
想要成功,结构师必须牢记是开发人员承担创造性和发明性的实现责任,所以结构师只能建议,而不能支配;时刻准备着为所指定的说明建议一种实现的方法,同样准备接受其他任何能达到目标的方法;对上述的建议保持低调和平静;准备放弃坚持所作的改进建议。
4.一个可以开阔结构师眼界的准则是为每个小功能分配一个值:
每次改进,功能x不超过m字节的内存和n微秒。
这些值会在一开始作为决策的向导,在物理实现期间指南和对所有人的警示。
5.项目经理必须坚持至少拥有两个系统以上开发经验的结构师的决定。
同时,保持对特殊诱惑的警觉,他可以不断提出正确的问题,确保原则上的概念和目标在详细设计中得到完整的体现。
第六章贯彻执行1.问题:
项目经理如何确保每个人听从、理解并实现结构师的决策?
对于有多个结构师的小组如何保持系统概念上的完整性。
2.手册、或者书面规格说明,是一个非常必要的工具。
手册是产品的外部规格说明,它描述和规定了用户所见的每一个细节;同样的,它也是结构师主要的工作产物。
手册不但要描述包括所有界面在内的用户可见的一切,它同时还要描述用户看不见的事物。
后者是编程实现人员的工作范畴,而实现人员的设计和创造是不应该被限制的。
体系结构设计人员必须为自己描述的任何特性准备一种实现方法,但是他不应该试图支配具体的实现过程。
规格说明的风格必须清晰、完整和准确。
用户常常会单独提到某个定义,所以每条说明都必须重复所有的基本要素,所以所有文字都要相互一致。
3.规格说明中,形式化定义是精确的,它们倾向于更加完整;差异得更加明显,可以更快地完成。
但是形式化定义的缺点是不易理解。
记叙性文字则可以显示结构性的原则,描述阶段上或层次上的结构,以及提供例子。
应同时包括形式化和记叙性定义两种方式。
4.通过会议的方式,开发人员进行沟通和讨论问题。
5.不同实现之间严格要求相互兼容。
如果起初至少有两种以上的实现,那么定义会更加整洁和规范。
6.对于存有疑问的实现人员,应鼓励他们打电话询问相应的结构师,而不是一边自行猜测一边工作。
一种有用的机制是由结构师保存电话日志。
日志中,他记录了每一个问题和相应的回答。
每周,对若干结构师的日志进行合并,重新整理,并发布给用户和实现人员。
这种机制很不正式,但非常快捷和易于理解。
7.在最后的分析中,用户是独立的监督人员。
在残酷的现实使用环境中,每个细微缺陷都将无从遁形。
产品测试小组则是顾客的代理人,专门寻找缺陷。
不时地,细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。
出于这方面的原因,设立测试小组是使设计决策得以贯彻执行的必要手段,同样也是需要尽早着手,与设计同时实现的重要环节。
第七章为什么巴比伦塔会失败1.项目人员之间的交流和沟通是项目能否顺利和成功的一个重要因素。
2.缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。
随着工作的进行,许多小组慢慢地修改自己程序的功能、规模和速度,他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。
团队如何进行相互之间的交流沟通:
清晰定义小组内部的相互关系和充分利用电话,能鼓励大量的电话沟通,从而达到对所书写文档的共同理解。
常规项目会议。
会议中,团队一个接一个地进行简要的技术陈述。
这种方式非常有用,能澄清成百上千的细小误解。
在项目的开始阶段,应该准备正式的项目工作手册。
3.项目工作手册不是独立的一篇文档,它是对项目必须产出的一系列文档进行组织的一种结构。
项目所有的文档都必须是该结构的一部分。
这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
4.使用项目工作手册的原因:
技术说明几乎是必不可少的。
如果某人就硬件和软件的某部分,去查看一系列相关的用户手册。
他发现的不仅仅是思路,而且还有能追溯到最早备忘录的许多文字和章节,这些备忘录对产品提出建议或者解释设计。
正确的文档结构非常重要。
事先将项目工作手册设计好,能保证文档的结构本身是规范的。
另外,有了文档结构,后来书写的文字就可以放置在合适的章节中。
控制信息发布,确保信息能到达所有需要它的人的手中。
5.团队组织的目的是减少不必要的交流和合作的数量。
减少交流的方法是人力划分和限定职责范围。
当使用人力划分和职责限定时,树状管理结构所映出对详细交流的需要会相应减少。
第八章胸有成竹1.问题:
系统编程需要花费多长时间?
需要多少工作量?
如何进行估计?
2.工作量是规模的幂函数。
portman的数据:
工作花费的时间大约是估计的两倍。
aron、harr、os/360的数据:
生产率会根据任务本身的复杂度和困难程度表现出显著差异。
carbato的数据:
对常用的编程语句而言。
生产率似乎是固定的。
这个固定的生产率包括了编程中需要注释,并可能存在错误的情况。
使用适当的高级语言,编程的生产率可以提高5倍。
第九章削足适履1.系统的空间规模:
规模是软件系统产品用户成本中如此大的一个组成部分,开发人员必须设置规模的目标,控制规模,考虑减小规模的方法。
同任何开销一样,规模本身不是坏事,但不必要的规模是不可取的。
2.对项目经理而言,规模控制既是技术工作的一部分,也是管理工作的一部分。
必须研究用户和他们的应用,以设置将开发系统的规模。
接着,把这些系统划分成若干部分,并设定每个部分的规模目标。
由于规模--速度权衡方案的结果在很大的范围内变化,规模目标的设置是一件颇具技巧的事情,需要对每个可用方案有深刻的了解。
聪明的项目经理还会给自己预留一些空间,在工作推行时分配。
仅对核心程序设定规模目标是不够的,必须把所有的方面
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 人月 神话 读书笔记