构建之法8,9,10章

8.创新分析
创新可以使改良型的,在现有的软件中增加几个新的功能,把某个程序变得更快一点,把程序移植到新的平台。颠覆性的创新,一个新的产品导致就得产品或产业发生巨大的变化或消失。但是如何按部就班地分析需求,有条理地说服别人你的创新呢?有NABCD模型。
Need,你的创意解决了用户的什么需求。
Approach,找到了需求,就需要使用独特的作法来领先于其他软件了。独特的作法有技术上的,比如有人脸识别技术,有超大规模的数据处理能力。还有商业模式上的,第一个团购,地域上的,第一个苏州公交系统,行业上的,嘀嘀打车。
Benifit,这些实现可以给用户带来什么好处呢,为什么为了达到这个好处用户会花费时间金钱成本去迁移呢?
Competiors,看出处知己知彼的优势,博百家之长,扬长避短。

Dlivery,如何分发。
需求定义之后需要靠功能来实现。要把用户从竞争对手那里吸引过来,团队自己的产品要有一个差异化的焦点,在这个焦点上,我们的团队能做得比别人好10倍,高一个数量级,这样的功能叫做杀手级功能,其他功能则相对来叫做外围功能。
除此之外,我们的竞争对手和用户已经决定了一些此类产品必须要满足的需求,不能满足这些需求,产品就不会被用户青睐,所以把功能又划分为必需需求和辅助需求。
举例分析一个电子词典软件。杀手功能:屏幕取词技术。外围功能:良好的界面。必需需求:翻译的准确性。辅助需求:可以选择皮肤。
对于必须且杀手功能,应该全力以赴,以此为工作的重心。对于必需且外围功能,快速达到其他产品的水平就好了。对于辅助杀手功能,应该不做等待更好的时机或者空闲。对于辅助外围功能,建议采取维持的方法,以最低代价维持此功能。

9.典型用户
在软件设计的过程中,我们往往会以自己使用产品的习惯和对软件行业的熟悉程度出发设计,忘记了我们的软件是给千千万万个不那么会用电脑的人使用的,在这种情况下,就需要搞一个典型用户。
不要指望把产品的拓展性做得很好,从一般用户到超级用户都能搞定,且不论这样是否会覆盖所有的用户,这种方法肯定有其副作用。我们要从小部分人出发,明确定义谁是我们的用户。典型用户描述了谁(名字,年龄,收入,教育水平,代表比例)在什么地方(使用场景,使用环境)用了什么功能(动机,目的)。当创建完了一些典型用户之后,我们就要模拟典型用户的使用场景了,把自己(开发者)代入其中,在模拟的生活中一步一步走,就能深入理解用户的需求,及时地发现问题。

10.软件测试
测试设计有两种分类方法:黑箱和白箱。这是软件测试设计的方法,不是软件测试的方法。
黑箱:在设计测试的过程中,把软件系统当作一个无法了解或使用其内部结构,从软件的行为,而不是软件的内部结构出发。例如,程序行为的易用性测试。
白箱:在软件测试设计的过程中,设计者可以看到软件系统的内部结构,并使用软件系统的内部结构来选择测试数据和方法例如软件内部结构的流程模块化单元测试。
测试方法有很多,例如单元测试,代码覆盖率测试,构建验证测试,验收测试,探索式测试,回归测试,系统测试,伙伴测试,效能测试。

时间: 2024-10-14 10:48:59

构建之法8,9,10章的相关文章

《构建之法》第三章学习心得

这周我学习了<构建之法>第三章,讲述了软件工程师的成长.软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程是怎么样的呢?以开发人员为例,流程如下. 1.通过交流.实验.快速原型等方法,理解问题.需求或任务 2.提出多种解决办法并估计工作量 3.其中包括寻找以前的解决方案,因为很多工作是重复性的 与相关角色交流解决问题的提案,决定一个可行的方案 执行,把想法变成实际中能工作的代码,同时验证

20179215 《构建之法》第三章

