软件成本估算：COCOMO 2模型方法的目录

Posted 2023-04-13

参考技术A

第1章 COCOMO II介绍
1.1 COCOMO II用户目标
1.2 COCOMO II模型目标
1.3 COCOMO II开发和发展策略
1.4 未来软件实践市场模型
1.4.1 中间部分
1.4.2 1999年模型评估
1.5 最终的COCOMO II模型系列
1.5.1 针对不同软件市场部分的COCOMOII模型
1.5.2 根据过程策略裁剪COCOMO II估算模型
第2章 COCOMO II模型定义
2.1 引言
2.1.1 概述
2.1.2 标称进度估算公式
2.2 规模估算
2.2.1 源代码行（SLOC）计算
2.2.2 未调整功能点（UFP）计算
2.2.3 UFP与SLOC关联
2.2.4 累加新的、改编的和复用的代码
2.2.5 需求演进和易变性（REVL）
2.2.6 自动转换的代码
2.2.7 计算软件维护的规模
2.3 工作量估算
2.3.1 比例因子
2.3.2 工作量乘数
2.3.3 多模块的工作量估算
2.4 进度估算
2.5 软件维护
2.6 应用COCOMO II进行软件决策
2.6.1 投资决策和商业案例分析
2.6.2 设定项目预算和进度
2.6.3 权衡分析
2.6.4 成本风险管理
2.6.5 开发与复用决策
2.6.6 遗留软件逐步淘汰决策
2.6.7 软件复用和产品线决策
2.6.8 过程改进决策
2.6.9 决策分析总结
2.7 COCOMO II模型总结和版本
2.7.1 模型公式、表和驱动因子等级量表
2.7.2 COCOMO II版本参数值
2.7.3 源代码逻辑行计数规则
2.7.4 COCOMO模型比较
第3章 应用实例
3.1 引言
3.2 事务处理系统（TPS）概述
3.2.1 事务处理系统描述
3.2.2 事务处理系统的软件功能
3.2.3 事务处理系统的软件开发机构
3.2.4 事务处理系统的软件开发估算
3.2.5 划定风险的边界
3.2.6 执行权衡研究
3.2.7 评估生命周期成本
3.3 机载雷达系统（ARS）概述
3.3.1 ARS描述
3.3.2 原型演示（起始阶段）
3.3.3 实验模型系统（细化阶段）
3.3.4 完全开发—顶层估算
3.3.5 完全开发—详细的组件估算
3.3.6 增量开发实例
第4章 校准
4.1 贝叶斯校准和COCOMO II建模方法学
4.1.1 贝叶斯校准 107
4.1.2 COCOMO II建模方法学
4.2 讲述的主题
4.3 COCOMO II模型的数据收集方法
4.3.1 获得一致数据
4.3.2 Rosetta Stone
4.4 模型建造
4.4.1 统计的建模过程
4.4.2 观测数据的分析
4.5 COCOMO II校准
4.5.1 COCOMO II.1997
4.5.2 COCOMO II.2000
4.6 针对特定机构裁剪COCOMO II模型
4.6.1 用现有项目数据校准模型
4.6.2 合并或消除冗余参数
4.6.3 在模型中增加不明显但重要的成本驱动因子
4.7 COCOMO II数据总结
4.8 结论
第5章 新扩展
5.1 应用组装：应用点模型
5.1.1 对象点数据和实验
5.1.2 应用点估算过程
5.1.3 应用点估算的准确性和成熟度
5.2 COPSEMO：阶段进度与工作量估算
5.2.1 背景
5.2.2 模型概况
5.2.3 模型实现
5.2.4 应用示例
5.2.5 动态COCOMO
5.3 CORADMO：快速应用开发估算
5.3.1 背景和基本原理
5.3.2 与COCOMO II的关系
5.3.3 模型概况
5.3.4 模型细节
5.3.5 处理的范围和生命周期
5.3.6 电子表格模型实现
5.3.7 应用实例
5.3.8 结论
5.3.9 未来工作
5.4 COCOTS：COTS 集成估算
5.4.1 背景和基本原理
5.4.2 与COCOMO II的关系
5.4.3 模型概况
5.4.4 目前已处理的范围和生命周期
5.4.5 成本来源
5.4.6 四个子模型
5.4.7 评估
5.4.8 裁剪
5.4.9 连接代码
5.4.10 系统易变性
5.4.11 总的COTS集成工作量
5.4.12 结论
5.5 COQUALMO：质量估算
5.5.1 引言
5.5.2 背景模型
5.5.3 软件缺陷引入（DI）模型
5.5.4 软件缺陷消除模型
5.5.5 COQUALMO与COCOMO II的集成
5.5.6 结论和进行中的研究
5.6 COPROMO：生产率估算
5.6.1 背景和基本原理
5.6.2 与COCOMO II的关系
5.6.3 模型概况
5.6.4 目前包括的范围和生命周期
5.6.5 模型细节
5.6.6 电子表格模型概况
5.6.7 使用实例
5.6.8 COPROMO 0.3文档
5.6.9 结论和未来工作
5.7 专家COCOMO：风险评估
5.7.1 引言和背景
5.7.2 风险描述
5.7.3 风险分类学和规则库
5.7.4 风险量化
5.7.5 输入异常
5.7.6 实现
5.7.7 当前状态和进一步的参考
第6章 未来发展的趋势
6.1 在软件生产率与估算准确性方面的趋势
6.2 对应用领域增加理解带来的影响
6.3 创新与变化的影响
6.4 处理变化：COCOMO II
6.5 处理变化：COCOMO II与机构
6.5.1 处理项目定义中的变更
6.5.2 处理项目实施中的变更
6.5.3 处理COCOMO II模型所需要的变更
6.5.4 主动的机构变更管理
附录A COCOMO II：假设条件和阶段/活动分布
附录B COCOMO II：估算增量开发
附录C COCOMO 套件：数据收集表单和指南
附录D COCOMO II和USC-CSE会员章程
附录E USC COCOMO II. 2000软件参考手册
附录F 附赠光盘的内容
词汇表
参考文献
索引

