软件工程--人月神话PPT
人月神话PPT课件

最糟糕的的情况:导致重复产生进度灾难,耗费大量 人力,物资,却反而使开发出来的产品更差
Brooks 法则:
向进度落后的项目中增加人手,只会使进度更加落后 (Adding manpower to a late software project makes it later)
这就是除去了神话色彩的人月
图形化编程
图形化和可视化编程,计算机图形在 软件设计上的应用
银弹 否?
上述方法均未出现令人激动与信服 的进步
• 程序验证
• 测试和修复BUG
•环境和工具 •
集成数据库的使用
•工作站 •
处理能力和内存容量的稳固和快速提高
Summary
主要内容
• • • • • 人月神话 外科手术队伍 贵族的专制 银弹在哪里? 没有银弹
Part 3
贵族的专制
丏政与民主
丏政:占统治地位的阶级对敌对阶级实行的强力统治的国家 制度
民主:在一定的阶级范围内,按照平等和少数服从多数原则 来共同管理国家事务的国家制度
•对立
项目管理的制度该如何?
•专政? •经理 •民主?
•技术
•编码
•管理
•编码 •测试
概念完整性
一个项目,一个建筑,一个品牌想要获得成功,就必须有一 个完整的理念、概念设计,拥有自己的概念DNA
系统测试
• 系统测试进度的安排常常是编程中最不合理的部分,测试 实际需要的时间往往比传统预测的要长很多
•传统
•VS
•作者
除了系统测试,进度基本能保证
然而不为系统测试安排足够的时间简直就 是一场灾难
会付出相当高的商业代价 因此,在早期进度策划时,允许充分的系 统测试时间是非常重要的
【正式版】项目管理培训人月神话PPT文档

质量计划编制 人力资源计划编制
质量保证
质量控制
团队组建、团队建设 项目团队管理
沟通、协作计划
信息发布
风险管理计划、风险识 别、定性分析 定量分析、应对计划
采购计划、发包计划
询价、供方选择
绩效报告、干系 人管理 风险监控
合同管理
项目收尾 合同收尾
项目管理培训
项目生命期与组织
人月神话
人月神话的博客
治大国,若烹小鲜。 为学日益,为道日损,损之又损,以至于无为。无为而无不为。 为之于未有,始之于未然
人月神话的博客
项目管理四要素
范围 进度 成本 质量
核心思想-目标管理
人月神话的博客
❖ 人的因素 – 成员自主,自觉,自治 ❖ 目标体系 – 逐层分解,相互配合 ❖ 重视成果 – 管理本质不在于知而在于行,不在于逻辑而在于成果
执行
控制
收尾
范围核实 范围控制 进度控制
成本控制
计划制定 计划执行 整体控制 项目复盘
质量计划
质量保证 质量控制
沟通计划
信息发布
资料归档
风险识别 风险量化 应对措施
风险控制
团队组建
团队建设
采购计划 招标计划
招标
采购
合同收尾
人月神话的博客
产品和项目
G300手机 |—主机板 |—显示屏A |—手机软件
项目群
项目群
项目
项目
项目
WBS 活动 任务
项目
人月神话的博客
业务战略
项目和项目组合
风险
活动项目
决策准则
项目组合 优先级和资源载量
组合监控
战略平衡 批准授权
软件工程--人月神话PPT

