系统架构师与系统分析师的区别

[shuihan20e]

上周六才参加了软考，今天在群里看到有人问系分与架构的区别，一朋友的回答很有意思，发上来给大家乐一下

上联：系分就是跟着老板出去胡吃海喝，吹牛无边
正联：架构就是带领团队在家苦逼开发，加班无底
横批：技术最牛，钞票最大

[Josslin025]

系统分析师的侧重点是需求，系统架构师的侧重点是如何技术实现。

[无怨_无悔]

确实不错，很有道理。

[delphi_dcs]

这个学习学习，呵呵

[bpboy2008]

分析师解决"做什么"的问题, 架构师解决"怎么做"的问题. 分析师侧重点在系统开发周期的前半部分 架构师侧重点在后半部分 分析师主要是整理需求, 形成需求规格说明书 架构师根据需求文档, 把软件实现 分析师如果对用户的需求理解不充分, 会造成做出来的软件与用户偏差的预期 分析师的输出是架构师的输入 架构师的输出就是建模, 系统和模块的概要和详细设计 他的输出是软件工程师的输入 软件工程师就是软件的编码实现

[zvc666]

5.23 裸考高项

[wuwh____]

引用 49 楼 hbu_pig 的回复:

引用 34 楼 birdsaction 的回复:

系统架构师显然是懂把系统搞大，系统分析师是分析搞大后的系统是什么个样子。 其实是一唱一和的结果。

也不是搞大，就是软硬件平台的一个架构搭建，可兼容，可扩展

不错,现在越来越觉得一个好的架构很重要了,被现在的维护开发伤透了,但是我只会根据以前的开发经验去整理,完全没有理论支持```

[欢乐的小猪]

哎，我工作跟架构不沾边。

引用 104 楼 wuwh1986 的回复:

不错,现在越来越觉得一个好的架构很重要了,被现在的维护开发伤透了,但是我只会根据以前的开发经验去整理,完全没有理论支持```

[xuyanquan]

不懂不懂啊，架构师太遥远了

[一直在努力中]

你别吓我啊，我的方向就是往构架师走的啊，然后再到CTO

[娃都会打酱油了]

《.NET设计规范：.NET约定、惯用法与模式》这本书更多的还是讲规范吧，4+1本来就是讲究的活用，然后每一部分都可以出特定的东西给到相关人员，而且这也不是什么必须的东西，只是一个指导性方法而已，教你从哪几个角度去考虑系统的设计，你按照它来考虑，则考虑的更全面，更容易让其他人了解接受，不按照它来，也没人说不能开发出一个稳定的系统来，况且如果你就是简单的帮别人做个小工具，谁吃饱了没事瞎设计…… 顶着个架构师的头衔对程序员呼来喝去的，这其实就跟顶着个经理的头衔呼来喝去一样让人反感

引用 107 楼 FreeWick 的回复:

不好意思，没注意到你的回复。4+1就很好呀，关键是要对开发工作有用，不能流于形式，顶着个架构师的头衔对程序员呼来喝去的。 可复用性关键是框架设计，我一直参考《.NET设计规范：.NET约定、惯用法与模式》。 [quote=引用 88 楼 starfd 的回复:] [quote=引用 87 楼 FreeWick 的回复:] 一看就是RUP的4+1，非功能性需求可不是只针对运行视图，部署视图通常要考虑性能和安全性，这都是ilities。逻辑视图和开发视图当中，不也要考虑可复用性吗 [quote=引用 86 楼 starfd 的回复:] [quote=引用 85 楼 FreeWick 的回复:] 让我说什么好，架构师的任务是解决非功能性需求，功能性需求对应的设计是系统设计，而不是架构设计。

非功能性需求只针对运行视图，功能性需求对应逻辑视图和开发视图，怎么跟架构设计没关……[/quote][/quote] 可复用性跟 性能有一定的关系，但更多地是跟健壮性、可扩展之类的有关，当然4+1视图中彼此之间是相互影响相互依赖的，硬把非功能性需求全归纳到运行视图本身也有问题 看样子你对这方面有所研究啊，有什么可以推荐的资料或者文章吗？[/quote][/quote]

[其实我是真性情]

好像很厉害的样子，虽然我已经没分了

[龙井茶Sky]

架构师，不是你会设计数据库表、需求分析、编代码那回事。 架构师，应该从程序框架整体出发、规划系统使用什么技术框架、底层设计的吧 分析师，感觉更像对需求分析、进行数据库设计的 架构师更屌吧

[freewick]

