帮帮文库

人月神话(外文翻译) 人月神话(外文翻译)

格式:DOC | 上传时间:2022-06-25 20:10 | 页数:16 页 | ✔ 可编辑修改 | @ 版权投诉 | ❤ 我的浏览
人月神话(外文翻译)
人月神话(外文翻译)
1 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
2 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
3 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
4 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
5 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
6 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
7 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
8 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
9 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
10 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
11 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
12 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
13 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
14 页 / 共 16
人月神话(外文翻译)
人月神话(外文翻译)
15 页 / 共 16

1、受到的牵涉更彻底。而且,要求的时间依赖于所遇到的缺陷数量以及捕捉它们的程度。理论上,缺陷的数量应该为零。但是,由于我们的乐观主义,通常实际出现的缺陷数量比预料的要多得多。因此,系统测试进度的安排常常是编程中最不合理的部分。对于软件任务的进度安排,以下是我使用了很多年的经验法则计划编码构件测试和早期系统测试系统测试,所有的构件已完成在许多重要的方面,它与传统的进度安排方法不同分配给计划的时间比寻常的多。即便如此,仍不足以产生详细和稳定的计划规格说明,也不足以容纳对全新技术的研究和摸索。对所完成代码的调试和测试,投入近半的时间,比平常的安排多很多。容易估计的部分,即编码,仅仅分配了六分之的时间。通过对传统项目进度安排的研究,我发现很少项目允许为测试分配半的时间,但大多数项目的测试实际上是花费了进度中半的时间。它们中的许多项目,在系统测试之前还能保持进度。或者说,除了系统测试,进度基本能保证。特别需要指出的是,不为系统测试安排足够的时间简直就是场灾难。因为延迟发生在项目快完成的时候。直到项目的发布日期,才有人发现进度上的问题。因此,坏消息没有任何预兆,很晚才出现在客户和项目经理面前。另外,此时此刻的延迟具有不寻常的严重的财务和心理上的反应。在此之前,项目已经配置了充足的人员,每天的人力成本也已经达到了最大的限度。更重要的是,当软件用来支持其他的商业活动计算机硬件到货,新设备服务上线等等时,这些活动延误出现即将发布前,那么将付出相当高的商业代价。实际上,上述的二次成本远远高于其他开销。因此,在早期进。

2、统测试必须被延长。因此,在第三个月的月末,仍然残留着个人月的工作,但此时只有个有效的人月。如同图所示,产品还是会延期,如同没有增加任何人手图。期望四个月内完成项目,仅仅考虑培训的时间,不考虑任务的重新划分和额外的系统测试,在第二个月末需要增添个,而不是个人员。如果考虑任务划分和系统测试的工作量,则还需要继续增加人手。到那时所拥有的就不是人的队伍,而是人以上的团队并且小组的组织和任务的划分在类型上都不尽相同,这已经不是程度上的差异问题。注意在第三个月的结尾时,情况看上去还是很糟。除去管理的工作不谈,月日的里程碑仍未达到。此时,对项目经理而言,仍然存在着很强的诱惑添加更多人力,结果往往会是上述循环的重复。这简直就是种疯狂愚蠢的做法。前面的讨论仅仅是第个里程碑估计不当的情况。如果在月日,项目经理做出了比较保守的假设,即整个估计过于乐观了,如图所示。个人手需要添加到原先的任务中。培训任务的重新分配系统测试工作量的计算作为练习留给读者。但是毫无疑问,重现灾难所开发出的产品,比没有增加人手,而是重新安排开发进度所产生的产品更差。简单武断地重复下法则向进度落后的项目中增加人手,只会使进度更加落后。这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制,人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表,该表安排的人员较少,花费的时间较长唯的风险是产品可能会过时。相反,分派较多的人手,计划较短的时间,将无法得到可行的进度表。总之,在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原。

