未验证 提交 3f99cb90 编写于 作者: X xiaowuhu 提交者: GitHub

Xiaowuhu/20201116 (#597)

* add ch12

* modify

* update

* add one slide

* add new

* Create 10.1 原型开发.md

* add ch08

* add more

* add more

* add more

* add more

* refine

* Update 8.2 原型模型.md

* okl

* add images

* add more

* move files

* update

* Update 10.3 技术选型.md

* update

* update

* Update 10.3 技术选型.md

* modify

* update images

* Update 10.3 原型模型.md

* Update 10.4 估计与计划.md

* add more

* update

* Update 10.4 估计与计划.md
Co-authored-by: NXiaowu Hu <xiaowuhu@microsoft.com>
上级 02106fac
......@@ -32,11 +32,11 @@ if __name__ == '__main__':
hp = HyperParameters_2_0(n_input, n_hidden, n_output, eta, max_epoch, batch_size, eps, NetType.MultipleClassifier, InitialMethod.Xavier)
net = NeuralNet_2_2(hp, "Bank_233")
net.LoadResult()
#net.LoadResult()
#net.train(dataReader, 100, True)
#net.ShowTrainingHistory()
net.train(dataReader, 100, True)
net.ShowTrainingHistory()
fig = plt.figure(figsize=(6,6))
DrawThreeCategoryPoints(dataReader.XTrain[:,0], dataReader.XTrain[:,1], dataReader.YTrain, hp.toString())
......
......@@ -18,6 +18,10 @@
### 关于“木头”
本书中有很多关于“木头”的故事,“木头”是一个虚构的人物,但是 TA 所经历的故事都是在真实事件基础上经过微小改编的,只不过故事的原主人公可能是笔者,也可能是笔者的同事或朋友。
词汇表
......@@ -42,5 +46,7 @@
|SDE||
|RSDE||
|NLP||
|UWP|Universal Windows Platform|
|XAML||
我们把参考资料列表放在每一章的开始部分,而不是像通常的做法放在后面,以表示对原著和作者的崇高敬意。
......@@ -93,7 +93,7 @@ MSRA 有很多的实习生,招聘、管理实习生是一个很重要的工作
微软在北京中关村有两座大厦,南北相望,南侧的是1号楼,北侧的是2号楼。每个楼都有12部电梯,位于大堂东西两侧,各6部。
出于部门安排的一些考虑,1号楼的电梯是分层配置的,1~10层乘坐东侧电梯,11~17层乘坐西侧电梯。而2号楼的电梯就是普通的配置,即可以达到任意楼层。
出于部门安排的一些考虑,1号楼的电梯是分层配置的,1-10层乘坐东侧电梯,11-17层乘坐西侧电梯。而2号楼的电梯就是普通的配置,即可以达到任意楼层。
木头在2号楼工作,感觉平时乘坐电梯时有个痛点:
......
......@@ -64,12 +64,12 @@ Persona 用户画像,古希腊罗马戏剧中的面具。
|序号|角色|需求层次|举例|
|--|--|--|--|
|0|局外人|没有需求|军儿哥|
|1|群众|基本需求|实习生小皮|
|2|关注|扩展需求|研究员小雨|
|3|粉丝|主流需求|高级研究员大陈|
|4|职业|专业需求|主管级研究员老张|
|5|专家|深度需求|大佬 Harry|
|0|局外人,非用户|没有需求|军儿哥|
|1|群众,普通用户|基本需求|实习生小皮|
|2|关注,活跃用户|扩展需求|研究员小雨|
|3|粉丝,贡献用户|主流需求|高级研究员大陈|
|4|职业,专业用户|专业需求|主管级研究员老张|
|5|专家,资深用户|深度需求|大佬 Harry|
由此,我们可以得到研究员的用户画像,如图 5.5.3 所示。
......
......@@ -37,7 +37,7 @@
### 参考资料
- [1] 《软件工程》,清华大学出版社
- [2] 周金根 《软件需求的三个层次》http://www.zhoujingen.cn/itbang/352.html
- [3] 李鸿君 大话软件工程《需求分析与软件设计》清华大学出版社
- [2] 周金根《软件需求的三个层次》http://www.zhoujingen.cn/itbang/352.html
- [3] 李鸿君,大话软件工程《需求分析与软件设计》,清华大学出版社
- [4] Difference Between Aggregation and Composition, https://techdifferences.com/difference-between-aggregation-and-composition.html
- [5] 杨长春 《实战需求分析》 清华大学出版社
- [5] 杨长春,《实战需求分析》,清华大学出版社
......@@ -89,4 +89,4 @@
......
大家还聊了很多,木头把后来的一些细节放到了“木头与神经网络课程的故事”中,为老师和同学们描述了一下 AI 教学系统的真实体验。
大家还聊了很多,木头把后来的一些细节放到了“木头与 AI 教学的故事”中,为老师和同学们描述了一下 AI 教学系统的真实体验。
......@@ -120,8 +120,11 @@ Rumbaugh 和他的同事提出的对象模型化技术(OMT)用于分析、
2. 建立动态模型
- 第一步,编写典型交互行为的脚本。虽然脚本中不可能包括每个偶然事件,但是,至少必须保证不遗漏常见的交互行为。
- 第二步,从脚本中提取出事件,确定触发每个事件的动作对象以及接受事件的目标对象。
- 第三步,排列事件发生的次序,确定每个对象可能有的状态及状态间的转换关系,并用状态图描绘它们。
- 最后,比较各个对象的状态图,检查它们之间的一致性,确保事件之间的匹配。
3. 建立功能模型
......@@ -165,17 +168,26 @@ Wirfs-Brock 方法不明确区分分析和设计任务。从评估客户规格
统一的建模语言(UML)已经在企业中广泛使用,它把Booch、Rumbaugh和Jacobson 等各自独立的 OOA 和 OOD 方法中最优秀的特色组合成一个统一的方法。UML 允许软件工程师使用由一组语法的语义的实用的规则支配的符号来表示分析模型。
在UML中用5种不同的视图来表示一个系统,这些视图从不同的侧面描述系统。每一个视图由一组图形来定义。这些视图概述如下:
在UML中用5种不同的视图来表示一个系统,这些视图从不同的侧面描述系统。每一个视图由一组图形来定义。这些视图形成一个序列,如图 6.6.3 所示:
<div align="center">
<img src="Images/Slide25.JPG"/>
图 6.6.3 - UML 中的模型视图
</div>
【slide】
1. 用户模型视图:这个视图从用户( 在UML中叫做参与者)角度来表示系统。它用使用实例(use case)来建立模型,并用它来描述来自终端用户方面的可用的场景。
2. 结构模型视图:从系统内部来看 数据和功能性 。即对静态结构(类、对象和关系)模型化。
3. 行为模型视图:这种视图表示了系统动态和行为。它还描述了在用户模型视图和结构模型视图中所描述的各种结构元素之间的交互和协作。
4. 实现模型视图:将系统的结构和行为表达成为易于转换为实现的方式。
5. 环境模型视图:表示系统实现环境的结构和行为。
1. 用户模型视图:这个视图从用户( 在UML中叫做参与者)角度来表示系统。它使用用例(use case)来建立模型,并用它来描述来自终端用户方面的可用的场景,在 6.7 节中讲述。
2. 结构模型视图:从系统内部来看数据和功能,即对静态结构(类、对象和关系)模型化,在 6.8 节中讲述。
3. 行为模型视图:这种视图表示了系统状态和行为,还描述了在用户模型视图和结构模型视图中所描述的各种结构元素之间的交互和协作,在 6.9 节中讲述。
4. 实现模型视图:将系统的结构和行为表达成为易于转换为实现的方式,在本书的第 5 部分中讲述。
5. 环境模型视图:表示系统实现环境的结构和行为,在本书的第 5 部分中讲述。
通常,UML 分析建模的注意力放在系统的用户模型和结构模型视图,而 UML 设计建模则定位在行为模型、实现模型和环境模型
通常,UML 需求分析建模的注意力放在系统的用户模型和结构模型视图,而 UML 系统设计建模则定位在行为模型、实现模型和环境模型。但是正如 6.9 节中将要学习到的,行为模型有两种:一种是还原现实世界的行为,属于需求分析的范畴;另外一种是在计算机的数字世界中设计新的行为模型,后者是对前者的抽象和扩充
## 6.6.3 划分需求分析与系统设计的边界
......@@ -183,13 +195,17 @@ Wirfs-Brock 方法不明确区分分析和设计任务。从评估客户规格
为什么这种情况能一直持续下去呢,一个重要原因是在一般的软件公司里,总会有一位“领域专家”,往往是他/她既做需求分析,又做系统设计。在微软其实也是这样,没有各自独立的角色分别做需求分析和系统设计两件事,往往是一个从底层做起的程序员,逐渐成长为领域专家后,再去负责需求分析与系统设计的工作。这样做的问题是:
1. 他/她在做需求分析的时候,脑子里会不自觉地想到如何去实现;
2. 写出来的文档没有边界,定义出来的类会让后续的开发人员感觉到限制;
3. 隐藏了一些真实的用户需求,而用自己的理解直接代替。
1. 他/她在做需求分析(做什么)的时候,脑子里会不自觉地想到如何去实现(如何做),这样就混淆了“做什么”和“如何做”;
2. 写出来的文档没有边界;
3. 定义出来的类会让后续的开发人员感觉到限制;
4. 隐藏了一些真实的用户需求,而用自己的理解直接代替。
用一个简单的比喻帮助大家理理解它们的分界线:我们在做需求分析的时候,可以把每个角色、实体、模块等等都看作一个鸡蛋,它们在需求分析阶段都是不透明的,我们也不需要在需求分析阶段去窥探鸡蛋内部的构造,否则的话,我们会得到一堆破鸡蛋——所有的蛋液流出来并混在一起,造成无法进行下一步的分析。
这个鸡蛋壳,就处于上述的“统一的 OOA 方法”的5个视图中的第3个上。
这个鸡蛋壳,就处于上述的“统一的 OOA 方法”的5个视图中的第3个上,如图 6.6.3 中的分界线所示
笔者在多年的软件工程实践中也总结出了一套方法,经过与各种模型、理论的对比,发现竟然与“统一的 OOA 方法”完全一致!所以,我们会在后续的章节中通过真实的案例继续介绍这种方法。
......@@ -3,7 +3,7 @@
这是做技术需求分析的第一步,在这一步中,我们要建立“用户模型视图”。我们使用 6.3 节中的 AI 教学需求来作为例子进行分析,步骤如下:
<div align="center">
<img src="Images/Slide25.JPG"/>
<img src="Images/Slide26.JPG"/>
图 6.7.1 - 用户模型视图的建立方法
</div>
......@@ -27,7 +27,7 @@
我们先看第一张图:
<div align="center">
<img src="Images/Slide26.JPG"/>
<img src="Images/Slide27.JPG"/>
图 6.7.2 - 上下文图
</div>
......@@ -64,7 +64,7 @@
我们再看第二张图:
<div align="center">
<img src="Images/Slide27.JPG"/>
<img src="Images/Slide28.JPG"/>
图 6.7.3 - 错误的上下文图
</div>
......@@ -88,7 +88,7 @@
### 简单的例子
<div align="center">
<img src="Images/Slide28.JPG"/>
<img src="Images/Slide29.JPG"/>
图 6.7.4 - 系统与子系统用例
</div>
......@@ -108,8 +108,8 @@
在上面的图中,一共有四种图例:
1. Actor(参与者),在这里是“学生”。它描述与系统交互的人或物,代表外部实体(如用户,硬件、设备等);
2. 系统或者子系统边界,这里是AI教学系统和作业子系统;
1. Actor(参与者),用人形表示,在这里是“学生”。它描述与系统交互的人或物,代表外部实体(如用户,硬件、设备等);
2. 系统或者子系统边界,用矩形框表示。这里是AI教学系统和作业子系统;
3. 用例,包括子系统用例(作业子系统、实验子系统)和功能用例(浏览作业、提交作业、获得评分、获得提示)。它是执行者与计算机一次典型交互,代表系统某一完整功能。
4. 关联线,表示参与者与用例的交互关系。注意这是一条直线,没有箭头,在旧的版本的UML中是一条指向用例的三角箭头线。
......@@ -134,7 +134,7 @@
### 复杂的例子
<div align="center">
<img src="Images/Slide29.JPG"/>
<img src="Images/Slide30.JPG"/>
图 6.7.5 - 特殊关系的用例
</div>
......
......@@ -3,7 +3,7 @@
这是需求分析的第二步,在这一步中,我们要建立“结构模型视图”。步骤如图6.8.1:
<div align="center">
<img src="Images/Slide30.JPG"/>
<img src="Images/Slide31.JPG"/>
图 6.8.1 - 结构模型视图
</div>
......@@ -30,7 +30,7 @@
我们看看 AI 教育系统的例子中,关于学生作业上传后自动评分的功能是如何实现的,请看图 6.8.2 中的上半部分。
<div align="center">
<img src="Images/Slide31.JPG"/>
<img src="Images/Slide32.JPG"/>
图 6.8.2 - 数据流图
</div>
......@@ -59,7 +59,7 @@
图6.8.3这个例子,场景是考察同学们对预处理特征值的理解:
<div align="center">
<img src="Images/Slide32.JPG"/>
<img src="Images/Slide33.JPG"/>
图 6.8.3 - 数据流图
</div>
......@@ -101,7 +101,7 @@
我们仍然用作业自动评分的功能能来举例,分析一下老师、学生、作业、题目、答案、排行榜之间的关系,见图 6.8.4。
<div align="center">
<img src="Images/Slide33.JPG"/>
<img src="Images/Slide34.JPG"/>
图 6.8.4 - 定义数据模型
</div>
......
......@@ -8,19 +8,19 @@
请注意:到了这里已经快接近设计范畴了,也就是说,我们已经快破开鸡蛋壳了,一旦破壳,就会进入设计的大门。所以到了这一步,是需求分析的最后一个环节了。说到底,需求分析和系统设计也不是完全隔离的,所以在这一步里有些交融也是合理的。
## 6.9.1 状态转换图(State Machine)
## 6.9.1 对象级别的状态转换
状态转换(迁移)图是描述对象的状态在响应外部的信号后进行转换的一种图形表示。
State Machine,状态转换(迁移)图是描述对象的状态在响应外部的信号后进行转换的一种图形表示。
### 对现实世界的状态转换分析
<div align="center">
<img src="Images/Slide34.JPG"/>
<img src="Images/Slide35.JPG"/>
图 6.9.1 - 类内状态转换图
</div>
### 对现实世界的状态转换分析
我们以作业对象为例,绘制出状态转换图,如图 6.9.1 的左上角的子图。我们可以看到四种图例:
我们以作业对象为例,绘制出状态转换图,如图 6.9.1。我们可以看到四种图例:
1. 起始和终止状态,圆形;
2. 状态,被观察到的对象行为模式,用圆角矩形表示;
......@@ -40,7 +40,13 @@
### 对软件系统的状态转换设计
在需求分析阶段,很容易犯的错误是绘制如图 6.9.1 右下角所示的状态转换图。比较左上角和右下角子图,我们可以看到后者多出来几个状态:
<div align="center">
<img src="Images/Slide36.JPG"/>
图 6.9.2 - 类内状态转换图
</div>
在需求分析阶段,很容易犯的错误是绘制如图 6.9.2,与图 6.9.1 比较,我们可以看到后者多出来几个状态:
- 未完成
- 已完成
......@@ -65,14 +71,14 @@
- 是否在完成作业后,在回过头来修改;
- 是否在提交作业后,在老师还没有批改的前提下,收回作业,做进一步的修改。
### 系统的状态转换
## 6.9.2 系统级别的状态转换
前面我们介绍的是某个对象(类)的微观状态转换,对于一个大系统来说,也是有状态转换的,比如AI教育系统中的训练子系统,如图 6.9.2 所示:
<div align="center">
<img src="Images/Slide35.JPG"/>
<img src="Images/Slide37.JPG"/>
图 6.9.2 - 系统状态转换图
图 6.9.3 - 系统状态转换图
</div>
表 6.9.2 列出了状态转换表。
......@@ -100,4 +106,3 @@
- 也可以算作设计的一部分:需求方没有想到这一点,而是需求分析人员或者系统设计人员从技术角度给与的建议,需要征求用户的同意后,成为技术需求的一部分。
笔者倾向于后一种看法,即它是系统设计的一部分,所以在需求分析阶段,可以不绘制这张图,而是留在系统设计阶段再拿出来。
......@@ -19,5 +19,5 @@
- [5] 马斯洛理论 https://www.simplypsychology.org/maslow.html
- [6] 百度百科《今日头条》https://baike.baidu.com/item/%E4%BB%8A%E6%97%A5%E5%A4%B4%E6%9D%A1/4169373
- [7] 《构建之法》,邹欣,人民邮电出版社
- [8] 《刷新》,萨提亚.纳德拉
- [8] 《刷新》,萨提亚·纳德拉
- [9] 王佳亮,http://www.woshipm.com/pmd/4196067.html
......@@ -19,7 +19,7 @@
<div align="center">
<img src="Images/Slide34.JPG"/>
图 7.10.2 - 产品和服务
图 7.10.2 - 需求文档的产生
</div>
## 7.10.2 需求规格说明书的模板
......@@ -56,7 +56,7 @@
Function 和 Feature 不是同一层意思:
||Function 功能|Feature 特性|
||Feature 特性|Function 功能|
|--|--|--|
|定义|产品或服务可以完成的任务、目标|可以实现某一功能的工具、方法|
|组成|产品、服务、任务、流程、计算、系统、应用、文档、组件、机器,等等|窗口、按钮、菜单、列表、图形、声音、视频、卷滚条,等等|
......
# 7.6 需求的恶性变更与控制
# 7.6 需求的变更与控制
## 7.6.1 需求变更的普遍性故事
......@@ -137,7 +137,7 @@
木头:那么你们遇到的最麻烦的事情是什么呢?
大淘:比如原定10月1号要上线,但是我的测试一直都没有通过,用户这边的测试没有通过,那有可能就要拖,拖到客户验收为止,可能到10月30号啊,这是一种情况。另一种情况是你上线了之后,客户不讲理,尾款会拖着付。
大淘:比如原定10月1号要上线,但是我的测试一直都没有通过,用户这边的测试没有通过,那有可能就要拖,拖到客户验收为止,可能到10月30号啊,这是一种情况。另一种情况是你上线了之后,客户不讲理,尾款会拖着付。
木头:原因是什么呢?
......
# 7.7 避免非理性需求
非理性需求往往表现在三个方面$^{[8]}$,用公式 7.7.1 来表示:
非理性需求往往表现在三个方面$^{[7]}$,用公式 7.7.1 来表示:
$$
非理性需求=\begin{cases}
......@@ -16,7 +16,7 @@ $$
<div align="center">
<img src="Images/Slide27.JPG"/>
图 7.7.1 - 非理性需求
图 7.7.1 - 非理性需求举例
</div>
## 7.7.1 关系和利益
......@@ -51,7 +51,7 @@ $$
当时,Bing Search(必应搜索)算是一个新生的产品,因为微软看到谷歌在搜索上大赚其钱,眼红了。在沈向洋博士的带领下,必应搜索终于能在美国市场可以与谷歌搜索分庭抗礼了。
到了萨提亚时代,一本《刷新》$^{[7]}$(英文名称为 Refresh)的书阐明了 CEO 的新思想,微软放弃 Windows Phone,大力投入 Azure 云。Mobile First, Cloud First(移动为先,云为先)的战略使得微软有了新的利润增长点,股票价格也是一路飘升。
到了萨提亚时代,一本《刷新》$^{[8]}$(英文名称为 Refresh)的书阐明了 CEO 的新思想,微软放弃 Windows Phone,大力投入 Azure 云。Mobile First, Cloud First(移动为先,云为先)的战略使得微软有了新的利润增长点,股票价格也是一路飘升。
从组织结构上也可以看出,Windows 的明星光环已经暗淡,在足球场上处于后卫的位置,当然后卫也很重要。但是 Windows Team 内部的一些陈旧的做派实在是不能被木头所认可,但也许那就是 Windows 的产品风格吧?
......
......@@ -35,9 +35,12 @@ $$
在微软,PM 的比例大概为 15% 左右,即开发人员和 PM 的比例大概为 5:1 左右。PM 平时的工作关系网大致如图 7.9.2 所示。
- 左侧的市场、销售、客户、用户很好理解,提供产品的说明;
- 上方,和设计师(designer)合作设计交互和界面,与其它团队的 PM 联系团队间的合作;
- 下方,要负责给各级领导汇报做 PPT;
- 右侧,一般是和 Dev Lead/Manager 打交道,有时候如果开发人员人数较少,可以直接与之沟通。
- 上方,要负责给各级领导汇报做 PPT;与其它团队的 PM 联系团队间的合作;
- 右侧,和设计师(designer)合作设计交互和界面,和 Dev Lead/Manager 打交道,有时候如果开发人员人数较少没有层级关系,可以直接与之沟通;
- 下方,与品质保证与测试人员沟通测试方案,执行测试计划。
<div align="center">
<img src="Images/Slide30.JPG"/>
......@@ -150,11 +153,11 @@ $$
- 执行
完整执行特性撰写和评审、任务估计、技术设计评审、制定各个阶段的验收标准和时间表,以及性能标准。
完整执行 PM Spec 的撰写和评审、任务估计、技术设计评审、制定各个阶段的验收标准和时间表以及性能标准。
- 估计
用系统思维方式提供准确的时间估计。但是大多数时候,PM 还是要听从 Dev Lead/Manager 的意见,因为后者更能够准确地估算开发和测试时间,而 PM 可以估算其它环节的时间。
用系统思维方式提供准确的时间估计。但是大多数时候,PM 还是要听从 Dev Lead/Manager 的意见,因为后者更能够准确地估算开发和测试时间,而 PM 可以估算其它环节的时间,比如审批流程的耗时、合作伙伴的配合等外部因素
- 评审
......@@ -186,8 +189,3 @@ PM 并不是写完 PM Spec 就没事儿了,后面一系列的工程环节都
上面这些条目中,PM 需要和 Dev Lead/Manager 合作来完成的,因为能当上 Dev Lead/Manager 的人也是有足够能力的,PM 得到这些人的支持会事半功倍。
木头曾经为 Windows Phone 10 做一款预装的 APP,在这之前,木头一直在 Windows Phone 8.1 上工作。当时的 PM 和 Dev Lead 都没有告诉木头这个新 APP 是为 Windows 10 的,而 Designer 拿出的设计用了一些新的 UWP 的标注方式。木头在 Windows Phone 8.1 上做出 Prototype 后,界面特别丑,而且有几个技术点还不能实现。
Designer 在自己的手机上看到 Demo 后,感觉字号不对,就来和木头确认是否是 Windows 10 的开发环境。木头赶紧去问 PM 和 Dev Lead,才知道这是为 Windows Phone 10 设计的 APP。幸好前面的 Prototype 没有耽误太多时间。木头又用了两天时间,在当时并不稳定的 Windows 10 桌面机上,安装并不稳定的 Windows 10 SDK,再花时间熟悉新的 SDK,很快又做出了新的 Prototype,安装在并不稳定的 Windows Phone 10 上,结果和 Designer 的设计图完全匹配。
在这个真实故事中,Designer 的交互设计都出来了,说明在这之前 PM 和 Designer 已经开过很多次会了,他们的上下文就是 Windows Phone 10,所以理所当然地认为木头也知道这个上下文。PM 以为木头知道情况,就没有告诉木头是 Windows Phone 10 上的 APP。
# 需求演进
需求演进与
需求变更是指由甲方提出的
## 需求演进 - 木头与浏览器的故事
木头曾经参与了手机上的 Edge 浏览器的开发工作,深刻体验到了需求演进的过程。
1. Week 1,第一周
最初得到的消息很简单:
1. 我们要做一个手机端的浏览器,在 iOS 和 Android 上都有;
2. 基于 Google 的 Chromium 开源软件开发
木头心想:浏览器简单呀,天天都用,应该没啥难度。所以在第一周,木头的心中只有一个大方框,里面有三个大字:浏览器。
2. Week 2,第二周
3. Week 3,第二周
4. Week 4,第二周
## 需求挖掘