Postgres EXPLAIN ANALYZE 成本估算行数大大高于实际行数。没有吸尘？

【中文标题】Postgres EXPLAIN ANALYZE 成本估算行数大大高于实际行数。没有吸尘？

【英文标题】：Postgres EXPLAIN ANALYZE cost estimate row count massively higher than actual row count. No Vacuuming?

【发布时间】：2018-12-11 08:22:15

【问题描述】：

我在 Django 项目中的 Heroku 上运行了一个 Postgres 9.4.18 数据库。我注意到查询变得越来越慢，所以我对一个查询运行了“解释分析”，并注意到对于一个节点，行估计大大高于实际行数：

->  Seq Scan on listings_listing u1  (cost=0.00..1536692.01 rows=5030003 width=8) (actual time=0.811..11263.410 rows=173537 loops=1)

然后我在表上运行“VACUUM FULL ANALYZE”，然后在查询中重新运行“EXPLAIN ANALYZE”并得到：

->  Seq Scan on listings_listing u1  (cost=0.00..23554.61 rows=173537 width=8) (actual time=0.001..33.884 rows=173537 loops=1)

现在执行时间快了 100 倍。

所以两个问题是：A）自动吸尘不应该防止这种情况发生吗？ （我如何检查它是否已启用？）B）假设没有执行真空吸尘，它是如何做到的？

--------------------------------更新

我从 heroku 中找到了这个给出 autovacuum 统计信息的命令，这是输出（不幸的是，我在手动清理之后运行了它。

heroku pg:vacuum_stats DATABASE_URL

schema |                  table                  | last_vacuum | last_autovacuum  |    rowcount    | dead_rowcount  | autovacuum_threshold | expect_autovacuum 
--------+-----------------------------------------+-------------+------------------+----------------+----------------+----------------------+-------------------
 public | listings_listing                        |             | 2018-06-27 15:36 |        173,537 |              0 |         34,757       | 

