关键词：
使用软件的人叫做用户。那么，想要编出一个好软件，就必须要清楚的知道自己的用户是什么样的。
于是乎，典型用户和典型场景的分析就变得尤为重要。
那么，怎么定义典型用户呢？
定义典型用户的模板可以包括以下内容：
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.有必要的提示和帮助文档
构建之法第四章读后感
构建之法第四章主要讲述了两人合作，理论和知识点包括代码规范、极限编程、结对编两人合作的不同阶段以及影响他人的技巧。代码规范包括：代码风格规范和代码设计规范，代码风格规范主要是文字上的规定，看似表面文章... 查看详情
构建之法第四章读后感
第四章读后感在经过对第四章的阅读后，我更加清晰地认识到了在项目开发中，规范二字的重要性，也新学到了除开代码规范以外，其他对于团队协作也很重要的东西，比如说构造函数的使用，模块化的编程思想，当然自己也对... 查看详情
《构建之法》第四章读后感
问题1：我对于书中的一段有些疑问，这段书中说，不要注释程序是怎么工作的，而要让程序本身来说明这个问题。我认为比较简单的代码确实不需要解释程序是怎么工作的，但是有时候为了两个人更好的配合，对于较负责代码... 查看详情
构建之法第四章读后感
从实际软件开发的各个阶段出发，详细地分析了软件工程的各个环节，如：需求分析、设计实现、用户体验、软件测试已经最后的发布等等。以前写软件或者说程序，就只是写程序，最多会考虑到数据结构的知识，很少会用到软... 查看详情
《构建之法》第四章第十七章读后感
第四章问题：如果另一个合作者不合作的话，我是应该选择脱离这个团队还是去催他工作？ 本章讲了许多关于结对编程的内容，文中写了结对编程的分工问题，结对过程中会出现的问题以及结对合作的不同阶段。 正常来... 查看详情
构建之法读后感part4
本周读完了构建之法的第四章，本章内容主要是讲“两人合作”，有一句话众所周知“三个臭皮匠赛过诸葛亮”，无论是从事什么活动或者工作，合作的力量总是1+1>2软件开发的过程是复杂的，显然的一个人的智慧是不够的，... 查看详情
构建之法读后感01
第四章阅读笔记我过去的做法写代码时不写注释，变量命名为a,b,c，如果if，for语句后只有一个语句，不用大括号包起来。之前这么做只要运行成功就行，不管别人能不能看懂这么做的缺点进入团队以后，队友看自己的程序会一... 查看详情
《构建之法》第4章第17章读后感
第四章 原文： 4.3.2：goto函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。 问题： 是否什么地方都可以使用goto语句，为什么... 查看详情
《构建之法》第第十七章读后感(代码片段)
第四章 在这一章最后一页“让独占一样还有一个好处：一眼就能看出是否有多余的代码行，还有些情况下是致命的错误”给出的参考链接http://lpar.ath0.com/2014/02/23/learning-from-apples-goto-fail/，我还是没明白的致命错误在... 查看详情
构建之法第第五章读后感
第四第五章着重讲了合作的重要性，从两人合作到团队合作，编程开发都不是一件容易的事情，要注意许多要点。代码书写的规范。你写的代码不仅仅是给机器看的，给你看的，也是给其他人看的，是给合作的队友看的，在写的... 查看详情
《构建之法》读后感
写《构建之法》读后感的想法，其来已久，一直未能完成。拖延症爆发的原因大概有二，一是感觉吸收的不够丰富而无法反刍，二是选择不好读后感切入的角度。《构建之法》2014年出的第一版，买到书时已是开学季，想要调整... 查看详情
构建之法的读后感
构建之法的读后感 七月份读完了构建之法这本书，粗读，基本了解了软件工程这个专业的工作，就业，和前景。目前有如下体会（构建之法这本书正如前言所介绍，适合软件工程的任何阶段去读，我现在只阅读了一遍，还会... 查看详情
《构建之法》读后感
《构建之法》读后感 通过对本书的阅读首先让我了解了软件的组成：软件=软件工程+程序，对软件工程的意义有了更深入的理解。软件工程是在为了解决软件危机的背景下提出的，它使软件从需求分析到代码设计再到软... 查看详情
构建之法读后感
构建之法的第八章主要是讲述了需求分析开发团队是主要为用户着想，在开发项目之前进行用户分析；讲述软件需求的4个步骤，（1）获取和引导需求（2）分析和定义需求（3）验证需求（4）在软件产品的生命周期中管理需求。... 查看详情
《构建之法》读后感02
通过阅读这一章的构建之法，让我感受最深的一个道理就是一个真正的软件是由多人完成的。虽然个人能力非常重要，但是团队之间的配合却是更为重要。而我们现在最缺少的就是这种团队之间的沟通交流。因为我们从... 查看详情
构建之法读后感
通过几天的阅读，初步对《构建之法》这本书有了初步的了解。最深的一点感受是这本书将开发过程中遇到的现实问题描绘的很好，很有幽默感。但是对一些专业术语不是很明白。比如开始都不知道最基本的瀑布模... 查看详情
《构建之法》读后感
这学期的软件测试课程多加了《构建之法》这本书，这学期利用自己的课余时间学了这本书，感觉受益匪浅。对于这本书可以简单地有两个词语来概括：“专业”、“接地气”。这本书的开头就是给我解释什么事软件、什么是软... 查看详情
构建之法六章读后感
在本周我主要学习了构建之法的第五章和第六章，第五章主要讲述团队和流程，第六章主要讲述敏捷流程；软件团队的模式有：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐... 查看详情