Enterprise Engineering Forum

企业工程论坛
Categorized as: 企业管理,需求与规划   Tagged as: ,, , , ,

企业应用相关知识技能领域与角色分析四:设计者

Author: 余彤鹰,  Source: 企业工程论坛,  Published: 2011-07-05

Excerpt: 本文是系列文章的第四篇。在前面两篇提出的九种企业应用知识与技能领域,和对“管理+IT”跨领域复合型人才讨论的基础上,本篇针对企业应用设计过程的主要参与者进行专门的讨论。首先讨论了软件开发企业的常规岗位设置,及其相对于企业应用开发的功能设计环节所存在的问题。进一步,在对企业应用开发特点的分析基础上,探讨“功能/应用架构师”角色的导入,在这一角色基础上配置企业应用开发团队。

企业应用设计过程的参与者

企业应用(软件)的开发,大致上包括需求分析、功能、架构、软件设计、编码实现几个重要阶段。这里要较为完整地讨论企业应用设计过程中的重要角色,将涉及从所谓“需求分析”到“设计”完成(形成可交付编码实现的软件系统设计方案)的过程。企业应用系统的开发任务是非常多样性的,它们之间的差异可能非常巨大。例如,较为成熟的对于个别客户的定制/半定制开发业务,通常都有成熟的系统架构以及特定的平台/工具,所涉及的人员角色类型与要求,也在相当大程度上取决于这些基础环境与设施。本文的讨论,主要基于非针对特定客户的,在通用软件开发环境基础上进行全新企业应用(软件)系统开发的情形。

软件开发企业的常规岗位设置

在软件开发企业中直接参与“设计”工作(见前面范围的说明)的基本岗位,主要有需求/系统分析师、产品/客户经理、系统架构师(及/或技术总监或总工程师)等。技术总监通常是软件开发企业的通用职位,除了综合性技术督导,在参与具体产品设计的实质性工作时,它可能扮演系统架构师的角色。总工程师则是更老派的称号,职责通常与技术总监类似。这里的讨论将围绕系统开发的角色,所以后面的讨论将主要基于系统架构师而不是技术总监。

产品/客户经理,在不同企业及项目中的设置方式也可能有很大区别。排除掉与市场或客户服务相关的部分,产品经理也可能在企业应用系统的设计中担负重要的责任。然而,必须留意,它们首先属于业务/管理类职位而不是工程/技术或研发职位,也就是说,其自然的工作内容应当主要是管理型或业务/事务性的。

“系统架构师”近些年愈发常见[1]。国内传统的软件技术职称体系,覆盖相应职能的,大致是“系统分析师”。但系统架构师与系统分析师可能同时设立。稍微细致一些的分工,可分别设置“需求分析师”和“系统分析师”,将前者定位在用户业务/需求分析,后者与之衔接/协同提供技术解决方案方面的基础——或直接担负软件方案的设计。此时若另有架构师岗位,则可更为明确地定位在“架构设计/控制”方面,而将更具体的软件方案设计交给系统分析师。对于复杂的企业应用系统而言,系统架构师尤其重要。近些年IT的发展趋势,例如网络与基础平台环境、终端、实现技术等的多样性、开放性,互联网的崛起等,使得企业应用设计的技术环境变得空前复杂,架构的重要性超过以往任何时候。但无论如何,技术的选择、系统的技术架构,都是为功能服务的。这种复杂化的趋势,意味着企业应用开发者需要投入更多的资源和精力,但并不意味着任何对于应用功能方面的相对削弱。这个道理,可能很少有人会反对,但现实中的却常常被违背。

功能设计——常规岗位设置中隐藏的问题

在上述常规、典型的岗位设置中,隐藏着一个问题——从“需求”到“软件设计”中最关键的功能设计[2]到底由谁完成?在前面提到的常规岗位设置中,功能设计的主导责任有几种可能安排:需求分析师、系统分析师、系统架构师或产品经理。首先,传统软件开发的需求分析师,是广义的软件工程师的一种,它们的专业知识与技术,是软件工程的一部分(需求工程),先天就不是业务专家,甚至也不是软件功能设计的专家。系统分析师与系统需求师对应,其理想工作方式应该是根据功能设计的结果完成软件设计。系统架构师通常是专业软件开发团队中的顶级软件技术专家。要求他们兼职进行业务/需求研究,显然违反了最基本的分工原则。而产品经理,如前所述,本质上属于管理类职位,究其本职而言,更应该以管理/支持的角色参与有关用户业务/需求研究与功能设计的活动。

