B.1 简答题（40分）

1. 基于算法/方程的模型：
• 核心思想：使用经验公式（通常形式为：工作量 = a × (规模)^b × 乘数）来估算成本。
• 著名模型：
• COCOMO模型：最著名的模型系列，分为基本、中间、详细三个层次，考虑规模和各种成本驱动因子。
• Walston-Felix模型、Bailey-Basili模型等。

2. 非算法模型：
• 核心思想：依靠专家的经验和判断。
• 著名方法：
• 专家判断法：由多位专家根据经验直接估算。
• 类比估算法：与过去类似的项目进行比较得出估算。
• Parkinson法则：基于给定的资源和时间来决定工作范围（不科学，但现实中存在）。

1. PDM前导图法：
• 特点：节点表示活动，箭线表示逻辑关系。
• 优点：最常用，可以表示四种依赖关系（完成-开始，开始-开始，完成-完成，开始-完成），逻辑清晰。

2. ADM箭线图法：
• 特点：箭线表示活动，节点表示事件（时刻点）。
• 优点：引入了“虚活动”来表示逻辑关系，能清晰显示关键路径。
• 缺点：绘图较复杂，不如前导图法直观。

3. CDM条件箭线图法：
• 允许活动序列相互循环与反馈，从而形成许多条件分支。

1. 人力资源：项目团队成员。

2. 设备资源：开发、测试所需的硬件和设备。

3. 材料资源：消耗性物资。

4. 资金资源：项目预算。

5. 技术/信息资源：软件工具、库、专利、知识。

1. 瀑布模型：线性顺序开发，阶段划分严格，文档驱动。

2. 迭代模型：将项目分解为一系列小循环（迭代），每个迭代都完成一个可执行的子集，逐步完善产品。

3. 敏捷模型（如Scrum, XP）：以人为核心，采用迭代、渐进的方式，通过紧密协作和快速反馈来应对变化。

B.2 问答题（ 30 分）

1. 启动阶段：
• 定义项目目标：明确新工资系统的业务需求（如降低成本、掌握自主权、提高效率）。
• 进行可行性研究：从经济（购买/维护成本 vs 政府收费）、技术（现有产品是否满足需求）、操作（校内人员能否胜任）等方面分析项目是否可行。
• 立项：获得批准，正式启动项目。

2. 规划阶段：
• 需求分析：详细调研用户（如财务处、人事处）对新系统的功能和非功能需求。
• 供应商与产品选型：评估市场上的现成系统，选择最适合的软件供应商。
• 制定项目计划：包括采购计划、实施进度计划、成本预算、人员配置计划、数据迁移计划、风险应对计划等。

3. 执行与监控阶段：
• 采购与签订合同：与选定的供应商完成商务流程。
• 系统部署与配置：安装软件，并根据学校情况进行初始化配置。
• 数据迁移：将历史工资数据从政府系统安全、准确地导入新系统。
• 测试：进行单元测试、集成测试和用户验收测试，确保系统运行正确。
• 培训：对最终用户进行系统操作培训。
• 全程监控：对比项目计划，监控进度、成本和质量，处理过程中出现的问题和变更。

4. 收尾阶段：
• 系统上线与切换：正式启用新系统，停止使用政府服务。
• 项目验收：获得用户和发起人的正式签字认可。
• 项目总结：归档项目文档，总结经验教训。
• 后续维护移交：将系统移交至运维团队，进入日常维护阶段。

• 定义：螺旋模型是一种风险驱动的软件开发过程模型。它将开发过程表现为一个逐步展开的螺旋线，每个循环（螺旋）都包括四个阶段：
1. 制定计划：确定项目目标、方案和约束。
2. 风险分析：识别并评估所有潜在风险，制定风险应对策略。
3. 工程实施：开发和验证该螺旋的产物（如原型、子系统）。
4. 客户评估：评估工程成果，计划下一轮的工作。

• 优势：
1. 高风险项目的理想选择：在风险造成重大危害之前就对其进行识别和应对。
2. 灵活性高：支持需求的变化，适用于大型、复杂、需求不明确的项目。
3. 客户参与度高：每个循环都包含客户评估与反馈，确保产品始终朝着客户满意的方向演进。
4. 逐步构建：通过多个循环逐步深化，最终构建出完整的系统。