小组成员:
人月神话
弗雷德里克·布鲁克斯 Frederick P. Brooks, Jr.
人物简介:
• 美国工程院院士
• “IBM 360系统之父”,曾担 任360系统的项目经理,及该 项目设计阶段的经理。凭借在 此项目中的杰出贡献,在1985 年获得美国国家技术奖。
• 1999年荣获美国计算机领域最 具声望的图灵奖( A.M.TURINGAWARD)桂冠。
人月神话——祸起萧墙
• 图为1802年A.Canova所作雕 塑:英雄海格力斯( Herculues)摔死带来死亡之 袍的信使力卡斯(Lycas)。
• 海格力斯是希腊神话中最伟大 的半人半神英雄,一生业绩辉 煌,却因微小的家庭变故摔死 不知情的力卡斯而走向了英雄 末路。
• 潜藏的小祸患看似微不足道, 有朝一日却可能葬送原本看起 来坚不可摧的事物。
• 适合的开发工具、评测技术 能有事半功倍的效果,切合 实用的工具和技术是项目团 队的重要财富。
人月神话——整体部分
• 图为迪士尼公司著名的 米老鼠魔术师形象。
• 作者认为某些泛泛号称自 己能完成庞大软件项目的 业界人士,与旧时以夸张 吹嘘来吸引观众注意的魔 术师一样,其表演的东西 经不起实质追究。
• 如: 20人* 5个月 > 50人* 2个月
《人月神话》目录
• 第1章 焦油坑 • 第2章 人月神话 • 第3章 外科手术队伍 • 第4章 贵族专制、民主政
治和系统设计 • 第5章 画蛇添足 • 第6章 贯彻执行 • 第7章 为什么巴比伦塔会
失败 • 第8章 胸有成竹 • 第9章 削足适履 • 第10章 提纲挈领
人月神话——未雨绸缪
• 在做项目设计和规划时,一定要考 虑到各种不确定的变化因素,灵活 适应多变的环境,否则很可能酿成 悲剧后果。
第一章软件工程PPT

(3)详细设计
详细设计是针对单个模块的设计。目的是 确定模块的过程结构,详细说明实现该模块功 能的算法和数据结构,有时也称算法设计。详 细设计的完成是用图形或伪代码描述的模块设 计说明书。
(3)编码
编码的任务是根据模块设计说明书,用指 定的程序设计语言把模块的过程性描述翻译成 源代码。与“需求分析”和“设计”相比,“ 编码”要简单得多。
2020/3/19
定义 阶段
2020/3/19
可行性研究与计划
需求分析
开
设计
发
阶
编码
段
测试
维护阶段
图2 瀑布模型
运行维护
瀑布模型的特点: ✓ 阶段间具有顺序性和依赖性; ✓推迟实现的特点; ✓每个阶段必须完成规定的文档; ✓每个阶段结束前完成文档审查,及早改正错误 。 瀑布模型的优点:
开发阶段清晰、便于评审、审计、跟踪、管 理和控制。 瀑布模型的缺点: ✓ 2020/3/19 不能对付含糊不清和不完整的用户需求;
2020/3/19
软件的概念
为了弄清软件的概念,首先要知道什么是程 序的概念。
一般认为,程序是计算机为完成特定的任务 而执行的指令的有序集合。更通俗的讲,
面向过程的程序=算法+数据结构 面向对象的程序=对象+消息 面向构件的程序=构件+构架 通常,软件可定义为: 软件=程序+数据+文档
2020/3/19
2020/3/19
听取用 户意见
建造/修改 原型
用户测试 运行原型
2020/3/19
图3 原型范型
原型化模型的特点: 原型驱动。因此必须先有一个模型,至少要
有一个原型的核心。 原型化模型的优点:
人月神话PPT

软件开发中的焦油坑
每位程序员每年生产多少行代码?
以最不幸的情况来估计,每行代码都需要自己编写, 得到结果:35,000,000 行/(5000人*5年) = 1400行/人.年。 这个效率远远低于一名正常程序员的产出量。 两种可能:
焦油坑之一:进度滞后
对于进度滞后项目的解决方案 (1)在新的进度安排中分配充分的时间,确保工作能彻底、 认真地完成 (2)当项目延期所导致的后续成本很高时,往往削减系统 的功能是唯一的解决方法
对于许多小型的开发团队,加派人手是通常的解决方法?
焦油坑之二--缺乏沟通
巴别塔为什么会失败?
巴别塔:圣经中继“诺亚方舟”后人类第二个大工程,以失败告终
焦油坑之二--缺乏沟通
巴别塔为什么会失败? ......现在整个大地都使用同一种语言。在一次迁徙的过程中, 人们发现了苏美尔地区,并且在那里定居下来。他们说: “来,让我们建造一座带有高塔的城市,这个塔将高耸云霄, 也让我们声名远扬。”于是上帝决定下来看看人们建造的城 市和高塔,看了以后,他说:“他们只是一个种族,使用一 种语言,如果他们一开始就能造出城市和高塔,那以后就没 有什么能难得倒他们了。来,让我们在人类的语言里制造些 混淆,让他们相互之间不能听懂。”上帝于是改变并区别开 了人类的语言,巴比伦塔不得不停工了。 --旧约 第11章 巴别:在希伯来语中是"变乱"的意思
是否存在终极利器?--银弹之争
人狼、银弹与软件项目 人狼:满月时会由人形变成狼形的怪兽。 银弹:唯一可以杀死人狼的武器。 软件项目:类似于人狼,常常看似简单明了的东西, 却有可能变成一个落后进度、超出预算、存在大量缺 陷的怪物。
软件工程--人月神话PPT..

