《软件工艺》的原文摘录

  • 一个非常典型的例子就是美国国防部于 1969 年至 1975 年间开发的 SAFEGUARD 弹道导弹防御系统。“SAFEGUARD 系统的开发和部署堪称有史以来最大、最复杂的软件系统。”在项目开始的第一年(1969 年),工作量为 188 人年;到 1972 年,年工作量已经达到 1 261 人年;整个项目的工作量共计 5 407 人年,平均每年生产率为每人年 418 条指令。 SAFEGUARD 是一个极其庞大的软件工程项目,它也代表了当时软件工程的最高水平。它所使用的计算机硬件是专为此项目而开发的。尽管程序设计工作都是用低级语言完成的,但编程和单元测试阶段在全部工作量中所占的比重还不到 20%。系统工程(需求分析)和设计各自占据了 20% 的工作量,其他的工作量(超过 40%)则用于集成测试。 在试图理解软件工程时,我们需要在脑海中牢记下列两点: 1. 像 SAFEGUARD 这样规模的项目属于凤毛麟角。 2. 但软件工程正是在这些超大型项目(超过 1 000 人年)的基础上定义的。 这些大型项目是真正的“系统工程”项目。这些项目通常同时包含硬件和软件的开发,其中的硬件是专为与软件协作而开发的。这一类项目有一个共通的特点:在项目的前期,软件开发者需要等待硬件的开发;而在项目的后期,则是硬件开发者在等待软件的开发。软件工程正是在这样一对矛盾中发展起来的。 等待硬件开发时,软件开发者在干什么? 在典型的软件工程项目前期,软件开发者会有很多的时间。这时,硬件的发明或者设计尚未完成,所以软件开发者有大把的时间来做需求调研,并编写出详尽的软件设计规格书。他们根本不可能提前开始编码,因为用于执行代码的硬件环境根本还不存在(在很多较早的范例中,在这一阶段甚至连编译器和代码加载器都还不存在)。有时,连编程语言都必须到项目的后期才能选定。所以,就算设计规格书已经巨细靡遗,提前... (查看原文)
    yuan 1回复 3赞 2013-08-13 10:07:35
    —— 引自章节:理解软件工程
  • 软件工程的关键问题就在于:它使我们忘记了“是人来开发软件”这样一个简单的事实。软件工程含蓄地给了我们一个承诺:只要能定义出一个有组织、有纪律、可计量的开发过程,任何人都可以成功地完成软件开发。可惜,这只能是一个梦想。正如 Curtis 的调研报告所表明的:就算有了一个理想的过程,想要获得项目的成功,出类拔萃的开发者仍然是必不可少的。 越好的程序员,所犯的错误就越少,并且发现错误也越快。 真正决定项目成败的,是作为个体的程序员的技能、知识和经验。 其实,我们应该讨论的不是“项目的缺陷可能性”,而是“开发者的缺陷可能性”。 (查看原文)
    yuan 2013-08-13 12:44:41
    —— 引自章节:软件工程的困境
  • SCRUM 软件开发过程的创始人曾经这样说道: 如果某个过程能够完全确定下来(即能够了解过程所涉及的所有细节,从而将其设计为可以重复地多次运行,并且完全能够预测其结果),那么该过程就被称为“确定过程”。从理论上来说,一切确定的过程都可以被自动完成。另一方面,如果人们并未了解某个过程中的所有细节,只是大致地知道在某些初始条件下、通过某些调节和控制就能得到想要的结果,这样的过程就被称为“经验过程”。 (查看原文)
    yuan 2013-08-13 14:34:33
    —— 引自章节:“有组织的、可计量的”软件开发过程现实吗?
  • 开发者哪怕只是动一动“排除所有缺陷”的念头也会被认为是浪费力气,因为一大半的特性很可能就实现在现有的错误之上。由于“足够好”的开发方式将编码和测试分离成了两个截然不同的阶段,所以用这种方式开发出的应用程序中必定会包含大量缺陷。 (查看原文)
    yuan 2013-08-15 22:10:20
    —— 引自章节:“足够好”的软件开发方法的危害
  • 软件开发的整个过程可以总结为:获取明确的和隐含的知识,并将这些知识具现化到软件之中。按照 Howard Baetjer 的观点,软件开发者的关键难题在于协调各种不同知识的学习,软件开发的关键局限在于“理解我们尝试做的事情的能力”。 特别是,客户也需要经历一个学习的过程,听项目组向他们解释需求所蕴涵的本质。这个学习的过程正是造成需求变更的一个主要原因。 软件开发的全部意义就在于解决未知因素。 (查看原文)
    yuan 2013-08-16 16:02:09
    —— 引自第24页
  • 在软件开发史的早期,情况并非完全如此,因为当时的最大困难是在实现阶段,也就是“如何给计算机编程”的问题。但是,随着开发者们逐渐创造出越来越好的编程方式,困难就逐渐从实现阶段转移到了设计阶段。而对于如今的很多项目来说,设计和实现都已经不再是难题,最主要的困难是在需求分析阶段和需求分析与软件设计之间的交流上。 (查看原文)
    yuan 2013-08-16 17:06:56
    —— 引自第25页
  • 我发现项目进度的瓶颈竟然如此变化不定,这一发现一直都令我非常惊讶。可能成为瓶颈的步骤包括: 谈判认可项目预算; 选择合适的开发团队(尤其是在进行外包时); 获取需求文档并签字认可(这一过程也许会长达 7 年之久); 与业务用户和决策者交流; 由项目指导委员会及时作出决策; 找到优秀的设计师和程序员; 通过与并行项目的竞争而获得项目所需的资源; 当有经验的开发者不得不抽出时间来指导新手时,他需要腾出时间完成被耽误的工作; 让技术选择得到批准和签字认可; 在各种各样的交付平台上测试; 让应用体系结构组认可整体设计概念; 使主要的开发者达成共识,选择合适的设计方案; 安排设计和代码复审的时间表; 调试和性能优化; 启动项目。 (查看原文)
    yuan 2013-08-16 17:36:42
    —— 引自章节:没有一劳永逸
  • 在需求说明书书和设计说明书之间存在着一条巨大的鸿沟。当我们忘记这一点时,我们就可能错误地低估软件开发的困难程度。 人们往往相信这样一种潜台词:软件开发是一件很容易的事情,只要掌握一些特殊的知识和晦涩的语法就行了。可惜,情况并非如此。“拥有知识”和“拥有利用这些知识开发软件的技巧和实践能力”是两码事。 (查看原文)
    yuan 2013-08-17 10:55:00
    —— 引自第42页
  • 当一位开发者推荐另一位开发者时,他同时也押上了自己的信誉,这跟认证组织宣称“这位开发者通过了认证考试”有着天壤之别:认证组织不担保任何事情。 按照软件工艺的做法,所有的推荐都是以私人身份提出的,因此没有人会轻率的作出推荐。 (查看原文)
    yuan 2013-08-17 11:29:53
    —— 引自章节:同行认可和推荐是获得更好软件的办法
  • 软件工程的目标是“管理持续经年的大型项目中的大批‘平均水准’的程序员”。 (查看原文)
    yuan 2013-08-20 16:19:39
    —— 引自第82页
  • 如果在一只运动队中,教练拿着比明星球员们还高的薪水,你认为这支球队能维持多久? (查看原文)
    白色的蓝 2014-04-10 00:12:17
    —— 引自第201页
  • 软件开发的整个过程可以总结为:获取明确的和隐含的知识,并将这些知识具现化到软件之中。 资产的设计过程,是一个社会性的学习过程,知识通过此过程而被具现化为对社会有用的形式。 (查看原文)
    红色有角F叔 2014-08-17 10:41:33
    —— 引自章节:理解软件开发
  • 没有反馈的实践只会强化错误。 (查看原文)
    红色有角F叔 2014-08-19 09:27:35
    —— 引自章节:学徒开发者
  • 所有开发者都必须花时间来从头了解业务领域。 项目结束之后,这支团队就会被拆散,开发者被分派到别的项目中去,对于构造这个应用程序的细节知识就此灰飞烟灭。 很多人都会常年光顾同一位牙医。软件开发也是如此。 (查看原文)
    红色有角F叔 2回复 2014-08-21 05:45:46
    —— 引自章节:外包的危害