全部来自 AI 原创生成并经逐题审校的题目，带 精品 标记的为 AI 复审通过。整卷生成请去组卷。
某团队约定，版本号采用“主版本.次版本.修订号”格式，正式发布候选版以“-rc.序号”标识，正式版不带该后缀。有人认为，4.7.0-rc.1与4.7.0核心数字相同，因此是同一发布版本的等价写法。判断该说法是否正确。
登录后查看答案
某系统发布新版本时，仅新增了一个可空字段，旧版本仍兼容新旧两种数据库结构。新版本上线后健康检查失败，且运行期间已有数据写入新增字段。团队准备将应用构件回退到旧版本。判断：为完成回滚，必须同时把数据库恢复到发布前的快照。
某软件项目交付前进行物理配置审计。审计员核对实际交付物：交付的产品介质版本为V2.1，与其对应的用户手册、安装说明均标注为V2.1，且交付包中包含合同规定的全部配置项。有学生据此得出结论：只要实际交付的所有文件版本号一致且配置项齐全，物理配置审计即通过，无需再核对交付物是否与批准的配置清单（产品规格）相符。请判断该结论是否正确。
某软件项目按效益费用比法评价，效益费用比定义为效益现值与费用现值之比。评审者认为，若效益现值是费用现值的1.2倍，则效益费用比为1/5，因为分子应取效益现值减费用现值。该判断正确吗？
某软件项目经估算，运行期内效益现值合计为 300 万元，费用现值合计为 240 万元。小明据此用效益费用比法计算：效益费用比 B/C = 300/240 = 1.25，因该比值大于 1，故从经济角度判断该项目可行。判断上述说法是否正确。
判断题：某软件项目的净现值（NPV）是按给定的基准折现率将项目寿命期内各年净现金流量折现到期初后的代数和。若该项目在其他条件不变的情况下提高所采用的基准折现率，则其 NPV 必然增大；因此只要 NPV 大于零，项目内部收益率一定小于该基准折现率。
某医疗影像软件团队需要严格的分支隔离、权限控制和审计追溯，并已使用 Jenkins 构建、Jira 跟踪问题。团队在选型时提出：“只要版本控制工具能接入 Jira，就无需再评估其分支模型、权限模型以及与 Jenkins 的集成深度；因为配置管理工具选型的决定因素只有问题跟踪集成。”该说法是否正确？
某项目在时点0、1、2的净现金流分别为−100万元、60万元、60万元，折现率为10%。若将全部净现金流（包括初始投资）整体推迟一个时期，折现率不变，则项目净现值保持不变。判断该表述是否正确。
判断题：某项目经理认为，在软件成本估算中，Delphi 法因依靠多轮匿名专家反馈收敛估算结果，属于基于历史数据的算法模型估算方法，而 COCOMO 模型以代码行规模为输入、利用经验参数公式计算工作量，属于专家判断法。
判断：软件成本估算中的类比估算法，是通过比较待估项目与历史相似项目并调整差异形成估算；即使没有可比的历史项目，也能仅凭待估项目规模直接得到类比估算值。
判断：功能点估算法必须等软件编码完成、代码行数确定后，才能用于软件成本估算。
判断下列说法是否正确：某项目使用 Git 作为版本控制工具，使用 Jira 管理需求与缺陷。项目经理提出：由于 Git 是分布式版本控制系统，开发者可以在本地完成提交和分支操作；而 Jira 与 Git 集成后，可以自动在每次代码推送时执行单元测试并报告结果，因此无需再引入 Jenkins。
某软件项目编制配置状态报告时，报告需反映配置项及其当前版本、变更请求的状态和已批准变更的实施状态。项目负责人认为，尚未批准的变更请求不属于配置状态报告内容，因此一律不予记录。判断该说法是否正确。
判断下列表述的正误：软件产品在开发阶段需要大量人力智力投入而复制成本极低，边际成本几乎为零；且其开发成功后可以在不损耗自身的前提下被多个用户重复使用，因而软件产品具有典型的规模经济性和非损耗性（可共享复用）的经济特性。但正因复制成本极低，软件产品的固定成本占比低、可变成本占比高，这是软件产品定价通常采用低边际成本策略的根本原因。
某团队设计持续集成流水线：代码提交后检出源码，随后并行执行不依赖构建产物的代码规范检查与编译；编译成功后，使用本次生成的制品运行测试；最后汇总各步骤结果并反馈。判断：该流程中，检查与编译并行执行并不违反持续集成流程设计，前提是测试仍在制品生成后执行。
某项目的构建脚本会读取环境变量 TARGET，并据此选择目标平台编译参数；构建要求 JDK 17、Gradle 8.7，且 CI 使用不保留用户变量的干净运行器。团队已固定 JDK 和 Gradle 版本，认为无需在 CI 中配置 TARGET，因为源码未变时构建环境配置便已一致。判断该说法是否正确。
某构建脚本先定义生成发布包的任务 package，后定义编译任务 compile，并声明 package 依赖 compile。有人断言，执行 package 时构建工具会按脚本定义顺序先执行 package、再执行 compile。该断言是否正确？
判断：在多人协作的远程仓库开发中，若执行 git push 时被远程拒绝（提示非快进更新），正确的做法是先执行 git pull（或 git fetch 后合并/变基）将远程最新提交合入本地，解决可能的冲突后再重新推送；而不应直接使用 git push --force 覆盖远程分支，因为强制推送会丢弃他人在远程分支上的新提交，破坏团队协作历史。
分支 topic 和 main 从同一提交分出，之后各自修改同一文件的不同区域。将 topic 合并到 main 时，Git 自动完成三方合并且未报告冲突。判断：合并提交会同时保留两条分支各自的改动。
判断题：某团队希望在 Jenkins 中实现“构建失败时自动在 Jira 中创建缺陷工单”的功能。小王认为，只需在 Jenkins 服务器上安装 Git 插件即可实现该功能，因为 Jenkins 平台的所有功能都由平台核心原生提供，插件只是用来加速的辅助组件。