弗雷德里克· 布鲁克斯 Frederick P. Brooks, Jr.
弗雷德里克·布鲁克斯的经典著作——《人月神话》
• 2000年新年伊始,国际计算机协会(ACM)在纽约宣布 1999年图灵奖得住为时年为69岁的Frederick P. Brooks, Jr.。评选委员会主席在致辞中提到,“今天我们所看到的 计算机体系结构、软件工程及三维计算机图形,均受益于 Brooks 的开创性工作,是他改变了这些领域的面貌。 ”Brooks确实是一位在计算机科学各方面均作出杰出贡 献的奠基者。
《人月神话》的由来
• IBM的System/360是第一个特大型软件项目,它催生了《人月神话》
《人月神话》的由来
• System/360的开发过程被视为计算机发展史上最大的一次豪赌,为了 研发System/360这台大型机,IBM决定征召六万多名新员工,创建五 座新工厂,而当时出货的时间不断的顺延。
人月神话
• 人月:软件开发过程中衡量工作量的常用度量单位。 • 而在实际情况中,增加“人”并不能缩短“月”的量 • 为什么说人月是神话? (1)许多任务是无法拆解的 (2)即使任务可以拆解,人员之间的沟通交流时间随着 人手的增加以(n-1)*n/2的规模递增 • 如: 20人* 5个月 > 50人* 2个月
• 概念完整性是系统设计中最 重要的因素,尤其对大型软 件系统来说,概念完整性是 项目顺利完成的必要保障。
• 图为Reims大教堂内景,位 于巴黎的Reims是建筑史上 最富盛名的哥特式教堂建筑 之一。
人月神话——பைடு நூலகம்蛇添足
• 设计者往往不肯放弃任何一个 细枝末节的创意,从而堆砌出 不胜繁复的设计,看似完美, 并现实无可行性,往往会成为 头重脚轻的空中楼阁。 • 软件项目的规划必须进行严谨 理性的估算才能为项目的顺利 进展打下牢固的根基,避免不 必要的复杂化风险。
(6)项目管理之项目时间管理(人月神话)

存在提前量的原因是活劢粒度粗 迚行活劢细分后往往丌存在提前量
6.3 活动资源估算
人月神话的博客 /cmmi
估算每项活劢所需要用到的材料、人员、设备戒用品的种类和数量的过程。 活劢资源估算过程和成本估算过程紧密相关。
输入 1.活劢清单 2.活劢属性 3.资源日历 4.事业环境因素 5.组织过程资产
输入 1.活劢清单 2.活劢属性 3.里程碑清单 4.项目范围说明书 5.组织过程资产
工具和技术 1.前导图PDM 2.确定依赖关系 3.确定提前量和滞后量 4.迚度网络模板
输出 1.项目迚度网络图 2.项目文件(更新)
前导图PDM
人月神话的博客 /cmmi
输入 1.范围基准 2.事业环境因素 3.组织过程资产
工具和技术 1.分解 2.滚劢式规划 3.模板 4.与家判断
输出 1.活劢清单 2.活劢属性 3.里程碑清单
工作包和活动的关系
人月神话的博客 /cmmi
工作包强调结果,活劢强调完成结果的过程 工作包可以作为成本核算最小单位,活劢丌定义 挣值管理需要基于工作包,而丌能基于活劢
外部输入(EI):通过界面等的输入,揑入更新等操作都是典型外部输入 外部输出(EO):仅仅输出,入导出,报表,打印等输出
外部查询(EQ):先要输入数据,在根据输入数据计算输出,如查询
内部逡辑文件(ILF):可以理解为业务对象,可能对应多个数据表 外部接口文件(EIF):其它应用提供的接口数据.
RBS
材料
人力
工具设备
需求
设计
编码
测试
开发类
测试类
架 构 设 计 岗
概 要 设 计 岗
详 细 设 计 岗
“人月神话”和CMMI(上篇)