由此可见,在前述常规岗位设置中,达成软件设计最核心的活动之一“功能设计”活动,没有合适的专门角色。换言之,这类常见的开发组织风格弱化甚至忽略了本应相对独立于技术架构与软件设计的功能设计环节——它被淹没在需求分析、架构设计以及软件设计之间——同时也使得应用系统的整体思想和功能设计取决于软件术专家而不是应用/业务专家的判断和理解。

事实上,上述常见的开发体系风格,主要来源于也更适合于相对纯粹的技术型产品或项目开发,例如开发平台或工具、外包软件项目,以及那些设计者本身就使用或能够充分理解的产品,比如字处理软件、短信息平台、通用、只涉及常规事务的协同办公平台之类。这些产品的功能更容易由软件技术专家(例如架构师)直接理解,或者可以由有软件技术基础的调查人员(需求分析师)直接有效地进行“建模”。

企业应用开发的一些特点和特殊角色需求

我们认为,企业应用系统的开发,有以下几个方面的特点:

  • 用户需求具有天然的幼稚性、不确定性,必须进行深入有效的需求研究,而不只是调查、记录、传达、约定[3]。
  • 企业应用的功能将是复杂的业务中的有机组成部分,应用功能设计与业务规划是本质相连的,甚至直接涉及业务方法与模式的改变/创新。
  • 功能设计可能具有多种多样的选择;技术架构与实现技术可能制约某些功能的实现。
  • 功能设计不是单纯描述、建模,是创造新的复杂系统的过程。

由此,可以得出如下企业应开发的原则:

  • 需要业务/应用跨领域专家,将实质性需求分析与研究与功能设计密切结合。
  • 功能设计需要遵循一定的架构,这个架构至少有两个相对独立的层次:应用(功能要素)层次和系统实现层次。
  • 功能设计是在先的,但必须与技术性架构的设计过程有机结合。
  • 一个企业应用系统的设计过程,需要明确的主导者进行统筹,做出最终决定。

从角色分工的角度说,从以上原则中,可以归纳出这么一种角色:深入理解相关业务,是应用专家,掌握需求研究与功能设计的方法与技巧,充分理解可用的软件开发与支持资源,了解它们的可能性(能力)和限制。这一角色既非纯粹的业务专家,也非传统的需求分析师,按照架构师的岗位设计路线,可以将其称为功能架构师或“应用架构师”[4]同时,这个角色,比架构师更适合主导整个企业应用的设计过程。

以功能/应用架构师主导的角色配置

前面的分析,应该已经充分地说明,企业应用设计者(从需求到软件设计方案)应该是一个团队。一种比前面描述的常规方案更合理的角色分配可以是这样的:总设计师(功能/应用架构师)加需求分析师、系统架构师加系统分析师(必要时)。在这个团队中,功能/应用架构师带领需求分析师完成需求调查与研究,完成功能设计——当然,它可能会包含一些技术性思路或建议,这些涉及技术选择的问题,在确定过程中,已经与系统架构师和系统分析师交流并达成(正式的)共识。另一方面,系统架构师主持的技术架构和软件实现方案设计,亦需要由功能/应用设计师的参与和确认。无疑,这要求对软件开发相关技术必须有足够的理解。从上面的方案可以看出,这里重点提出和讨论的核心角色——功能/应用架构师——大大超出传统的需求分析师,需要独特的知识与技能。在后续文章中,我们还将基于以上讨论,给出它的定位和简明知识与技能需求模型。

另一方面,这里提出的角色配置模式,并不是对常见或传统配置的否定,而是一种可能的选择的方案:由系统(技术)架构师主导还是这里提出的功能/业务架构师主导,取决与产品特性更适合于技术导向还是应用(业务/功能)导向;企业应用应属于后者。

注释

[1 ]“架构师”(architects)从建筑领域借鉴而来,它的含义更接近设计者而不是建造者,它的理解应当基于架构(architecture)概念。本文的“系统架构师”对应的是企业应用软件系统层面,其它典型定位,还可以是业务层面(业务架构师,business architects)等。

[2] “功能设计”提出目标系统的完整的功能,它应该是“可实现”的,但不等于软件设计方案。一个理想的功能设计,只包含面向最终用户的要素,典型表达方式是“用户手册”以及某种功能模型及/或文档,其中原则上不直接包含技术方案要素——但充分体现实际可采用的实现/支撑技术的能力与限制。

