软件体系结构师工做流程

软件体系结构师工做过程

软件体系结构师和建筑师在许多方面都是相通的，都是对于一个本来不存在的事物设计出轮廓，而后分步骤的对单个模块进行设计，同时要从全局角度考虑，保证总体的正常运行。经过课上的一期《梦想改造家》节目，我以为不管是建筑师，房屋设计师在新建或者改造一座房子前，通常也会须要通过需求的调查获取，而后对需求进行分析，发现其中的问题和问题的本质，而后根据发现的问题本质提出多种解决方案，选择一种比较适合的方案，进行有步骤的实施，同时对于实施过程当中出现的新问题也须要可以及时的解决，最后项目完成以后，须要交由用户检验。对于不一样的项目也没有一套通用的解决方案能够解决全部的项目问题，只能根据具体的状况再作具体的解决方案。

总结起来就是软件架构师的工做流程大概能够分为需求调研与分析，需求分解与规划方案，工程实施，工程交付用户。

需求调研与分析阶段，需求人员先听取用户当前出现的问题，全程快速记录，对于不太明白的地方要及时和用户进行沟通，同时分析用户是否还有潜在的需求没有表达出来，可能这种需求会在之后的软件中起到重要做用，因此需求阶段这部分需求尤其重要。在项目开发过程当中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须获得架构师的承认。架构师须要和分析人员反复交流，以保证本身完整并准确地理解用户需求。

需求分解与规划方案时，分析人员将记录的需求告诉架构师，架构师根据获得的这些需求将需求进行逐层分解，层层分离，逐渐探究出问题的本质问题。架构师经过对系统的一系列的分解，最终造成了软件的总体架构。技术选择主要取决于软件架构。Web Server运行在Windows上仍是Linux上？数据库采用MSSql、Oracle仍是MySQL？须要不须要采用MVC或者spring等轻量级的框架？前端采用富客户端仍是瘦客户端方式？相似的工做，都须要在这个阶段提出，并进行评估。架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际状况进行权衡，最终进行确认。根据这些本质问题，与分析人员和用户反复交流，共同商量，探究出比较好的，双方均可以接受的解决方案。解决方案肯定以后，须要与客户研究项目的交付日期，还有软件的交付质量等问题。最后将整个需求文档补充完整，进行需求总结，接下来就开始实施具体的解决方案。

工程实施阶段，须要组件软件的开发团队，测试团队等其余相关人员，给每一个人分配适当的任务，要让每一个人都能适宜的完成交代给本身的工做任务，同时要保证任务在肯定的期限内完成。期间，架构师的任务则是继续与用户沟通开发当中出现的问题，同时还要兼顾软件的开发进度以及软件的开发质量。在开发过程当中遇到的新问题，架构师也要可以及时的思考出对应的解决办法，对各个方面进行全面的思考，保证开发工程的顺利进行，在规按期限内完成开发工做。

项目完成以后，须要交付项目给用户。交付软件给用户时，须要让用户检验软件是否符合约定的指望，而且可否正常的顺利使用，此时应该交给用户详细的使用说明书等文档内容，若是软件与约定的质量有差异，则应向用户说明状况，并商量解决办法。若是后续有升级，则能够在后续版本当中弥补当前的不足状况。

软件的架构师和建筑师其实在不少方面仍是很类似的，在工做的流程上也存在不少的类似之处，善于倾听并引导用户的需求，分析需求当中的问题，抽取本质，并根据存在的问题提出解决方案，最后实施解决方案，达到用户的要求。

 

一个好的软件架构师基本的工做职责是在一个软件项目开发过程当中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的整体架构，指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员

在能力要求方面，在技术全面、成熟练达、洞察力强、经验丰富，具有在缺少完整信息、众多问题交织一团、模糊和矛盾的状况下，软件架构师能迅速抓住问题要害，并作出合理的关键决定的能力 l、具有战略性和前瞻性思惟能力，善于把握全局，可以在更高抽象级别上进行思考。主要包括以下：

1.对项目开发涉及的全部问题领域都有经验，包括完全地理解项目需求，开展分析设计之类软件工程活动等

2.具有领导素质，以在各小组之间推动技术工做，并在项目压力下作出牢靠的关键决策；

3.拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目成员的信任；