“人月神话”和CMMI(上篇)前面文章聊过IBM的一些人一些事,这个IT行业的百年老店,大方向来说对计算机的发展其作用如树根,基石。
小领域譬如软件工程其作用如先知,先行。
两位大神级的人物:Frederick Brooks和Watts Humphrey均由IBM出品。
前面已立文介绍过两位,印象不深的可以选择回放。
以今天的视角来看,两位大师的成果也有局限也有不足,但其在软件工程发展史的地位无人能撼。
今天我要写的是,把两位大师的成果做个串烧,从十个方面对“人月神话”和CMMI做个比较,促进我们理解CMMI实践追求的目的,能够回答“为什么”的问题,而正确读懂模型的价值是有效使用它改进软件工程的基础。
在做比较之前,我有个基本假设:开发团队是一个技术强悍的团队。
这也是两位大师结论的前提。
打破软件“人月神话”的Brooks软件质量和CMMI之父Humphrey人月神话结论一:开发系统软件产品的难度比开发个人使用,独立开发的软件困难得多。
产品的通用性,系统的协同性让我们顾此失彼,导致开发的产品不是用户真正需要的!Brooks明确指出,系统软件产品的开发成本是开发具备同样功能的独立软件构件的9倍!CMMI应对策略一:CMMI给出了成功开发系统软件产品的重要要素:如需要梳理清楚需求的应用场景,开发的约束条件;管理好模块间的接口;建立统一架构支持功能开发;通过评审让相关角色对需求、架构要求、规范要求、缺陷、等达成一致的理解;通过部件级,系统级,使用环境的充分测试确保系统产品的可靠及适用性;在整个开发过程中,管理好不确定的风险,管理好团队之间的协调沟通,管理好共享资源;同时在开发过程中,维护必要的需求可追溯性,并为系统产品提供必要完备的文档,使程序变得易用,易修改,易扩展。
很多人都认为CMMI仅代表重量过程,这是因为它是为最复杂场景制定的。
殊不知其可裁剪性及其它灵活性使之也可以指导建立、完善为简单场景服务的轻量过程。
人月神话结论二:缺乏合理的时间进度是造成项目滞后的最主要原因。
基于人月神话理论的软件开发生命周期分析

基于人月神话理论的软件开发生命周期分析第一章:引言随着信息技术的不断发展和普及,软件已经成为人们生活中不可或缺的一部分。
然而,软件开发的过程和周期往往被人们所忽视,乃至于对软件开发周期的规划和安排深信不疑的开发者也常常会因为开发过程中的不确定性而手忙脚乱。
因此,在软件开发周期的管理和掌控上,越来越多的软件开发企业和项目管理人员开始关注人月神话理论。
该理论指出,软件开发的成功与否取决于软件开发周期的合理规划和管理,而这需要开发人员和各个部门的密切协作和高效沟通。
本文将从人月神话理论的角度出发,对软件开发生命周期进行分析,旨在帮助开发者和项目管理人员掌握软件开发的合理规划和管理方法。
第二章:软件开发生命周期1. 定义软件开发生命周期是指从软件项目的启动到最终交付使用并维护的整个过程,通常包括软件需求分析、软件设计、编码、测试、发布和维护等多个阶段。
2. 各阶段的任务和特点(1)软件需求分析在软件开发的早期阶段,开发团队需要与项目的客户或业务方进行沟通,了解项目的需求和要求,并对其进行详尽的分析和梳理。
同时,还需要确定软件开发项目的目标、范围和时间等关键要素,为后续的开发工作提供指导和约束。
(2)软件设计在软件需求分析的基础上,开发团队需要对软件的整体架构、功能模块、数据库结构等进行详细设计。
同时,还需要确定软件的开发框架、开发工具和开发语言等,以及确定软件的开发流程和开发规范等。
(3)软件编码在软件设计完成后,开发团队可以开始根据设计文档进行软件编码工作。
这个过程需要开发人员采用所选定的开发工具和语言进行编码实现,并且注意到相应的编码规范。
在此过程中,开发人员也需要对软件进行相应的单元测试和代码质量评估。
(4)软件测试当软件编码完成后,开发团队需要进行软件的整体测试。
软件测试的目的是发现潜伏在软件中的错误或者缺陷,以便及时修复。
软件测试主要分为单元测试、集成测试和系统测试等多个层级,以确保软件的各项功能和性能都能达到预期目标。
人本开发课件

