人月神话读书笔记(一)第一章焦油坑；表面上看起来好像没有任何一个单独的问题会导致困难；这，就是编程；1.在众多软件项目中，缺乏合理的时间进度是造成项；首先，我们对估算技术缺乏有效的研究；第三，由于对自己的估算缺乏信心，软件经理通常不会；第五，当意识到进度的偏移时，下意识（以及传统）的；3.成本的确随开发产品的人数和时间的不同，有着很；因为软件开发本质上是一项
人月神话读书笔记(一) 第一章 焦油坑 表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被 解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变 得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很 难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理 解它。
清楚地解释系统开发的困难所在。 这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共 存的创造性活动。对于许多人而言，其中的乐趣远大于苦恼。而本书 的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。
本书的目的 第二章 人月神话 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. 对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。必 须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干 部分，并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内 变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。 聪明的项目经理还会给自己预留一些空间，在工作推行时分配。
仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。
在指明模块有多大的同时，确切定义模块的功能。
培养开发人员从系统整体出发，面对用户的态度。
3. 在速度不变的情况下，更多的功能意味着需要更多的空间。其中一个技巧是用功 能交换尺寸。设计人员必须决定用户可选项目的精细程度。
4. 考虑空间--时间的折衷。对于给定的功能，空间越多，速度越快。 项目经理可以做两件事来帮助他的团队取得良好的空间--时间折衷。一是确保他们在 编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使 用新语言或者新机器时，培训显得尤其重要。另一种方法是认识到编程需要技术积累， 需要开发很多公共单元构件。
5. 战略上的突破常来自数据或表的重新表达--这是程序的核心所在。数据的表现形 式时编程的根本。
第十章 提纲挈领
1. 文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查 列表、状态控制，也可以作为汇报的数据基础。
2. 软件项目文档的内容：
目标。待完成的目标、迫切需要的资源、约束和优先级。 软件开发网
产品技术说明。
资金预算。
工作空间分配。
人员组织。 3. 为什么要有正式的文档
首先，书面记录决策是必要的。人们能从令人迷惑的现象中得到清晰、确 定的决策。
第二，文档能作为同其他人沟通的渠道。项目经理的基本职责是使每个人 都向着相同的方向前进，所以他的工作主要是沟通，而不是做出决定。文 档能极大地减轻他的负担。
最后，文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚 项目所处的状态，以及哪些需要重点进行更改和调整。
项目经理的任务是制订计划，并根据计划实现。只有书面计划是精确和可 以沟通的。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己 的方向。
第十一章 未雨绸缪
1. 对于大多数项目，第一个开发的系统并不合用。可能太慢、太大，而且难以 使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的 办法--即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成 ，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。 -- 构建一个试验性的系统，然后抛弃它。
2. 一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可 避免。
3. 为变化设计系统，包括细致的模块化、可扩展的函数、精确完整的模块间接 口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动技术。
最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。采用编译时的操作来整合标准说明，在很大程度上帮助了变化的调整。
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应 该有自己的日程表和冻结日期。在此之后的变更属于下一个版本的范畴。
4. 为变更计划组织架构和团队。
5. 程序维护中的一个基本问题是 -- 缺陷修复总会以(20%--50%)的机率引入新 的bug。整个过程是前进两步，后退一步。作为引入新bug的一个后果，程序每条 语句的维护需要的系统测试比其他编程要多，成本非常高。
缺陷不能被彻底修复的原因：
首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级 别的问题。其次，维护人员通常不是编写代码的开发人员。
5. 使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大 的回报。设计实现的人员越少、接口越少，产生的错误也就越少。
6. 维护工作破坏系统的架构，增加了系统的混乱程度。随着时间的推移，系统 变得越来越无序，无法再成为下一步进展的基础。这时，系统的重新设计完全是 必要的。
系统软件开发是减少混乱度的过程，软件维护是提高混乱度的过程，即使是最熟 练的软件维护工作，也只是放缓了系统退化的进程。 三亿文库包含各类专业文献、各类资格考试、中学教育、幼儿教育、小学教育、外语学习资料、人月神话笔记03等内容。　
　专题推荐 读书笔记的格式和范文 《幸福和成功》读书笔记 《成功是一种心态》读书... 代码大全2读书笔记1/2 相关文档推荐 《人月神话》读书心得 2页 免费 人月... 　人月神话阅读笔记之一_工学_高等教育_教育专区。人月神话阅读笔记 01 发表日期时间:
19:07 这段时间我开始阅读本学期我选择的第二本书《人月神话... 　人月神话读书笔记(一) 第一章 焦油坑 表面上看起来好像没有任何一个单独的问题会导致困难,每个都能被 解决,但是当它们相互纠缠和积累在一起的时候,团队的行动就... 　09人月神话阅读笔记之二_文学_高等教育_教育专区。人月神话阅读笔记 02 发表日期时间: 16:35 这两周我继续看了人月神话这本书,虽然没有开发大型... 　10人月神话阅读笔记之三_计算机软件及应用_IT/计算机_专业资料。人月神话阅读笔记 03 发表日期时间:
21:17 这两周我把《人月神话》剩下的章节看... 　《人月神话》读书笔记 1页 1下载券 希腊神话读书笔记【自我... 暂无评价 1页...时代神话》 E 时代神话》读书笔记 麦克尔?格伯简介: 麦克尔?格伯简介: 先锋派... 　学习策划笔记_营销/活动策划_计划/解决方案_实用文档。学习策划笔记 策划三层境界...? 项目管理 《人月神话》 《人件》 《黑客与画家》 《项目管理之美》 《... 　【笔记】我的项目管理学习笔记_企业管理_经管营销_专业资料。企业项目管理的概念...人月神话的团队管理理念(转载) 团队建设是项目管理中人力资源管理的一个重要内容...用户名：yaocoder
文章数：144
评论数：604
访问量：558619
注册日期：
阅读量：1297
阅读量：3317
阅读量：458925
阅读量：1143471
51CTO推荐博文
首先我要说明的是题目有着双关的含义。一层含义针对我而言，而这个“人月神话”是指Brooks老爷子的书籍，我很认可这本书中的大多数观点。一层含义针对一些企业管理者而言，我从我的角度对某些企业的管理层提出质疑，为什么他们确实相信人月这个神话。首先讲讲《人月神话》这本书之前这本书的大名早就如雷贯耳，但是一想到是一本几十年前的老龄书籍，心里想着伴随着软件业日新月异的发展，这本书的观点一定也是老掉牙的，也就多次放弃了对这本书的阅读。直到前一阵为了收藏买了一本32周年中文纪念版，翻起阅读却惊奇地发现书中探讨的问题和大多数观点依然是当前软件业存在的，而一些解决方案也符合当今软件业的潮流。下面我摘录书中的几个观点与大家分享下。焦油坑乐观永远是软件行业的天敌。请记住：你做的不是一个软件，也不是一个系统，而是一个稳定易用的产品。往往你会乐观估计到软件完成或是系统集成成功这一步，那这样后面的日子对你来说就是噩梦。人月神话人月在大多数情况下始终是个神话。一个人十个月能完成的任务十个人一个月就能完成吗？一个很形象的例子，一个人怀胎十月你可以找十个人来怀胎一月吗？概念完整性是产品质量的核心虽然我们鼓励团队所有人对产品的架构设计、产品设计提出建议，但是一定要让其保持概念的完整。所以我们不能没有架构师和产品经理的决策。瀑布模型是错误的乌托邦很美好，但是太理想化，所以不可能实现。瀑布模型假定一切都按照既定步骤顺利的走下去，可能吗？增量开发模型更佳当今这是一种潮流，敏捷开发就是其中一种。今天，你敏捷了吗？人就是一切（或者说，几乎是一切）“21世界什么最重要？人才”，但是有了人才，你还要做到怎样管理人，激励人，与之良好合作。没有银弹某种编程语言、面向对象思想、某些开发流程...都曾经被当做IT业的银弹，最终呢？.....再讲讲企业相信的神话&这个产品半年一定能完成，因为我们有昂扬的斗志，我们有不分白天黑夜的加班，我们还有大把的钱招新的人加入项目组为大家分担工作。&半年后，产品未按期交付，&都怪你们这帮工程师，埋怨，降薪......&,谁鸟你，遇到你这种管理者，最好的办法就是拍屁股走人。这样的管理者，推荐你去相信那本《人月神话》，而不是这种人月的神话。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)
15:32:22 01:13:25 08:46:50 09:17:28人月神话,最全面的人月神话文章 - 电子工程世界网
在电子工程世界为您找到如下关于“人月神话”的新闻
人月神话资料下载
《人月神话》内容源于作者Brooks在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理时的实践经验。《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。在《人月神话（英文版）》中，既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见。《人月神话》提出了2条著名的法则： 1、人月神话：向一个已经延后...
经典测试管理－《人月神话》,人月神话……...
人月神话THE MYTHICAL MAN-MONTH 人月神话FREDERICK P. BROOKS, JR.翻译：Adams Wang关于作者Frederick P. Brooks，Jr.是北卡罗来纳大学 Kenan-Flagler 商学院的计算机科学教 授，北卡来罗来纳大学位于美国北卡来罗来纳州的查布尔希尔。Brooks 被认为是“IBM 360 系统...
内容摘要 《人件》第1版于 1987 年出版，专门讨论了软件开发和维护团队的管理问题，并向人们的传统认识提出了挑战。作者在书中推崇人本管理思想，正确指出知识型企业的核心是人，而不是技术，呼吁给予软件工作者充分的自由和信任。本书推出后，立即在西方引起了轰动，被誉为“几十年来对美国软件业影响最大的理念”。与《人月神话》一样，《人件》现已成为软件团队管理的经典之作。它和《人月神话》共同被誉为...
《人月神话》中文版...
人月神话软件工程师必备, 可以提高软件的开发能力是很好的一本书...
人月神话是一本经典的关于软件工程方面的书籍，他详细的介绍了关于软件开发的各个方面。...
在软件开发领域一个非常流行的人月神话问题：在众多的软件开发项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大，导致这种普遍性灾难的原因是什么呢？相信人月神话会给你一个满意的回答，并提出了优秀的解决方案。...
人月神话 经典的著作 此为20周年纪念版...
软件工程经典------人月神话,……...
人月神话相关帖子
《人月神话》读书笔记
.cn/detail/HOHO/9637
《人月神话》这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。现在终于找到读他的理由了，可以感受一下大师的杰作。在读之前我已经读过了《软件工艺》和《极限编程》，为什么留到最后读人月神话...
& && &&&正如编程的趋势和各种语言，编程书也在不断更新换代。不过以下的7本经典书籍经受了时间的考验。有些书比其他的书面世的晚，但是这些书为新人还是有经验的程序员都提供了深入的见解.
1.《人月神话：软件工程论文集》（周年第二版） 作者：**Frederick Brooks, Jr.http...
一个4通道DMX接收调光控制程序,用C语言编写的
JavaScript从入门到精通
Keeloq编解码例程
Java基础教程
人月神话 - 经典书籍
嵌入式处理器
LiquidCrystal_I2C函数库
采用C2000 TMS320F28027的LaunchPad启动开发工作
《ARM Cortex-M3嵌入式开发实例详解：基于NXP LPC1768》随书源程序...
Keeloq编解码例程
人月神话 - 经典书籍
shell编程从入门到精通
经典算法大全
Visual.C.6.0.用户界面制作技术与应用实例
嵌入式处理器
半天学会ARM_Cortex-M3_课件
sop8封装库
dsPIC数字信号控制器入门与实战--入门篇
PSoC 4 CY8CKIT-042 Pioneer Kit
ATMEL官方开源的M7 六层PCB...
经典算法大全
shell编程从入门到精通
人月神话 - 经典书籍
elisp参考手册
VC6精简版MSDN
嵌入式处理器
STM32 Nucleo板软件开发工具入门
SMT8+RC523(源代码可以读身份证号)
ARM DS-5 Crack
深入浅出Cortex-M3—LPC17xx上册
红外线遥控Proteus仿真电路 发射接收程序
嵌入式系统
《嵌入式...
本帖最后由 tiankai001 于
17:20 编辑
软件工程领域影响最大的两本书之一《人月神话》
作为软件工程的经典著作，《人月神话》的主要贡献是对软件开发过程的几个重要关键点，提出了独到的见解。
　　 这几个关键内容就是：
　　（1）提倡外科手术式的团队组织：
　　 [在软件开发组织上的过份民主，往往带来的是没有效率和责任...
本帖最后由 tiankai001 于
17:20 编辑
在这本书的扉页上，写着这样的一句话：在成千上万的书架上，《人件》永远和《人月神话》并列在一起。
　　 作为一本主要讨论软件组织中人文环境因素的著作来说，这本书面向的主要对象应该是软件组织的管理者。
　　 但这真是一本令人震惊的书，看来无论国内国外，软件业的真实现状，都不容乐观...
——《人月神话》及其地位
& &第二节 错误的命题——对《人月神话》的反思
& &第三节 具体工程以及工程的具体化
& &第四节 控制规模
& &第五节 隔离问题域
& &第六节 这样是不是太简单了
& &第七节 郑人的履
&&第十一章 是思考还是思想...
“我刚刚找出了最后一个错误。”
& &&&人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国20年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法...
/MDD& && && &122第五节 审视AP 和XP& && && & 125第十章具体工程& && && &&&131第一节预言——《人月神话》及其地位& &&nbsp...
人月神话视频
你可能感兴趣的标签
热门资源推荐}