《人月神话》阅读笔记04

第四章  贵族专制、民主政治和系统设计

这一章主要讲述了概念一致性、获得概念的完整性、贵族专治统治和民主政治、在等待时实现人员应该做什么。

绝大多数欧洲的大教堂中,由不同时代、不同建筑师所建造的各个部分之间,在设计或结构风格上都存在着许多差异。后来的建筑师总是试图在原有建筑师的基础上有所“提高”,以反映他们在设计风格和个人品味上的改变。对于计算机系统而言,尽管它们通常没有花费几个世纪的时间来构建,但绝大多数系统体现出的概念差异和不一致性远远超过欧洲的大教堂。这通常并不是因为它由不同的设计师们开发,而是由于设计被分成了由若干人完成的若干任务。

编程系统(软件)的目的是使计算机更加容易使用。为了做到这一点,计算机装备了语言和各种工具,这些工具实际上也是被调用的程序,受到编程语言的控制。使用这些工具是有代价的:软件外部描述的规模大小是计算机系统本身说明的十倍。用户会发现寻找一个特定功能是很容易的,但相应却有太多的选择,要记住太多的选项和格式。只有当这些功能说明节约下来的时间,比用在学习、记忆和搜索手册上的时间要少时,易用性才会得到提高。现代编程系统节省的时间的确超过了花费的时间,但是近年来,随着越来越多的功能添加,收益和成本的比率正逐渐地减少。

概念的完整性要求设计必须由一个人,或者非常少数互有默契的人员来实现。而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节中所讨论的、一种崭新的组建编程开发团队的方法。

概念的完整性的确要求系统只反映唯一的设计理念,用户所见的技术说明来自少数人的思想。实际工作被划分成体系结构、设计实现和物理实现,但这并不意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反,整个系统将会开发得更快,所需要的测试时间将更少。同工作的水平分割相比,垂直划分从根本上大大减少了劳动量,结果是使交流彻底地简化,概念完整性得到大幅提高。

时间: 2024-10-05 21:32:41

《人月神话》阅读笔记04的相关文章

《掌握需求过程》阅读笔记04

<掌握需求过程>阅读笔记04 我们在开发我们的系统的时候要是要给用户用使用的,所以用户的使用感受非常重要,这就需要我们站在用户的角度去考虑这个系统如何让用户的使用更加的简捷,而不是站在你开发者的角度去考虑这个系统如何开发比较省我自己的事儿.抱着多一事不如少一事的态度开发出的系统是我们懒惰情况下的残次品,是注定要被淘汰的,而我们也可能因为这样的态度,面临我们的工作也将被人这样轻视.要把握好用户的使用习惯.操作环境,就需要我们去体会用户的使用感受,就需要我们具有同理心. 编写用户故事.我们可以把我

《用户故事与敏捷开发》阅读笔记04

  <用户故事与敏捷开发>阅读笔记04 今天抽出了两个小时读了<用户故事与敏捷开发>的第十二.十三.十四以及十五章并写了这篇阅读笔记.第十二章标题为"故事不是什么".IEEE 830是一本关于如何编写软件需求规格的指南,最突出的特征是使用短语"系统应该.....",但作者认为以这种方式编写系统的所有需求实际是一个不可能的任务.因为用户看到正在开发的软件时总会有有效和重要的反馈循环.他们会改变之前的想法,而且每个需求的成本是不可见的,会造成分析

UML大战需求分析——阅读笔记04

读<UML大战需求分析>有感04 开发某系统的重要前提是: 这个系统有谁在用? 这些人通过这个系统能做什么事? 一般搞清楚这件事,再画个业务流程图,就能条例清楚的表达系统的需求了.作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙. 用例图是用处非常广泛,使用频率最高的UML图,它用来描述什么角色通过某某系统能做什么事情,关注的是系统的外在表现.系统与人之间的交互.

《构建之法》阅读笔记04

