过程

-----------------------------------------------------------------

1.成功项目的特征：
1)存在很强的架构愿景
架构关注结构和行为，具有良好架构的系统是具有概念完整性的系统，拥有“清晰的内部结构”是很关键的，
好的软件架构具有以下共性：
*它们由定义良好的抽象层构成，
*在每一层的接口和实现之间有清晰的分离关注；
*架构很简单：共同的行为是通过共同的抽象和共同的机制来实现的；
2)应用了管理良好的迭代、增量式开发生命周期；
 ---------------------------------------------------------------------
       没有指南，但有很好的定义，为成熟的软件开发组织提供了可预测、可重复的过程；
追求理性的开发过程，因为设计者需要指导，如果我们尝试遵循一个过程，而不是任意为之，那么我们就能够离理性更近一些；
软件开发过程的框架，从两方面描述，整体软件开发生命周期(宏观过程)和分析设计过程(微观过程)，宏观过程是微观过程的上下文，
1.宏观过程：软件开发生命周期
1)宏观过程的内容维：科目
在软件开发过程中制作原型，行为原型，
任何编程方式都应该支持概念验证原型的开发，以便让开发团队更好地理解一种思想，揭示风险；
一些好的软件管理实践，包括一些基本实践如需求管理、配置管理、测试和品质保证、代码走查以及编写文档
2)宏观过程的时间维：里程碑和阶段
初始，细化(探索)，构造(构建阶段就是从探索转向生产，缺陷发现率)，移交(alpha测试，beta测试)
3)宏观过程的时间维：迭代
决定迭代的平均时间即决定发布版本的时间间隔，
对6-12个月的项目，可能意味着2-6周发布一次；
对12-18个月的项目，可能意味着2-3个月发布一次；
对更大的项目，可能意味着大约6个月发布一次；

2.微观过程：分析和设计过程
从两个维度时间和内容来描述，
从抽象层次和内容(活动和工作产品)，
分析关注的是行为，而不是形式。
在设计开始之前拿出完整额分析是不可能的，也是不值得追求的。确保没有遗漏基本的行为模式，这样就足够了。

1)架构的重要性，所以要理解分离关注，
从架构的角度
从组件的角度
将需求分配到解决方案的元素中去，
确定元素---确定元素间的协作---确定元素--确定元素的语义，
选择怎样的细节层次来描述架构取决于待开发的系统以及所选择的开发过程的类型，
模型驱动架构MDA，
2）用文档记录架构
软件架构涉及多个方面，所以架构描述也应该包括多个方面，不同的视角和视图，
4+1架构视图模型(Kruchten)：
(1)需求视图(也被称为用例视图)，描述了架构重要性的需求，包括功能性需求和非功能性需求；
(2)逻辑视图
分析和设计元素、它们的关系以及他们组织成的组件、包和层，也描述了形成系统结构的关键机制和模式；
(3)实现视图
关键实现元素(可执行程序、目录)和他们的关系，
(4)过程视图
系统中独立的控制线程和哪些逻辑元素参与了这些线程
(5)部署视图
描述了不同的系统节点(如计算机、路由器和虚拟机/容器)以及具有架构重要性的逻辑元素、实现元素或过程元素在这些节点上的分配；
  其他不同的架构框架，有Zachman Framework、Department of Defense Architecture Framework
(DoDAF)和 Federal Enterprise Architecture(FEA)，
SAD软件架构文档，

3.架构分析，架构设计
组件分析，组件设计
1)识别元素
这项活动实际上是元素从一个抽象层向另一个抽象层演化，
分类技术，目的是识别面向对象元素(即经典面向对象分析、行为分析、领域分析、用例分析、CRC卡、有意义的英语描述和结构化分析)；识别面向对象元素包括两项活动：发现和发明，
在分析过程中，必须善于发现抽象，能够研究问题域并发现有意义的分析元素；
在设计过程中，必须善于从解决方案出发，创造出新的设计元素；
除了查看分析元素作为设计元素的灵感之外，也可以通过应用选择的架构模式、设计模式和一般的设计原则，将分析元素细化到设计元素，一些模式的例子包括IBM的eBusiness模式、架构模式和设计模式；
Cheesman and Daniels描述的企业组件设计原则？？
[54]
Herzum and Sims 描述的开发业务组件的最佳实践？？
[56]
分析机制将细化为设计机制；
里程碑和评价标准；

2)确定元素间的协作 P208