说到软件工程，大家第一时间就会想到大学的《软件工程》的课程，这还是本科就读专业的名字。我印象中最清楚的就是里面各种UML图，刚开始会觉得书中的知识点都是瞎扯淡的内容。随着“珍妮弗”的数量日渐稀少，越来越能体会书中的各种奥义所在。这篇就是想总结下这几年四处挖坑的软件工程上的实践经验。 作者在现在的公司经历了数个软件产品(系统)从0到1的令人回(ku)味(bi)的研发过程。不过幸好这些产品现在都还活的不错，且业务还在持续扩张）。从中深深感受到软件研发属于一项极其复杂且要求精密的系统工程，如果没有精确的项目管控、研发管理等一系列相关领域配合，是很难做到精确把控软件开发流程，保证大项目交付的。关于系统工程的比较通用的就有实践：需求分析、功能分析和分配、设计综合、系统分析、验证和确认、控制，这些实践不但止适用于软件产品工程应用，同样对其他工业产品工程。
1. 软件产品的项目环境
首先我们了解下软件产品研发整体项目环境，就拿目前正在负责的产品线就是从2B招投标市场走出来的产品，所以软件产品研发所在项目环境就有可能直接决定软件产品的规划方向以及投入的资源，目前有3种用于指导项目成功完成的基本管理工具，第一种是项目总体规划, 识别组织角色和职责、要执行的任务以及预期结果。第二种是总体的的时间表、里程碑、评审和决策点。最后一种是总体预算，识别分配给每个组织团队来确保计划任务执行的资源。其中整体项目环境如下图所示， 可看到软件产品研发与项目管理、企业管理等密切相关，软件产品还需要满足相关客户、用户的诉求。
2.软件产品分解结构
要真正掌握一种软件产品的意义或本质，就一定要了解它的结构，有许多术语可以用来识别组成产软件产品的构建模型或元素，包括函数、程序、应用程序和对象等，普遍用术语“组件”来描述产品的软件分解结构，其中组件指的是一个部分、成本或者一个更大部分的组成部分，组件也被定义为一种组装，“软件单元”代表了软件产品中最初被组装的软件组件中的可分离、独立的基础元素或成分。一个软件的典型分解结构如下所示。
通过结构分解视图我们可以看到，其实开发一个软件也就是像一个建筑师解释房屋的设计一样，建筑工作中的其他方面都超出了房屋设计本身。必须还要考虑定位房子的结构、与街道联通、水电安装以及污水排放等一系列的问题，并且对于架构的总体性能和准确性来说都是完善的。这些外围因素必须在软件开发中得到解决，包括在产品发布、交付、安装和部署之后如何维护软件茶品。其实系统工程分支已经给出了一个完整的产品和过程开发概念来解释产品的并行工程和生命周期维护的概念，当这种模式应用于软件时，它将获取与开发后过程相关的外围因素。
3.通用的软件开发模型
大家熟知的如瀑布、快速原型、螺旋开发等开发模型中，可以发现软件开发是一直遵循着一系列的阶段，最基本的一套阶段包括了需求分析、设计、编码和测试。软件开发的这种简单表示方式与大多数的工程管理方法都类似 ，软件开发阶段与方法会随着软件产品相关的规模、复杂性以及开发成本而不断改进或变化。将软件开发与项目管理方法、过程开发的标准相匹配将会生成一个开发框架（通常说的”套路“)。这个框架中会有一系列的阶段、里程碑和评审，意在更好地把控软件开发流程，降低不可控因素造成的影响。在这里只对该开发框架中的重要开发阶段、评审节点进行说明。
3.1 需求定义阶段
项目团队和相关用(客)户的交互来收集、分析和优化关于待开发的软件产品的一系列的需求和期望，需求说明书是在产品交付时，准备用来介绍已确定的产品功能、特性和特征的文件资料。在开发后的软件维护过程中，最初的一组需求可以在产品说明或者一个或多个相关说明中获得。
**产品需求评审:**在于确保软件产品需求足够明确，并评估相关的开发资源、软件需求的说明、技术计划、工作进度表是否合理。
**软件需求评审:**通过涉众和项目管理代表来评审软件需求说明，并且收集关于需求、产品要求、开发后的软件维护概念以及下一阶段的研发计划的反馈。
3.2 概要架构定义阶段
在这一开发阶段中，团队通过进行功能分析与分配，为软件产品了建立一个功能架构。应该做好多个技术实现方案调研，做好充分的方案对比与风险评估。同时，要准备好领域模型、主页业务数据流设计图、以及初始的数据字典等，并定义开发后的软件维护过程（正常版本迭代过程），并且这些都需要记录在的一个或多个过程规约文档中。
概要架构评审: 该评审的重点在于软件产品的功能架构和初始结构化配置技术评审涉及软件开发团队和关键涉众，目的在于评估概要架构定义，以确保它充分满足软件需求和涉众需要，并且是简单的，可以用已确定的软件开发资源实现的。
部署策略评审: 部署策略评审是一项关于软件部署方法的技术性评审,该方法包括产品复制、包装、发布以及必要时的安装和设置。比如我们的是有软硬件产品的，硬件设备的app采用ota方式发布，后台软件采用云部署的策略。
3.3 关键架构定义阶段
在这一开发阶段中，开发团队通过进行综合的软件设计，为软件产品建立了物理架构 。可选的结构化设计的应利用软件分析方法中用于执行风险评估和权衡分析的的方法来评估和比较。开发后的软件维护过程在这一阶段进行设计和记录。
详细架构评审: 是一项完整软件架构的技术型评审，目的是确保架构解决方案已经为概要设计评审做好准备。
**部署设计评审:**是一项关于软件部署过程设计和实现方案的技术性评审，制定所需要的基础设施和人员来支持该过程。
关键设计评审:是一项项目级的评审，通过各个相关方来评审软件的物理架构，收集关于功能定义、性能配置、行为、数据定义、功能性说明以及下一阶段开发计划的反馈。
3.4 软件单元编码和测试阶段
在这个开发阶段，软件实现团队准备进行单元设计执行同行评审，根据接受的同行评审，接下来单元设计会针对结构单元说明进行编码和测试。
3.5 软件组件的集成和测试阶段
在这个开发阶段， 软件开发团队会针对结构化组件、集成组件进行测试，并且根据集成测 试的结果决定是否进行进一步的集成工作。
3.6 验收测试阶段
在这个开发阶段，完成的产品要根据测试方案和程序进行测试。在软件不满足制定需求的情况下，都需要对软件产品进行缺陷矫正，或提出偏差申请或者放弃该产品。偏差表示对于一个软件产品的已知缺陷的暂时接受。偏差的目的在于允许对带有已知需求缺陷的软件产品进行发布或部署。
4.敏捷驱动的软件开发模型
敏捷驱动的软件开发模型是最近几年比较火的概念，目前我们的软件团队也是遵循着敏捷开发的通用流程规范，经过前面的介绍，大家可能对软件开发流程有比较清晰的认识了，敏捷开发遵循以下的重要原则：个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。下图展示是我们团队正在使用的敏捷迭代的流程，其中的计划/任务/发布看板都用jira软件来管理。
4.总结
啰嗦了这么多，其实也是对自己对软件产品的研发过程的一个体悟，主要分享几个重要点：“**一定一定一定要分清需求优先级”，”多产品线多版本的并行迭代时要注意好资源(人与环境)的 分配与隔离“，“要强调交付和质量精神”，“要预留充足的发布缓冲时间”，”一定要开好复盘会议"。这些都是真实踩过的坑。总而言之，**一个优良的软件研发流程可以获得以下优势:
1.减少产品交付时间。合理利用软件开发的资源损耗，减少后续扩展和昂贵的返工周期;
2.更好地降低风险。能让我们对风险、成本、进度、性能的影响有一个更好的认识，可以在方法和流程上降低潜在风险;
3.提高产品和开发过程的质量。团队合作和管理可以为产品和开发流程的改善提供支持，为相关企业和涉众提供产品和流程的质量。
