软件开发流程✍（笔记）

软件开发流程

基本流程：

​ 需求 - 粗评 - 细评 - 概要设计 - 详细设计 - 设计评审 - 开发 - CR自测 - 提测 - 测试 - 集成测试 - 产品验收 - 发版申请 - 发版 - 复盘 - 收益回报

需求（必须）

1. PRD（product requirement document）

产品需求文档是前期所有产品设计工作的最终集合，涵盖框架、逻辑、角色、权限、页面、策略等

封面—>PRD修改记录—>目录—>项目背景和项目目标—>系统框架图—>产品流程图—>角色与权限对照表—>功能详述—>验收校准

PRD怎么写

• 梳理产品的结构框架，让研发了解核心的功能分布以及层级结构。
• 设计产品的使用流程，让研发了解用户的行为走向。
• 角色和权限的定义，了解全量角色以及角色对应的权限情况。
• 拆解原型图，为每一页原型图标注策略和交互上的文字说明（在这个过程中，研发同学可以结合前期给出的框架，流程和角色，来对照这个部分的详细说明进行开发）。
• 最后说清楚验收标准，在上线之前产品经理与研发同学要基于这套验收标准来评判该项目是否严格按照产品经理给出的需求来实现的。

PRD的作用

• 为视觉设计师和交互设计师提供参考。

• 为开发工程师提供逻辑参考：基础评估->技术评审->投入开发。

• 为测试工程师提供验收参考。

• 需要由浅至深、由大到小、事无巨细地把整个产品项目描述清楚。

  2.需求说明（详细）

编写目的：软件需求说明书是需求分析阶段的文档，是对软件目标及范围的求精和细化，深入描述软件的功能和属性以及软件的约束范围，便于用户和软件开发者对软件的输出规定有了大概了解，有利于对项目的回溯和后续开发和维护。

主要内容包括：

需求说明通常包括以下内容：

1. 问题陈述：对当前问题或需求的简要叙述和背景说明。
2. 功能需求：对产品所需实现的功能的具体描述，可以使用用例、流程图、时序图等方式来阐述，更好地表达功能之间的关系和流程。
3. 非功能需求：包括性能要求、安全要求、可用性要求等非功能性方面的需求。
4. 用户界面设计：对产品的界面进行详细的设计说明，包括布局、交互方式、视觉风格等。
5. 数据需求：对所需处理和存储的数据进行详细说明，包括数据格式、数据来源和数据处理要求等。
6. 约束和限制：对项目或产品的时间、预算、技术限制等进行明确约定。
7. 验收标准：对需求的验收标准进行明确定义，以便项目团队和相关利益相关方一致对产品的质量进行评估和验证。

基本目录结构

• 引言（编写目的、背景、定义、参考资料等）
• 任务概述（目标、用户特点、假定和约束）
• 需求规定（对功能的规定、对性能的规定、输入输出要求、数据管理能力要求、其他要求）
• 运行环境规定（设备、支持软件、接口、控制）

粗评（非必须）

1. 产品方向把关

在需求说明中，产品方向的把关是指对产品定位、目标用户、核心功能等方面进行评估和确认。

2. 市场价值和预期收益评估

在需求说明中，进行市场价值和预期收益是为了评估产品的商业可行性 和潜在收益。这个过程需要进行市场调研、竞争分析和用户调研，以了解目标用户和竞争环境，宠儿更精确地评估产品的市场潜力和预期收益。

3. 技术实现选型评定

在需求说明中，对技术实现选型进行评定时为了确定适合产品需求的技术解决方案。这个过程需要考虑因素包括技术架构，开发成本，开发周期，团队技能等，已选择最合适的技术方案来支持产品的实施和开发过程。

细评（必须）

1. 数据交互

数据交互是指在系统、应用程序或网络服务中，数据在不同组件、模块、用户之间进行传递、共享和交流的过程。

在应用程序或网站的上下文中，数据交互通常包括：数据输入（通过设备输入）、数据处理、数据输出、数据传递。

2. 界面展示
3. 用户体验
4. 其他

概要设计（研发）

（非必须）

1. 在宏观架构中的位置
2. 对宏观架构的影响
3. 工程结构

详细设计（必须）

1. 逻辑运行图

展示各个组件之间的交互管理和信息流动。可以描述系统的工作流程，展示模块之间的依赖关系和执行顺序。

2. E-R图

一种图形化方式，用于表示系统中的实体之间的关系，它描述了实体的属性和实体之间的联系，以及关系的类型和约束条件。

3. 业务逻辑伪代码

一种用于描述业务逻辑的伪代码表示方式，使用类似编程语言的语法，但不是具体的编程代码。他能清晰的表达业务逻辑的流程、条件和操作，帮助开发人员理解和实现系统的逻辑功能。

4. 接口文档

米哦啊哈俗了系统接口和接口的使用方式。它包括接口的参数、返回值、调用方式、错误处理等信息，帮助其他开发人员理解如何与系统进行交互，并正确使用系统提供的功能。

5. 类、包结构

类和包结构用于描述系统的代码组织结构。类结构描述了系统各个类之间的关系和依赖关系，包结构描述了类的组织方式，以模块化和层次化的方式组织代码，增加代码的可管理性和可拓展性。这有助与开发人员理解代码的组织结构，并提供清晰的代码结构指导。

设计评审（必须）

• 设计评审要经过部门大多数人的认可开发（必须）

1. 代码规范，接sonar等检测工具

确保代码的可读性、可维护性、稳定性和安全性非常重要。

代码规范：

• 遵循一直的命名约定，使用有意义的变量和函数名
• 使用适当的缩进和格式化，使代码更易读
• 编写注释，解释代码段的意图和关键细节
• 避免冗余和重复的代码，使用函数和类来模块化抽象复杂的逻辑
• 强制使用合适的设计模式和最佳实践

