针对软件研发流程，我总结出的流水线生产方法论

2016-05-09  杨税令  聊聊架构

目前看到大家分享了各种新技术和各种优秀的管理方法，但是唯独在关于开发与实施工艺上没有人分享，这相当于士兵上战场打仗前装备了各种先进武器，军师制定了各种战术布了各种妙局，但唯独没有告诉士兵如何到达战术位置，百谋而一疏。更像缺少了心法修炼的练武之人，有其形而无其势，永远成为不了高手，这也是为什么那么多公司使用了很先进的开发工具基于很优秀的框架依然做不好产品的原因。

今天我们就来分享一下，做一个好产品，架构师需要哪些心法，需要什么样的设计工艺。

背景介绍

这个我们需要先从产品的生命周期说起。在移动应用爆发之前，一个软件产品的寿命往往是7年，移动应用爆发之后缩短到了十个月，很多产品还没到过年就看不到了，在这么短的时间内产品还要经历上百个版本的迭代，这对于开发来说是一个很大的挑战。为了赶上进度，很多团队是需求一提出来马上就进入开发，甚至小版本直接在生产环境中进行开发和测试，并把这种开发称为“敏捷开发”。

快速迭代，这对于功能性的互联网应用没有太大的问题，但是很多互联网金融团队照猫画虎利用“敏捷开发”进行金融产品的研发，实在是让人不可思议，多少客户的资金莫名其妙被盗，多少公司被挤兑，多少产品提前死亡。

在一个产品生命周期中共有七大工序，每一次的迭代都要经历这七个工序，上述类团队为了缩短开发进程实际裁减了很多工序，比如分析与设计，直接从需求进入开发，这是很多产品不断出现用大坑填小坑的办法解决问题的直接原因，而大家会把这两个阶段忽略掉，除了工作量的原因，往往是不清楚这两个阶段能带给我们什么，认为只要梳理清楚了需求中需要的功能点就可以了。

除此之外部分原因是不知道这两个阶段该如何高效进行。我们通过总结以往的经验，结合海内外的先进开发工序，提炼出了一套五级实施工艺，从五个层级：应用、组件、活动、任务、步骤逐层为这七个阶段的实施保驾护航。

首先这套工艺以明确产品目标为前提。对于不知道自己的产品要做成什么样的团队，就相当于不知道谁是敌人的士兵一样，纵有千般本领也无处施展。我们首先来分享一下我们梳理的一个完整产品生命周期的五级工艺：

以上就是我们开发一个产品所要经历的工序，这些工序就是告诉士兵如何准时准确安全地到达战术位置，从而更好地把军师制定的战术优势发挥出来，开发中就是把产品要达到的效果、架构设计的特性、框架提供的性能都发挥出来。

没有这些步骤就可能出现猪一样队友的囧况，比如架构设计了多重加密保证用户数据不被篡改，结果前端开发人员为了方便，将前端获取到的用户编号传回后端，直接作为业务中用户的识别标识直接使用，从而导致各种安全设计形同虚设，我相信遇到过这种情况的同学不在少数。

我们今天分享这一套工艺，就是为了避免产品中出现这种情况，让业务中的开发没有机会出现这种情况，即使出现这种情况也无法通过下一个工序，即使通过下一个工序也不会暴露到最终用户那里，即使暴露到用户那里也不会对产品整体造成影响。为了避免话题扩散，我们今天专注于分享系统分析这部分，也就是架构设计的关键部分。

分析阶段就是系统设计阶段，这个时候往往产品经理或者业务人员已经确定好要实现的业务目标，在这个过程中主要有四个活动：

• 项目分析

• 应用分析

• 架构设计

• 实施分析

一、项目分析

该活动中主要有三大任务：

1、确定产品目标和范围

实施管理员是执行人，参与人还有领域架构人员、企业建模人员、业务人员、应用设计人员、组件设计人员、应用集成设计人员，可以是一人共担多个角色，但是这些角色是要有的，它可以帮您梳理清楚接下来的步骤。

在这个工序中，主要有以下步骤：

1. 针对业务需求确定产品目标和业务效果；

2. 分析需求涉及到的系统建设现状和当前整体实施情况；

3. 规划实施范围；

4. 最后要输出产品分析报告，其中要包括产品实施目标、业务效果、范围、非功能约束。

2、架构分析

这里主要是确定架构与应用的解决方案。实施管理员依然是执行人，参与人还有企业建模人员、业务人员、应用设计人员、组件设计人员、应用集成设计人员、数据集成设计人员、领域架构人员。

在这个工序中，基于在产品分析步骤中输出的产品实施目标、业务效果、范围、非功能约束作为输入条件。包括以下步骤：

1. 分析上下文关系；

2. 分析应用架构；

