企业开发软件时会按照基线和定制两块并行方式执行项目开发工作

菏泽炫佑科技

企业开发软件时会按照基线和定制两块并行方式执行项目开发工作

在软件开发过程中，企业在开发软件时，会与基线和定制并行地进行项目开发工作。 无论什么样的公司，都需要遵循成熟的产品开发流程体系，才能生产出更优质的产品。 因此，如果项目较多，应合理安排定制前的基线和里程碑，使基线产品能够收集尽可能多的用户通用需求，为定制项目的进展提供技术支持，减少大量的定制工作。定制项目中的代码更改。 ，需要添加新模块。 另外，产品开发流程体系也需要根据业务的实际时间要求而改变，一切都需要找到适合自己的方式。

我们使用基线产品开发流程作为此处的流程。 项目执行前，必须明确各阶段目标，明确计划，及时沟通，确保各时期所有成员对项目的认识一致。

1、用户需求

在开始开发软件之前，需要确定成本与获得的价值之间的比较，即ROI（On）。 一旦确定需要创建，就需要安排一系列资源来支持软件的生存。 这是对需求*原始的描述。

为什么要同时有用户需求和产品需求？ 产品需求是由用户需求转化而来的技术实现需求。 需要对用户提出的产品目标进行细分，总结每个具体的功能点，然后将每个功能点细分为各个操作流程。 从技术上定义每个操作流程。

用户需求和产品需求很容易产生差异。 这是因为虽然大家都在谈论需求，但出发点可能不同，导致双方的关注点和思维方式不同。 用户需求聚焦于系统如何支持业务流程，底层需求是“实现业务目标”。 技术人员关注的是合理的技术方案，其背后的要求是“工作量”、“实施难度”和“系统性能”。

2、产品需求

我们需要弄清楚产品经理或者项目请求者为什么要做这个项目？ 这是*基本的业务需求。 需求分析确定的业务需求来源于业务需求，必须服务于业务需求。

产品需求通常包括产品需求规格和产品需求矩阵。 产品需求矩阵一般按照子系统、功能集、执行单元的结构列出所有功能需求。 每一列对应每个功能的工作步骤以及每个步骤的工作量。

产品需求写好后，需要进行审查。 在需求评审会上，产品和技术详细评审要求是否完成？ 产品功能的正常使用场景是什么？ 是否形成闭环？ 有哪些不寻常的场景？ 是否深思熟虑？

需求评审后，开发和测试负责人分别编写技术方案和测试用例。 在技​​术方案评审过程中，开发负责人召集其他系统涉及的负责人一起讨论技术方案。 技术计划必须包括业务流程图和序列图。 业务流程图是为了梳理开发对业务的理解，看看是否与需求一致。 序列图就是为了梳理这个需求所涉及到的系统交互。 技术方案审核通过后，确认工作量和交付时间，并向产品反馈。

3、总体设计

设计阶段的主要目标是对待开发系统的架构进行分析和设计，建立系统架构的基线，为后续的实施工作提供稳定的基础。

设计阶段包括系统架构的输出。 良好的系统架构设计可以帮助人类梳理业务逻辑和把握核心需求，设计稳定、可扩展的业务系统，评估业务开发周期和开发成本，有效规避风险。 例如，建造房屋时，必须有建筑图纸。 有了图纸，就可以计算出工期。

总体设计是整个系统的框架设计。 意义重大，一般情况下不能省略（只有维护项目可以省略总体设计，因为基线工程已经设计好了）。 所有产品开发项目都需要首先进行总体设计。 这是设计的**步，绝对不允许本末倒置。 先编码再设计是不可能的。 这是软件开发的第二大痛点（**是需求不明确，随意改变需求）。

总体设计分为三个阶段：

**阶段：初步设计。 基于对给定数据流图的审查和细化，将其转化为初始模块结构图。

第二阶段：精细化设计。 根据模块“高内聚、低耦合”的原则，细化了*初的模块结构图，设计了全局数据结构和各模块的接口。

第三阶段：设计评审阶段，评审前两个阶段得到的高层软件结构，必要时对软件结构做一些细化工作。

4、外形设计

总体设计的目的是描述系统各模块的内部设计，起着总体设计和详细设计之间的纽带作用。

外形设计按照结构化设计方法进行设计。 结构化设计方法的基本思想是：根据问题领域，将软件逐步细化，分解为不需要分解的模块，每个模块完成一定的功能，并服务于一个或多个父级。模块（即接受调用），也接受来自一个或多个子模块的服务（即调用子模块）。 模块的概念对应于编程语言中的子例程或函数。

在概要设计阶段，将软件按照一定的原则分解为模块层次，为每个模块分配一定的任务，并确定模块之间的调用关系和接口。

在这个阶段，设计者会粗略地思考和照顾模块的内部实现，但不要过多关注。 主要是划分模块、分配任务、定义调用关系。 这个阶段应该非常仔细和清晰地制定模块之间的接口和参数传递，并且需要编写严格的数据字典，以避免后续设计中的混乱或误解。 外形设计一般不是一次性完成的，而是反复进行结构调整。 典型的调整是合并功能重复的模块，或者进一步分解可以重用的模块。 在概要设计阶段，应*大限度地提取可复用的模块，并建立合理的结构体系，以节省后续环节的工作量。

