这段时间看书主要还是在啃基本的定义，定义理解了之后就开始考虑如何应用到工作中。
目前我们的软件研发形式其实还是瀑布式的研发模式，各角色工作比较独立，等到开发研发结束后测试才能介入，而在开发研发阶段介入的话，目前业务测试可以产生价值的地方很有限。通过大半年来对版本bug注入阶段的分析，要想降低bug数量，前移bug发现阶段，对于业务测试而言，目前可以做两点，一是帮助开发细化业务实现，二是帮助开发明确业务边界。
开发阶段bug的主要原因为功能细节遗漏，影响考虑不周，配置疏忽大意，这三项占到了总体bug的70%左右
细化业务实现可以帮助开发减少功能细节遗漏和配置疏忽大意的问题，明确业务边界可以帮助开发减少影响考虑不周的问题。
而UML在这个过程中可以起到的作用是，统一文档出入口，加强文档的可回溯性，同时良好的可回溯性也会加强文档的可复用性和易读性，便于后期维护。
但与此同时，要使用UML使得uml在这个过程中起到作用，需要耗费的精力也是较大的。
我自己认为，首先需要确定根模型，即原始业务架构到软件业务架构到技术架构的映射，然后在此基础上进行集成。
-
优点：有了汇总了全过程的uml图，不管是哪个环节出现问题，回溯起来都会很快，同时对于该项只需维护进文档里，而不需频繁的写一些没有用的总结。
-
缺点：学习成本导致的时间成本增加；如果思想不一致，那么这个文档想以一种统一的方式进行维护很难，道理同代码维护。
目前在组内一些独立功能比如砂浆换算上进行过简单的实践，发现测试前期投入时间去做了分析并梳理的很细化，边界也确定的很明确，确实会对功能的测试结果有所帮助，但与此同时会降低单产。
但是uml这种思维会让人在定义边界以及确定粒度这两个关键问题上进行思考已经是这本书目前给我最大的收获了。
