一、引言
（一）核心概念定义
软件开发过程是指用于开发和维护软件及其相关产品（包括项目计划、需求文档、设计文档、代码、测试用例、用户手册等）的一系列活动、方法、实践和革新的集合。软件开发过程管理则是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法解决软件问题的管理活动，核心目标是提高软件生产率、提升软件质量、降低软件全生命周期成本。
（二）软考中的定位
本知识点属于软考中级信息系统管理工程师考试大纲中 "软件管理" 模块的核心内容，是历年考试的高频考点，在上午客观题中分值占比约 3-5 分，同时也是下午案例分析题中软件开发项目管理类题目的基础理论依据，要求考生掌握不同过程模型的特点、适用场景及优缺点对比。
（三）发展脉络
软件开发过程管理的演进可分为三个阶段：第一阶段为 20 世纪 70 年代的软件工程萌芽期，以瀑布模型为代表，强调线性流程与文档规范；第二阶段为 20 世纪 90 年代的过程改进期，迭代、增量、螺旋模型相继出现，重点解决需求变化与风险管控问题；第三阶段为 2000 年之后的敏捷开发时期，以敏捷宣言为核心，强调灵活性与快速响应，衍生出 Scrum、Kanban、XP 等多种实践框架。
（四）本文知识覆盖
本文将系统讲解软件开发过程的核心活动、管理工程师职责、5 类主流开发过程模型的原理与对比、敏捷开发的主流实践，同时梳理考试重点与实践应用要点。
二、软件开发过程核心基础
（一）一般过程活动详解
软件开发过程的核心活动覆盖从需求获取到系统下线的全生命周期，各活动的输入输出、核心目标如下：
- 需求分析：输入为用户初步需求描述，核心任务是通过访谈、调研、原型演示等方式完成需求的获取、分析、评审，输出经各方确认的《软件需求规格说明书》，明确功能需求、非功能需求（性能、安全、兼容性等）、约束条件三类内容。例如某政务系统开发项目中，需求分析阶段需明确系统支持的并发用户数不低于 1000、响应时间不超过 2 秒等非功能指标。
- 系统设计：输入为需求规格说明书，分为概要设计和详细设计两个子阶段，概要设计输出系统架构图、模块划分方案、接口规范、数据模型，详细设计输出每个模块的实现逻辑、算法描述、界面设计稿。例如电商系统设计阶段需明确订单模块、支付模块、用户模块的交互接口参数与调用规则。
- 编码：输入为设计文档，核心任务是按照编码规范编写程序代码，完成功能实现，输出可运行的程序包、代码注释、单元测试用例。通常要求代码注释率不低于 30%，单元测试覆盖率不低于 80%。
- 测试：输入为待测试的程序包与需求规格说明书，分为单元测试、集成测试、系统测试、验收测试四个层级，核心目标是发现软件缺陷，确保功能符合需求、性能满足指标、安全符合规范，输出测试报告、缺陷记录。例如金融类系统测试阶段需完成渗透测试，确保数据传输加密、权限控制符合等保 2 级要求。
- 部署：输入为测试通过的程序包与部署方案，核心任务是完成生产环境的配置、系统上线、用户培训，输出上线验收报告、用户操作手册。
- 维护：覆盖系统上线后的全生命周期，分为更正性维护（修复缺陷）、适应性维护（适配环境变化）、完善性维护（新增功能）、预防性维护（优化潜在问题）四类，输出维护记录、版本更新说明。
（二）信息系统管理工程师的核心职责
在软件开发项目中，管理工程师承担项目全周期的管理责任，核心职责包括：
- 项目计划：依据项目范围说明书，明确项目目标、交付物、进度里程碑、成本预算、质量要求，编制《项目管理计划》，其中需明确需求变更流程、风险应对方案、质量管控节点。例如某中小软件项目计划需明确需求变更需提交变更申请，经 CCB（变更控制委员会）审批后方可执行。
- 项目组织：搭建项目团队，明确项目经理、需求分析师、设计师、开发工程师、测试工程师、运维工程师的职责边界，分配人力资源、设备资源、预算资源，输出责任分配矩阵（RAM）。
- 项目执行：按照项目计划组织团队开展各项开发活动，协调跨部门资源，定期组织项目例会，跟踪任务完成情况。
- 项目控制：通过挣值分析、进度偏差分析等方法监控项目的进度、成本、质量绩效，当实际值与计划值偏差超过 10% 时，需及时采取纠正措施，例如赶工、快速跟进、调整范围等，确保项目符合目标要求。
- 项目结束：组织项目验收，完成文档归档、资源释放、项目总结，评估项目绩效，输出项目收尾报告、经验教训文档。
软件开发过程活动与管理职责对应关系示意图
三、常见软件开发过程模型详解
开发过程模型是指导软件项目开发活动的框架，不同模型适用于不同的项目场景，核心模型的原理、优缺点、适用场景如下：
（一）瀑布模型
- 核心原理：将开发过程分为需求分析、系统设计、编码、测试、部署、维护 6 个连续的线性阶段，每个阶段必须在前一阶段全部完成且输出通过评审后才能启动，每个阶段有明确的输入输出文档。
- 优缺点分析：优点为线性流程清晰，易于理解和管理，每个阶段的交付物明确，便于质量管控；缺点为灵活性差，无法应对需求变更，若在测试阶段发现需求层面的问题，需要回溯到需求阶段修改，返工成本极高。
- 适用场景：仅适用于需求明确且稳定、项目规模小、复杂度低的场景，例如企业内部的固定流程类工具开发、需求已通过原型完全确认的小型网站开发。
（二）迭代模型
- 核心原理：将开发周期划分为多个重复的迭代周期，每个迭代周期都包含完整的需求分析、设计、编码、测试、部署流程，每个迭代结束后交付一个可运行的、包含部分功能的系统版本，后续迭代在已有版本基础上优化功能、补充需求。例如某社交 APP 开发分为 3 个迭代，第一个迭代实现基础聊天功能，第二个迭代实现朋友圈功能，第三个迭代实现直播功能。
- 优缺点分析：优点为可逐步验证需求，早期发现设计缺陷，灵活应对需求变化，降低项目整体风险；缺点为对项目管理能力要求高，需要持续跟踪每个迭代的进度与质量，迭代次数控制不当会导致项目延期。
- 适用场景：适用于需求不明确、项目复杂度中等的场景，例如互联网产品开发、创新型软件项目。
（三）增量模型
- 核心原理：将系统功能按照优先级划分为多个独立的增量模块，第一个增量交付核心最高优先级功能，后续增量依次交付低优先级功能，每个增量的开发流程独立，可并行开展。例如 OA 系统开发中，第一个增量实现考勤、审批核心功能，第二个增量实现公文管理功能，第三个增量实现知识管理功能。
- 优缺点分析：优点为可快速交付核心功能，早期获得用户反馈，降低开发风险，模块间耦合度低便于维护；缺点为需要在项目初期明确所有增量的功能范围，模块集成时需解决接口兼容性问题。
- 适用场景：适用于需求可拆分、对交付时间有要求的项目，例如企业级管理系统开发、功能模块化程度高的软件项目。
（四）螺旋模型
- 核心原理：融合了瀑布模型与迭代模型的特点，每个迭代周期分为制定计划、风险分析、实施工程、客户评估 4 个象限，核心特点是每个迭代都优先开展风险识别与分析，针对高风险点制定应对方案后再推进开发工作。例如航天类软件、金融核心系统开发中，每个迭代都会优先评估安全风险、性能风险。
- 优缺点分析：优点为风险管控能力强，可有效降低高风险项目的失败概率，灵活适配需求变化；缺点为风险分析成本高，对团队的风险评估能力要求高，项目周期长、成本高。
- 适用场景：适用于规模大、复杂度高、风险等级高的项目，例如国防软件、金融核心交易系统、大型工业控制系统开发。
（五）敏捷模型
- 核心原理：以 2001 年发布的《敏捷宣言》为核心，强调 "个体和互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划" 四大价值观，常见的实践框架包括 Scrum、Kanban、极限编程（XP）。
- 优缺点分析：优点为响应需求变化速度快，迭代周期短（通常为 2-4 周），团队协作效率高，适合快速迭代的互联网产品；缺点为对团队成员的能力、自我管理能力要求高，缺乏完整文档不利于后续维护，不适合需求固定的传统项目。
- 适用场景：适用于需求变化频繁、交付时间要求高的互联网产品、创业型项目。
5 类软件开发过程模型对比表（包含定义、优点、缺点、适用场景、实施成本维度）
四、核心模型对比与敏捷实践详解
（一）迭代模型与增量模型的核心区别
二者常为考试易混淆考点，核心区别体现在两个维度：
- 交付物差异：迭代模型每个迭代交付的是完整但功能不全的系统版本，每次迭代都会对已有功能进行优化；增量模型每个增量交付的是独立的功能模块，模块之间可独立运行，逐步集成。
- 需求处理差异 ：迭代模型允许在后续迭代中调整已有功能的需求，适合需求模糊的场景；增量模型需要在项目初期明确所有增量的功能范围，适合需求可拆分、优先级清晰的场景。
例如迭代模型开发的电商系统，第一个迭代实现的下单功能仅支持微信支付，第二个迭代可优化下单流程并新增支付宝支付；增量模型开发的电商系统，第一个增量交付商品展示模块，第二个增量交付订单模块，第三个增量交付支付模块，每个模块独立开发、独立上线。
（二）主流敏捷实践框架对比
敏捷模型包含三类主流实践框架，各自的特点、适用场景如下：
- Scrum：迭代式敏捷框架，核心角色包括产品负责人（PO）、Scrum Master、开发团队，核心流程为：每个迭代称为 Sprint，周期通常为 2-4 周；Sprint 开始前召开计划会议，从产品待办列表（Product Backlog）中选取本次迭代要完成的需求，形成 Sprint Backlog；迭代过程中每日召开 15 分钟站会同步进度；迭代结束后召开评审会议演示交付成果，召开回顾会议总结迭代问题。适用于 10 人以内的跨职能开发团队，例如互联网产品的功能迭代团队。
- Kanban：流式敏捷框架，核心工具为看板，将开发过程划分为待办、进行中、测试、完成等列，任务卡片在列间移动，核心规则为限制在制品（WIP）数量（例如进行中的任务最多同时开展 3 个），通过拉动式生产提升流程效率，无固定迭代周期。适用于运维、需求响应类团队，例如技术支持团队、bug 修复团队。
- 极限编程（XP）：强调代码质量的敏捷实践，核心实践包括测试驱动开发（TDD，先写测试用例再写代码）、持续集成（代码提交后自动构建、自动测试）、结对编程、代码重构、小版本发布。适用于对代码质量要求高、需求变化频繁的小型开发团队，例如 SaaS 类产品的开发团队。
Scrum 核心流程示意图
三类敏捷实践框架对比表
五、过程模型选型原则与管理要点
（一）过程模型选型的核心依据
软件开发过程模型的选型需结合项目的 5 个核心维度综合判断，避免盲目选择敏捷或瀑布模型：
- 需求确定性：需求明确且稳定的项目优先选择瀑布模型，需求模糊或变化频繁的项目优先选择迭代或敏捷模型。
- 项目复杂度与规模：小型简单项目选择瀑布模型，中型复杂项目选择迭代或增量模型，大型高风险项目选择螺旋模型。
- 交付时间要求：要求快速交付核心功能的项目选择增量或敏捷模型，交付周期充裕的项目可选择瀑布模型。
- 团队能力：团队管理能力弱、成员经验不足的项目优先选择瀑布模型，团队能力强、自我管理能力高的项目可选择敏捷模型。
- 行业监管要求 ：金融、医疗、政务等对文档完整性、合规性要求高的行业，优先选择瀑布或螺旋模型，确保过程文档完整可追溯。
例如某银行核心系统升级项目，需求明确、风险等级高、合规要求严格，应选择螺旋模型；某初创企业的社交 APP 开发项目，需求变化频繁、交付时间要求高，应选择 Scrum 框架的敏捷模型。
（二）过程管理的通用最佳实践
无论选择哪种过程模型，都需遵循以下管理要求，符合 ISO90003、GB/T 8566 等软件过程标准规范：
- 文档管控：每个阶段的输出文档需经过评审并归档，即使是敏捷项目也需保留核心的需求文档、测试报告、上线记录，避免人员流动导致知识丢失。
- 变更管理：建立统一的需求变更流程，所有变更需提交申请、评估影响、经审批后方可执行，避免需求蔓延导致项目失控。
- 质量管控：每个阶段设置质量检查点，未通过质量检查不得进入下一阶段，例如需求文档未通过用户评审不得进入设计阶段。
软件开发过程模型选型决策树
六、前沿发展与考试重点提示
（一）前沿发展趋势
当前软件开发过程管理的发展方向主要包括三个方面：
- DevOps 融合：将开发过程与运维过程深度融合，通过自动化工具实现持续集成、持续交付、持续部署（CI/CD），缩短需求到上线的周期，目前已成为互联网行业的标准实践。
- 低代码 / 无代码开发的过程适配：低代码开发平台的普及使得开发周期大幅缩短，过程模型逐步向轻量型、敏捷化方向演进，需求确认、测试环节的占比提升，编码环节占比下降。
- AI 辅助开发：AI 代码生成、AI 测试等工具的应用，提升了编码、测试环节的效率，过程管理中新增 AI 输出内容的质量审核节点，例如 AI 生成的代码需经过人工评审后方可合并。
（二）软考考试重点提示
本知识点的高频考点、易错点如下：
- 高频考点：5 类过程模型的优缺点、适用场景，迭代与增量模型的区别，Scrum 的核心角色与流程，软件开发过程的核心活动，信息系统管理工程师的职责。
- 易错点：混淆迭代与增量模型的差异，误认为敏捷模型不需要文档，误认为螺旋模型的核心是迭代而忽略风险分析的核心地位，混淆瀑布模型的适用场景。
软件开发过程管理技术演进路线图
七、总结与备考建议
（一）核心要点提炼
- 软件开发过程包含需求分析、系统设计、编码、测试、部署、维护 6 项核心活动，信息系统管理工程师承担计划、组织、执行、控制、收尾 5 项管理职责。
- 瀑布模型适合需求稳定的小型项目，迭代模型适合需求不明确的中型项目，增量模型适合功能可拆分、需快速交付的项目，螺旋模型适合高风险大型项目，敏捷模型适合需求变化频繁的互联网项目。
- 敏捷主流实践中，Scrum 为固定迭代的团队协作框架，Kanban 为流式任务管理框架，XP 为强调代码质量的开发实践。
（二）备考与实践建议
- 备考策略：重点记忆各类过程模型的优缺点、适用场景，对比梳理易混淆知识点，例如迭代与增量的区别、不同敏捷框架的差异，通过历年真题巩固考点。
- 实践应用：实际项目中根据需求确定性、项目规模、团队能力等维度综合选择过程模型，避免盲目跟风敏捷，优先保证项目的质量、进度、成本可控，符合行业监管要求。
八、课后小测
以下关于瀑布模型的描述，不正确的是（）
A. 瀑布模型的流程是线性的，易于理解和管理
B. 瀑布模型适用于需求不明确或可能变化的项目
C. 每个阶段有明确的输入和输出
D. 如果在开发后期发现问题，可能需要返回到前面的阶段
答案：B。解析：瀑布模型为线性流程，无法应对需求变化，仅适用于需求明确且稳定的项目。