今天,我阅读了构建之法10-12章.总结出了自己以前一些不对的思想和做法. 以前认为对软件需求最大的人肯定就是我们的典型用户了呀.于是就可以为这些人打造一款软件就等于软件成功了.可是大多数时候我们软件已做完发现这些人根本不用我们的软件.为什么呢?因为不会用.所以我们定义典型用户的时候首要条件就是会用这款软件,然后和需求有关系的用户. 以前认为工程师做软件就是先把要做的任务分分类,然后大家把自己的任务文成,最后链接起来就可以了,可是这样做出来的软件真的解决了需求了吗?软件设计是首先要把需求先搞清楚

软件需求模式阅读笔记04

今天开始阅读<软件需求模式>的第7.8章,其中第7章主要讲的是数据实体需求模式,主要是数据处理的一些需求模式,而第8章讲的是用户功能需求模式,主要是介绍了如何应对用户的一些需求. 第7章数据实体需求模式,系统的开发者常常是以轻视,随意的态度对待信息,没有规则定义什么时候数据可以被删除,对丢失数据很松懈--而本章就是通过引入一种方案把所有的实体分为几个固定种类,增加秩序性和一致性. 活实体需求模式,它用来定义一种实体,它的信息需要保存,并且具有预期寿命.但是不能将它应用于系统配置的实体:而应该使

大道至简阅读笔记04

本周我阅读了<大道至简>的第4张——流于形式的沟通,读后反思与感慨也是颇多的,下面与大家分享一下. 为不存在的角色留下沟通的渠道,这一节对自己来说体会是最多的.之前我们或其他自己所知道的团队中都存在这样一个问题:维护旧项目比做新项目更难:或是很多时候当项目负责人员离开后,项目就中断和中止. 许多人应该深有同感.     本书中对此情况进行了说明,把这一切的原因归咎于“没有history”.历史记录(History)与注释(Comment)不是一回事.代码中的注释是为阅读代码而留备的,而Hist

构建之法阅读笔记04

2017.4.1 今天我看的是绩效管理的内容,这是一个软件在阶段性总结时所不能逃避的话题,每个团队都应该有自己的团队绩效,应该用团队绩效来评估该团队的成员在这一阶段对这个软件做出的贡献.这好像的确是一个问题.我们应该从不同的方面来评估一个人在这一阶段对软件做出的贡献.单单从一个方面去评估一个人的价值是不合理的. 每个人在每个方面的贡献都是不可低估的.另外这章中还提到了团队合作的几个阶段,开始大家聚集在一起,是团队的萌芽阶段,每个人都很生疏,不知道做事的流程,不知道在团队中该怎么做.接着团队进入磨

《UML大战需求分析》阅读笔记04

在学习了前面的几种UML图并不能满足所有情况的建模,如当流程图涉及到多种角色,并且通过对多种角色交互展开时,顺序图才是不二选择.顺序图就如同中文语法的说话语言相似,描述的是一种事件发生的顺序.顺序图分为循环及分支语法结构两种语法.它强调的先后顺序. 作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙.业务用例在整个软件开发过程可以获取需求,在整个项目开发过程中起到指导

构建执法阅读笔记04

第九章 项目经理 项目经理的作用 协调团队成员的工作内容,把握产品定位和方向,解决用户痛点,调节团队中的矛盾,总控团队的进度,使一个团队加强交流.在一个团队中,项目经理是必不可少的一个重要角色.一个合格的项目经理需要良好的沟通能力,通过和团队成员的沟通交流,使一个团队能够有效地运转.同时,项目经理还需要及时的了解用户需求,精确地把握软件的定位与方向.而且还需要有长远的眼光和独特的见解,是产品的功能更加完善 第十章 典型用户和场景 在做一个产品之前,我们应该明确产品所需要服务的用户,为不同的用户建

编写有效用例_阅读笔记04

第十一章作为本书的第一部分的最后一个章节,提供了几种可供选择的用例格式.第一种是完整正式的用例格式,首先是单列文字,其次没有条件语句,最后便是扩展的部分的编号规则是数字和字母的组合.我个人在看了本书之后,比较喜欢这种格式,其原因一是从前看到后看习惯了,另一个原因就是扩展部分的编号规则更能让我接受. 在看了几个格式后,不禁好奇,怎么会有这么多种的模板来参照,如此不严谨的确不像是我们这类工程类的文档的要求,往后看才知道,原来影响用例书写格式的因素很多,从社会文化到理解层次到项目人员的相关要求到经验到