4.以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推进力，而非构想者或梦想家（追求完美）；

5.精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）；

6.具有系统设计员的全部技能，但涉及面更广、抽象级别更高； 活动肯定用例或需求的优先级、进行构架分析、建立构架的概念验证原型、评估构架的概念验证原型的可行性、组织系统实施模型、描述系统分布结构、描述运行时刻构架、肯定设计机制、肯定设计元素、合并已有设计元素、构架文档、参考构架、分析模型、设计模型、实施模型、部署模型、构架概念验证原型、接口、事件、信号与协议等。

在知识体系方面，软件架构（softwarearchiecture）也称之为软件体系结构，它是一组有关以下要素的重要决策：软件系统的组织，构成系统的结构化元素，接口和它们相互协做的行为的选择，结构化元素和行为元素组合成粒度更大的子系统的方式的选择，以及指导这一组织（元素及其接口、协做和组合方式）的架构风格的选择。软件架构是对系统总体结构设计的刻划，一直以来，对于架构的理解有两个基本概念，一个称之为组成，另外一个称之为决策。

组成：架构的组成概念强调"计算机及组件之间的交互"。例如在的初步设计中，"表示层"和"业务层"是两个粗粒度的黑盒，当内部也表达了一些粒度比较细的组件的时候，这两个黑盒变成了"灰盒"。交互的概念表如今架构描述了它们之间的关系，例如数据如何读取、功能如何调用等。

决策：架构决策不但表现了系统组织、元素、子系统的组织风格决策，还包括了非功能性需求的决策，例如对于可扩展性的决策，对于表示逻辑与业务逻辑变化的隔离，第三方工具包变化的隔离等，这就使架构有了弹性。架构的组成与决策是架构设计的两个基本概念，这两个概念并不矛盾，在架构设计中，每每是同时体现这两个概念，确保架构知足产品要求。由这两个概念出发，咱们天然会提出：软件架构的核心思惟究竟是什么呢？

首先，任何软件系统都是以知足需求做为目的，因此，好的架构设计必须以全面深刻的需求分析做为基础，根据需求来组织合理的产品架构。事实上架构设计是没有统一的模式的任何模式只有针对问题才有意义。做为架构设计来讲，必须对需求分析有足够的理解，这样才能有针对性地解决问题，才可能设计出真正优秀的产品来。

其次，一个软件系统的质量，很大程度上是由架构设计的质量决定的，因此架构师的眼光通常都专一于质量属性上，应该根据产品质量属性的要求提出合理的架构决策。可是很长时间以来，人们大都把目光关注在流程、方法、结构原理甚至编码的自己，而不太注意架构设计最本质的东西，思考的深度也欠深刻，结果，不少产品即便设计出来，后期运行中也是问题百出，特别是发生变动的时候带来了很大的困难。这就给咱们提出了一个问题，架构设计的思惟究竟是什么？

另外一方面，任何架构思想的实现，必须与具体的项目组织相匹配才能发挥做用。所以，系统架构师应该仔细研究现代项目管理的思想和方法，吃透其中的精髓，根据本身的设计思想，提出合适的软件工程策略。反之，一个软件工程策略，也不可避免的也会影响到架构设计的特色。

上述讨论引起了三个核心思惟，一个是架构设计的源泉来自于需求分析，第二个是架构设计重心和特色来自于质量需求（非功能性需求），第三个观点是，架构总体特征应该考虑项目管理特征。所以，软件架构设计是一个系统工程，它须要系统构架师有很宽的知识面，从需求分析、架构设计到类设计甚至代码实现一直到项目管理都须要有透彻的理解，这之间的关系是你中有我我中有你，是不可能截然分开的。必须说明，软件系统设计的方法不是一个僵化的规则，关键是在实践中实事求是的摸索规律，从而找出符合实际达到要求的设计来。

参考文档：

http://developer.51cto.com/art/200912/169389.htm

https://www.douban.com/note/484776935/

http://blog.csdn.net/huwei2003/article/details/51392131

http://wenku.baidu.com/link?url=3JUO4dSEzXC0qDnspPS8wL19fOvnjykD6c2LrDDzq_tlpiCD_6En89If3rR4pupn41RRgYUw88pADtf7KvOyyO-LoYll9KIJj_CTWAyxzG_