《构建之法》阅读笔记第十&十一章

《构建之法》第十&十一章主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为“典型用户和场景”以及“软件设计与实现”。其中第十章大部分内容和教授上课所讲的一样比如说,用户的分类(典型用户可以包括以下内容:

1. 名字(越自然越好)

2. 年龄(不同年龄和收入的用户有不同的需求)

3. 收入

4. 代表的用户在市场上的比例和重要性(比例大不等同于
重要性高,如付费的用户比例较少,但是影响大,所以更重

5. 使用这个软件的典型场景

6. 使用本软件/服务的环境(在办公室/家里/沙发/床上/公
共汽车/地铁……)

7. 生活/工作情况

8. 知识层次和能力(教育程度,对电脑、互联网的熟悉程
度)

9. 用户的动机、目的和困难(困难 = 需要解决的问题)

10. 用户的偏好)

这十点已经将用户的种类划分得很详细了,我们也可以有针对性的去编写软件以满足对不同用户的需求问题。

然后就是用户场景分析,在没有听课或者看这本书之前呢这些我是完全想不到的,那时候脑子里只有一个简单的想法——把功能实现了不就得了,哪有那摸多的麻烦事啊!真的是和书上说的一样的那种人,但是看完书后发现是真不行,因为我们的软件是要卖给别人的,不是单单的实现某些所谓的功能的。所以用户场景分析就十分有必要了,这样一来一是可以检测到用户在使用过程中会遇到哪些问题以便我们解决,以及在任何环境下或者用户(外行人)的任何操作都必须让软件看起来是正常的,也就是传说中的换位思考,把自己当场一个不太了解电脑的用户来做软件。

接下来的事情就是写文档了,“什么?!程序员还需要写文档?你不是在逗我吧!没错,不仅仅要写而且还要写的十分的详细,就像,就像电视剧本那样详细,但是用不着写得那样生动”反而呢要做的越简单越容易理解越好,但是不能太枯燥乏味了,这样没人愿意读得好吗!看到这里呢,我又一次感到了巨大的压力感和荣耀感,妈呀原来程序员还是数理文学通吃啊,全能人才啊!!

第十一章主要讲到而“软件设计与实现”,大体分为两个部分第一”设计的方法“,第二"如何实现"

关于设计方法,我会学过一种“图形建模”也就是画用例图等等,还有“表达数据流动”等方法,还是需要我们用时间和精力去学习的。至于如何实现

时间: 2024-10-18 09:22:55

《构建之法》阅读笔记第十&十一章的相关文章

构建之法阅读笔记三—结对编程

构建之法阅读笔记三——结对编程 何谓结对编程,结对编程就是程序员肩并肩,平等的,互补的进行开发工作,他们使用同一台电脑,编写同样的程序,一起分析,一起设计,一块交流想法. 然而我以前却并不是这样做的,我以前喜欢在没人打扰的环境下写代码,我觉得有人在我身边看着,会影响我的思路,还有我个人自尊心比较强,不太喜欢被人指指点点,所以每次都是,我写完代码之后,自己先找自己的bug,每当自己实在找不到之后,才会请教大神,但是有时候可能由于自己的能力不足,往往一个很简单的问题,我自己发现就会花费很久的时间,让

构建之法阅读笔记四—团队开发

构建之法阅读笔记—团队开发 软件开发过程中有团队和非团队之分.其区别就在于目标利益的不同,团队中每个人的目标是一致的.共同的,会根据实际情况给每个人分配不同的任务,不会计较个人利益的得失.非团队每个人的目标都是不同的,大家都为自己的利益而奋斗. 在阅读了构建之法后,我了解到团队开发有以下的特点:1.团队开发有一致的集体目标,团队要完成这个目标.一个团队成员不一定要同时工作.2.团队成员有各自的分工,互相依赖合作,共同完成任务.还有完成一个项目开发的工作流有业务建模,需求,分析和设计,实现,测试,

构建之法阅读笔记6--敏捷开发2

构建之法阅读笔记—敏捷开发2 敏捷开发并不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发:而这种开发方式的主要驱动核心是人:它采用的是迭代式开发:敏捷开发并不是瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据:而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心.而所谓的迭代开

03构建之法阅读笔记之一

构建之法阅读笔记03 遇到问题总是想弄清楚所有细节.所有依赖关系之后再动手,想的太多,没法前进,分析的就会出现错乱,或者直接动手,慢慢发现偏离的一开始的轨道,忘记了目标,这样就会产生"分析麻痹"和"不分主次,想解决所有问题",以后遇到问题应该时刻记住自己的目标,在解决问题的时候不断提醒自己,应该如何思考.越早对自己有一个清晰的定位,对自己越好,很多人只是把软件工程师当成一个工作,当成一个能挣钱养家的营生,而我想把它的当成自己投身的事业,把软件项目相关的目标作为长期的

构建之法阅读笔记09

这段时间我主要阅读的是<构建之法>的质量保障一章: 1. 有些成功人士或公司认为不需要独立的测试角色(Test),你怎么看?就像很多事情一样,不能把所有的事情说得太绝对了,举个例子来说,大多数的软件开发都是以小组的形式来进行的,每个人分配了一个模块,如果说每个人对自己的模块都进行一下测试,当然这样的情况下可以不需要独立的测试角色,编程的过程就是不断对自己的程序排错.测试来完成的,但是最后所有的模块整合成一个大的系统,这样如果程序员只对自己的模块进行测试,是肯定不能满足需求的,这时候就需要一个独

构建之法阅读笔记08-第十一章

阅读笔记 第十一章:软件设计与实现 在第十一章的软件设计与实现方面,介绍了一些关于典型的开发流程和开发阶段的一些管理方法. 在拿到设计文档之后,还需要做一些其他事情,比如估计任务所需要的时间,写一些原型代码,看看效果:做代码的自我复审,进行重构:写单元测试等等.最后还要把修改集集成到代码库中. 开发人员有一个标准的工作流程:进行功能需求分析,复审设计文档,详细设计,实现设计来编写代码,同伴复审,源代码的合并.构建等等,其中的每一步都有可能出现bug,要随时发现并且修改bug,最后是测试完成,发布

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

构建之法阅读笔记05

2017.5.20 今天阅读的是<构建之法>第8章需求分析的阅读笔记,我们如果要开始做一个软件,最先要进行的就是需求分析,我们应该充分的了解我们这个软件是否具有前景,我们为用户提供的服务是不是用户所需要的,这一章详细的叙述了如何进行需求分析. 首先是获取和引导需求,我们应该找到软件的利益相关者,了解挖掘他们对软件的需求,引导他们表达出真实的需求.然后分析和定义需求,对各个方面的需求进行规整,定义需求内涵,从各个角度将需求量化,然后估计实现这些需求所需要的时间和资源,确定各个需求的优先级.紧接着

构建之法--阅读笔记二

阅读笔记二—代码规范 代码的风格的原则就是:简明,易读,无二义性.我虽然是计算机系的学生,但是我以前却没有秉着这个原则来编写代码,现在阅读了构建之法后,我明白了如何让你的代码变得简明,更容易理解. 代码在编写的过程中注意: 用Tab键缩进 要注意行宽,最多限定100字符的行宽 在复杂的条件表达式中,用括号清楚地表达逻辑优先级 要注意断行与空白的{ }行,有明确的“{”和“}”来判断程序的结构 不要把过多的语句放在同一行上 对变量命名要有实际的意义 用下划线来分隔变量名字中的作用域标注和变量的语义