《构建之法》

Posted 2020-09-19

本周阅读了第10～12章，进一步学习了在开发一个软件时需要考虑并做到的几个方面。

 

第10章  典型用户和场景

 

作为软件，目的是为了实现用户的需求，所以，开发软件最大的目的不是“软件工程”，而是“用户”。

1.典型用户和典型场景

典型用户就是互不相同的、最可能使用软件的若干类用户；要作为“典型”，还要完善他们的使用诉求、习惯以及本身的软件操作水平。以强迫我们考虑问题的时候从用户的角度出发。

首先，定义典型用户，从典型用户到场景，从场景到任务，从任务到代码。

典型用户(Persona)的模板：

（1）名字（越自然越好）。

（2）年龄（不同年龄和收入的用户有不同的需求）。

（3）收入。

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

（5）使用这个软件的典型场景。

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

（7）生活/工作情况。

（8）知识层次和能力（教育程度，对电脑、万维网的熟悉程度）。

（9）用户的动机、目的和困难（困难 = 需要解决的问题）。

（10）用户的偏好。

有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的（如：购物者，产品提供商，滥发广告者……）对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事/Story。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，在写场景的时候要有针对性。

2.规格说明书（spec）

规格说明书(Specification),简称Spec。有两种:

 a)软件功能说明书（functional spec）：主要用来说明软件的外部功能, 和用户的交互情况 (把软件当作一个黑盒子)

第一, 定义好相关的概念。

第二, 规范好一些假设 （assumptions）。

第三, 避免一些误解， 界定一些边界条件。

第四, 描述主流的用户/软件交互步骤。

第五，一些好的功能还会有副作用。我们要把这些副作用明明白白地写出来。

第六，服务质量的说明。

 b) 软件技术说明书（technical spec）：又叫 design doc, 设计文档, 主要用来说明软件内部的设计 (把软件当作一个透明的箱子)

 

3.功能驱动（feature driven design，FDD）的设计

将用户需求变成团队成员可以直接操作的开发工作

步骤：

(1)构造总体模型

(2)构造功能列表

(3)制定开发计划

(4)功能设计阶段

(5)实现具体功能

 

 

第11章  软件设计与实现

 

本章主要是介绍开发的流程。

1、分析和设计方法

我们写软件就是要解决用户的需求，我们需要搞清楚在“需求分析”阶段、“设计与实现阶段”、“测试”和“发布”阶段个自该做些什么及怎么做。

2.图形建模

表现实体和实体之间的关系：

思维导图（mind map）

实体关系图（entity relationship map）

用例图 （Use Case Diagram，UCD )

用例图主要有下列的元素：

参与者（Actor）: 表示参与系统运作的外部因素，例如用户，管理员，外部模块，设备，来自外部的信号等。 通常是一个简笔画的小人。

系统：通常用一个方框来表示系统的边界。有时也可以忽略。

用例（Use Case）：表示系统和参与者交互的一次场景。它是一组动作的集成，而不是一个单独的内部元素。

信息传递线：用带箭头的线用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。

表达数据的流动 （Data Flow Diagram）：

当我们要关注数据在不同的实体之间依赖一定的规则流动的时候， DFD 是一个合适的工具。

表达控制流 （Flow Chart,  Finite State Machine）

统一的表达方式（Unified Modeling Language, UML）

这些图形建模方法各有特点，它们使用了不同的几何图形、标注规则、专有词汇和颜色。

3、其他设计方法

在计算机软件发展的过程中，科学家和工程师们还尝试了很多其他方法， 它们在不同程度上解决了一些局部问题，从不同的方面推动了相关领域的发展。

形式化的方法 （Formal Method）

用无歧义的、形式化的语言描述我们要解决的问题，然后用严密的数学推理和变换一步一步把软件实现出来，或者证明我们的实现的确完整和正确地解决了问题。在这个领域一个比较成熟和经过实践考验的方法是 Vienna Development Method （VDM）。 

文学化编程 （Literate Programming）

它是 “写文档，时不时有些代码”。 它使用了宏（Macro）来进行抽象和信息隐藏。 通过工具的支持，它的源代码可以提取出让计算机编译执行的部分（叫 Tangle），以及文档（叫 Weave）。

 

 

第12章  用户体验

 

讲“用户体验”，其实就是为了能够让开发者能够在“think on customers feet”与"think by themself"之间自如切换——体验软件的时候站在用户角度，设计这些体验的时候在设计者角度

计算机软件的用户界面（user interface，UI）&用户体验（user experience，UX）

无论软件还是硬件,都有很多功能，各个部件还要有机地结合起来，才能够满足用户的需求

 

1、用户体验的要素

一、用户的第一印象

如何判断一个是不是一个好的设计？

who：目标用户

when：他们会在什么时候使用你的产品

where：何处使用

why：为什么要使用你的产品【个人认为这个问题很致命】

how：如何使用

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

从用户的角度考虑问题

用户需要帮助，但是用户没有那么笨

光吃狗食也不够。dogfood的传统可以帮助发现问题（自己使用自己开发的软件）

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

长期使用之后，软件会变得好用吗? 

4.短期刺激和长期影响

在测试中，测试人员受到的大多数是短期刺激；而客户在实际使用的时候受到的是长期影响（比如，一个饮料喝上一瓶和喝上5瓶是一样的感受吗？）

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

界面设计上，比如把“submit”和“cancel”设计的距离很近，这样用户手一抖就会点错

6.用户体验和质量

7.情感设计

 

二、用户体验设计的步骤和目标 

1.用户体验的评价标准

 尽快提供可感触的反馈。

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

(主要指的是使用用户语言而不是开发者语言，让用户能理解。

用户有控制权。

一致性和标准化

适合各种类型的用户

帮助用户识别，诊断并修复错误

有必要的提示和帮助文档

 

[注]  如何评估用户界面?  可以参考 Nielsen的启发式十条原则：

   01  可视性原则

    系统状态有反馈，等待时间要合适

   02  系统界面符合现实惯例

    使用用户语言而不是开发者语言，贴近生活实际而不是学术概念或开发者的概念。

   03  用户有自由控制权

     操作失误可回退

   04  一致性和标准化

   同一事物和同类操作的表示用语要各处保持一致

   05  预防用户出错

   关键操作有确认提示，及早消除误操作

   06  减少记忆负担 

   识别胜于回忆，提供必要的信息提示（可视&易取），减少记忆负担

   07  使用效率和灵活性

    为新手和专家设计定制化的操作方式，快捷操作可调整。

   08 易读性

    减少无关信息，体现简洁美感

   09 帮助用户识别，诊断并修复错误

   给用户明确的错误信息，并协助用户方便的从错误中恢复工作

   10 提示和帮助文档

    无需文档就能流畅应用当然更好，一般地文档很必要，而且也提供便利的检索功能，从用户的角度出发描述具体步骤，并且不要太冗长。