<构建之法>第三章 读书笔记 ?本章为软件工程师的成长,主要介绍了评价软件工程师水平的主要方法,技能的反面,TSP对个人的要求. 一.个人能力的衡量与发展 ?软件开发流程:软件开发流程包括团队的流程,也包括个人的流程 ?软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,我们把这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程如下. 通过交流.实验.快速原型等方法,理解问题.需求或任务 提出多种解决办法并估计工作量 其中包括寻找以前的解决

读《构建之法》第四章 、第十七章

第四章    两人合作 通过对于<构建之法>第四章的阅读使我对代码规范 . 代码复审 . 以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:简明 . 易读 . 无二义性,代码书写的形式,变量命名的方法,注释程序如何工作都有详细的介绍,令我受益颇多.代码设计规范不光是程序书写的格式问题,而且牵涉到咸亨需设计 . 模块之间的联系 . 设计模式等方方面面,函数的设计,语句的使用,错误的处理,这些都是我们在进行程序设计的时候需要注意的地方.

阅读《构建之法》第四章、第十七章收获

阅读<构建之法>第四章.第十七章 阅读这一章的时候,我意识到了很多以前写程序没有注意到的地方,以前写程序就只知道能运行就好,根本不管自己写的程序占多少内存,运行的时间,是否有优化的空间,写代码的时候也不注意规范,有时候设计的函数根本用不上,造成代码冗余.同时也认识到结对编程的重要性,没读这本书之前就觉得结对编程就是两个人一人负责一个模块,然后合在一起,调试调试.但实则不然,真正的结对编程应该像书中那样,一个是驾驶人,一个是领航人,两个人有规律的进行编程.期间,一人编程一人复审,极大地提高了效率

构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程: 软件团队的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式: 开发流程包括:写了再改模式.瀑布模型.瀑布模型的变形(生鱼片模型.大瀑布带着小瀑布): Rational Unified Process统一流程(RUP):包括业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境: RUP的四个阶段包括:初始

构建之法读后感----第1章 绪论

首先,文章对于程序.用户需求.工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求.修复程序的bug.提供后续维护等服务. 需求分析:梳理需求,逐步展开后续工作,如设计(软件架构).实现(写数据结构和算法),测试,发布软件 软件=程序+软件工程(软件企业=软件+商业模式) 软将工程的核心部分:构建管理.源代码管理.软件设计.软件测试.项目管理

《构建之法》第十七章读后感

通过阅读<构建之法>第十七章,不能说对我造成了什么深远的影响,但是还是感触颇深: 第一,工作分配的重要性,说道工作分配,不得不说我们个小组的组长们,组长不仅仅是一个团队的领导者,更是这个团队的灵魂.它不仅需要了解随时掌握各组员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去非陪相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,有时甚者能更创造出以外的效果,达到更完美的状态.这不仅是组长的能力  其实其无时无刻也体现着我们这个小组的团结力和创造力.当初选

阅读《构建之法》第四章感想

课下阅读<构建之法>第四章,自己有以下一些感想. 1.我们写的代码最终都是要给人看的,所以代码规范化是一个优秀编程员必备的良好习惯,而且若是在团队里工作,那么代码规范更加重要.编程人员要遵循的代码风格的原则是:简明,易读,无二义性.以后自己要养成规范代码的习惯. 2.复审也是不可缺少的一个步骤,软件工程中最基本的复审手段就是同伴复审,找熟悉代码,有经验的人来进行复审. 3.当今时代,一个人能发挥的力量越来越小,团队的力量日渐重要,因此,如何合作,很关键.两个人合作,如何影响对方,要因人而异,因

《构建之法》第四章

<构建之法>第四章讲的是两个人的合作.结对编程.结对编程往往只需花费大约一半的时间就能编写出质量更高的代码. 代码规范方面,在给函数或者类取名的时候要严谨,不能写一些没意义的名称:在一些代码后面可以加些注释来说明此行代码的作用,在复审方面,我觉得自我复审时最好的,刚写好的代码脑袋里印象深刻,能很好的解决逻辑错误和算法错误. 结对编程方面,书中生动形象的说明了开发者的搭档关系,在结对的时候怎么分配任务,怎么通力合作.互相帮助,在两人的合作过程中,怎么磨合.互相提高水平,在遇到问题或者矛盾的时候,