博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
软件架构师之职责范围
阅读量:4597 次
发布时间:2019-06-09

本文共 1434 字,大约阅读时间需要 4 分钟。

  上一篇<>讲述了做为一名合格的架构师应该具备哪些基本条件。当我们具备了这些条件的时候就可以选择成为架构师了。这时候我们就应该知道软件架构师应该做些什么,不应该做些什么,也就是软件架构师的职责范围。

  由于国内外软件土壤差别巨大,适合国外的一些理论在国内不一定行的通,而国内的一些资料往往都是根据国外的资料直接搬过来用的,这也直接导致国外的软件架构师在国内变得水土不服。今天本篇随笔的内容则是在一些培训资料的基础上,加上自己的思考,总结出来的适合国情的软件架构师职责范围。

  1,需求整理分析
  有人认为 架构师是在需求规格说明书完成后介入的,但我认为架构师要从项目最开始的阶段就参与进来。理由有很多:首先,第一手的信息损失最少,架构师能够更好的把握需求;其次,分析人员在与客户交流时,往往不会深入挖掘需求,因为有很多隐藏的需求客户自己都不见得意识的到,而架构师则可以依靠敏感的软件嗅觉发现这些需求,减少以后的变数;第三, 分析人员往往脱离开发团队,盲目接受客户需求,而 架构师能够清楚把握现有的研发团队能做什么,不能做什么,提前预知风险,降低项目失败的机率。
  
2,系统分解
  在收集完信息后,架构师需要将用户需求转化为软件需求,同时要补充非业务需求,如健壮性,扩展性等等。 如何区分和化解用户需求与软件需求,如何有效把握用户需求与软件需求的区别,是 系统分解的核心。 这是最考验架构师的地方,也是只有架构师参与的工作。
  
3,技术选型
  这一步要根据对软件需求决定项目该使用何种架构,开发模型,及依赖选项。如使用多层架构还是分布式架构,是瀑布模型还是RUP,是使用MySQL还是SQLServer,是否需要使用企业库,是否需要使用ORM。但是,架构师对项目的技术选型要提供多种不同的方案,并为每种不同方案提供详细说明文档,用来阐述每种方案的优势,劣势,可行性等内容。这些文档供项目经理或领导决策最终的技术选型。
  
4,系统设计
  依据软件需求和技术选型,架构师需要和软件工程师一起将软件需求落实到软件详细设计说明书中。架构师负责将软件需求分解,重组织为子项目,子系统,组件和模块,以及它们之间的逻辑关系,从而形成不同的逻辑组成部分,最后还需要确定各个子系统及组件间的接口。 这些都是作为进一步的团队分工的依据。同系统分解一样,系统设计是考验架构师能力的重要职责。
  
5,培训与指导
  在软件详细设计说明书完成后,为保证项目的顺利进行,架构师需要对整个团队进行技术培训,让团队中的每个人明白自己的职责范围,该做什么,不该做什么。在项目实施过程中,架构师需要参与到具体开发过程中,给与每个开发人员有效指导,以避免团队成员对系统设计的误解而造成项目的延误。在我看来,这点对于新手比较多的团队尤为重要。因为国内新手的一个通病是眼高手低,刚学会了一点点就认为自己什么都会;当他们拿到真正的设计时又往往不知所措,畏首畏尾。
  
6,保持沟通
  沟通是保证项目顺利开展的有效保障。架构师要从多方面跟踪项目进度,及时与项目经理或直属领导汇报项目进展,与技术开发人员沟通遇到的问题,如果是迭代开发,还需要与用户沟通需求变更。
  以上是一个项目开发过程中架构师需要承担的主要职责,相比一些培训指导,我认为,架构师需要更深入地参与到项目中。

转载于:https://www.cnblogs.com/firstdream/p/3767346.html

你可能感兴趣的文章
任务就绪表OS_PrioGetHighest函数
查看>>
转:大灰狼的汇编视频教程笔记(下)
查看>>
javascript常见的几种事件类型
查看>>
关于大型网站技术演进的思考(八)--存储的瓶颈终篇(8)
查看>>
20+ 个很棒的 jQuery 文件上传插件或教程
查看>>
关于Struts2的多文件上传
查看>>
hosts学习整理
查看>>
github上的版本和本地版本冲突的解决方法
查看>>
ModalPopupExtender控件属性、功能
查看>>
js 工厂模式、简单模式、抽象模式
查看>>
扩展卡尔曼滤波(MRPT)
查看>>
如何解决Bluetooth系统设计的棘手问题
查看>>
加班两个星期做的一个小系统~(winform)
查看>>
排版系列1
查看>>
IDEA 生成 jar 包
查看>>
加减乘除混合版
查看>>
linux基础6-bash shell编程
查看>>
php 语法
查看>>
回顾MySpace架构的坎坷之路
查看>>
ubuntu系统无eth0网卡解决办法
查看>>