精
32
人本编码
开发者的惰性 推动策略
建立合理、明确的目标 执行力
精
33
人本编码
拉动策略
将工作过程同学习过程联系起来 树立榜样 适当的奖励 充分肯定人员价值
软件开发人员的需求
成就感 发展机遇 工作乐趣 个人生活 成为技术主管的机会 领先 同事间的人际关系 受认可程度 工资 责任感
学习是曲线上升的过程 对外界干扰反映强烈 人无完人,开发者肯定要犯错误
精
22
人本设计
学习是曲线上升的过程 设计过程是学习和创造过程的混合 如果设计人员没有参与需求,那就一定要让
他先充分的理解需求 除需求外,对设计方法的学习也是需要考虑
的因素 可以把两个学习过程结合起来,缩短整个周
计只有跟着感觉走了。 画UML图用了一个小时,其中有四十分钟在聆听
硬盘噪声中等待
精
26
人本编码
在编码过程中,我们需要重点考虑:
学习曲线 个体生产率不稳定 个体间的生产率差距更明显 对外界的干扰反映强烈 人无完人,开发者肯定要犯错误 除了天生的工作狂,开发者都有惰性
精
27
人本编码
粗暴的按照部门或者功能点划分任务。例如每两 天调研一个部门
调研时像学生一样的听客户讲解业务、需求,并 一丝不漏的记录下来
精
20
人本设计
设计过程将需求中的软件蓝图转化为概念模 型
高层设计经常会经过长时间的思考,一定的 讨论,得出简洁的结果
精
21
人本设计
在设计过程中,我们需要重点考虑:
反复同用户交流 从无到有的建立起软件蓝图 将需求和软件蓝图记录下来并文档化
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
• 本章结合软件工程领域的最新 发展,包括面向对象技术和软 件复用等回应了争议:人们期 待的重大突破不可能在近期内 到来。
是否存在终极利器?--银弹之争
• 人狼、银弹与软件项目
– 人狼:满月时会由人形变成狼形的怪兽。 – 银弹:唯一可以杀死人狼的武器。 – 软件项目:类似于人狼,常常看似简单明了的东西, 却有可能变成一个落后进度、超出预算、存在大量缺 陷的怪物。
银弹之争
• 无风不起浪:一篇《没有银弹》在学术界掀起了一场不大 不小的风浪,从而引发了再论“没有银弹”。
人月神话——再论“没有银弹”
• 完美的东西其实就是过去不曾 出现、现在不存在、将来也不 可能出现的东西:不要指望《 没有银弹》是完美的。
• 《没有银弹》中提到的观点是 以10年为限的。
• 图为儿童在搭建组合构造 玩具。利用成型的配件, 搭建大型的架构。
人月神话——焦油坑
史前 今天
焦油坑
大型软件项目
吞噬
围困
• 图为洛杉矶自然历史博物 馆GeorgeC.Page馆内布拉 雷亚焦油坑的中生代情形 想象图原图
成千上万的巨兽
无数庞大的开发团体
人月神话——人月神话
• 精美的烹饪需要时间
• 软件开发项目常以人月来衡量工 作,这种度量暗示着人手和时间 是可以互换的。这种“人多力量 大”的想法是一种一厢情愿的虚 妄神话。 • Brooks法则:向滞后的软件项目 追加人手会使得进度更迟缓。
• 图为迪士尼公司著名的 米老鼠魔术师形象。
人月神话——另外一面
• 巨石阵是世界上最大的没有 文档说明的“计算机器”。 古人没留下任何说明,至今 考古学家对古人建巨石阵的 目的莫衷一是。 • 提供给用户的使用说明等文 档是软件呈现给用户的另一 面,它也能直接影响用户对 软件的满意度和可用性评价 。
• 图为1897年美国老国会 图书馆内景。
人月神话——未雨绸缪
• 在做项目设计和规划时,一定要考 虑到各种不确定的变化因素,灵活 适应多变的环境,否则很可能酿成 悲剧后果。
• 图为纽约湾的Tacoma桥 由于空气动力学上的错 误设计而坍塌的新闻照 片
人月神话——干将莫邪
• “工欲善其事,必先利其器 ”
《人月神话》的由来
• IBM的System/360是第一个特大型软件项目,它催生了《人月神话》
《人月神话》的由来
• System/360的开发过程被视为计算机发展史上最大的一次豪赌,为了 研发System/360这台大型机,IBM决定征召六万多名新员工,创建五 座新工厂,而当时出货的时间不断的顺延。
• 图为1802年A.Canova所作雕 塑:英雄海格力斯( Herculues)摔死带来死亡之 袍的信使力卡斯(Lycas)。
人月神话——没有银弹-软件工程中的根本和次要问
题
消灭 银弹 人狼
攻克
软件项目 “焦油坑”危机
• 图为1685年德国线刻板画 的人狼故事
• 是否存在消灭人狼的法宝——银弹? • 由于软件的复杂性、一致性、变化性和 不可见性,解决软件危机的银弹并不存 在 • 没有任何一种单独的软件工程可以让软 件开发的效率提高一个数量级。
• 技术并非《人月神话》的着眼点,它更关注的是软件的创造过程、需 求的变化无常和管理的永恒困境。 • 《人月神话》的中心思想已经超越了具体的时代和技术。
名家谈人月神话
• 这是一本经典著作,与软件开发有关的每一个人都应该不只一遍地读 这本书。 ——Philippe Kruchten Rational 统一过程首席架构师 • 它仍然是计算机书籍中呗引用次数最多的书籍,而且即便本书最初出 版于1975年,其内容至今仍未过时。在阅读的时候,每隔几页不说一 句“对极了!”是很难受的。 ——Stee McConnell,Construx公司首席软件工程师
《人月神话》目录
• • • • • • • • • • 第1章 焦油坑 第2章 人月神话 第3章 外科手术队伍 第4章 贵族专制、民主政 治和系统设计 第5章 画蛇添足 第6章 贯彻执行 第7章 为什么巴比伦塔会 失败 第8章 胸有成竹 第9章 削足适履 第10章 提纲挈领 • • • • • • 第11章 未雨绸缪 第12章 干将莫邪 第13章 整体部分 第14章 祸起萧墙 第15章 另外一面 第16章 没有银弹-软件 工程中的根本和次要问题 • 第17章 再论“没有银弹” • 第18章 《人月神话》的 观点:是与非 • 第19章 20年后的《人 月神话》
– 在信息化社会里,市场对信息的巨大需求将成为经济诱因,促使 银弹的出现。--Cox,1990
没有银弹! --Brooks
• 软件工程的内在特性
– 复杂度:不同于建筑、汽车等产品,软件实体可能比任何由人类 创造的其它实体都要复杂,因为没有任何两个软件部分是相同的 (至少是在语句的级别上)。
• 无规则性:不同于数学、物理等学科,软件工程所控制的 很多复杂度是随心所欲、毫无规则可言的,来自于若干必 须遵循的人为惯例和系统。
• 我唯一一本读过一遍以上的书,是Fred Brooks的《人月神话》,实 际上我每过一两年就会重读一遍。部分原因是这本书文笔很好,另外 就是书中的忠告很有价值,即使是25年以后。我非常推崇这本书,这 是我唯一能想起来的能从中体会到乐趣和思想的计算机学科书籍。 ——Brian Kernighan ,著名《C程序设计语言》的合著者之一。
• 图为佛罗伦萨著名的圣母百 花大教堂钟楼上的装饰浮雕 ——A.Pisano于1335年制作 的“雕刻者”。
• 适合的开发工具、评测技术 能有事半功倍的效果,切合 实用的工具和技术是项目团 队的重要财富。
人月神话——整体部分
• 作者认为某些泛泛号称自 己能完成庞大软件项目的 业界人士,与旧时以夸张 吹嘘来吸引观众注意的魔 术师一样,其表演的东西 经不起实质追究。 • 良好的软件项目管理,应 该准确把握全局,严谨审 核细节。
• 图为14世纪宗教湿壁画 Wells启示录中的七天 使号手
人月神话—— 为什么巴比伦塔会失败
• 在基督教传说中,人类打算 建筑一座通往天堂的巴别塔 ,上帝使人类各族语言不通 ,才阻止了这项工程。
• 图为维也纳 Kunsthistorisches博物馆 馆藏的16世纪奥地利兄弟画 家中大Breughel所绘“巴别 塔的建造”。
• 在软件开发中,也许现有的 技术已经可以所向披靡,但 如果整个团队不能进行良好 有效地沟通,项目就有可能 功败垂成。
人月神话——胸有成竹
• 有效的管理和决策是致胜的关键。
• 图为美国历史上最伟大的职 业棒球运动员贝比.鲁斯( Babe Ruth)在球场上发号施 令。
人月神话—— 削足适履
• 在有限的空间中装载整个 世界,这需要精巧的策划 ,绝不可轻易耗费资源。
人月神话
小组成员:
人月神话
人物简介:
• 美国工程院院士 • “IBM 360系统之父”,曾担 任360系统的项目经理,及该 项目设计阶段的经理。凭借在 此项目中的杰出贡献,在1985 年获得美国国家技术奖。 • 1999年荣获美国计算机领域最 具声望的图灵奖( A.M.TURINGAWARD)桂冠。
• 概念完整性是系统设计中最 重要的因素,尤其对大型软 件系统来说,概念完整性是 项目顺利完成的必要保障。
• 图为Reims大教堂内景,位 于巴黎的Reims是建筑史上 最富盛名的哥特式教堂建筑 之一。
人月神话——画蛇添足
• 设计者往往不肯放弃任何一个 细枝末节的创意,从而堆砌出 不胜繁复的设计,看似完美, 并现实无可行性,往往会成为 头重脚轻的空中楼阁。 • 软件项目的规划必须进行严谨 理性的估算才能为项目的顺利 进展打下牢固的根基,避免不 必要的复杂化风险。
– 可变性:由于软件是纯粹的思维产物,易于修改,用户经常会提 出改进要求。 – 不可见性:软件是无法可视化的,不仅限制了个人的设计过程, 也阻碍了设计人员之间的交流。
是否存在终极利器?--银弹之争
• 没有银弹(“No Silver Bullet”)
– 没有任何技术或管理上的进展,能够独立地许诺十年内使生产率 、可靠性或简洁性获得数量级上的进步。--brooks,1986 – 原因:由软件工程的内在特性所决定的:复杂度,一致性,可变 性和不可见性。
• 存在银弹("There Is a Silver Bullet")
弗雷德里克· 布鲁克斯 Frederick P. Brooks, Jr.
弗雷德里克·布鲁克斯的经典著作——《人月神话》
• 2000年新年伊始,国际计算机协会(ACM)在纽约宣布 1999年图灵奖得住为时年为69岁的Frederick P. Brooks, Jr.。评选委员会主席在致辞中提到,“今天我们所看到的 计算机体系结构、软件工程及三维计算机图形,均受益于 Brooks 的开创性工作,是他改变了这些领域的面貌。 ”Brooks确实是一位在计算机科学各方面均作出杰出贡 献的奠基者。
• 图为1882年画家A.rOBIDA发 表于比利时《二十一世纪报 》上的插画:一个想象中极 尽复杂的活动空中楼阁
人月神话——贯彻执行
• 号角声在七位天使间依次 传递,前一位吹响后,后 一位将照样吹响下一声, 有条不絮,号角传递得十 分精准。
• 团队间沟通顺畅有序,只 有这样,概念完整性才能 被正确贯彻到各处
• 当时的专案经理Frederick P. Brooks, Jr.事后根据这项计划的开发经 验,写作《人月神话:软件项目管理之道》(The Mythical ManMonth: Essays on Software Engineering)记述人类工程史上一项里 程碑式的大型复杂软件系统开发经验。
• 在《人月神话》中,Brooks博士为人们管理复杂的项目提供了最具洞 察力的见解,既有很多引人深思的观点,又有大量软件工程的实践。
• 图为早年新奥尔良的安东尼奥 法式餐厅的菜单