似乎指示的阈值应该在很久以前就导致它运行真空。

此外，这里是 Heroku 页面，其中包含有关吸尘设置的文档： https://devcenter.heroku.com/articles/managing-vacuum-on-heroku-postgres

【参考方案1】：

要查看 autovacuum 是否已按应有的方式启用，请运行

SHOW autovacuum;

要查看是否为您的特定表禁用了 autovacuum，请运行

SELECT reloptions FROM pg_class WHERE relname = 'listings_listing';

B) 的答案很简单：

如果 autovacuum 没有运行，每个UPDATE 或DELETE 都会在表中创建一个“死元组”（或“死行版本”）。除非您手动运行 VACUUM，否则这些将永远不会被清除，这会导致表增长，从而导致顺序扫描变慢。

A）的答案更难：

有几件事可以阻止 autovacuum 完成其工作：

此表的更改率可能非常高，以至于默认运行缓慢的 autovacuum 无法跟上正常活动。

在这种情况下，您应该将 autovacuum 调整为对该表更具侵略性：

ALTER TABLE listings_listing SET (
   autovacuum_vacuum_cost_limit = 1000,
   toast.autovacuum_vacuum_cost_limit = 1000
);

如果这还不够好，你可以

ALTER TABLE listings_listing SET (
   autovacuum_vacuum_cost_delay = 0,
   toast.autovacuum_vacuum_cost_delay = 0
);

有并发的长事务。

Autovacuum 只能删除比最旧的正在运行的事务更早的死元组，因此长事务可能会使其无法正常工作。

还有更多的故事；阅读this blog post。

但是，这也会使 VACUUM (FULL) 无法正常工作，所以这可能不是您的问题。

该表经常被SHARE UPDATE EXCLUSIVE 或更强大的锁锁定，例如通过运行“LOCK listings_listing”。

当 autovacuum 遇到这样的锁定时，它会退出而不是阻止用户活动。

确定发生了什么的一种有用方法是像这样查询pg_stat_user_tables：

SELECT n_live_tup, n_dead_tup, last_vacuum, last_autovacuum
FROM pg_stat_user_tables
WHERE relname = 'listings_listing';

但是现在你已经运行了VACUUM (FULL)，这个证据可能已经被销毁了。

另一件好事是将log_autovacuum_min_duration 设置为-1 以外的值并偶尔查看日志。

【讨论】：

谢谢。运行您的命令显示此表的 autovacuum 已打开且未禁用。 pg_stat_user_tables 显示 last_autovacuum 是在 2018-06-27 完成的。我还运行了一个显示 autovacuum_threshold 为 34,757 行的 heroku 命令。所以我不明白为什么它还没有运行。还是与 autovacuum_vacuum_cost_delay 不同？我不在此表上执行长锁。

也许只是批量删除。监控表膨胀，看看会发生什么。

我每 15 分钟运行一次删除陈旧列表的任务，因此不太可能进行批量删除。我将尝试监控膨胀。改变 cost_delay 的想法是否可能是它试图吸尘但它一直在睡觉？我的服务不是那么受欢迎，所以我很难相信。

Autovacuum 默认变慢，它经常需要休息。除非你知道有必要，否则不要调整它。

【参考方案2】：

Laurenz Albe 的回答非常适合解释自动吸尘的原因，但我现在想回答我后来发现的为什么我的死元组数量激增。

基本上由于我的代码中的错误，我每 15 分钟更新一次数据库中的每一行，而不仅仅是匹配过滤器的行。每次更新都会创建一个死元组，并且它膨胀得如此之快，以至于吸尘无法跟上。我花了一段时间才找到错误，因为我只查看代码中的删除而不是更新，因为我（当时）没有意识到它们也会创建死元组。

修复后无需更改任何自动吸尘设置。肿胀增加是正常的。