人月神话读后感.doc

人月神话读后感“人月神话”这个书名乍听起来真像是一部科幻小说或是言情小说的名字，真是很吸引别致，后来经老师提醒才知道这竟是一部在软件行业中享有里程碑地位的名著，一部在软件领域拥有极高声誉，畅销了20多年的必读经典。在这本书中，以我的总结，作者主要详述了包括工程计划，团队组成，文档重要性，项目排错等等的软件工程世纪的方方面面。 而“人月神话”顾名思义让人联想到神话故事，而事实确实作者阐述软件开发项目上项目进度和开发人员这两个概念的不能互换与混淆。 对此书，老实说，可能能力十分有限，对其理解也不是很深刻，在此提出对我影响最深的几点概念： 焦油坑的提出使我想到一个事实，虽然此书出版已20多年，但它所能反映的在软件项目上的问题依然能给软件工作者带来困扰，就如同在焦油坑中挣扎，问题依然没有解决。 人月神话概念的提出，引出Brooks法则：向进度落后的项目增加人手，只会导致进度更加落后。这就是除却了神话色彩的人月。因此缺乏了合理的时间进度是造成项目滞后的最主要原因。 在第三章中，作者有用了一个很好的实例：外科手术队伍。他提出了疑问，如何在有意义的时间进度内创建大型系统呢？要使工作易于管理，他给整个软件团队使用分解的技术，明确了各个工作细则，明确体系架构和实现之间的界限，如系统结构师必须专注于体系结构，其他依然。 为什么软件设计会和贵族专制，民主政治有关呢？因为概念设计必须由一个人或有默契的少数人一起才能进行，概念完整性必须要求系统只反映唯一的设计理念，而用户所见的技术说明来自少数人的思想。 如何避免画蛇添足呢？这告诉我们必须坚持设计拥有两个系统以上开发经验结构师的决定，同时保持对特殊诱惑的警觉，才可以不断提出正确的问题，确保原则上的概念和目标在详细设计中完整体现。 软件设计很重视贯彻执行这一概念，以用户手册为中心，即需求分析，设计人员与实施人缘进行交流，会议，电话记录，电子邮件来沟通，避免理解错误，最终的测试以用户手册为准则进行测试。此时还要注意，不同系统的用户手册是不同的的可能是界面说明，程序也可能是借口说明。巴比伦塔是人类继若亚方舟之后的第二大工程壮举，但同时也是一个彻底失败的工程。作为一个纯粹的工程来看，它似乎具有很好的先决条件：清晰的目标，但很不现实，因此这点看来，此项目已注定败局；充足的人力；材料丰富；足够的时间，而技术方面，在很明显那个石器时代确是有很大的限制。缺少了什么呢？呵呵，是两个方面：交流以及交流的结果，组织。一部分是文档的项目工作手册，另一部分则是人缘的树形结构组织了。这几点是至关重要的。所谓实践是最好的老师，但如果不能从中学习，再多的实践也没用。估算有三个要素：实践，量化指标，根据量化的指标建立模型。因此软件设计过程是一个不断实践和学习的循环，过程犹如实践，然后量化指标，再估算模型，继而实现，量化指标，重新建立模型。削足适履：程序占用资源的控制。成本的chin供需控制，规模控制，空间预算的多少和控制，数据的表现形式，都指出如何把这些东西撞到一个小小的空间中来削足适履以获得好的结果。于整个过程中，少数文档形成了关键的枢纽，没见项目管理的工作都围绕它们，它们是经理们的主要个人工具。有什么用呢？第一，书面决策记录使其明朗分析，突出矛盾。第二，以文档最为沟通渠道。第三，数据基础和检查列表，通过周期性回顾，可以清晰项目状态，进行调整。如何应对软件过程中的千变万化呢。就需要未雨绸缪了，不变时愿望，变化才是永恒，唯有接受与生俱来的变化，为变更设计系统，组织架构。还有一个很重要的关键，那便是好的工具：巧匠因为他的工具而出名。而可用的工具可分为目标机器和辅助机器，高级语言和交互式编程。而辅助机器我觉得比较重要的有编程工具和文档系统。回归整体，如何开发一个可以运行的系统，如何测试系统，如何经过测试一系列构建集成到已测试过，可依赖的系统？一读这一章，就让我感触颇深，特别是这句话BELL实验室监控系统项目的V.A.Vyssotsky提出，关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作产品定义。现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。什么会导致进度灾难性偏离呢？这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。项目对于公司就如程序对测试工程师一样，如果不了解它，