概要设计文档*重要的部分是层次化的数据流图、结构图、数据字典以及相应的文字描述等。基于概要设计文档，可以并行地进行各模块的详细设计。

5、详细设计

详细设计阶段是在总体设计阶段分解的基础上，对各模块中的算法和流程进行设计，并对各模块完成的功能进行详细描述，并将功能描述转化为准确、结构化的流程描述。

在详细设计的这个阶段，每个模块可以分配给不同的人进行并行设计。 设计者的工作对象是一个模块，根据设计纲要分配的部分任务和外部接口，设计并表达该模块的算法、流程、状态转换等。这里需要注意的是，如果发现有需要进行结构调整（如分解子模块等），必须返回概要设计阶段，并将调整反映在概要设计文件中，但未经问候无法当场解决。 详细设计文档*重要的部分是模块流程图、状态图、局部变量以及相应的文字描述等。一个模块对应一份详细设计文档。

软件结构图通常在总体设计阶段获得，详细设计阶段常用的描述方法包括：流程图、NS图、PAD图、伪代码等。详细设计的目的是描述处理过程某个模块内部的流程、开发方法和编码技巧。 一般来说，详细设计由项目简介、模块描述（具体说明各模块内部的流程、功能、逻辑、消耗以及未解决的问题）、接口设计（包括内部接口和外部接口）、数据结构设计（包括物理结构及逻辑结构）、特殊加工等部分。 软件的详细设计*终是用文字表达软件系统各部分的具体设计方法、逻辑和功能。 这样，在实现过程中，编码人员就可以严格按照这个原则来实现代码。

6. 编写代码

编写代码可以遵循以下原则：

先做核心模块的压力测试：很多程序员习惯把事情做完，然后等快上线的时候进行性能测试，所以如果之前的设计出现了问题，那就是大问题了。 当然，后面快上线的时候也会做性能测试，但是我觉得前期还是很重要的。 当然，要做好这件事，你需要了解一些业务。 你需要知道业务压力在哪里，业务请求的重点在哪里。 很多时候产品经理不说，但是你要问清楚。

确保过程可控：代码执行时，必须维护中间输出。 例如，每处理10万条日志，就会写入一个状态日志，记录已处理的日志条目数和当前执行时间。

多做日志：很多时候我对代码写的不是很满意，比如某个处理效率不够优化，某个处理方法不够简洁，或者扩展性比较差，代码很费脑子迟钝，但短时间内可能没有办法想出*合理的解决方案。 考虑到这不是*初上线的重点，所以我不会刻意优化它，但在这种情况下，我会经常留下注释，解释下一步优化可能的思路。 或者想到的可行解决方案是什么。

简单易懂的逻辑：不要让自己卷入其中。 时间长了，没人能理解你的逻辑。 如果函数内部的逻辑确实很难完成，请尝试分片。

不要沉迷于框架：框架*大的问题是什么？ 嵌套太繁琐了。 为什么我总是对框架感到恼火？ 因为我们经常会遇到每秒上千个请求的处理场景，所以在调优的时候，我们需要从无数的框架中找到数据处理的逻辑，找到性能卡点。 只改两行代码是可以的，但是要找到问题需要两天的时间。 程序员记住，你的技术能力一定不能受到框架的限制。

使用熟悉且成熟的技术：很多人不了解自己的障碍和问题在哪里，也不知道相关技术产品的优缺点。 在阅读了一堆第三方数据评估后，他们的大脑变得很热，他们学习了新的知识。 那么技术就掉进了坑里，出不来了。 如果是创业公司，项目可能会死在里面。 在使用一项新技术之前，建议充分了解该技术的特点、适用范围、不适用范围。

7. 代码审查

众所周知，在团队中进行代码审查（Code）可以提高代码质量、共享项目知识、明确职责，*终构建更好的软件和更好的团队。

代码审查极其重要。 一般来说，每周应该进行一次代码审查。 首先，代码审查可以帮助您跟踪项目的进度。 我们可以真正看到我们手下的人进展如何，并尽早发现他们是否误入歧途。

8. 单元测试

要理解单元测试，首先必须理解什么是“单元”。 所谓“单元”是指代码调用的*小单元，实际上指的是功能块（）或方法（）。 所以单元测试是指测试调用这些代码的单元。

单元测试是白盒测试的一种，是必须非常清楚单元的代码细节的测试。 因此，单元测试的编写和执行都是由软件工程师来完成的。 与单元测试相反，还有集成测试。 集成测试基本上是黑盒测试，主要由测试人员根据软件的功能手册进行，需要专门的测试环境的配合。 集成测试分为功能测试、回归测试等。

