当前方法的缺陷

核心摘要

软件项目失败的根本原因是当前行业方法只测量数据边界并依赖历史乘法因子来估算，而FSSM方法论通过从功能需求出发全面测量架构的所有组件来消除估算误差。

干货提炼

主题一：当前方法的缺陷

• [当前方法只测量部分功能]：IFPUG和COSMIC方法只关注数据边界和移动，如逻辑数据文件和跨边界的数据事务（entry, exit, read, write），忽略界面、算法逻辑、错误处理等内部复杂性。
• [用乘法因子填补盲区导致估算失效]：因为测量不完整，行业方法用通用的乘法因子来“猜”未测量部分的规模。例子：只数了窗户数量就乘以一个通用的房子因子来估算整个房子的木材和电线用量，但玻璃温室和混凝土碉堡的窗户与结构比例完全不同。

主题二：FSSM的测量原理

• [从功能需求出发进行全面测量]：FSSM完全符合ISO/IEC 14143-1标准，测量完全基于功能需求规格（FRS），抛弃历史统计假设。它将需求分类为四个主要支柱：功能数据、功能执行、用户界面、消息交换。
• [用标准算术而非复杂建模计算规模]：FSSM将每个细粒度功能指派为“功能点”（SCFP），通过评估基本数据元素和执行逻辑复杂度来计算点数，然后用标准加减乘除汇总。虽然前期分析需要投入，但完全消除了假设误差。
• [通过悖论证明乘法因子失效]：数据库悖论：50个表各需1次读写 vs 2个表各需25次读写，操作数相同但架构工作量完全不同。界面悖论：2个屏幕各访问50次 vs 100个屏幕各访问1次，UI开发工作量天差地别。

主题三：动态性能预测

• [区分静态和动态测量]：静态测量代码在仓库中的架构工作量；动态测量代码在实际运行时产生的行为，如内存流量、总线饱和。
• [循环场景揭示动态盲区]：单个磁盘读操作在静态上微不足道，但如果放在一个执行循环中，用户每次触发工作流时运行1000次，会导致大量内存流量和总线饱和。传统方法仅看静态代码会低估系统压力。
• [决策树场景预测负载倾斜]：逻辑分支静态上看上去是50/50，但业务逻辑导致75%的路径执行重型内存写入。FSSM的软件操作指标可以提前标记这个动态压力点，让架构师在代码编写前就预配缓存或优化数据库层。

高光金句

• ❝ The assumption is simply that software development is inherently unpredictable, so you know, budgets are just destined to blow up. ❞
• ❝ The planning is built on a foundation of historical assumptions rather than the factual architecture of the current project. ❞

提及资源

• 组织：Wiley - 学术出版商。