2. 自测，写UT

UT：单元测试（Unit Test）

自测：

• 对于编写的代码尽可能全面地测试各种不同的情况和输入。包括正常情况、边界条件和异常情况。
• 针对代码的每个函数、方法或模块尽量覆盖所有可能执行路劲和分支
• 可以使用打印日志调试工具或断言语句来验证代码的正确性
• 借助测试工具和框架，进行手动测试和自动化测试

编写单元测试步骤：选择单元测试框架>编写测试用例>设置测试环境>调用被测试代码>验证结果>运行测试>检查测试失败结果>重复上述步骤。

开发（测试+产品）

Code Review

代码审查是一种对代码进行系统性检查和评估的行为，末地石发现潜在的问题，改进代码质量并提供反馈。代码审查有助于减少错误和缺陷，提高代码质量，并促进团队协作和知识共享。代码审查应该是一种合作和建设性的过程，只在提高整体团队的技术水平和代码标准。

• 明确目标：在CR之前确保明确审查的目标和标准，明确检查的内容和期望的结果。
• 代码可读性：检查代码可读性，命名、格式、注释、确保其他开发人员能轻松理解和维护代码
• 编程规范：检查代码是够遵循使用语言的编程规范
• 功能正确性：去报代码输出符合预期，并处理便捷情况和异常情况
• 性能和效率：是否存在明显的性能问题和潜在的资源浪费
• 可冲永兴和模块化：确保代码可以在不同环境中重复使用，并且抑郁维护和拓展
• 错误处理和异常处理：确保代码能够适当的处理错误，并提供用户友好的错误信息
• 测试覆盖率：确保测试用例涵盖各种场景并验证代码的正确性
• 安全性：确保代码没有潜在的安全漏洞，如跨站脚本攻击、SQL注入等
• 维护性和可扩展性：审查代码的结构和设计，确保代码易于修改和添加新功能

提测

​ 提测时指软件或应用程序提交给质量保证团队或测试团队进行测试的过程。

​ 在提测前，代码必须经过review。需求评审通过后，QA（Quality Assurance，质量保证）第一时间撰写冒烟CASE（基本功能测试或验证测试），并提交给相应的研发，研发自测的最低要求时覆盖冒烟CASE。

​ 冒烟测试：也称为基本功能测试或验证测试，是在软件进行较大规模测试之前进行的一种初步测试。冒烟测试的目标是验证软件的基本功能是否能够正常工作，以便于在更深入的测试之前及早发现严重的问题。

QA接到提测申请后，先跑冒烟，冒烟不通过拒绝本次提测；

同一功能，连续多次冒烟不通过打回，QA可直接向项目管理者反馈

基本步骤：

• 确认开发完成：开发团队确认软件的开发工作已经完成，并且已经解决了软件所有一直缺陷
• 准备测试材料：包括软件部署包、配置文件、测试用例等
• 说明需求和变更：提供详细的需求和变更说明，以便于测试团队了解软件的预期功能和改动部分
• 提交测试申请
• 环境准备：质量保证团队或测试团队准备测试环境，包括软件的部署、配置和必要的测试数据准备
• 执行测试
• 缺陷跟踪和修复

测试（必须）

QA必须撰写全面地TEST CASE，TEST CASE的覆盖场景要经过全方位的评审，最大限度地保证不会漏测场景

集成测试

集成测试是软件开发过程中的意向关键测试活动，旨在验证多个组件、模块或子系统在集成后的功能和性能。其目标是确保各个组件之间的接口和协作正常，整体系统能够按照预期工做。

• 发版之前的验证，主要测试新旧功能之间的衔接情况

进行集成测试步骤：

1. 制定集成测试计划：确定测试目标、范围和策略。制定测试计划包括确定测试阶段、定义集成顺序、制定测试用例和测试数据等。
2. 准备测试环境：搭建针对集成测试的环境，包括安装和配置必要的软件、硬件和网络环境。确保测试环境与最终生产环境尽可能接近，以更准确地模拟真实场景。
3. 确定集成顺序：确定组件之间的集成顺序，以保证依赖关系的正确性和稳定性。通常，先集成最基础的组件，逐步集成更高级别的组件，直至最终形成完整的系统。
4. 编写集成测试用例：根据需求和设计文档，编写集成测试用例，覆盖各个模块和组件之间的接口和交互。测试用例应包括正常情况下的测试以及边界情况、异常情况的测试。
5. 执行集成测试：按照测试计划和测试用例，执行集成测试。测试团队运行测试用例，验证组件之间的正确连接、数据传递和功能协作。记录测试结果，并及时报告和修复发现的缺陷。
6. 问题解决和修复：如果在集成测试过程中发现问题，测试团队和开发团队应该进行合作，追踪和解决这些问题。修复后的代码需要重新进行集成测试，确保问题已经得到解决。
7. 验证集成系统性能：除了功能验证之外，集成测试还应包括对整个系统的性能进行评估。这可以包括性能测试、负载测试和压力测试等，以确保系统在预期负载下能够稳定运行。

产品验收

发版申请（必须）

1. RD提出发版申请，指明本次发版的影响范围
2. QA确认版本号已经测试情况，附带测试报告
3. RD在提出申请时，要填写发版必须的check list

发版

1. 发版人员事先准备好发版SOP，严格按照SOP进行操作。
2. 发版完成后，QA要做线上主流程回归，确保本次上线不影响主业务。
3. 发版过程中出现问题，第一时间回滚，然后在线下找问题。
4. 控制发版频率

复盘

项目完成后总结得失，为下一次迭代积累经验

收益汇报

1.是对产品价值的体现

2.是对产品方向的肯定