• 限制：
1. 复杂且成本高：风险分析和原型构建需要投入大量时间和资源，不适用于小项目。
2. 对风险管理技能要求高：风险分析的有效性高度依赖于开发团队的风险评估能力。
3. 合同管理困难：循环和可变的特点使得在项目初期确定准确的预算和工期变得困难。

• 定义：工作分解结构（WBS） 是项目管理中一种以可交付成果为导向的分解技术，它将项目工作和项目目标分解为更小、更易于管理的组成部分。它位于规划过程的中心，是制定进度、成本和资源计划的基础。

• 核心思想：100%规则——WBS必须包含项目的全部工作范围，包括内部、外部和临时的所有工作。

• 举例说明（以“开发一个工资管理系统”为例）：
WBS通常以树形结构图或列表缩进式来表达。
树形结构图表达法：
列表缩进式表达法（更常用且易于书写）：

1. 初始级：
• 特征：过程是无序的、临时的，甚至混乱的。成功高度依赖于个人的能力和英雄主义。
• 结果：项目不可预测，难以重复成功。

2. 已管理级：
• 特征：在项目层面上，已建立了基本的项目管理过程来跟踪成本、进度和功能。能对必要的过程纪律进行规划和管理。
• 结果：项目能按计划执行，对类似的重复性项目可重复成功。

3. 已定义级：
• 特征：过程已被标准化、文档化，并集成为组织的标准过程。所有项目均使用经批准、剪裁的组织标准过程来开发和维护软件。
• 结果：过程在整个组织内保持一致，质量和效率得到提升。

4. 量化管理级：
• 特征：为过程和产品建立了量化的质量目标，并利用统计技术对过程和产品进行量化管理。
• 结果：过程是量化的、可预测的，并能通过细微调整实现预期的质量目标。

5. 优化级：
• 特征：专注于过程的持续改进。利用来自过程和试点新思想、新技术的量化反馈，能够持续地改进过程。
• 结果：组织能够主动地改进过程，应对变化，并防止缺陷发生。

1. 需求的模糊性和主观性：用户的需求通常最初是模糊的、不完整的，并且基于他们的主观感受和经验，难以精确地转化为技术规格。

2. 需求的不稳定性和易变性：在项目开发过程中，市场环境、业务规则和用户认知都会发生变化，导致需求随之改变，即“需求蔓延”。

3. 沟通鸿沟：用户和开发人员处于不同的领域，使用不同的“语言”。用户懂业务但不熟技术，开发人员懂技术但不理解业务深层逻辑，容易产生误解。

4. 利益相关者的多样性和冲突：不同用户角色（如管理者、操作者）对系统有不同的期望和需求，这些需求之间可能存在冲突，难以调和。

5. 需求分析的复杂性：大型系统的需求数量庞大，之间存在复杂的逻辑关联和依赖关系，梳理清楚并保证其一致性和完整性是一项艰巨的任务。

6. 对需求的重要性排序困难：在资源有限的情况下，难以科学地确定哪些需求是核心的、必须实现的，哪些是可以延迟或削减的，这影响到项目的范围和计划。

7. 金本位：个别拥有决策权的权威人物（如高级管理者）可能会提出不切实际或片面的需求，干扰了基于集体共识的需求分析过程。

B.3 计算分析题（ 15 分）

 

 

• 专家A：O = 7万, M = 8万, P = 9万

• 专家B：O = 6万, M = 8万, P = 10万

• 专家C：O = 5万, M = 7万, P = 9万

B.4 案例分析题（ 15 分）

• 变更请求识别与记录：及时识别并记录所有变更请求，确保每个请求有唯一标识。

• 变更影响分析：评估变更对项目范围、成本、进度、质量和现有系统的影响，提供决策依据。

• 变更审批决策：由变更控制委员会（CCB）或授权人员审查变更请求，决定批准、拒绝或延期。

• 变更实施与跟踪：对批准的变更安排实施，监控变更过程，确保按计划执行。

• 变更验证与测试：验证变更是否正确实施，并通过测试确保没有引入新缺陷。

• 变更文档化与沟通：记录变更详情，更新配置项，并通知所有相关干系人变更状态。

