`
mabusyao
  • 浏览: 253344 次
  • 性别: Icon_minigender_1
  • 来自: 南京
社区版块
存档分类
最新评论
阅读更多
关于软件神话,摘抄一些句子。觉得还是很有道理的,人常常会在同一个问题上反复犯错误,最好的解决办法,就是记下来。

管理者的神话:负责软件的管理者象大多数其他行业的管理者一样,都有巨大的压力,要维持预算、保持进度及提高质量。就像溺水者抓住一根救命稻草,软件管理者常常抓住软件神话不放,如果这些神话能够缓解其压力的话(哪怕是暂时的)。

神话:我们已经有了关于建造软件的标准和规程的书籍,难道它们不能给人们提供所有其需要知道的信息吗?
事实:不错关于标准的书籍已经存在,但真正用到了它们吗?软件实践者知道它们的存在吗?它们是否反映了现代软件开发的过程?它们完整吗?很多情况下,对于这些问题的答案均是“不”。
        新的神话:过度一栏软件工程的流程和规范,而忽略了软件是由人来创造的。这些人既不是艺术家也不是工程师,而应被称为工匠


神话:我们已经有了很多很好的软件开发工具,而且,我们为它们买了最新的计算机。
事实:为了使用最新型号的主机、工作站和PC机去开发高质量的软件,我们已经投入太多的费用。实际上,计算机辅助软件工程(CASE)工具相比起硬件而言对于获得高质量和高生产率更为重要,但大多数软件开发者并未使用它们
        新的神话:过度迷恋最新的工具或者是技术,云计算,虚拟化或者SOA之类的,期待能够彻底改变软件工程中的弊端。但事实上软件工程自诞生以来,从未过出现革命性的技术能做到这一点,不管那些大公司如何吹嘘


神话:如果我们已经落后于计划,可以增加更多的程序员来赶上进度(“有时称为蒙古大夫概念”)。
事实:软件开发并非象制造一样是一个机械过程。用Brooks[BRO75]的话来说,“给一个已经延迟的软件项目增加人手只会使其更加延迟”。看起来,这句话与人的直觉正好相反。但实际上,增加新人,原来正在工作的开发者必须花时间来培训新人,这样就减少了他们花在项目开发上的时间。人手可以增加,但只能是在计划周密、协调良好的情况下
        新的神话:敏捷开发认为可以通过灵活多变的计划方式避免这样的问题,但事实上帮助微乎其微,所以我们曾经遇到的问题,在敏捷开发中都会遇到。Agile至多也只是提供了一种心理上的安慰。

用户的神话:需要计算机软件的用户可能就是邻桌的人,或是另一个技术组,也可能是市场/销售部门,或另外一个公司。在许多情况下,用户相信关于软件的神话,因为负责软件的管理者和开发者很少去纠正用户的错误理解。神话导致了用户过高的期望值,并引起对开发者的极端不满意。

神话:有了对目标的一般描述就足以开始写程序了——我们可以以后再补充细节。
事实不完善的系统定义是软件项目失败的主要原因。关于待开发项目的应用领域、功能、性能、接口、设计约束及确认标准的形式化的、详细的描述是必需要的。这些内容只有通过用户和开发者之间的通信交流才能确定。
        新的神话:有关此项,敏捷开发与传统开发方式仍在大战中,很难说清楚谁对谁错。

神话:项目需求总是在不断变化,但这些变化能够很容易地满足,因为软件是灵活的。
事实:软件需求确实是经常变化的,但这些变化产生的影响会随着其引入的时间不同而不同。如果我们很注重早期的系统定义,这时的需求变化就可被很容易地适应。用户能够复审需求,并提出修改的建议,这时对成本的影响会相对较小。当在软件设计过程中才要求修改时,对成本的影响就会提高得很快。资源已经消耗了,设计框架已经建立了,这时的变化可能会引起大的改动,需要额外的资源和大量的设计修改,例如,额外的花费。实现阶段(编码和测试阶段)功能、性能、接口及其他方面的改变对成本会产生更大的影响。当软件已经投入使用后再要求修改,这时所花的代价比起较早阶段做同样修改所花的代价可能是几何级数级的增长。
        新的神话:有关此项,敏捷开发与传统开发方式仍在大战中,很难说清楚谁对谁错。

开发者的神话:那些至今仍被软件开发者相信的神话是由几十年的程序设计文化培植起来的。正如我们在本章一开始就提到的,在软件的早期阶段,程序设计被看作是一门艺术。这种旧的观念和方式是很难改变的。

神话:一旦我们写出了程序并使其正常运行,我们的工作就结束了。
事实:有人说过:“越早开始写程序,就要花越长时间才能完成它”,产业界的数据表明在一个程序上所投入的50%到70%的努力是花费在第一次将程序交给用户之后。
        新的神话:究竟该何时交付可以使用的程序,现代的开发流程认为应该尽早交付可运行的程序。

神话:在程序真正运行之前,没有办法评估其质量。
事实:从项目一开始就可以应用的最有效的软件质量保证机制之一是正式的技术复审。软件复审(见第8章)是“质量的过滤器”,比起通过测试找到某类软件错误要有效得多。(事实上,有一种理论说测试并没有真正改善软件质量

神话:一个成功项目唯一应该提交的就是运行程序。
        事实:运行程序仅是软件配置的一部分,软件配置包括:程序、文档和数据。文档是成功开发的基础,更重要的是,文档为软件维护提供了指导。
分享到:
评论

相关推荐

    软件工程人月神话

    ### 软件工程人月神话知识点解析 #### 一、《人月神话》概述 《人月神话》是软件工程领域中非常经典的一部作品,由Frederick P. Brooks, Jr.撰写。该书首次出版于1975年,至今仍被广泛阅读并受到高度评价。Brooks...

    软件工程人员必看人月神话

    《人月神话》是软件工程领域的一本经典著作,由弗雷德里克·布鲁克斯(Frederick P. Brooks Jr.)所著,首次出版于1975年。这本书在软件开发历史上留下了深刻的印记,对软件工程的理论与实践产生了深远影响。书名中...

    人月神话 (软件工程电子书)

    《人月神话》是软件工程领域的一本经典之作,由弗雷德里克·布鲁克斯(Frederick P. Brooks Jr.)撰写。这本书自1975年首次出版以来,一直被视为软件开发管理和项目策划的必备参考书,对整个IT行业产生了深远影响。 ...

    人月神话--软件工程书籍

    《人月神话》是软件工程领域的一部经典著作,由Frederick P. Brooks, Jr.撰写。这本书自1975年首次出版以来,一直备受业界推崇,被视为程序员和软件工程师必读的书籍。作者Brooks是IBM 360系统的主要设计师和项目...

    软件工程书籍:人月神话

    ### 软件工程经典著作:《人月神话》 #### 一、作品背景与作者简介 《人月神话》是一本在软件工程领域享有极高声誉的经典著作,由Frederick P. Brooks, Jr.撰写。该书首次出版于1975年,至今仍被广泛引用和阅读。...

    经典软件工程书籍《人月神话》

    《人月神话》是软件工程领域的一部经典之作,由Frederick P. Brooks, Jr.撰写,初版于1975年,至今仍被广泛阅读和引用。该书深刻探讨了软件开发过程中的诸多挑战,特别是项目管理、团队协作、需求分析、设计与编码等...

    人月神话(一本不可多得的关于软件方面的书!)

    《人月神话》是软件工程领域的一本经典之作,由弗雷德里克·布鲁克斯(Frederick P. Brooks Jr.)撰写。这本书在1975年首次出版,至今仍被广大软件开发者和项目经理视为必读的经典文献。书中探讨了软件开发中的诸多...

    软件工程思想人月神话

    《人月神话》是软件工程领域的一本经典著作,由弗雷德里克·布鲁克斯(Frederick P. Brooks Jr.)撰写。这本书首次出版于1975年,至今仍被广泛阅读和引用,其影响力跨越了多个世代的软件开发者和项目经理。书中的...

    人月神话(软件项目管理经典)

    《人月神话》是软件项目管理的经典之作,由Frederick P. Brooks, Jr.撰写,他被誉为“IBM 360系统之父”。这本书探讨了软件开发过程中的挑战、管理策略以及团队协作的关键要素。Brooks在IBM的多个重要项目中积累了...

    人月神话人月神话人月神话

    《人月神话》是软件工程领域的一本经典著作,由弗雷德里克·布鲁克斯(Frederick P. Brooks Jr.)所著,首次出版于1975年。这本书以其独特的视角深入剖析了软件开发过程中的诸多问题,提出了许多至今仍被广泛引用的...

    人月神话 关于软件工程的电子书

    ### 人月神话 关于软件工程的电子书 #### 知识点概述: 1. **软件工程与传统工程项目管理的相似性与差异性** - 本书探讨了软件工程项目的管理与传统工程项目管理之间的相似之处及独特差异。 - 强调了软件项目...

    人月神话关于软件工程的书

    总之,《人月神话》不仅是一本关于软件工程的经典著作,更是每个从事软件开发工作的人都应该阅读的一本书。它提供了一种看待软件开发的独特视角,并且提醒我们在面对复杂性时要保持谦逊的态度。

    软件 希腊神话 百科必备

    作为英语专业的同学 学习希腊神话是非常必要的 对希腊神话感兴趣的朋友 也可以找到你兴趣所在

Global site tag (gtag.js) - Google Analytics