下载掌阅APP，畅读海量书库
立即打开
研发过程中需要解决的核心问题是领域工程和应用工程的业务需求沟通、体系结构的设计和交付可重用的组件，为了更好地借助领域工程和应用工程分离实现可变性管理，研发过程中也需要借助一些成熟的研发方法，包括需求的结构化描述方法、参考“4+1”视图和四色原型法进行体系结构设计、软件持续交付的方法与规范、行为驱动的软件测试方法，以及业务可变性分析的方法等。
需求分析是软件工程中的一个关键过程，也是一个复杂的过程。需求的管理与各个应用的特征密切相关，同时还涉及非功能性需求及其与功能性需求的错综复杂的关系。需求需要方方面面的人员参与，业务部门是需求的发出者，需求分析人员是需求的接受者，开发人员是需求的执行者，只有三方人员对需求的理解达成一致才能开发出成功的软件产品。但这三种人员由于背景知识不同、擅长的领域不同，通常不能完整、正确地了解对方领域的知识，再加上沟通的不充分，最终导致需求理解存在偏差。
举个简单的交易前检查的例子：
· V1.0：必须是登录的用户才可以进行交易；必须是未惩罚、未冻结的用户才可以进行交易。
· V1.1：海外登录的用户IP不能是“XX.XX.XX.XX”。
· V2.0：金额大于1000元需要短信验证码确认，单日限额10000元。
· V2.1：短信验证金额、单笔限额、单日限额可以由用户调整……。
· V2.5：转账给曾经转账用户小于2000元无须短信认证……。
· V3.0：购买行内理财产品仅需输入密码确认；购买三方理财产品需要短信验证……。
· V4.0：久眠户交易必须增加实名认证和生物识别，且金额大于500元需要审批。
一般需求描述方法随着迭代周期的延伸，最终流程图复杂到我们无法一目了然地找到需求切入点。如果需求人员都不知道该在哪里加需求，谈何设计和开发呢？
因此，如何对业务需求进行准确的传递至关重要。用结构化的表达方式来描述需求，统一项目相关方对于需求的理解，是保证需求被正确理解的重要方式。为了更好地支撑业务中台的标准化、端到端、柔性的业务流程建设，我们需要一套需求结构化方法，从产品、架构、需求、设计、开发、测试等多角色的全链路视角，建立标准化的信息描述语言和可复用标准，打造跨越业务、需求、设计的需求结构化管理与沟通协作方法。
一个软件的架构要涵盖的内容非常多，很难一蹴而就，因此多采用分而治之的办法从不同视角分别设计。目前软件架构设计常用模型就是视图模型，可以从多个角度描述一个复杂的软件系统，分而治之下一个架构视图是从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体，这为软件架构的理解、交流和归档提供了方便。1995年，Philippe Kruchten在 IEEE Software 上发表了题为 The 4+1 View Model of Architecture 的论文，引起了业界的极大关注，并最终被RUP采纳。该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途，如图3-2-5所示。
图3-2-5 “4+1”视图
· 逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块等。
· 开发视图：描述软件在开发环境下的静态组织。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系，比如逻辑层一般会映射到多个程序包等。
· 运行视图：描述系统的并发和同步方面的设计。运行视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题，同开发视图相比，运行视图比较关注的正是这些运行时单元的交互问题。
· 部署视图：描述软件如何映射到硬件，反映系统在分布方面的设计。部署视图关注目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器上，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。和运行视图相比，部署视图重视目标程序的静态位置问题，是综合考虑软件系统和整个IT系统相互影响的架构视图。
运用“4+1”视图方法可以针对不同需求进行架构设计，“4+1”视图模型实际上使得有不同需求的人员能够得到他们对于软件体系结构想要了解的东西。系统工程师先从部署视图，然后从运行视图靠近体系结构；最终使用者、客户、数据专家从逻辑视图看体系结构；项目经理、软件配置人员从开发视图看体系结构。
“4+1”视图可以全面阐述中台建设的体系结构，运用“逻辑视图”讲述中台分解方式、模块层次关系、依赖关系；运用“运行视图”讲述应用系统内外的运行期交互模式，柔性价值等；运用“部署视图”讲述中台进程在机器上的安装部署，并和网络等配合满足软件系统的可靠性、可伸缩等要求。运用“开发视图”讲述开发视角的组织管理形式、技术框架支撑等。运用“关键过程”讲述业务中台的研发交付机制。
四色原型是领域模型的一种原型，领域中的任何模型及其关系都可以抽象为“四色原型”。四色原型可以用这句话进行描述：某个人（Party）的角色（PartyRole）在某个地点（Place）的角色（PlaceRole）用某个东西（Thing）的角色（ThingRole）做了某件事情（MomentInterval）。
（1）时刻-时间段原型（Moment-Interval Archetype）：表示在某个时刻或某一段时间内发生的某个活动。使用粉红色表示，简写为MI。
（2）参与方-地点-物品原型（Part-Place-Thing Archetype）：表示参与某个活动的人或物，地点则是活动的发生地。使用绿色表示。简写为PPT。
（3）描述原型（Description Archetype）：表示对PPT的本质描述。它不是PPT的分类！Description是从PPT抽象出来的不变的共性的属性的集合。使用蓝色表示，简写为DESC。
（4）角色原型（Role Archetype）：角色就是我们平时所理解的“身份”。使用黄色表示，简写为Role。
四色建模是建立在UML基础之上的一种新型建模方式，在建模过程中需要按照四个步骤来完成业务领域的建模工作：
（1）分析业务流程，确认流程中的关键名词，抽象出业务实体。
（2）从用例入手，找出其中的红色。
（3）找出其中的相关元素。
（4）细化每一个类的方法和属性。
这四种类型不仅规定了各种类的属性和方法，而且也蕴含了不同原型间的典型交互方式。通过彩色编码不仅有利于开发组中各种人员的沟通，而且还可以加深开发人员对领域问题的理解，从而保证开发可以按照分析阶段的领域模型正确地进行开发。
采用中台架构后，各业务系统将从原来一个巨石型系统发展为大量的服务，服务可以独立部署与发布，降低了系统耦合度，水平扩展能力得到显著提高，但也带来交付与运维复杂度增加的问题。中台建设需要建立持续交付的方法与规范，将需求、设计、开发、交付、运维的过程协同与配合，用于促进应用开发、技术运营和质量保障各职能之间的沟通、协作与整合，通过优化开发（DEV）、测试（QA）、运维（OPS）的流程，使开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
首先需要建立敏捷的项目管理方法。敏捷的项目管理方法以需求进化为核心，采用迭代、循序渐进的方法进行软件研发管理。项目不再采用瀑布式的模式，而是被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。分布式应用让应用、服务、数据、感知都可以独立发布、部署、运行，可以把一个大的业务系统项目分为多个相互联系但可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。支撑平台支持这种敏捷的项目管理方法，帮助业务系统研发团队管理需求与设计，建立需求、设计与开发、测试的关联，分配任务并跟踪进度，有效整理与跟踪出现的问题，对团队行为进行记录，通过看板方式可视化团队活动，提高各业务系统项目的项目管理水平。
其次要建立持续集成能力。持续集成可帮助业务系统的研发团队经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，支撑平台连接统一的代码库，调用研发人员编写的编译脚本、自动化测试用例进行自动构建与自动测试，通常每次代码递交后都会在持续集成服务器上触发一次构建，可以在模拟生产环境中自动测试。研发人员需要保证每次构建都要100%通过，每次构建都可以生成可发布的产品。持续集成有利于检查缺陷，了解软件的健康状况，减少了代码编译、数据库集成、测试、审查、部署及反馈中的重复劳动，同时对功能完成度和缺陷率等项目的状态自动产生有效的报告，提高了软件研发的质量。
最后要实现一键式部署与持续交付。业务系统开发过程中，往往存在多个环境，包括开发环境、测试环境、预发环境、性能测试环境、生产环境，研发人员需要将代码、配置、类库等部署到多个环境中，遇到问题需要回退到前一个状态，手工操作是一个非常烦琐的过程，通常研发人员会编写部署脚本进行一些自动化的操作，但是这些脚本又缺少规范与管理，无法成为统一、一致的行为。通过支撑平台，研发人员可以自定义部署过程，实现一键部署、一键供应、一键创建新环境，环境的创建可以通过一条命令或一键点击的方式创建，减轻运维人员的负担，避免错误，缩短业务系统上线的周期。一键式部署让持续交付成为可能，通过更频繁的自动化部署，业务系统新上线的功能可以尽可能快地呈现在用户面前，并能在一定的时间内从用户处获得尽可能多的反馈，根据反馈更快速地对新业务功能进行调整，从而加快业务系统交付的速度，适应业务变化。
传统软件研发模式的问题在于业务人员把业务需求描述给软件需求分析人员之后，软件需求分析人员按照自己的理解编写软件需求规格说明书，然后研发人员根据软件需求规格说明进行软件架构设计和编写软件代码，最后测试人员根据软件需求规格说明书编写测试案例进行测试。由业务需求到软件编码，再到软件测试的过程中，不同角色和不同人员在不同时段对软件开发所需的信息进行处理，这中间有太多可能的机会丢失、弄错甚至直接忽视业务人员的原始需求。软件研发的众多环节中，只要有一个环节出错，软件研发团队就很难按时交付出符合业务人员要求的软件产品。
行为驱动开发（Behavior Driven Development，BDD）是一种敏捷软件开发的方法，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。应用在自动化测试中也可称为行为驱动测试。BDD借鉴了敏捷和精益实践，让敏捷研发团队尽可能理解产品经理或业务人员的产品需求，并在软件研发过程中及时反馈和演示软件产品的研发状态，让产品经理或业务人员根据获得的产品研发信息及时对软件产品特性进行调整。BDD帮助敏捷研发团队把精力集中在识别、理解和构建跟业务目标有关的产品特性上面，并让敏捷研发团队能够确保识别出的产品特性被正确设计和实现出来。
BDD的软件研发过程是这样的：
产品经理（业务人员）通过具体的用户故事使用场景来告诉软件需求分析人员他（她）想要什么样的软件产品。使用软件产品的使用场景来描述软件需求，可以尽可能地避免相关人员错误理解软件需求或增加自己的主观想象的需求。
软件需求分析人员（BA）和研发团队（研发人员、测试人员）一起对产品经理（业务人员）的用户故事进行分析，并梳理出具体的软件产品使用场景举例，这些场景举例使用结构化的关键字自然语言进行描述，例如中文、英文等。
研发团队使用BDD工具把用户故事场景文件转化为可执行的自动化测试代码，研发人员运行自动化测试用例来验证开发出来的软件产品是否符合用户故事场景的验收要求。
测试人员可以根据自动化测试结果开展手工测试和探索性测试。
产品经理（业务人员）可以实时查看软件研发团队的自动化测试结果和BDD工具生成的测试报告，确保软件实现符合产品经理（业务人员）的软件期望。
BDD并不是一种软件研发方法，也不是用来替代Scrum、XP、看板等现有的敏捷理论和方法，而是把现有的工作方法融合起来，让软件研发团队更加高效地工作，从而减轻因软件产品计划延误或功能缺失带来的压力。