• 作用：
• 集中存储配置信息：记录所有配置项的属性、版本、依赖关系和状态。
• 支持变更影响分析：提供数据以评估变更的潜在影响。
• 跟踪配置历史：维护配置项的变更记录，便于审计和回溯。
• 促进版本控制：确保使用正确的配置项版本，避免混乱。

• 分类：
• 开发库：用于开发人员日常工作的动态库，存储正在开发的配置项。
• 受控库：存储已通过测试和审核的配置项，用于正式构建和测试。
• 产品库：存储最终发布的软件产品版本，用于交付和部署。

1. 变更申请：用户或项目成员提出变更请求，填写变更申请单。

2. 变更记录与分类：配置管理员记录请求，并分类为紧急、常规等优先级。

3. 初步分析：评估变更的可行性、成本、进度和资源影响。

4. 变更评审：变更控制委员会（CCB）召开会议，审查分析结果，做出批准或拒绝决定。

5. 变更实施：如果批准，开发团队实施变更，并更新相关配置项。

6. 验证与测试：测试团队对变更进行验证，确保符合要求且无副作用。

7. 变更关闭：更新配置数据库，文档化变更结果，通知干系人，并关闭变更请求。

8. 后续监控：监控变更后的系统稳定性，必要时进行调整。

• 制定配置管理计划：定义配置管理的目标、策略、流程、角色和职责。

• 配置标识：识别所有配置项（如代码、文档），并制定命名和版本规则。

• 变更控制：建立变更控制流程，管理所有变更请求，确保变更受控。

• 配置状态报告：定期报告配置项的状态、变更历史和当前版本，提高可视性。

• 配置审核：进行功能配置审核和物理配置审核，验证配置项是否符合需求和标准。

• 版本管理：控制配置项的版本变化，确保版本一致性和可追溯性。

• 发行管理：管理软件的构建、打包、发布和交付过程，确保发布版本的正确性。

1. 需求调研阶段缺乏有效沟通与承诺：
• 客户部门对需求调研不配合，说明项目未能获得关键干系人的认可与支持。
• 需求收集方法单一（仅依靠票据），未能深入理解业务流程和真实需求。

2. 缺乏正式的变更控制流程：
• 变更请求以非正式方式提出（口头要求），未经过规范的影响分析和审批。
• 仅通过“变更列表+盖章”的方式试图锁定需求，但缺乏对变更范围、成本和进度的综合评估。

3. 变更管理策略僵化且被动：
• “锁定需求”的方式不符合软件开发灵活性要求，反而引发客户反感。
• 未能建立变更优先级机制，所有变更被平等对待，导致开发团队不堪重负。

4. 缺乏变更影响分析和沟通：
• 未向客户清晰说明变更对项目目标（成本、进度、质量）的影响。
• 客户认为“重新制作变更列表”即可实现变更，说明未建立变更的成本意识。

5. 团队士气与资源配置问题：
• 频繁变更导致开发团队产生倦怠情绪，缺乏有效的激励和资源调整。

1. 改进需求获取与分析方法：
• 采用联合需求规划（JRP）会议、原型法等主动沟通方式，邀请关键用户参与设计。
• 通过业务流程图、用例分析等方法系统性梳理需求，确保双方对需求理解一致。

2. 建立正式的变更控制机制：
• 成立变更控制委员会（CCB），明确变更审批权限和流程。
• 所有变更必须提交书面《变更申请单》，附详细说明和业务理由。

3. 实施变更影响分析与沟通：
• 对每个变更进行成本、进度和技术可行性分析，形成《变更影响报告》。
• 将分析结果可视化（如“变更影响矩阵”），帮助客户理解变更后果。

4. 采用灵活的变更管理策略：
• 建立变更优先级标准（如紧急/重要程度），对非核心变更建议纳入后续版本。
• 推行迭代开发模式，通过短期交付获取持续反馈，减少后期大规模变更。

5. 加强合同与范围管理：
• 在项目章程中明确范围边界，约定变更处理机制和成本承担原则。
• 对重大变更签订补充协议，明确资源调整和交付时间变更。

6. 团队管理与维护准备：
• 建立变更预留缓冲时间，避免频繁打断开发节奏。
• 完善项目文档和版本管理，为后期维护提供完整基线。

7. 持续干系人管理：
• 定期向客户管理层汇报变更累积影响，争取高层对流程规范的支持。
• 对积极配合的部门给予认可，建立合作共赢的项目文化。