本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。
电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6###
一个量化管理项目的一生
本章通过一个例子展示本书所述的量化需求分析与建模方法在项目中实际应用的情况。
注意本章所有数字均只需要两个来源：本章中的配图，业界的数据。配图中的元素隐含了量化规则，只从其中某些元素的个数、样式即可获得量化数据。除此之外不需要任何其他额外信息，也不需要其他额外的估算或度量过程。
预防针
下面的例子中将会看到大量度量数据，对于曾经用过传统估算、度量方法的读者，可能会心生恐惧。
不过，全部这些数据，不是来自独立的或者说额外的“度量和估算活动”，而是一种量化需求分析与建模方法的产物。在按照这种方法绘制完几个简单图形并根据图形元素编写Word后，可以从Word目录直接生成度量数据。配合本书提到的Word和Excel模板，全程只需要2分钟就能自动计算得到规模、工作量、进度、某些类的数量、某些方法的数量、测试用例、质量……等数据，也就是本章所提到的所有数据。
第一天
产品经理兴冲冲地走进会议室，高层经理昨天已经同意了包括“在已有电子商务网站上增加收发货等子系统”的新版本提议，不过需要项目组尽量简化功能，以逐步递增功能的形式推进。
愿景
尽管需求很不明确，但领导倒是提出了一些抽象的愿景。比如其中一条是做一个“值得信赖的收发货子系统”。一般团队或许此时会一筹莫展，但这个使用QUML的团队花费15分钟讨论绘制了这样一张“角色-业务图”：
买家在确认收货后才，店主才会和物流结帐，这样就保证了物流“值得信赖”。尽管可能还有其他实现方案或者扩展功能——比如买家可以评价物流——但是团队决定这个版本到此为止。
实体，关系
10分钟后，人们分析下面这张“实体-关系图”中的数据是实现这个版本的充分必要条件：
这个实体关系图可不是凭空来的。店主，物流，买家是愿景图里边的；结帐记录来自“结帐”“收账”两个词的宾语，而“发货记录”来自“发货”“送货”“确认收货”三个词的宾语。
规模，工作量
这个子系统中的2个业务数据（即实体，“结帐记录”和“发货记录”）预示着2×平均35功能点=70功能点的规模（注：这里不是我们口语中常说的“功能点”，而是与IFPUG和NESMA兼容的国际标准功能点，有严格的定义和很好的一致性、可比性），换算成人天差不多也正好是70人天左右的工作量——碰巧当前中国业界的生产率大约就是1功能点需要1人天——不过这是覆盖从需求到上线所有活动的工作量。作为开发团队，他们感受到的只有一半左右，也就是35人天。
这个数据不会很准，但由于领导需要下午就要给出一个大致的工作量估计，因此团队没有进一步细化需求，而是转而分析其他子系统。
整个版本
最终，团队又用类似方法分析了所有其他这个版本的子系统（本例中未给出），最后估算出整个新版本总计需要400功能点，也就是大约400人天的工作量。不过，这是按照业界数据估算的结果，他们团队决定按自己的生产率修正到300人天——这得益于他们已经统计和修正过自己的生产率数据——5个人工作60人天，也就是大约3个月的时间。团队决定使用3个迭代来完成开发，最后一个迭代包括部署上线。