#包笔记

软件需求分析教程阅读笔记二

软件需求分析教程阅读笔记二管理人员在要求开发一个系统时并不会理解进行需求分析的重要性,他们只知道能不能尽快开发出相应的系统来方便使用,但是如果不做好需求分析,最终开发出的系统也不会有人用。客户的需求认识并不像软件开发人员这样,了解的比较清楚,客户通常并不懂得从系统的实际用户处得到信息的重要性,然而从产品的实际用户处收集...

软件需求分析教程阅读笔记一

软件需求分析教程阅读笔记一许多工程项目不能按时完成或者最后导致失败的一个很大的原因就是弄不清需求是什么,不能准确理解客户的需求意图,所以前期做好需求调研是一件非常重要的工作,是一件与系统代码开发占有同等比重的工作。读这本书的同时,要注意实践过程,不必非得要从一个新项目开始应用,可以找一个以前的或者是现在正在进行的项目,...

阅读笔记之我们应当怎样做需求分析

我们应当怎样做需求分析?成功的软件项目都是一样的,失败的项目却各有各的问题。不过归根到底还是需求的问题。正是我们在需求分析过程存在的巨大隐患,最终导致了那么多项目的失败。只有深入地去理解客户的业务,最后做出来的东西必然是客户满意的。当客户提出业务变更的时候,一定不能被客户牵着走。要从业务角度深入的去分析,他为什么提出变...

人月神话阅读笔记—第四章

人月神话阅读笔记—第四章------2016.6.14概念的完整性是很重要的,为了反应一系列连贯的设计思路,可以省略一些不规则的特性和改进,不提倡独立和无法整合的系统,最需要的是在整体概念上的完整性要求。获得概念的完整性时,会出现一种情况,编程系统使计算机更加好用,但是功能比较多的时候,软件外部描述就会比系统本身大很多...

人月神话阅读笔记—第三章

人月神话阅读笔记—第三章一个由一流人才组成的小型的精干的队伍比由一群平庸的程序员组成的大型团队更有效率,但是这里面有一个重要的问题:如何在有意义的进度安排内创建大型的系统。优秀的程序员和较差的程序员之间生产效率的差距是巨大的,当一个10人的精干团队进行开发,和一个100个人的平庸程序员进行开发,前者的效率更高。但是对于...

人月神话阅读笔记—序言及第一、二章

人月神话阅读笔记—序言及第一、二章初读人月神话这本书的前言和序言,觉得这本书在关于软件体系结构思想层次方面应该是很高的,而且它流传甚广,并且经过了40余年的沉淀,仍然经久不衰,可见此书的影响是相当深远的。从目录来看,此书说的不是如何进行程序代码的编写,更多的是关于软件工程中的管理问题,从很多的具体事例,和软件工程历史上...

构建之法阅读笔记09-第十二章

阅读笔记第十二章:用户体验在进行软件界面设计时,要考虑用户使用的第一印象,不要弄的多么纷杂,一定要一目了然,看起来简单明了。在软件的功能特别多的时候,要考虑用户的使用情况,可以大胆的减去一些不必要的功能,当然是针对某一部分用户来说。设计的过程中,一定要从用户的角度考虑问题。有一些功能,针对不同的用户,需求时不同的。而且...

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

阅读笔记第十一章:软件设计与实现在第十一章的软件设计与实现方面,介绍了一些关于典型的开发流程和开发阶段的一些管理方法。在拿到设计文档之后,还需要做一些其他事情,比如估计任务所需要的时间,写一些原型代码,看看效果;做代码的自我复审,进行重构;写单元测试等等。最后还要把修改集集成到代码库中。开发人员有一个标准的工作流程:进...

构建之法阅读笔记07-第八章

阅读笔记第十章:典型用户和场景对于同一个工具,不同的用户使用的场景是不一样的。在定义典型用户的时候,需要分析不同用户之间的需求相同点和不同点。按照年龄,收入,使用软件的场景,和用户本人的生活情况进行分类。当然并不是给用户分类之后,就算完成了,还需要将用户置于这种用户的典型场景中,而不是泛泛的说用户如何使用这个工具。将场...

构建之法阅读笔记06-第八章用户需求

阅读笔记第八章:需求分析第八章的需求分析介绍了软件需求的类型、利益相关者,获取用户需求的常用方法和步骤,竞争性需求分析的框架NABCD以及项目计划和估计的技术。在软件需求方面,可以从利益相关者那里,引导他们表达需求,从而获取。从用户那里获取了需求之后,需要分析和定义需求,也就是对需求进行规整,来定义一下需求的内容。下一...

构建之法阅读笔记05-第六章

阅读笔记第六章:敏捷流程第六章敏捷流程主要介绍了什么是敏捷流程及其原则,还有什么时候可以选择敏捷的开发方法,什么时候选择其他方法。敏捷的流程是指一系列价值观和方法论的集合。介绍了一些敏捷开发原则,比如,经常发布可用的软件,业务人员和开发人员在项目开发过程中应该每天共同工作,面对面的交流始终是最有效的沟通方式,不断关注技...

构建之法阅读笔记04-第五章

阅读笔记第五章:团队和流程团队有一些共同的特点:有一致的集体目标,成员之间有各自的分工,合作完成任务。团队一开始可能是"一窝蜂模式",都想写出好的软件,但是没有各自的分工,一般不会这种模式不会存活太久。慢慢会演化成其他模式,比如"主治医师模式",本来是不错的模式,但是在学生身上退化为了一个学生干活,其余打酱油的情况。还...

构建之法阅读笔记03——4.5和4.6

阅读笔记4.5相对于一个人自己写程序,有时候可能不如结对编程,即极限编程。它可以把一些很有成效的编程方法使用起来,并且一直使用。结对编程时,要起到对应的角色作用,可能一开始觉得不适应,但是方法得当以后会发现,结对编程比一个人效率要高,并且后期错误会比较少。当然也有一些不适合结对编程的情况,那么就需要量力而行。4.6在一...
代码星球 ·2021-02-20

构建之法阅读笔记02_3.3——4.4

阅读笔记3.3如果说自己精通某个方面,就不要出现低级错误,或者出现低层次问题。一个人的技能的高低要看技能的反面,即解决问题的能力。要先通过不断的练习来解决低层次问题,使之不再出现,才有时间来解决高层次问题。再解决问题的时候,首先要知其然,知其所以然,接着就是进行创新。4.1&4.3代码规范问题:一个人的代码不光...
代码星球 ·2021-02-20

构建之法阅读笔记01。第二章

阅读笔记2。1程序要进行单元测试来保证程序的健壮性。还要进行回归测试,就是在原版本上运行的测试用例通过的话,在下一版本上再运行时,却没有通过,这就是软件"退化",所以需要进行回归测试。在新版本上运行所有已经通过的测试用例,来验证后面的版本没有出现软件"退化"的情况。但是如果是模块功能发生了变化,那么测试用例也需要修改来...
首页上一页...56789...下一页尾页