面向对象应用框架 02
Nite工程发布周期方法论 (Engineering Release Cycle Methodology - ERCM)
ERCM 是一种用于管理软件开发和发布流程的结构化方法。它定义了从产品概念到最终发布的各个阶段、里程碑和角色职责。
关键术语定义:
- PRD: 产品需求文档 (Product Requirements Document)
- SPEC: 规格说明书 (Specification)
- CC: 代码完成 (Code Complete)
- CF: 代码冻结 (Code Freeze)
- ER: 工程发布 (Engineering Release)
- PM: 产品经理 (Product Manager)
- EM: 工程经理 (Engineer Manager)
- DEV: 开发人员 (Developer)
- QA: 质量保证 (Quality Assurance)
- FVR: 功能验证报告 (Feature Validation Report)
核心理念:
- QA 团队不仅是测试者，也参与到项目的前期阶段（如需求和设计评审）。
- QA 团队需要专注于执行，确保产品质量。
PRD (产品需求文档)
PRD (Product Requirements Document) 是一份详细的清单，描述了产品必须具备的功能。它在整个软件开发项目中作为关键的参考点。通常，PRD 由产品经理 (PM) 根据客户的真实需求来撰写和定稿。在 PRD 的创建阶段，工程经理 (EM) 和开发工程师 (DEV) 会参与其中，仔细审查文档并指出潜在问题。随后，当 PRD 生成后，质量保证 (QA) 工程师会加入对 PRD 的审查，报告他们发现的任何问题。所有检测到的问题将由 PM、DEV 和 QA 团队共同讨论，并根据达成的共识对 PRD 进行修改。PRD 审查结束后，所有相关方——PM、EM、DEV 和 QA——都应对产品需求有统一的理解。
SPEC (规格说明书)
SPEC (Specification) 是关于产品设计和运营的详细技术描述。一旦 PRD 确定下来，EM 就会根据 PRD 进行 SPEC 的设计。在 SPEC 中，每个客户的需求都根据 PRD 进行了细致的阐述，包括每个功能的设计、组件之间的逻辑关系、产品界面风格等。SPEC 设计完成后，PM、DEV 和 QA 团队会协作评审该文档，检查其中是否存在潜在的设计缺陷或遗漏。EM 会讨论提出的任何疑虑，并基于这些对话进行后续修订。一旦 SPEC 设计最终确定，DEV 将根据 SPEC 设计开始开发文档，QA 则开始构建测试计划和测试用例。
测试计划 (Test Plan) 与测试用例 (Test Case)
测试计划 (Test Plan) 的设计阶段由 QA 工程师牵头。在 SPEC 内容最终确定后，QA 工程师开始创建测试计划。与此同时，开发工程师开始编码过程。
在测试用例 (Test Case) 设计阶段，QA 工程师也负责以 SPEC 为指导文件来创建测试用例。这个过程几乎与测试计划的设计同时进行。与此同时，开发工程师会对他们编写的代码进行单元测试 (Unit Tests)。
代码完成 (Code Completion - CC)
当产品 SPEC 最终确定后，即启动代码完成 (Code Completion - CC) 阶段，开发工程师开始编码过程。在 CC 阶段，所有的代码设计都应最终完成，并且代码的单元测试也应完成。
代码冻结 (Code Freeze - CF)
最后是代码冻结 (Code Freeze - CF) 阶段。在代码完成 (CC) 后，测试工程师开始测试周期。通常，经过两到三轮的测试迭代，大部分产品问题都会被发现。一旦所有已识别的产品缺陷都得到纠正并符合 CF 标准，任何进一步的代码修改通常都是被禁止的。在需要修改代码的特殊情况下，必须执行严格的流程控制，以防止回归问题 (regression problems) 的发生。 解释：回归问题指的是修复一个 bug 或添加新功能后，导致之前正常工作的功能出现问题。
软件需求 (Software Requirements)
软件需求的三个层次
- 商业需求 (Business Requirements): 这些需求反映了组织或客户对一个系统或产品的高层次目标。它们在项目视图和范围文档中有详细说明。
- 用户需求 (User Requirements): 这些需求在描述用户必须使用产品完成的任务的文档中有详细说明，如用例文档或场景脚本所示。
- 功能需求 (Functional Requirements): 这些需求定义了开发者必须实现的软件功能，使用户能够完成他们的任务，从而满足商业需求。
软件工程中的需求视图
解释：该图展示了从不同利益相关者的视角（执行官、开发者、客户）如何产生不同类型的需求（商业、用户、功能/非功能），并最终汇总成统一的软件需求规格说明书 (SRS)。
软件需求的主要内容
- 概述 (Overview): 本部分描述了软件的用途，定义了其范围，介绍了相关的缩写或首字母缩略词，引用了参考文件，并对文档内容进行了全面概述。
- 总体描述 (General Description): 本部分对提议的软件产品进行了总体描述，讨论了其预期效果、提供的功能以及其潜在用户的特点。
- 具体需求 (Specific Requirements): 本部分包括详细的规格说明，例如：
- 功能需求 (Functional Requirements): 突出软件应执行的基本操作。
- 可用性需求 (Usability Requirements): 详细说明确保用户友好界面和体验的方面。
- 可靠性需求 (Reliability Requirements): 强调软件需要保持一致的性能以及从故障中恢复的能力。
- 性能需求 (Performance Requirements): 规定了对软件速度、响应能力、资源使用等方面的期望。
- 可支持性需求 (Supportability Requirements): 阐述了软件的可维护性和可扩展性的条件。
- 设计约束 (Design Constraints): 这些是可能影响软件设计的限制。
- 用户文档和帮助文件需求 (User Documentation and Help Files Requirements): 定义了用户手册或指南以及在线帮助文件的预期内容、格式和功能。
- 支持组件的采购需求 (Purchase Requirements for Support Components): 指定支持软件所需的任何第三方组件。
- 接口需求 (Interface Requirements): 指明软件应如何与其他系统、硬件或软件进行交互。
- 支持信息 (Supporting Information): 本部分包含之前各节未涵盖的任何额外需求，可能包括法律要求、合规性考虑或特定的质量属性。
软件需求的主要特性
- 清晰性 (Clarity): 软件需求应精确、无歧义且易于理解。它们应明确规定软件应做什么，不给误解留下任何空间。
- 完整性 (Completeness): 需求应全面，涵盖软件的所有功能和约束。不应留下任何未解决的方面。
- 一致性 (Consistency): 需求应连贯且无冲突。如果不同需求之间出现任何冲突，必须在需求规格阶段解决。
- 可测试性 (Testability): 每个需求都应是可验证的，意味着应该有一种方法来测试该需求是否已得到满足。
- 可追溯性 (Traceability): 可追溯性指的是在需求整个生命周期中追踪它的能力，从其起源，经过开发和规格说明，到其后续的部署和使用。
- 可行性 (Feasibility): 需求应该是可达成的，意味着它们应该可以用可用的资源和技术来实现。
- 可修改性 (Modifiability): 由于软件项目经常会发生变化，需求应灵活且易于修改，以适应潜在的调整和变更。
- 优先级排序 (Prioritized): 并非所有需求都同等重要。一些需求对业务来说比其他需求更为关键。因此，需求应该被排序或划分优先级。
- 无歧义性 (Unambiguity): 每个需求必须只有一种解释。它必须用清晰简洁的语言编写，能被技术和非技术利益相关者理解。
- 已验证 (Validated): 软件需求应被检查其在待开发系统中的有效性和适用性。这包括与所有利益相关者进行验证，以确保系统将满足他们的需求和期望。
软件工程的卡诺模型 (Kano Model of Software Engineering)
卡诺模型是一个用于产品开发和客户满意度理论的模型，它将客户偏好分为五个类别。在软件工程中，它常用于对需求进行优先级排序。
- 阈值/基本属性 (Threshold/Basic Attributes): 客户认为产品“理所当然”应该具备的属性。如果不满足这些需求，客户会非常不满意；但即使满足了，客户也不会因此感到更满意。
- 性能/期望属性 (Performance/One-dimensional Attributes): 这些属性与客户满意度成正比。提供的越多，客户就越满意。例如，更快的处理速度。
- 激励/魅力属性 (Excitement/Attractive Attributes): 这些是客户意想不到的惊喜功能。如果存在，它们会带来极大的满意度；但如果不存在，客户也不会感到不满。随着时间的推移，激励属性可能会转变为性能属性，甚至基本属性。
软件需求规格说明书 (Software Requirements Specification - SRS)
SRS 是一份全面描述待开发软件系统预期功能和行为的文档。它是开发团队、测试团队、项目经理和客户之间沟通的桥梁。
推荐视频：如何编写软件需求规格说明书
软件需求分析的主要目标
- 识别和理解用户需求 (Identify and Understand User Needs)
- 文档化需求 (Document Requirements)
- 避免误解 (Avoid Miscommunication)
- 验证和确认 (Validation and Verification)
- 需求优先级排序 (Prioritization of Requirements)
- 促进系统设计 (Facilitate System Design)
- 为测试和验证提供基础 (Basis for Testing and Validation)
- 规划未来需求 (Plan for Future Needs)
- 成本和时间估算 (Cost and Time Estimation)
- 为项目规划和管理提供基础 (Basis for Project Planning and Management)
- 最小化返工 (Minimize Rework)
软件需求分析的过程
- 需求启发或收集 (Requirement Elicitation or Gathering)
- 需求分类和组织 (Requirement Classification and Organization)
- 需求优先级排序 (Requirement Prioritization)
- 需求文档化 (Requirement Documentation)
- 需求验证 (Requirement Validation)
- 需求评审和批准 (Requirement Review and Approval)
- 需求基线和管理 (Requirement Baseline and Management)
- 需求可追溯性 (Requirement Traceability)
软件工程的需求管理
需求管理是一个持续的过程，贯穿整个软件生命周期，确保项目满足利益相关者的需求。
软件可行性 (Software Feasibility)
可行性分析是在项目启动前进行的一项评估，旨在确定项目是否值得进行。它帮助利益相关者做出明智的决策，避免资源浪费。
可行性分析的目标
- 评估项目可行性 (Evaluating Project Viability)
- 风险识别 (Risk Identification)
- 成本效益分析 (Cost-Benefit Analysis)
- 识别需求 (Identifying Requirements)
- 决策制定 (Decision Making)
- 资源分配 (Resource Allocation)
- 避免失败 (Avoiding Failures)
- 投资合理性论证 (Investment Justification)
- 奠定基础 (Building a Foundation)
- 降低风险 (Reducing Risks)
可行性分析的类型
- 技术可行性 (Technical Feasibility): 评估组织是否拥有实现项目所需的技术资源和专业知识。
- 经济可行性 (Economic Feasibility): 进行成本效益分析，确定项目是否能在财务上带来收益。
- 操作可行性 (Operational Feasibility): 评估项目一旦完成，是否能够顺利地运行和被用户接受。
- 进度可行性 (Schedule Feasibility): 确定项目是否能在规定的时间内完成。
推荐视频：可行性研究介绍
Spring 学习资源
- Spring Boot 参考文档:
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/
- Spring Framework (3.2.x MVC) 参考文档:
https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html
- Spring Framework (当前版本) 参考文档:
https://docs.spring.io/spring/docs/current/spring-framework-reference/
- TutorialsPoint Spring 教程:
https://www.tutorialspoint.com/spring/index.htm
可能的考点与示例考题
考点梳理
- ERCM 流程: 理解 ERCM 的各个阶段（PRD, SPEC, CC, CF, ER）以及 DEV 和 QA 在其中的角色和任务。
- 软件需求层次: 能够区分商业需求、用户需求和功能需求。
- 软件需求特性: 掌握需求的几个关键特性，如清晰性、完整性、可测试性、可追溯性等，并能解释其含义。
- 可行性分析: 了解进行可行性分析的目的以及四种主要类型（技术、经济、操作、进度）。
- Kano 模型: 理解三种主要的需求类型（基本、期望、魅力）及其对客户满意度的影响。
示例考题
问题 1: 在工程发布周期方法论 (ERCM) 中，为什么质量保证 (QA) 团队需要在项目早期（如 PRD 审查阶段）就介入，而不仅仅是在编码完成后进行测试？
参考答案:
-
中文: 在 ERCM 中，QA 团队早期介入有几个关键原因：
- 预防缺陷: 在需求 (PRD) 和设计 (SPEC) 阶段发现并修正问题的成本远低于在编码甚至发布后修复。QA 团队可以从可测试性和用户体验的角度提出见解，帮助在源头预防缺陷。
- 确保需求的清晰性和可测试性: QA 工程师可以审查需求是否清晰、无歧义且可被验证。如果需求模糊不清，将无法编写出有效的测试用例，也可能导致开发人员的错误实现。
- 更早地准备测试: 早期介入使 QA 团队能够更早地理解产品功能，从而提前规划测试策略、设计测试计划和编写测试用例，提高了测试阶段的效率。
- 促进团队协作与共识: QA、DEV 和 PM 在项目初期就共同评审文档，有助于建立对产品需求的统一理解，减少后续因沟通不畅导致的返工。
-
English: In ERCM, involving the QA team early is crucial for several reasons:
- Defect Prevention: The cost of fixing issues found in the requirements (PRD) and design (SPEC) phases is significantly lower than fixing them after coding or release. The QA team can provide insights on testability and user experience, helping to prevent defects at the source.
- Ensure Clarity and Testability of Requirements: QA engineers can review requirements to ensure they are clear, unambiguous, and verifiable. Vague requirements make it impossible to write effective test cases and can lead to incorrect implementation by developers.
- Earlier Test Preparation: Early involvement allows the QA team to understand the product features sooner, enabling them to plan test strategies, design test plans, and write test cases in advance, which increases efficiency during the testing phase.
- Foster Team Collaboration and Consensus: Having QA, DEV, and PM review documents together at the beginning of the project helps build a shared understanding of the product requirements, reducing rework caused by miscommunication later.
问题 2: 请解释软件需求的“可追溯性” (Traceability) 特性，并举例说明其在软件开发中的重要性。
参考答案:
-
中文: 可追溯性 (Traceability) 是指在软件开发的整个生命周期中，能够追踪一个需求从其来源（如商业目标、用户请求）到其实现（设计文档、代码、测试用例）再到最终部署和使用的能力。它建立了一条清晰的链接链条。
重要性举例:
- 影响分析 (Impact Analysis): 假设客户要求修改一个功能需求（例如，改变登录验证方式）。通过需求可追溯性，项目经理可以快速找到所有与该需求相关的设计文档、代码模块和测试用例，从而准确评估修改所需的工作量和可能带来的风险。
- 验证覆盖率 (Verification Coverage): 在测试阶段，可以通过追溯性来确保每一个功能需求都有对应的测试用例覆盖，防止需求遗漏。
- 变更管理 (Change Management): 当项目范围发生变化时，可追溯性有助于理解变更的根本原因，并确保所有相关的工件（artefacts）都得到相应更新，保持项目的一致性。
-
English: Traceability is the ability to trace a requirement throughout the entire software development lifecycle, from its origin (e.g., a business objective, a user request) through its implementation (design documents, code, test cases) to its final deployment and use. It establishes a clear chain of links.
Example of its Importance:
- Impact Analysis: Suppose a client requests a change to a functional requirement (e.g., altering the login authentication method). With requirements traceability, a project manager can quickly identify all related design documents, code modules, and test cases linked to this requirement. This allows for an accurate assessment of the effort and potential risks involved in making the change.
- Verification Coverage: During the testing phase, traceability can be used to ensure that every functional requirement is covered by corresponding test cases, preventing an omission of requirements.
- Change Management: When the project scope changes, traceability helps in understanding the root cause of the change and ensures that all related artifacts are updated accordingly, maintaining project consistency.