3、所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人也可能是成百上千琐碎的挫折赶走了大多数人,只剩下了那些习惯上只关注结果的人还可能仅仅因为计算机还很年轻,程序员更加年轻,而年轻人总是些乐观主义者无论是什么样的程序,结果是勿庸置疑的这次它肯定会运行。或者我刚刚找出了最后个。所以系统编程的进度安排背后的第个假设是切都将运作良好,每项任务仅花费它所应该花费的时间。对这种弥漫在编程人员中的乐观主义,理应受到慎重的分析。在她的书中,将创造性活动分为三个阶段构思实现和交流。书籍计算机或者程序的出现,首先是作为个构思或模型出现在作者的脑海中,它与时间和空间无关。接着,借助钢笔墨水和纸,或者电线硅片和铁氧体,在现实的时间和空间中实现它们。然后,当人阅读书本使用计算机和运行程序的时候,他与作者的思想相互沟通,从而创作过程得以结束。以上的阐述不仅仅可以描绘人类的创造性活动,而且类似于基督的教义,能指导我们的日常工作。对于创造者,只有在实现的过程中,才能发现我们构思的不完整性和不致性。因此,对于理论家而言,书写试验以及工作实现是非常基本和必要的。在许多创造性活动中,往往很难掌握活动实施的介质,例如木头切割油漆电器安装等。这些介质的物理约束限制了思路的表达,它们同样对实现造成了许多预料之外的困难。由于物理介质和思路中隐含的不完善性,实际实现起来需要花费大量的时间和汗水。对遇到的大部分实现上的困难,我们总是倾向于去责怪那些物理介质,因为它们不顺应我们设定的思路。其实,这只不过是我们的骄傲使判。

4、,它比其他所有因素加起来的影响还要大。小麦或收获棉花的工作中是可行的而在系统编程中近乎不可能。图人员和时间之间的关系完全可以分解的任务当任务由于次序上的限制不能分解时,人手的添加对进度没有帮助图。无论多少个母亲,孕育个生命都需要十个月。由于调试测试的次序特性,许多软件都具有这种特征。图人员和时间之间的关系无法分解的任务对于可以分解,但子任务之间需要相互沟通和交流的任务,必须在计划工作中考虑沟通的工作量。因此,相同人月的前提下,采用增加人手来减少时间得到的最好情况,也比未调整前要差些图。图人员和时间之间的关系需要沟通的可分解任务沟通所增加的负担由两个部分组成,培训和相互的交流。每个成员需要进行技术项目目标以及总体策略上的培训。这种培训不能分解,因此这部分增加的工作量随人员的数量呈线性变化。相互之间交流的情况更糟些。如果任务的每个部分必须分别和其他部分单独协作,则工作量按照递增。对交流的情况下,三个人的工作量是两个人的三倍,四个人则是两个人的六倍。而对于需要在三四个人之间召开会议进行协商同解决的问题,情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用,此时我们会被带到图的境地。图人员和时间之间的关系关系错综复杂的任务因为软件开发本质上是项系统工作错综复杂关系下的种实践沟通交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。从而,添加更多的人手,实际上是延长了,而不是缩短了时间进度。系统测试在时间进度中,顺序限制所造成的影响,没有哪个部分比单元调试和系统测试。

5、的不同,有着很大的变化,进度却不是如此。因此我认为用人月作为衡量项工作的规模是个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况个任务可以分解给参与人员,并且他们之间不需要相互的交流图。这在割经理面对的选择方案有哪些呢假设任务必须按时完成。假设仅仅是任务的第个部分估计不得当,即如图所示,则剩余了个人月的工作量,时间还有两个月,即需要个开发人员,所以需要在原来个人的基础上增加个人。假设任务必须按时完成。假设整个任务的估计偏低,即如图所示,那么还有个人月的工作量以及个月的时间,需要将原来的个人增至个人。重新安排进度。我喜欢,个具有丰富经验的硬件工程师的忠告避免小的偏差。也就是说,在新的进度安排中分配充分的时间,以确保工作能仔细彻底地完成,从而无需重新确定时间进度表。削减任务。在现实情况中,旦开发团队观察到进度的偏差,总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时,这常常是唯可行的方法。项目经理的相应措施是仔细正式地调整项目,重新安排进度或者是默默地注视着任务项由于轻率的设计和不完整的测试而被剪除。图图图图前两种情况中,坚持把不经调整的任务在四个月内完成将是灾难性的。考虑到重复生成的工作量,以第种为例图不论在多短的时间内,聘请到多么能干的两位新员工,他们都需要接受位有经验的职员的培训。如果培训需要个月的时间,那么三个人月将会投入到原有进度安排以外的工作中。另外,原先划分为三个部分的工作,会重新分解成五个部分些已经完成的工作必定会丢失,。

