概要设计、架构设计、解决方案 的差异 - 软件工程/管理 / 开发过程版
越搞越晕了,
高手们来谈谈 概要设计、架构设计、解决方案 的差异 , 相同点及各自关注的角度
------解决方案--------------------
楼主提到的,我只对"架构"略有认识,其他的不懂,
我曾经给架构的定义如下:
至少在我的团队里,架构就是一套强制所有生产人员按照SOP执行的高度自动化的生产工具:
1、在目前我们的水平上,架构在同一个业务领域是项目无关的,
2、通过架构,团队的技术依赖降至基本不需要Coder的水平,
3、通过架构,项目可以快速重建,
4、通过架构,项目迭代没有数据库参与,
------解决方案--------------------
我的理解:
概要设计:
客户最初需求之后的产物,主要分为业务功能和非业务功能两大部分。
包括对系统业务整体描述的业务设计,还包括对软硬件环境要求的非业务设计。
架构设计:
概要设计之后的产物,主要是对系统软硬件环境构成的整体设计。
解决方案:
是在架构设计过程中,软硬件环境构成及之后正式开发的可行性分析与提案等。
以上是自己从工作中总结的皮毛,随便说说而已,愚昧之处请大家见谅,并请指正,谢谢。
------解决方案--------------------
补充一下,这些几个过程并不是完全独立分开的,可能会有一部分重复与融合,而且要在之后的设计过程中根据客户的反馈与新需求结合,不断地修正与完善。
------解决方案--------------------
我的理解:
概要设计:具体到系统中,系统用到的技术及其他软硬件说明,和系统的功能概要。
架构设计:具体到系统中,系统设计风格,B/S,C/S.
解决方案:也就说明你如何实现系统要求,采用了那些技术,怎么划分系统功能。
------解决方案--------------------
------解决方案--------------------
概要设计:取决于系统分析师对业务领域的经验,将需求捕获为用况,识别领域中的类和对象。该设计的核心就是要搞清楚这些对象和类之间的关系。这种关系是逻辑上、抽象的、没有量化的。但是真实的体现了“系统对用况的相应”
架构设计:构架其实不能够理解为整体设计,系统构架是支撑起整个软件系统的骨骼。“壮而瘦”、“简而精”,就好比是框架式建筑物的钢铁框架。这样讲有些笼统,应用到较大的系统开发的时候就有所悟了。PS:这2年时间以来我都在改造staruml。
解决方案:在RUP中,解决方案侧重于用况的分析、执行策略的确定,以及评估标准的确定。从传统的观点来说,解决方案只包含方案的生成阶段,具体的执行阶段是另外划分的