需要单元测试的代码实际上是开发人员自己编写的逻辑。 测试逻辑所依赖的环境是否正常并不是单元测试的目的。 在环境访问代码中引入逻辑只会使逻辑更加难以测试，使逻辑代码无法进行单元测试。 因此，可单元测试的代码可以进行单元测试。 确定可测试代码的另一种方法是查看该方法是否可以使用 main 函数直接运行。 如果是这样，那么它就是可单元测试的代码。 可测试代码的另一个特点是方法单元的参数可以由开发人员自由模拟，而不依赖于外部环境。

9. 集成测试

集成测试也称为组装测试或联合测试。 在单元测试的基础上，根据设计要求将所有模块组装成子系统或系统进行集成测试。 实践表明，有些模块虽然可以独立工作，但并不能保证连接后也能正常工作。 一些无法在本地反映出来的问题，很可能会在全球范围内暴露出来。

集成测试是在软件系统集成过程中进行的测试。 其主要目的是检查软件单元之间的接口是否正确。 它根据集成测试计划，将模块或其他模块组合成一个越来越大的系统，同时运行系统，分析组成的系统是否正确以及各个组件是否配合在一起。 集成测试有两种主要策略：自上而下和自下而上。 也可以理解为将软件设计单元和功能模块组装集成到一个系统中时，对应用系统的各个组成部分（软件单元、功能模块接口、链路等）进行联合测试，以确定其是否能够工作一起。 部件可以是代码块、独立应用程序、网络上的客户端或服务器端程序。

10.系统测试

系统测试阶段包括系统测试计划和用例编写、功能测试、性能测试和稳定性测试。

为了验证需求分析确定的功能是否完整、正确实现，还必须对安装、部署、适应性、安全性、接口等非功能性需求进行测试。 系统测试也是测试人员的职责。 应在需求分析完成后进行设计，在集成测试完成后实施。

功能测试一般由独立的测试团队采用黑盒方式进行，主要测试系统是否符合“需求规范”。 经过以上阶段的测试和确认后，系统完全模拟客户环境进行测试。 系统测试是结合已确认的软件、计算机硬件、外设、网络等要素，对信息系统进行各种组装测试和确认测试。 目的是通过将开发的功能与系统需求进行比较来发现它们。 当系统与用户需求不匹配或矛盾时软件开发，可以提出更完整的解决方案。

性能测试验证系统的稳定性和效率，检查系统是否满足指定的性能要求。 性能测试通常会选择一些典型的功能来检查系统在大量用户同时使用系统时是否稳定。 性能测试是测试人员的责任。 可以在系统测试完成后进行，也可以先进行重要模块的性能测试。 它可以贯穿整个测试周期。 目的是尽早发现系统性能瓶颈并尽早解决。

稳定性测试和性能测试必须等到系统基本良好稳定后才有效。 否则，就很难顺利测试，也无法判断异常是系统架构问题还是功能缺陷。

稳定性测试（也称为可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（通常是7x24小时）来测试系统是否能够稳定运行。

11.产品发布

产品发布是系统测试后的*后一步。 通常，在软件产品开发过程中，不需要进行产品试产，可以直接上线。 系统测试人员只需输出系统测试报告并批准产品发布（在线）。

在产品发布之前，需要回顾一下从立项到产品发布简报的整个产品开发流程，指出整个过程中的不足，总结经验，为下一步的项目提供经验案例。 这个会议可以以正式会议的形式召开，需要召集产品经理、主要开发人员、测试人员、上级领导等参加，做好准备，并把这个产品的效果和好处解释为发布后尽可能清晰，以便评估上线后的价值。 准备。 这个链接是不可或缺的。 即使在迭代速度很快的互联网公司，这个环节仍然需要满足。

12. 开发流程审核

其实这个流程在开发流程体系中是不存在的，但是我个人认为非常重要。

所有的总结只有带着问题去思考才能得到。 这是回顾。 不管我说多少，如果没有类似的经历，很难产生强烈的共鸣。 我认为清楚地看待问题的*好方法是你在问题中扮演过两个不同的角色。

总结项目的经验教训的目的是总结问题企业开发软件时会按照基线和定制两块并行方式执行项目开发工作，分析原因，避免以后再犯同样的错误，而不是追究任何人的责任。

假设需求理解有缺陷，如果在需求阶段就发现了，修改起来可能只需要一个小时，但是如果在设计完成时才发现缺陷，估计就需要一天的时间，因为涉及的人员和文件增加。 这个缺陷当时才发现，可能需要十八天的时间。 如果没有发现缺陷，而是直接进入生产系统怎么办？ 这不是工作量的问题，估计损失也很难估计。 在质量管理理论中，缺陷每延迟发现一次，修复成本就会增加十倍。

敏捷开发、极限开发等模式是为了解决需求不明确、时间紧张时的快速迭代，而不是从根本上否定研发流程。 设计还是要设计，但是生命周期是划分的，流程是横向的。 分为几个循环。 软件开发是一门具有严格工程要求的学科。 让我们坚持以严谨的态度和高效的工作方法打造高可用、高品质的软件产品。

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等