3. 分析数据架构；

4. 分析技术架构；

5. 分析安全架构；

6. 提出应用解决方案的概要设计；

7. 最后输出架构解决方案和应用解决方案。

3、实施分析

这里主要是要确定实施方案。实施管理员依然是执行人，参与人还有企业建模人员、业务人员、应用设计人员、组件设计人员、应用集成设计人员、数据集成设计人员、领域架构人员。

在这个工序中，主要有以下步骤：

1. 通过明确产品实施策略，提出相关系统协同实施方案；

2. 提出业务过渡期方案；

3. 提出初步系统改造和数据迁移方案；

4. 制定产品里程碑计划和资源需求；

5. 最后输出产品立项分析报告

二、应用分析

该活动中主要有四大任务：

1、功能需求分析

业务人员与实施管理员为执行人，参与人还有企业建模人员和应用设计人员。

在这个工序中，承接上一步的立项分析报告作为输入，包括以下步骤：

1. 列出并确认产品范围内的活动流程、产品任务列表；

2. 建立业务事件与活动任务的映射关系；

3. 列出现有系统已实现的功能列表；

4. 建立与每个业务任务及其步骤的映射关系；

5. 针对业务需求分析现有功能对应需求的支持情况，给出差异及其差异处理说明；

6. 确定现有系统功能可完全匹配需求的业务任务列表，形成业务迁移功能需求列表；

7. 确定被现有系统部分满足的，系统改造功能需求列表；

8. 确定现有系统功能没有实现的业务任务列表，作为新增业务功能需求；

9. 确定现有系统已实现，而业务需求没有提出或小于现有系统功能实现的业务任务列表；

10. 最后输出功能需求分析报告。

2、实施效果分析

参与人与上一步一致，在这个工序中，主要有以下步骤：

1. 列出产品范围内的目标业务能力列表；

2. 列出应用和组件需求定义的业务任务列表；

3. 针对每一条目标业务能力匹配业务任务的定义，分析两者之间的吻合程度给出问题列表；

4. 针对问题从问题对应的业务功能对业务制度的支持程度、业务价值、实施就绪程度、系统实施复杂度、产品实施进展要求等方面进行分析，分析问题对目标业务能力实现的影响；

5. 针对上面的分析结果，从保证产品的业务实施效果出发，得出问题解决的优先程度，并提出现实可行的问题解决方案；

6. 对于需要在当期产品中体现的任务建立补充需求列表；

7. 最后输出实施效果分析报告。

3、协同业务还原分析

参与人与上一步一致，在这个工序中，主要有以下步骤：

1. 列出并确认产品范围内涉及协同业务的业务活动列表；

2. 还原协同业务，生成协同业务各种变化组合的业务活动流程；

3. 针对每个业务活动流程模型，从业务条件、流程步骤、业务决策、角色、事件等方面，分析各个活动流程之间的差异；

4. 从应用实现的角度考虑对流程进行聚类，从实施出发在充分考虑现有后台服务系统的现状；

5. 据差异分析的结果生成还原协同业务后的活动流程列表；

6. 对每个还原协同业务后的活动流程用流程图的方式进行描述，并保持内容完整性；

7. 标识业务活动流程中受协同业务影响的业务任务；

8. 最后输出协同业务还原分析报告、业务活动流程图、业务任务定义。

4、体验需求分析

业务人员与用户提现界面设计人员为执行人，参与人还有用户体验建模人员和实施管理员。

在这个工序中，主要有以下步骤：

1. 列出并确认产品范围内的任务列表；

2. 确定人机交互界面需求；

3. 确定人机交互界面客户体验设计模式；

4. 提供每个人机交互界面的样式；

5. 确定人机交互界面外部输入输出类型、名称、样式或文件格式；

6. 确定人机交互界面输入输出内容详细字段信息；

7. 建立用户体验建模框架；

8. 确认用户人机交互界面需求分析结果符合业务需求；

9. 最后输出用户体验需求分析。

三、架构设计

该活动中主要有六大任务：

1、分析上下文

领域架构人员为执行人，参与人还有应用设计人员、组件设计人员、应用集成设计人员、数据集成设计人员。在这个工序中，主要有以下步骤：

1. 列出本产品相关系统及子系统清单；

2. 分析并确定与本产品子系统相关的外部环境；

3. 针对产品相关系统描述各个系统在总体架构中的功能定位，在产品中需实现的功能及对其它子系统提供的服务，及在非功能需求实现中所起的作用；

4. 用上下文关系图描述本产品与外部环境的关系；

5. 描述本产品与各个子系统之间的关系；

6. 最后输出上下文关系与架构决策。

2、分析应用架构
参与人与上一步一致，在这个工序中，主要有以下步骤：

