系统的概要设计
小组分享记录
ppt 由nodeppt 制作，地址：https://github.com/qqqdu/myppt/blob/master/mark.md
架构
基础架构
技术选型 操作系统 编程语言 技术框架 第三方库
强调选择能力，技术前瞻性和判断力
大中台小前台
分解出业务无关的技术
业务架构
业务系统的分解能力
领域问题：领域的用户群面临的普遍需求。
没有需求分析，就没有业务架构。需求分析需要占1/3，第二步就是系统的概要设计。
系统概要设计
对系统进行分解的能力，明确子系统职责边界和系统协议，把系统框架搭建起来。
分解系统的标准：子系统如何分解模块，模块如何分解类、函数。
项目案例
于大爷挖隧道
- 美国人
提出需求[1]，在西海岸和东海岸建一条海底隧道。 - 于大爷和他父亲接需求，草草的进行了
需求分析[2]，
并签了合同[3] 两人[4]带着铁锹就赶去了海岸，一边一个开始挖。- 项目竣工了，发现两个人没
碰面[5]，导致修了两条隧道[6] 美国人很满意[7]
于大爷复盘会
拿到了两份工资的于大爷和他父亲把上面的事儿告诉了他的架构师儿子：郭小宝。
小宝意识到事情不简单，虽然这次 “隧道项目” 美国人给了两份工资，但这事儿要发生软件项目开发周期上，那于大爷和他父亲就危险了。于是小宝仔仔细细回顾了整件事情。
毫无疑问，美国人就是产品经理，于谦是开发组组长，他父亲则是组员。
提出需求
美国人
提出需求[1]，在西海岸和东海岸建一条海底隧道。
美国人这个需求就很不地道，需求最起码要满足三要素：谁在哪儿遇到了什么问题。而这里只说了要建条海底隧道，那这个需求该如何提出呢？
比如，
背景是：水深火热的美国人想去西海岸到东海岸（东海岸火锅好吃点）涮火锅，但飞机票太贵，开车去比较划算，而目前二者之间没有公路
解决方案是，在东海岸西海岸建一条海底隧道。
期望达到的目的：把火锅带到每一个美国家庭。
具体想达到的目标是：每年有100000车流量，每辆车收取 100$
需求分析
于大爷和他父亲接需求，进行了
需求分析[2]并签了合同[3]（排期）：
事实上于大爷和他父亲并没有做需求分析，如果他们做了需求分析，那这个糟糕的项目就不会接下来，也不会签订合同。
作为“开发组组长”，于谦并没有对糟糕的需求文档说不。
拒绝不规范的需求文档
首先，”在西海岸和东海岸建一条海底隧道”,这是需求吗？不，这是方案。当你的产品经理提出的不是需求时，你可以拒绝他，让他重新编写需求文档。
需求的紧急度
其次，假定美国人提出了需求：建隧道是为了解决美国人涮火锅问题。这是痛点吗？美国人吃不吃火锅重要吗？紧急吗？非得这个时候建隧道吗？能不能降优先级？我看让纽约人民尽早扭上大秧歌更紧急。
最佳方案
再假定，美利坚人民吃火锅的欲望很强烈，必须得在年底圣诞节前吃上火锅，吃不上就要在白宫门口搞一道“美丽的风景线”。但建隧道是唯一选择吗？能不能找其他解决方案，比如外包给中国建海上高铁，或者用顺丰速运火锅底料走空运。（最佳方案）
排期
最后，就算美利坚人就喜欢开车到东海岸，吃着火锅唱着歌，需求是正确的、是优先的，方案是合理的。最终于大爷签了合同，也不知道合同里填的项目周期是多少，但在需求分析之后直接给出项目周期，显然不是一个好节点。这就引出了后面的话题：系统的概要分析。
开发的觉悟
总结下需求分析阶段于大爷要做的事情：
- 拒绝不规范的需求文档
- 审查项目的痛点和紧急度
- 协助产品选择最佳技术方案
- 排期前先做概要设计
系统的概要设计
假设，需求分析一切的一切都是顺利进行的，接下来美国佬虎视眈眈的看着于大爷，等着他数人头、定时间、签合同。
郭小宝：显然不行，我们还要进一步分析。合同(排期)这种东西可不能乱来。
于大爷是这么做的：签完合同，扛着铁锹就和他父亲一起去了，一个在东边开始修，一个从西面开始修。
模块划分
于老师将整个项目分为两个模块：
东海岸———————————_——————————————西海岸
于谦 ———————————_——————————————于谦父亲
按他的设想，这样分后面做起来肯定没问题，碰面了再将两段隧道的口子对在一起，但他低估了对口子的难度。事实上这种分法很糟糕。
一是分的粒度太大！这导致了双方无法准确的预估工作量。合同上的工期一定不会准确。
二是项目进度难以估计，畅想这个场景。
美国人：谦儿哥，现在项目进度如何？
于谦：现在具体到哪儿不知道，就看见个牌子写着“拉斯维加斯”。
美国人：那多久能修通呢？
于谦：不知道呀，先修修看，迟早有碰面那一天。
三是开发过程中于谦和他父亲每天的计划无法制定，比如事先说好每天修 1 里地，第一天海底淤泥比较少，谦大爷用铁锹挖的快一点，挖了 1.2 里，第二天珊瑚礁比较多，挖的很慢，挖了 0.5 里，那第三天要挖多少才能把项目周期赶回来呢？
那么，如果让小宝给谦大爷划分项目，该怎么分呢？
假设东西海岸有这些城市：
旧金山、奥克兰、圣何塞，拉斯维加斯，洛杉矶、长滩、圣迭戈，加利福尼亚（需求列表）
将城市分段归大类：(模块划分)
- 旧金山–奥克兰
- 奥克兰–圣何塞
- 圣何塞–拉斯维加斯
- 拉斯维加斯–洛杉矶
- 洛杉矶–长滩
- …
这样，这几大类都可以各自动工了，但这样有个问题，假设第一条隧道还没修到 奥克兰，第二条隧道已经开始修了。它的起点就是奥克兰，它需要从第一段的最后开始修起，后者依赖前者（模块间耦合了）。
小宝想了个好办法，他规定了每一段隧道的起点坐标和终点坐标（接口），这样各个隧道间不会有依赖关系（解耦），各自内部开工（内聚）。
还没完，拿 旧金山–奥克兰 这段路举例子，它还是有些大，我们还需进一步分类（细化扩展）。按照距离和海底环境又分成了好多小段。
对于模块划分，我们尽量做到 高内聚，低耦合。对于大模块可以继续细分成多个小模块。
一切皆需解耦
类、模块、函数或方法
前后端联调
mock
微服务
技术路线
当模块细分好之后，于大爷和他父亲扛着铁锹来到了旧金山海岸，发现了一个致命的问题：他们不会游泳！
所以扛着铁锹挖隧道，不是个好的技术选型。
在之后他们修隧道没碰面，显然他们的接口文档也非常之烂。
小宝稍微一检索，就发现，修海底隧道有前人干过（废话），选了条技术路线：
利用盾构掘进机在地层中推进，它前方的原型刀盘可以切割土石。且它操作简单（易用性），厂家有钱，提供支持（稳定性）。
星星牌传送带可以用来运送土石。比月亮牌传送带面积大，单位时间内运送量上升。（性能）
星星牌机器人可以安装隧道管片，且于大爷用过它（重视经验）
星星牌卫星手机信号好，通话质量佳，可以随时随地同步项目进度（接口文档）
项目开工了，有工人反映，盾构掘进机一秒内的切割量是 200 斤，但星星牌传送带一秒内的传送量是 190 斤，这就造成了少量土石被直接抛在传送带底部，工人时不时的要去清除。（开发规范的定制）
所以在进行技术路线选型时，我们要考虑以下几点：易用性、稳定性、性能、经验、开发规范的定制……
实现思路
模块的整合
流程图
龙哥的草图
技术难点
ppt
项目风险
项目排期
模块划分实例
猎才通：
- A： 首页
- B：项目管理-我的项目-新建
项目管理-我的项目-项目创建成功
项目管理-我的项目列表
项目管理-我的项目详情页 - C： 项目管理-人才管理
项目管理-人才推荐 - D：找人才
-人才库
-我的人才库
-简历详情页(有预览状态和编辑状态两种)
需求评审提前