[3] 传统需求工程的思路,主要集中在改进需求调查的手段,与用户沟通渠道,信息传递的精确性,表达方式(例如建模),规约的建立和维护等方面,对于需要与复杂业务高度融合的企业应用而言,是有所欠缺的。关于这个话题更多的讨论,见实质性需求分析与研究(ERAR)等文。

[4] 本文是从特定的角度引出并借用“应用架构”这个概念的,进一步讨论与企业架构领域的“应用架构”(applications architecture)的联系无疑是有意义的。另一个有关的角色,是近年常提的“业务架构师”(business architects),但它至少在字面上,更偏重于纯业务专家,而且其角色十分暧昧(比如,应该是属于应用企业的角色,还是软件开发企业的角色)。

Copyright

  本发布物版权归原作者所有,经原作者许可在企业工程论坛(EE-Forum.org)公开发布,并允许个人及公益性机构非牟利性使用及传播。传播中需保持从标题、署名到各项内容及此声明包括链接地址等完整内容不变。引用或摘编文中内容或观点应符合公认准则。其它机构,或牟利性使用,请预先取得作者许可。保留一切未说明的权利。
  详细说明见: http://www.ee-forum.org/about/copyright ,管理者电子邮箱:admin(at)ee-forum(.)org

Cite Style

GB7714 style: 余彤鹰. 企业应用相关知识技能领域与角色分析四:设计者[EB/OL]. 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2011-07-p2823.html, 2011-07-05[2017-09-20 01:12]

Chicago style: 余彤鹰, "企业应用相关知识技能领域与角色分析四:设计者", 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2011-07-p2823.html(accessed 2017-09-20 01:12)

Posted by   2011-07-05(Original)   Hits 8448   Modified 2011-07-05(Locked)
Prev Post: 
Next Post: 

Related Entries:

企业应用相关知识技能领域与角色分析五:实施支持者与用户
企业应用相关知识技能领域与角色分析二:管理/业务+IT复合型人才
企业应用相关知识技能领域与角色分析三:信息化领导者
企业应用软件和个人应用软件的区别
企业应用发展线索分析

