构建之法读后感第四篇

  使用软件的人叫做用户。那么,想要编出一个好软件,就必须要清楚的知道自己的用户是什么样的。

于是乎,典型用户和典型场景的分析就变得尤为重要。

那么,怎么定义典型用户呢?

定义典型用户的模板可以包括以下内容:

1.名字(越自然越好)

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

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

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

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

6.生活/工作情况

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

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

9.用户的偏好

  和典型用户、典型场景的方法类似,用例也是很常用的需求分析工具。它包括一下基本要素:

1.标题  2.角色  3.主要成功场景  4.扩展场景

使用用例的原则是什么呢?

1.通过讲简单的故事来传递信息  2.保持对全系统的理解  3.关注用户的价值  4.逐步构建整个系统  5.增量开发,逐步构建整个系统  6.适应团队不断变化的需求

  需求分析之后便是设计与实现阶段,我们要搞清楚:软件怎么解决需求的。

  图形建模和分析方法:

1.表达实体与实体之间的关系:思维导图、实体关系图

2.表达数据的流动:和管理机构相关的数据流、和读者相关的数据流、和新书入库相关的数据流、和时间相关的数据流

3.表达控制流

4.统一的表达方式

  其他的设计方法

1.形式化的方法

2.文学化编程

  从设计文档到实现的步骤:

1.把修改集集成到代码库中

2.开发人员的标准工作流程

3.代码完成

  开发阶段的日常管理

1.闭门造车  2.每日构建  3.构建大师  4.宽严皆误  5.小强地狱

  一个软件光是实现用户要使用的功能还不行,还得要能考虑到用户的体验,所以UI(用户界面)就很重要。

用户体检的要素:1.第一印象:

那么,怎么来判断一个设计是好的设计呢?我们可以采用5W1H的方法来判断:

WHO:谁是你的目标用户?

WHEN:他们会在什么时候使用你的产品?比如一个邮件应用,用户在起床的时候可能更偏向于快速查看,而在工作时间会发生更多的输入操作。

WHERE:目标用户会在哪里和你的产品交互?是晃动的公交上或阳光耀眼的室外?还是在沙发上?

WHAT:你的产品是什么?而用户的期待是什么?

WHY:用户为什么要使用你的产品?他们的动机是什么?还有,在众多竞争产品中,用户为什么会选择你的产品?

HOW:用户是如何与你的产品发上交互的?他们怎么用?在使用过程中出现了什么问题吗?

2.从用户的角度考虑问题

3.软件服务始终都要记住用户的选择

4.短期刺激和长期影响

5.不让用户犯简单的错误

6.用户体验和质量

7.情感设计

  对于一个用户界面有没有什么评价标准呢?答案当然是有的。

1.尽快提供可感触的反馈

2.系统界面符合用户的现实惯例

3.用户有控制权

4.一致性和标准化

5.适合各种类型的用户

6.帮助用户识别、诊断并修复错误

7.有必要的提示和帮助文档

  

时间: 2024-10-11 04:57:14

构建之法读后感第四篇的相关文章

构建之法读后感第三篇

同敏捷开发同样具有影响力的是微软的MSF开发模式,他有着一下几个基本原则: 一.推动信息共享与沟通 所有的信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人.当然,对牵涉到的技术机密.安全性等信息要采取必要的保护措施 这样确实有很多好处,首先,信息都保留了下来,其中更是对的,错的都有. 这一方面当我们想查询自己以前的程序时,可以很方便的找到程序,并且,我们可以不断的从自己的错误中积累经验. 二.为共同的远景而工作 这里 "共同的远景" 是指产品的远景,在同一时段,团队里

《构建之法》第四章读后感--软件工程

<构建之法>第四章读后感--两人合作 1.代码风格很重要,因为良好的代码风格,有益于两人的合作甚至多人的合作. 个人认为 : 良好的代码风格的培养就是 多去阅读别人的优秀代码 ,用于提高并且培养自己的代码风格. 2.关于结对编程的重要性 2.1 结对编程能提高设计质量与代码质量 2.2 结对有益于学习交流 3.如何结对编程 3.1 主动参与讨论,提出设计方案或者问题的解决方案 4.代码的复审 复审可以提高代码质量,优化项目性能.

《构建之法》阅读梳理篇读后感

我通过老师发的链接读了“<构建之法>阅读梳理篇”,我从中懂了很多,我懂了软件与程序的区别,明白了作为一个程序员是要掌握的基本能力,更明白了一个软件或项目是由一个团队完成的,个人的能力再强也强不过一个团体.在这篇文章中我明白了很多,同时我也对我日后可能要做的工作有了更全面的了解,也令我看清了程序员这个工作的前景和工作方式,更令我看清了自己的缺点和不足.我要以这篇文章里的要求去要求自己,向真正的程序员努力. http://www.cnblogs.com/lwr-/p/5199030.html?fr

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

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

构建之法读后感part4

本周读完了构建之法的第四章,本章内容主要是讲"两人合作",有一句话众所周知"三个臭皮匠赛过诸葛亮",无论是从事什么活动或者工作,合作的力量总是1+1>2 软件开发的过程是复杂的,显然的一个人的智慧是不够的,遇到问题一起解决,工作一起分担能使开发的效率提高很多.以后到公司团队工作,合作很大程度上实现优势互补,比如说有人擅长界面设计,有人擅长实现功能,这样的合作能减少工作量提高整个开发效率.有些人技术很好,可是在沟通这方面十分欠缺,这是很不利于合作的,在项目的开发

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

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

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

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

《构建之法》第四章

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

《构建之法》第四章---阅读总结

<构建之法>第四章---阅读总结 前言 看到这个章节的名字,我想起了之前老师叫我们看的<硅谷传奇>,原来老师是想让我们在学这一章节之前先了解两人合作的重要性.确实,软件工程既然能带上“工程”二字,那就说明它并不是一个人的事情,软件工程离不开团队合作,而团队合作的最简形态就是两人合作.由<硅谷传奇>可知,一个好的合作伙伴是多么重要,两人能有着共同的追求,又能包容对方的性格,各施其长后能力就不再是简单的1加1了. 分析与理解 本章节围绕“两人合作”的中心,主要讲解了编程规范