1、何时开始架构分析？
最好在第一次迭代前开始。因为，架构分析的失败会导致高风险。如：必须支持英语、在一秒响应时间内支持500个并发事务。
UP是迭代和进化的（不是瀑布式的），所以架构分析和开发工作齐头并进，一旦高风险问题没提前提出，优先级不高，会导致高风险。
2、变化点&进化点
变化点：原来没想到，新加或修改或删除的。如：必须支持多个税金计算接口
进化点：原来想到了，今后可能会发生。
这2点会导致架构设计中，事先决定好采用何种设计模式。例如：对于变化点，采用Decorator等适合的模式；对于进化点，事先设计设计模式，如多个税金接口可采用Facade、Strategy等模式。
总体原则就是，面向接口编程，做到未雨绸缪。对于变化点，不知道以后会发生什么变化，因此更要面向接口编程，利于以后的扩展实现。我认为：
只针对核心业务或复杂业务设计接口即可
3、什么是架构分析？
是在功能性需求（例如处理销售等）的语境中，识别和解决系统非功能性需求（如安全需求）的活动。包括识别变化点和最具可能性的进化点。
常见问题：
1）、可靠性和容错需求如何影响设计？如：那个一个远程服务（如：税金计算器）需要容错到本地？为什么？本地与远程的差异在哪儿？
2）、技术选型，采用开源构件还是收费的？
3）、可适应性和可配置性需求如何影响设计？如：客户可能经常改什么参数值？业务规则是否经常变化？从而决定配置参数是否写入配置文件中，是否采用规则引擎实现动态业务。
4、架构分析的步骤是什么？
第一步：识别和分析对架构有影响的非功能性需求（架构因素）。架构因素，参见《FURPS+与补充性规格说明》
初始阶段：在补充性规格说明或用例中粗略的记录部分此类需求。
细化阶段早期：更仔细的对这些需求做调查
第二步：解决以上非功能性需求。（架构决策）
A、删除需求
B、定制解决方案
C、终止该项目
D、雇佣一个专家