4 Comments

  1. “功能设计”提出目标系统的完整的功能,它应该是“可实现”的,但不等于软件设计方案。一个理想的功能设计,只包含面向最终用户的要素,典型表达方式是“用户手册”以及某种功能模型及/或文档,其中原则上不直接包含技术方案要素——但充分体现实际可采用的实现/支撑技术的能力与限制。

    ===========================================

    在网上看过一段文字,觉的对上面的讨论有些参考价值,特录在此凑趣:

    我发现多数需求分析说明书编写得毫无价值,多数公司的做法是写完该需求说明书之后,就把它扔一边,埋头苦干写程序了.一方面这和公司对需求分析的认识不够有关,另一方面,也和需求分析编写方式不尽合理,以至它的价值难以体现有关.
    软件程序,从最终的抽象意义而言,是计算机系统对自然语言的翻译.而需求分析充当了翻译任务的急先锋.很难想象,如果没有一份好的需求说明书,针对客户含糊不清的自然语言描述,开发者能做出一个符合要求的优秀软件.然而,什么是好的需求说明书?应具备什么样的特点?我认为好的需求说明书应有由如下三个阶段,经多次循环反馈而逐渐形成:

    1 调研阶段:
    客户和需求分析师讨论系统该具有的功能.客户希望系统能做什么,达到什么样的效果.需求分析师的责任是认真听取客户的原始言语,通过讨论,语言的提炼和客户达成共识,最终得到确切的需求–客户希望系统能做什么.这一过程运用的是自然语言,需求分析师必须具备良好的沟通能力,文字表达能力,并且必须具备客户领域内的相关业务知识,不使用用户不懂的计算机专业词汇.
    参与人员:需求分析师,客户,系统设计师.
    运用工具:自然语言.
    阶段成果:调研记录书.

    2 确定功能结构和设计系统原型:
    需求分析师和系统设计师讨论客户的需求.需求分析师针对调研阶段的记录,逐点提出客户需求,并用uml的用例概念,和系统设计师进行讨论.系统设计师根据这些需求,运用他的技术,知识和经验,将之分解总结为系统的功能结构.(此处仅针对应用系统而言,对于其他系统,可能还要总结进程结构或部署结构)得到功能结构之后,系统设计师还要构建系统原型,该原型用于和客户进行更好的交流.
    在这一阶段之后,由于得到了功能分解表和系统原型,需求分析师和系统设计师已明白系统的雏形,该成果将作为开发者和客户继续进行讨论的基础.
    参与人员:需求分析师,系统设计师(或该设计师领导的相关团队).
    运用工具:uml,构建原型的相关工具技术.
    阶段成果:功能分解表,系统原型.(大致的业务流程图)

    3 编写需求分析说明书
    在参照功能分解表和系统原型的基础上,需求分析师和系统设计师编写系统的需求分析说明书.该需求分析说明书作为客户和系统开发者的桥梁,既表达了客户想要系统做什么的愿望,又反映了系统开发者针对此需求得到的努力成果(功能分解表和系统原型).通过该说明书,对系统具有的功能和最终可能的形态,客户和开发者达成共识.
    有可能经过多次的1,2阶段的反复,最终才得到需求分析说明书.各阶段的成果应妥善保存.
    参与人员:需求分析师,系统设计师,客户.
    运用工具:自然语言,功能分解表,系统原型.
    阶段成果:改进的功能分解表,系统原型,(业务流程图),需求分析说明书.
    第1阶段,是开发者得到自然语言需求的阶段.该阶段的重要性不言而喻。
    第2阶段,是需求分析编写的核心阶段.很多公司会有意无意忽略该阶段.确实,该阶段耗费的人力和时间挺多,但这个阶段决不能马虎的进行,甚至忽略.只有详尽的将自然语言翻译成功能需求表,并为此构建原型,开发者对系统究竟能做什么和未来该怎么做的认识才会逐渐加深.并且,对应的功能界面,能够让客户大致认识到最终的系统会是什么样子.他能够据此提出自己的满意度,修改或者增加需求.

    • 余山兄,

      评论一下你贴的这段文字:

      这句“软件程序,从最终的抽象意义而言,是计算机系统对自然语言的翻译.”看来是作者自己的感触,无非是说,编程的过程就是把自然语言描述的“需求”(或功能?或所谓的“系统”?不得而知)翻译成程序语言表达。其实,这就是一种表面化的理解。

      后面的3点,则大致上复述了传统软件工程已有一些观点与方法,不很完整的叙述。

      我这篇文章主要针对分工角色,但涉及了我的观点,就是我在“实质性需求分析与研究”里概括的东西,首先就是要突破这里面隐藏的一些不合理假设。

  2. 我感兴趣的是这段话:
    该需求分析说明书作为客户和系统开发者的桥梁,既表达了客户想要系统做什么的愿望,又反映了系统开发者针对此需求得到的努力成果(功能分解表和系统原型).通过该说明书,对系统具有的功能和最终可能的形态,客户和开发者达成共识.

    与你的那段“典型表达方式是“用户手册”以及某种功能模型及/或文档”有类似之处,

    我感兴趣的是这里理清了三种语言:
    需求分析(调研)的记录语言或者描述语言,采用业务语言(自然语言),不涉及技术实现的部分
    功能模型设计语言:采用专业的计算机技术语言,比如UML语言,或者直接利用原型的屏幕演示,其中包括了功能框架的分解等,对需求的一种计算机的表达方式
    需求分析说明书,或者你说的“用户手册”的语言,应该仍然采用业务语言(自然语言),但是它虽然“原则上不直接包含技术方案要素——但充分体现实际可采用的实现/支撑技术的能力与限制。”

    • 这段话概括的不错,但这其实就是传统需求工程已经总结出来的基本认识。我的兴趣点是在如何超越这些现有认识中的问题,所以对这样一般性的复述不会激发特别的兴趣吧:-)
      余山兄有兴趣可仔细考察一下我在实质性需求分析与研究(ERAR)里的论述,虽然不算很充分,但认识的关键点基本有了。其中的问题也许并不很直观,但在你感兴趣的那段话中已经隐现了,比如,功能设计没有完成,何来功能分解表?原型法是SE提出了许多年的基本技术,为什么不能成为普遍的解决途径?

      我的着眼点与你上面所说并不太一样(不同才有更意义吧),你上面说的看法,我认为,基本上仍然属于现有需求工程的基本或较流行的观点范围:
      1)我强调功能设计的相对对立性。所以,功能设计的结果与需求分析(研究)的结果是两个层次的工作结果。
      2)“需求研究”的结果(当然,依然可以叫做需求研究报告之类)恰恰不限制对技术的涉及,反而应该更好地揭示特殊的技术关联/可能性/限制。
      3)功能建模强调计算机可转换或可执行,是现在计算机界(UML代表的那派)的两种努力方向。我的方向,不属于二者。虽然我并不是简单否定它们。我只会小心地说:至少对许多企业应用系统,还存在不同的途径。其中,与UML的可执行的异同是最微妙的。

Leave a Response

You must be logged in to post a comment.