1. 定义产品应用架构，说明应用组件在各逻辑层的分布、具体含义和之间的关系；

2. 根据架构设计原则来优化或调整产品应用架构；

3. 列出产品所使用应用组件及公共组件的清单；

4. 最后提出架构决策，输出应用架构与架构决策。

3、分析数据架构

参与人与上一步一致，在这个工序中，主要有以下步骤：

1. 分析产品实施范围；

2. 分析文件传输的路径和策略；

3. 分析数据创建范围；

4. 分析数据应用模式；

5. 分析数据存储策略；

6. 分析数据分布；

7. 最后提出架构决策。

4、分析技术架构

参与人与上一步一致，在这个工序中，主要有以下步骤：

1. 分析并明确应用及组件的生产部署模式；

2. 应用与组件的功能和数据的部署分析；

3. 分析并选择使用的技术架构服务；

4. 定义运营节点视图；

5. 最后提出架构决策。

5、分析安全架构

参与人与上一步一致，在这个工序中，主要有以下步骤：

1. 从身份认证、敏感信息保密、访问控制、数据安全、安全审计监控、基础设施安全等纬度，分析产品应用中涉及的安全需求；

2. 根据安全架构的安全策略管理要求及应用场景管理要求，针对产品的安全需求，设计相应的安全方案，描述各产品安全管理策略的落实方式；

3. 分析产品应用中对安全子系统及现状安全子系统的依赖关系，描述与安全子系统的上下文关系；

4. 最后提出架构决策。

6、典型交易线设计

参与人与上一步一致，在这个工序中，主要有以下步骤：

1. 参考前期典型交易场景的应用解决方案，选取对产品整体架构有至关重要应用的交易功能；

2. 依据交易线应用模式说明和数据应用模式说明，识别和选择典型交易解决方案的应用模式，并明确其中各相关组件的功能定位及所需提供的服务；

3. 以图的形式表达交易线的设计成果，其典型交易线的设计场景并集应覆盖外部产品相关应用组件、技术组件、数据组件、及安全组件的关键功能组件；

4. 最后输出典型交易线设计；

四、实施分析

该活动中主要有两大任务：

1、分析应用监控指标

实施管理员为执行人，参与人还有企业建模人员、业务人员、应用设计人员、组件设计人员、应用集成设计人员、数据集成设计人员、领域架构人员。

在这个工序中，主要有以下步骤：

1. 由应用设计人员根据其在分析阶段的成果，参照技术架构提供的应用监控指标列表，完成这些监控指标值的范围分析；

2. 由实施人员审核，包括应用监控指标是否全面、合理；

3. 应用设计人员根据反馈结果完成非功能指标的完善和最终确认；

4. 最后输出应用监控指标。

2、分析非功能指标

实施管理员为执行人，参与人还有实施人员、运维人员、应用设计人员、安全架构人员、应用架构人员。在这个工序中，主要有以下步骤：

1. 由应用设计人员根据其在分析阶段的成果，参照技术架构提供的应用非功能指标数据，完成指标值范围的分析，在这个过程中需要注意应结合运营节点视图，将一些指标做适当分解；

2. 由实施人员及安全架构人员审核，包括指标值是否合理、当前的技术架构服务的容量是否满足等，如果容量不满足，需要执行何种流程进行扩容；

3. 应用设计人员根据反馈结果完成非功能指标的完善和最终确认；

4. 最后输出非功能指标和约束、应用非功能指标调研表、组件非功能指标列表；

总结

到这里，架构设计的关键阶段系统分析就算完成了。这个阶段输出的成果将成为下一步细化设计的基础。使用“五级工艺”的工序来进行设计开发，开发出的可能不是最新潮的产品，但一定不是一个低级和有明显缺陷的产品。

我的公众号（微信搜索“杨税令”）里的金融系统设计文章基本上都是按照这个工序来写的，大家可以作为示例参考一下，比如银行的清算设计等，其中都有包括上下文关系、应用架构、数据架构、技术架构、安全架构、业务线这一系列设计。

您可能会问：对于追求快速迭代需要敏捷开发的产品适用“五级工艺”吗？
答案是适用，有些步骤您可以快速通过，但真不建议省略；但对于互联网金融产品这种有明确业务流程的产品，建议还是认真的走完这些步骤，这些产品与用户的资金息息相关，一个小疏忽便会导致百万级资金的损失，有多少互联网金融公司的客户便是因为技术缺陷导致的信任危机，从而引发集中提现导致兑付危机把公司推向死亡的边缘。

最后，再次建议，学习并内化这套“五级工艺”，它的步骤您可以快速通过，但脑袋里一定要清晰地知道每一步要解决的问题，因为它至少可以避免您的产品死在小问题上。