我想说，大家开发项目一定会混乱。因为大多数的开发都是经验谈，很少有方法论。混乱的根源在于需求不明确，因为很少有人将需求分层次，一般对开发级重视度不够。也很少有人对模块间的关系进行分析。所以，对模块间的关系也很少重视。但是，协作决定接口，没有协作，接口将来也不能满足应该用。开发经验很重要，但是也要有方法的指导。
架构是业务到系统的桥梁。将业务转换为我们要开发的系统。
1.需求阶段。这个阶段主目标是定关键功能，质量，约束。为概念架构做准备。
2.概念架构。这个阶段主要目标是回答客户的关心的业务（也可说是价值）如何实现，关心的问题如何解决。这里要注意：
1）用例图不能彻底覆盖系统，因为用例图并不能反应系统的非功能需求和约束。
2）不要过早概念架构不要进行接口+模块的设计。因为概念架构之前，并不能覆盖系统关键质量约束和非功能需求，也就不能明确模块间的关系，所以这阶段进行模块+接口的设计一定是不合理的。
3）概念架构只关心系统的关键部分。这样粗的看待系统，才能覆盖系统
4）围绕关进需求，质量，约束进行设计。
5）明确影响系统几个最大因素。针对关键问题进行设计。
6）概念架构要抓住客户关心的价值和担心的问题。
7）概念架构贵在有针对性，概念架构对关键部分，给出高层次的解决方案。主在确立架构大方向，针对关键要素进行设计和确定交互机制。（大体分层）
8）概念架构确定高层分割方案和其他关键决策是否合理。
概念架构的核心是发现职责，然后确定高层分割，考虑非功能需求。首先根据关键需求（质量，功能，约束，风险）发现职责（重点是发现职责，因为这是以后高层分割的基础），划分职责后确定高层分割。最后考虑非功能需求。这样大体确定系统的结构和交互机制。由于都是围绕关键功能和主要问题进行设计，所以一般情况下可以回答可会关心的功能和担心的问题如何解决。
3.细化架构。概念架构并不足以对并行开发做出指导和开发的规范。所以，要进行细化架构设计。这个时候要考虑接口+模块的设计。
累了，不写了，细化架构和之后的一些内容留到以后在写吧。今天的比较细，本人是粗人，并不喜欢太细的东西。最后写的内容一定要用一段话总结出来。就到这，剩下的以后写。