在软件开发中，企业通常会同时进行基线和定制两种开发方式。为了制造高质量的产品，需要遵循一套成熟的产品研发过程体系。如果出现多个项目的情况，需要合理安排基线和定制之前的里程碑，让基线产品能够尽可能收集用户的通用型需求，为定制项目提供技术支持，减少重复工作和成本，提高产品的质量和效益。产品研发过程体系还需要根据业务实际时间要求变化，不必拘泥于一定要按照瀑布方式或敏捷方式进行管理。
本文以基线产品开发过程为例，介绍该过程的阶段和注意事项，在项目执行前要明确各个阶段的目标、指定计划、及时沟通，并确保各个时期所有成员对项目理解一致。
项目启动会是一个重要的会议，旨在明确产品开发项目的目标和计划。目标和计划是相辅相成的，目标指导计划，计划的有效性影响着目标的达成。因此，在执行目标时，需要考虑清楚自己的行动计划，以更有效地完成目标。否则，目标越是不清晰或过高，都会影响项目的实际结果。
在项目启动会上，可以讨论以下内容：
1.目标明确：明确项目的目标和期望结果，以便确定项目的方向和重点。
2.项目范围：确定项目的范围和边界，包括所需资源、时间和预算等。
3.项目计划：根据目标和范围制定项目计划和时间表，分配任务和责任。
4.团队沟通：建立团队沟通机制和流程，并确保团队成员之间的沟通畅通。
5.风险管理：识别潜在的风险和障碍，并制定预防和应对策略。
6.项目评估：建立项目评估机制，定期审查项目进展和成果，以及提出改进建议。
在项目启动会后，每个人都需要考虑自己的行动计划，以确保目标的有效实现。此外，在计划执行过程中，需要不断监测项目进展和成果，并调整计划以适应变化。
用户需求是指用户对产品或服务的需求和期望。这些需求可以是明确的或隐含的，可以是功能性的或非功能性的，可以是必需的或可选的。用户需求对于产品或服务的设计、开发和改进都非常重要，因为它们直接影响产品或服务的质量和用户体验。
用户需求可以通过多种方式获得，包括：
1.用户调研：通过问卷、访谈、焦点小组等方式，收集用户对产品或服务的需求和期望。
2.市场分析：通过市场调查、竞争分析等方式，了解用户对产品或服务的需求和市场趋势。
3.数据分析：通过分析用户行为和反馈数据，了解用户对产品或服务的使用情况和需求。
4.原型测试：通过原型测试，收集用户对产品或服务的反馈和建议，以改进产品或服务的设计和功能。
用户需求对于产品或服务的设计和开发非常重要，因为它们决定了产品或服务是否能够满足用户的需求和期望。如果产品或服务不能满足用户的需求，用户可能会选择其他产品或服务，从而影响产品或服务的市场竞争力和盈利能力。因此，了解用户需求并将其融入产品或服务的设计和开发过程中是非常重要的。
产品需求是指对于某个产品的功能、性能、设计、用户体验等方面的需求和期望。产品需求是产品设计和开发的基础，也是产品与用户之间的桥梁。通过产品需求的明确定义和管理，可以确保产品能够满足用户需求，同时也可以确保产品的质量和用户体验。。
产品需求规格说明书和产品需求矩阵是产品需求管理的两个主要工具。产品需求规格说明书是一份详细的文档，描述了产品的功能、性能、设计、用户体验等方面的需求和期望。产品需求矩阵则是一种结构化的表格，按照子系统、功能集、执行单元的结构列出所有的功能需求，每列则对应每项功能的工作步骤以及每个步骤的工作量。产品需求矩阵通常包括以下几个方面：
功能需求：产品需要具备的功能和特性，包括产品的主要功能和次要功能、交互设计和用户界面等。
性能需求：产品的性能指标和要求，包括产品的速度、响应时间、稳定性、可扩展性等。
设计需求：产品的外观和设计要求，包括产品的颜色、形状、材料、图标等。
用户体验需求：产品的用户体验要求，包括产品的易用性、可访问性、可用性、可靠性等。
安全需求：产品的安全要求，包括数据安全、用户隐私、网络安全等。
产品需求矩阵对于产品设计和开发非常重要，它可以帮助团队了解产品的需求和期望，并将其转化为具体的开发任务和工作量。通过产品需求矩阵，团队可以更好地进行工作计划和任务分配，同时也可以更好地进行进度跟踪和优先级调整。
需求评审后，开发和测试负责人，分别编写技术方案和测试用例。
技术方案评审，开发负责人拉上涉及到其他系统的负责人一起讨论，技术方案中必须要有业务流程图和时序图，业务流程图是为了梳理开发对业务的理解，是否和需求一致。时序图是了梳理本次需求涉及的系统交互。技术方案评审通过后，确认工作量和交付时间，反馈给产品。
设计阶段的目标主要是对待开发系统的构架进行分析和设计，并建立系统构架的基线，以便为之后的实施工作提供一个稳定的基础。
设计阶段包括了系统架构的输出，一个好的系统架构设计可以帮助人类梳理业务逻辑且抓住核心需求，设计稳定可扩展的业务系统，评估业务开发周期和开发成本，有效的规避风险。例如盖房子的时候得有建筑图纸，有了图纸，才能核算施工周期。
总体设计是整个系统的框架型设计，意义及其重大，一般情况下不能省略（只有维护项目可以省略总体设计，因为基准项目已经设计完毕），所有的产品开发项目均需要首先进行总体设计，它是设计首要步骤，决不允许本末倒置，不能出现先编码后设计的情况，这是软件开发的第二大痛点（第一大是需求不明确、任意变更需求！）。
总体设计分为三个阶段：
第一阶段：初始设计。在对给定的数据流图进行复审和精化的基础上，将其转化为初始的模块结构图。
第二阶段：精化设计。依据模块“高内聚低耦合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口。
第三阶段：设计复审阶段，对前两个阶段得到的高层软件结构进行复审，必要时还可能需要对软件结构做一些精化工作。
概要设计是软件开发过程中的一个关键阶段，其主要目的是描述系统的每个模块的内部设计，同时承上启下，对总体设计和详细设计进行衔接。
概要设计按照结构化设计方法进行设计。其基本思路是将软件系统逐级细化，分解为不必再分解的模块，每个模块完成一定的功能，为一个或多个父模块服务，同时也接受一个或多个子模块的服务。模块的概念与编程语言中的子程序或函数是对应的。
包括系统分解、模块任务分配、模块间调用关系和接口的确定，以及性能和可靠性的考虑。这些任务的完成有助于团队更好地理解系统的功能和结构，为后续的详细设计和实现工作提供指导方向。
在概要设计阶段，设计者需要考虑并照顾模块的内部实现，但不过多纠缠于此，主要集中于划分模块、分配任务、定义调用关系。同时，设计者需要制定十分细致明确的模块间接口和传参规范，编写严谨的数据字典，避免后续设计产生不解或误解。
此外，概要设计一般不是一次就能做到位，而是需要反复进行结构调整。典型的调整包括合并功能重复的模块，或者进一步分解出可以复用的模块。在概要设计阶段，设计者应尽可能地提取可以重用的模块，建立合理的结构体系，以节省后续环节的工作量。
概要设计文档是软件开发过程中重要的一个文档，主要内容包括分层数据流图、结构图、数据字典以及相应的文字说明等。这些内容有助于团队更好地理解系统的整体结构和模块之间的关系，为后续的详细设计和实现工作提供指导方向。根据概要设计文档，各个模块的详细设计就可以并行展开了。
详细设计阶段依据概要设计阶段的分解，主要任务包括确定模块的输入输出，设计模块内的算法和流程，描述模块的功能，考虑性能和可靠性等。要把功能描述转变为精确的、结构化的过程描述这些任务的完成，有助于团队更好地理解每个模块的功能和任务，为后续的实现工作提供指导方向。
在详细设计阶段，可以将各个模块分配给不同人员并行设计，每个设计者的工作对象是一个模块。设计者需要依据概要设计的要求，设计并表达出模块的算法、流程、状态转换等内容。需要注意的是，如果需要进行结构调整，必须回到概要设计阶段反应调整，而不是就地解决。详细设计文档对于团队的开发非常重要，其中最重要的是模块的流程图、状态图、局部变量及文字说明等内容。每个模块都应该对应一篇详细设计文档。
在软件开发中，概要设计阶段通常会产生软件结构图，而详细设计阶段则常用流程图、N-S图、PAD图、伪代码等方式描述具体模块的处理流程、开发方法和编码技巧。通常，详细设计包括项目简介、模块说明、接口设计、数据结构设计、特殊处理等几个部分。其中，模块说明会具体说明每个模块的流程、功能、逻辑、消耗以及未解决的问题；接口设计则包括内部接口和外部接口；数据结构设计则包括物理结构和逻辑结构。通过详细设计，软件系统的各个部分的具体设计方法、逻辑和功能得以采用文字方式表述。在实现的过程中，编码人员应该严格按照详细设计进行代码实现。
编写代码可以遵循以下几点原则：
先做核心模块的压测：在开发过程中，对于核心模块的设计和实现，就要考虑到系统面临的业务压力和请求重心，这样才能准确地模拟出实际的运行情况，从而测试系统的性能和稳定性，并发现和解决可能存在的问题。这样做可以及早发现潜在的性能问题，避免在上线之后出现严重的性能问题，从而降低了系统运行过程中的风险。
确保过程可控：代码执行过程中保持中间的输出是一个很好的习惯。这样可以在代码运行的过程中随时了解程序的运行状态，比如处理了多少数据，执行了多长时间，是否有错误等等。这些信息可以帮助开发人员更好地了解代码的执行情况，及时发现问题并进行调试和优化。同时，对于较大的数据处理任务，及时输出处理状态信息也可以让用户了解任务的进度和状态，提高用户体验。
多打日志：多打日志是一个很好的习惯，可以帮助开发人员在代码执行过程中了解程序的运行状态，以及发现和解决问题。同时，留下注释也是一个很好的习惯，可以帮助开发人员更好地理解代码的设计和实现，以及理解开发人员的思路和想法。在实际编写代码时，可以在关键的代码段或处理逻辑处增加日志输出，以便在代码出现问题时可以更好地进行定位和排查。同时，留下注释也可以帮助其他开发人员更好地理解代码的实现和设计思路，以便在需要修改或扩展代码时更加容易进行。
简单易懂的逻辑：代码的逻辑应该尽量简单明了，易于理解和维护。如果代码的逻辑过于复杂，就会给其他开发人员带来困难和不便，使得代码难以维护和修改
不要沉迷于框架：框架是为了提高开发效率和代码复用性而设计的，但是过度依赖框架可能会导致代码的复杂性和难以维护性增加，从而影响代码的质量和性能。
使用熟悉、成熟的技术：新技术虽然可能具有一定的优势和特点，但是也可能存在一些未知的问题和风险，如果不了解其优劣势和适用范围，就可能会导致代码质量和性能的下降。同时，还需要考虑团队的技术水平和经验，以便更好地掌握和应用技术。在选择新技术时，需要尽量避免盲目跟风和跟从市场热点，而是要根据实际需求和场景进行选择。
众所周知，在团队中进行代码审查（Code Review）可以提升代码质量，分享项目知识、明确责任，最终达到构建更好的软件、更好的团队。
通过代码审查，可以及时发现和纠正代码中存在的问题，提高代码的可读性、可维护性、可扩展性和安全性，同时也可以促进团队成员之间的交流和合作，提高团队的协作效率和项目的质量。
在进行代码审查时，需要遵循一定的规范和流程，例如选择合适的审查工具和方式、明确审查的目的和标准、制定审查计划和时间表、分配审查任务和责任、记录审查过程和结果等等。同时，需要注意审查的方式和态度，避免过于苛刻或过于宽容，以及避免过度批评、指责或攻击团队成员。
要认识单元测试，首先要明白什么是“单元（Unit）”。所谓“单元”指的是代码调用的最小单位，实际上指的是一个功能块（Function）或者方法（Method）。所以单元测试指的就是对这些代码调用单元的测试。
单元测试是一种白盒测试，就是必须要对单元的代码细节很清楚才能做的测试。所以，单元测试的编写和执行都是由软件工程师来做的。相对于单元测试，还有集成测试。集成测试基本都是黑盒测试，主要是由测试人员根据软件的功能手册来进行测试，需要有专门的测试环境配合。集成测试又分功能测试、回归测试等。
需要单元测试的代码实际上是开发人员自己写的逻辑，测试逻辑所依赖的环境是否正常不是单元测试的目的。在环境访问代码中引入逻辑，只会让逻辑更难测试，导致逻辑代码无法进行单元测试。因此，可单元测试的代码，才能够采用单元测试。判断可测试的代码还有一个方法，就是看这个方法能否用一个 main 函数直接运行，如果可以的话就是可单元测试的代码。可测试的代码还有另一个特征，就是该方法单元的参数，开发人员可以自由模拟，不需要依赖外部环境。
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的借口是否正确。它根据集成测试计划 ，一边将模块或其他模块组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。也可以理解为在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元、功能模块接口、链接等）进行的联合测试，以决定他们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。
系统测试阶段包括系统测试方案及用例编写、功能性测试、性能测试、稳定性测试。
为了验证需求分析确定的功能是否齐全并被正确实现，同时还要对安装、部署、适应性、安全性、界面等非功能性需求进行测试。系统测试也有测试人员负责，应该在需求分析完成后进行设计，在集成测试完成后进行实施。
功能性测试
一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。在经过以上各阶段测试确认之后，把系统完整地模拟客户环境来进行的测试。系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。
性能测试
验证系统的稳定性和效率，检查系统是否满足规定的性能要求。性能测试通常选择一些典型的功能，检验这些功能在大量用户同时使用系统时系统是否稳定。性能测试由测试人员负责，可以在系统测试完成后进行，也可以对重要模块先进行性能测试，可以贯穿整个测试周期，目的是尽早发现系统的性能瓶颈并提早解决。
稳定性测试和性能测试都必须等到系统基本没问题、趋于稳定时再进行才有效果，否则很难顺利测下去，出现异常也不能定位究竟是系统架构的问题，还是功能上的缺陷。
稳定性测试（亦可称可靠性测试）
通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为 7x24 小时），检测系统是否能够稳定运行。
产品发布是系统测试结束后的最后一步，通常在软件产品开发过程中不需要产品试制环节，可以直接上线，只需要系统测试员输出系统测试报告并批准产品发布（上线）就可以了。
产品发布前需要通过产品发布说明会形式，对整个产品开发过程从立项开始回溯过程，指出整个过程中的不足点，总结经验，为下一个项目提供经验案例。这一会议可以通过正式会议形式召开，需要召集产品经理、主要开发人员、测试人员、上级领导等参与，准备充分，尽最大可能说清楚这个产品发布之后的效果、效益，为上线后的价值评估做准备。这一环节不可缺少，即便在互联网公司，迭代速度很快的情况下，这一环节也需要满足。
其实开发过程体系里并没有这一过程，但是我个人认为它非常重要。
所有的总结，只有带着问题去思考才会有收获，这就是复盘。不论我说多少，如果没有过类似的经验，就很难有很强的共鸣。我觉得看清一个问题最好的方式，就是你曾经处在一个问题的两个不同的角色中。
总结项目经验教训的目的，在于总结问题、分析原因，避免以后犯同样的错误，而不是追究谁的责任。
假设一个需求理解的缺陷，如果在需求阶段发现，修改一下可能只要一个小时，但是如果到了设计完成时发现这个缺陷，因为涉及的人员、文档增多，估计要一天时间，而如果等到代码都编写完成时才发现这个缺陷，可能需要十天八天了。如果缺陷没被发现，而是直接到了生产系统中呢？这就不是工作量的问题了，估计损失就难以估计了。在质量管理的理论中，缺陷每延迟一个阶段被发现，修复的代价就要乘上十倍。
敏捷开发、极限开发等等模型是为了解决需求不明确、时间紧迫情况下的快速迭代，而不是为了从根本上否定研发流程，该设计还是要设计，只是将生命周期进行切分，将过程横向切分为若干个周期。软件开发是一门工程性要求很严谨的学科，让我们坚持严谨的态度、高效的工作方式，打造高可用、高质量的软件产品。
更多新闻