架构师主要出现在设计和构建阶段，架构模式和风格的选择，关键的技术决策。通常架构师也是资深软件工程师，能解决技术难题。如果是敏捷开发，还要负责关键代码的重构。 系统分析师最早出现在系统规划阶段，负责可行性分析（包括经济可行性），解决方案。从知识结构上看，系统分析师还要掌握投资，财务管理，营销等各方面的知识。

引用 110 楼 ewqewqqwe 的回复:

架构师，不是你会设计数据库表、需求分析、编代码那回事。 架构师，应该从程序框架整体出发、规划系统使用什么技术框架、底层设计的吧 分析师，感觉更像对需求分析、进行数据库设计的 架构师更屌吧

[大炮V587]

真形象！

[Eric_Hxy]

系统分析师在问题域 系统设计师在解决域 架构设计师在二者之间

[信仰诠释过往]

反正不管怎么样，最后总是程序员的锅

[freewick]

不好意思，没注意到你的回复。4+1就很好呀，关键是要对开发工作有用，不能流于形式，顶着个架构师的头衔对程序员呼来喝去的。 可复用性关键是框架设计，我一直参考《.NET设计规范：.NET约定、惯用法与模式》。

引用 88 楼 starfd 的回复:

[quote=引用 87 楼 FreeWick 的回复:] 一看就是RUP的4+1，非功能性需求可不是只针对运行视图，部署视图通常要考虑性能和安全性，这都是ilities。逻辑视图和开发视图当中，不也要考虑可复用性吗 [quote=引用 86 楼 starfd 的回复:] [quote=引用 85 楼 FreeWick 的回复:] 让我说什么好，架构师的任务是解决非功能性需求，功能性需求对应的设计是系统设计，而不是架构设计。

非功能性需求只针对运行视图，功能性需求对应逻辑视图和开发视图，怎么跟架构设计没关……[/quote][/quote] 可复用性跟 性能有一定的关系，但更多地是跟健壮性、可扩展之类的有关，当然4+1视图中彼此之间是相互影响相互依赖的，硬把非功能性需求全归纳到运行视图本身也有问题 看样子你对这方面有所研究啊，有什么可以推荐的资料或者文章吗？[/quote]

[shuihan20e]

引用 108 楼 starfd 的回复:

《.NET设计规范：.NET约定、惯用法与模式》这本书更多的还是讲规范吧，4+1本来就是讲究的活用，然后每一部分都可以出特定的东西给到相关人员，而且这也不是什么必须的东西，只是一个指导性方法而已，教你从哪几个角度去考虑系统的设计，你按照它来考虑，则考虑的更全面，更容易让其他人了解接受，不按照它来，也没人说不能开发出一个稳定的系统来，况且如果你就是简单的帮别人做个小工具，谁吃饱了没事瞎设计…… 顶着个架构师的头衔对程序员呼来喝去的，这其实就跟顶着个经理的头衔呼来喝去一样让人反感 [quote=引用 107 楼 FreeWick 的回复:] 不好意思，没注意到你的回复。4+1就很好呀，关键是要对开发工作有用，不能流于形式，顶着个架构师的头衔对程序员呼来喝去的。 可复用性关键是框架设计，我一直参考《.NET设计规范：.NET约定、惯用法与模式》。 [quote=引用 88 楼 starfd 的回复:] [quote=引用 87 楼 FreeWick 的回复:] 一看就是RUP的4+1，非功能性需求可不是只针对运行视图，部署视图通常要考虑性能和安全性，这都是ilities。逻辑视图和开发视图当中，不也要考虑可复用性吗 [quote=引用 86 楼 starfd 的回复:] [quote=引用 85 楼 FreeWick 的回复:] 让我说什么好，架构师的任务是解决非功能性需求，功能性需求对应的设计是系统设计，而不是架构设计。

非功能性需求只针对运行视图，功能性需求对应逻辑视图和开发视图，怎么跟架构设计没关……[/quote][/quote] 可复用性跟 性能有一定的关系，但更多地是跟健壮性、可扩展之类的有关，当然4+1视图中彼此之间是相互影响相互依赖的，硬把非功能性需求全归纳到运行视图本身也有问题 看样子你对这方面有所研究啊，有什么可以推荐的资料或者文章吗？[/quote][/quote][/quote] 扯不到4个视图+1个场景吧

[shuihan20e]

引用 85 楼 FreeWick 的回复:

让我说什么好，架构师的任务是解决非功能性需求，功能性需求对应的设计是系统设计，而不是架构设计。

有道理，架构设计就要考虑安全性，可靠性，性能等方面，没有最好的架构，只有最合适的，任何架构都是有弊端存在的

[疯狂糖三角]

架构就像是外星人，很多人都听说过，没有几个人见过