6、影响还大。导致这种普遍性灾难的原因是什么呢首先,我们对估算技术缺乏有效的研究,更加严肃地说,它反映了种悄无声息,但并不真实的假设切都将运作良好。第二,我们采用的估算技术隐含地假设人和月可以互换,地将进度与工作量相互混淆。第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作。第四,对进度缺少跟踪和监督。其他工程领域中,经过验证的跟踪技术和常规监督程序,在软件工程中常常被认为是无谓的举动。第五,当意识到进度的偏移时,下意识以及传统的反应是增加人力。这就像使用汽油灭火样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了场注定会导致灾难的循环。进度监督是另篇论文的主题,而本文中我们将对问题的其他方面进行更详细的讨论。乐观主义所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人也可能是成百上千琐碎的挫折赶走了大多数人,只剩下了那些习惯上只关注结果的人还可能仅仅因为计算机还很年轻,程序员更加年轻,而年轻人总是些乐观主义者无论是什么样的程序,结果是勿庸置疑的这次它肯定会运行。或者我刚刚找出了最后个。所以系统编程的进度安排背后的第个假设是切都将运作良好,每项任务仅花费它所应该花费的时间。对这种弥漫在编程人员中的乐观主义,理应受到慎重的分析。在她的书中,将创造性活动分为三个阶段构思实现和交流。书籍计算机或者程序的出现,首先是作为个构思或模型出现在作者的脑海中,它与时间和空间无关。接着,借助钢笔墨水和纸,或者电线硅片和铁氧体,在现实的时间和空间中实现它们。。

参考资料:

[1]现代企业的人力资源管理(外文翻译)(第14页,发表于2022-06-25 20:02)

[2](定稿)园林绿化服务中心水源保护区生态环境建设示范工程实施计划方案8(喜欢就下吧)(第59页,发表于2022-06-25 20:02)

[3]企业的社会责任:一种趋势和运动,但社会责任是什么,是为了什么?(外文翻译)(第14页,发表于2022-06-25 20:02)

[4](定稿)玉门市政府搬迁项目实施计划方案6(喜欢就下吧)(第117页,发表于2022-06-25 20:02)

[5]公路边坡常见支护方法(外文翻译)(第25页,发表于2022-06-25 20:02)

[6](定稿)玉米方便系列食品加工项目实施计划方案4(第85页,发表于2022-06-25 20:02)

[7]复杂性科学及其在煤矿安全行为问题研究方面的启示(外文翻译)(第22页,发表于2022-06-25 20:02)

[8](定稿)永康市南山水厂源水管线(二期)工程项目实施计划方案2(喜欢就下吧)(第66页,发表于2022-06-25 20:02)

[9](定稿)优质肉牛养殖和加工基地项目实施计划方案1(喜欢就下吧)(第64页,发表于2022-06-25 20:02)

[10]MySQL数据库管理中心(外文翻译)(第15页,发表于2022-06-25 20:02)

[11](定稿)玉米产业园项目实施计划方案9(喜欢就下吧)(第74页,发表于2022-06-25 20:02)

[12](定稿)余热锅炉余热利用资源综合利用节能工程项目实施计划方案8(第61页,发表于2022-06-25 20:02)

[13](外文翻译)-深入浅出JavaScript(第11页,发表于2022-06-25 20:02)

[14](定稿)油气工艺处理设备制造项目实施计划方案6(喜欢就下吧)(第73页,发表于2022-06-25 20:02)

[15](定稿)有机无公害脱水蔬菜、真空气调速冻保鲜蔬菜加工项目实施计划方案5(第91页,发表于2022-06-25 20:02)

[16](定稿)幼儿园建设工程项目实施计划方案4(第47页,发表于2022-06-25 20:02)

[17](定稿)永艾大道改造工程项目实施计划方案2(第99页,发表于2022-06-25 20:02)

[18]一种基于嵌入式零树小波算法的鲁棒图像压缩新方法(外文翻译)(第14页,发表于2022-06-25 20:02)

[19](定稿)优质肉牛养殖和加工基地项目实施计划方案0(喜欢就下吧)(第64页,发表于2022-06-25 20:02)

[20](定稿)永康市南山水厂源水管线(二期)工程项目实施计划方案9(喜欢就下吧)(第66页,发表于2022-06-25 20:02)

下一篇
温馨提示

1、该文档不包含其他附件(如表格、图纸),本站只保证下载后内容跟在线阅读一样,不确保内容完整性,请务必认真阅读。

2、有的文档阅读时显示本站(www.woc88.com)水印的,下载后是没有本站水印的(仅在线阅读显示),请放心下载。

3、除PDF格式下载后需转换成word才能编辑,其他下载后均可以随意编辑、修改、打印。

4、有的标题标有”最新”、多篇,实质内容并不相符,下载内容以在线阅读为准,请认真阅读全文再下载。

5、该文档为会员上传,下载所得收益全部归上传者所有,若您对文档版权有异议,可联系客服认领,既往收入全部归您。

帮帮文库——12年耕耘,汇集海量精品文档,旨在将用户工作效率提升到极致