楼主的文章太长，没看完。我就可重用简要的说说，请大家批评指正。
重用可以分为：
代码级的重用
组件级的重用
架构级得重用
设计思想方法的重用
甚至连文档都可以重用。
这都需要在开发中不断的总结、抽取、积累、完善。
其实，像MFC的Framework是最好的重用的例子。对于一个公司，可以建立一个相应的重用机制。在不同的阶段，启用不同的方法。
在最初的设计阶段，可以引用已经成形的重构，然后再实现阶段，可以在小范围上进行重构。如果项目结束，可以有一段时间进行系统级的总结和重构，回顾整个系统，可以有很大的收获，可以抽取出很多可再次利用的东西。
重用可以分为：
代码级的重用
组件级的重用
架构级得重用
设计思想方法的重用
甚至连文档都可以重用。
这都需要在开发中不断的总结、抽取、积累、完善。
其实，像MFC的Framework是最好的重用的例子。对于一个公司，可以建立一个相应的重用机制。在不同的阶段，启用不同的方法。
在最初的设计阶段，可以引用已经成形的重构，然后再实现阶段，可以在小范围上进行重构。如果项目结束，可以有一段时间进行系统级的总结和重构，回顾整个系统，可以有很大的收获，可以抽取出很多可再次利用的东西。
问题定义
问题是什么
关于规模和目标的报告书
可行性研究
有可行的解吗需求分析
系统必须做什么
系统的逻辑模型：
总体设计
功能设计详细设计
怎样具体地实现这个系统
编码规格说明(SDL)
综合测试
维护
关于重用
需求分析的重用
系统或子系统的功能要求 已经有现成模块（可能是组件，中间件，webService）
总体设计的重用
单个模块的设计完全相同
详细设计的重用
代码的重用如类库、通用的（MFC、VCL）或专用的（在项目开发前先将整个系统中会大量重复使用的东西，集中开发是有益的）
在目前的开发中大量的工作量在程序的实现，如动态的菜单，，，写了大量的代码
这些都是与开发的商业逻辑无关的。所以一个公司、软件工程师，应该积累自己的
类库，将把程序员极大地解放出来，更多地关注业务逻辑流程本身，而非技术上的细节。越是业务逻辑复杂规模大的软件，应该提高系统的模块化，总体设计时分成多个子系统，严格定义系统的接口，各个子系统可以单独开发，单独进化，选择几个子系统以可以组成系统，子系统可以单独完成一个功能。