怎样做一个优秀的系统分析师

系统分析师连接着用户的需求,系统分析师主导着开发的实现,系统分析师的素质高低对IT项目的成败起到很重要的作用。要想成为一名优秀的系统分析师,首先必须弄明白与系统分析师相关的一些职业理念和相关的工作概念定义。

笔者常常在思考一个问题,什么是系统分析师?什么样的人是优秀的系统分析师?什么样的人是企业真正需要的系统分析师?系统分析师也许很神秘,也许很抽象,他有很多其他称谓,比如需求分析师、分析师等等。你可以说系统分析师是IT技术专家,也可以说他是业务专家,甚至可以说系统分析师是管理专家,那么他到底是什么?

    也许,有一点我们可以确定,系统分析师连接着用户的需求,系统分析师主导着开发的实现,系统分析师的素质高低对IT项目的成败起到很重要的作用。 

    近年来,我国IT软件产业发展规律迅猛,需要大量IT人才,尤其需要居于IT人才金字塔顶端的系统分析师人材,笔者以自己的做系统分析师一些经验和对这个职业的理解,试图用一些文字研究系统分析师的素质和能力模型,以飨读者和广大IT技术人员、系统分析师同仁。 

    要想成为一名优秀的系统分析师,首先必须弄明白与系统分析师相关的一些职业理念和相关的工作概念定义。 

    一、如何理解系统、信息系统、系统分析、系统设计、系统分析师? 

    系统是一组为实现某些结果相互联系、相互作用的部件的集合体。而信息系统是一组完成收集、处理、储存信息和以输出完成商业任务所需信息作为提交的系统。系统分析是理解并详细说明信息系统应该做什么的过程。系统设计是详细说明信息系统的诸多组件在物理上是怎样实施的过程。 

    系统分析师是使用信息技术的商业专业人员,利用分析和设计技术解决业务问题。他是团队中的一种角色,主要负责与涉众客户代表协同工作,以便对项目需求进行获取、分析、编写说明规格、确认和管理,也可称需求分析师,业务分析员等。 

    做一名系统分析师,要首先认识什么是系统分析师。对于同样一件事物的认识,每个人都会不一样,“一千个人有一千个哈姆雷特”,这关乎到认识论。其实,一个人的认识正好折射出了他的经验、水平、层次、能力。一句话,大道由简,我们也许熟悉了很多系统分析方面的技术,然后我们需要问自己是不是真的懂这个职业的本质含义所在,一定不要舍本求末。 

    上面的定义很简单,但反映了一些基本的要素。系统分析师首先是商业人员,然后才是IT技术人员,但系统分析师不是程序员,他的使命是解决业务问题,手段是信息技术。他不但要理解还要会详细地说明,这意味着他的商业知识、理解分析能力以及表达能力是比较基础的核心能力。还有, 系统分析最重要的是实践过程。系统分析师最好和业务人员打成一片,这样才会获得用户的信任。 

    顺便需要说明的是,信息系统有很多种类型,常见的有OLTP、 MIS、EIS、DSS。当然,你还可以谈很多,其实,任何一个名词都足够写一本书,你就大胆地讲出你的理解吧。但一定要记得总结,用一句话能总结出来就不用两句话,系统分析这个职位对思维的清晰要求颇高。 

    二、系统分析师需要哪些技能? 

   
首先,系统分析师应熟悉如何建立信息系统,这要求相当高的信息技术能力,包括软件工程、主流技术架构、网络、数据库技术等等。 

    第二,系统分析师应必须熟悉自己正为之工作的商业行业,以及该行业如何使用各种类型系统的情况。

    最后,系统分析师应需要熟悉相当多的人及其工作方式,因为这些人是信息系统的使用者,或者说是系统分析师的“客户”。 

    系统分析师是“通才”,正是因为他们连接了IT和业务。优秀的分析师其实懂三种“世界”的语言,即计算机语言、商业语言、人的语言。 

    对于商业,有些分析师一生专门研究一个特定的商业行业,比如制造业、零售业、服务业或贸易行业。一个非常熟悉某特定行业的分析师能够为这个行业的公司解决一些复杂的问题。

熟悉这个公司则需要花费一些时间,尤其是细节方面,包括组织结构、使命、成功的因素、战略和计划、企业文化和企业价值。 

    总之,系统分析师=行业业务专家+IT技术专家+管理专家。 

    三、系统分析师解决问题的大致过程是什么? 

    系统分析师解决问题的大致过程一般如下: 

    (1)研究和理解问题。 

    (2)核实解决问题的效益大于成本。 

    (3)确定解决问题的需求。 

    (4)制定一套可能的解决方案,提供多种可供选择的方法。 

    (5)决定最佳方案并推荐给决策层。 

    (6)详细说明所选方案的细节。 

    (7)实施解决方案。 

    (8)监控结果是否达到预期结果。 

    这个是经过归纳的大致过程,实际还有其他经典的过程,与之的区别只是形式上不同,但求解问题的过程是一致的。 

    上面的步骤是经过归纳过的,也许不同类型的系统,不同类型的企业工作方法不尽相同,但从宏观的角度看的确是类似的。

    四、系统分析原型法的意义 

    原型(Prototype) 即样品、模型的意思。把系统主要功能和接口通过快速开发制作为“软件样品 ”,以可视化的形式展现给用户,及时征求用户意见,从而明确无误地确定用户需求。另外,原型也可用于征求内部意见,作为分析和设计的接口之一,可方便于沟通。 

    对原型的基本要求包括:体现主要的功能、提供基本的界面风格、展示比较模糊的部分以便于确认或进一步明确。原型最好是可运行的,至少在各主要功能模块之间能够建立相互连接。 

    原型法意义在于可视化、强化沟通、降低风险、节省后期变更成本、提高项目成功率。一般来说,采用原型法后可以改进需求质量。虽然投入了较多先期的时间,但可以显著减少后期变更的时间。原型法投入的人力成本代价并不大,但可以节省后期成本。对于较大型的软件项目来说,原型系统可以成为开发团队的蓝图。另外,原型通过充分和客户交流,还可以提高客户满意度。 

    原型法是在计算机技术发展到一定阶段,用户应用需求高涨的情况下发展的一种方法论,但它同时又是对开发人员有高要求的一种方法论。 

    原型法的基本思想如下: 原型法是确定需求策略,是对用户需求进行抽取、描述和求精。它快速地、选代地建立最终系统工作模型,对问题定义采用启发的方式,由用户作出响应。原型法实际上是一种动态定义技术。

  原型法被认为对于大多数企业的业务处理来说,需求定义几乎总能通过建立目标系统的工作模型来很好地完成,而且这种方法和严格定义方法比较起来,成功可能性更大。 

    原型法开发策略基于如下的假设:

 (1)并非所有的需求在系统开发以前都能准确地说明。

 (2)有快速的系统建造工具。

 (3)项目参加者之间通常都存在通信上的障碍。

 (4)需要实际的、可供用户参与的系统模型(system model)。 

    文字和静态图形是一种比较好的通信工具,然而其最大的缺点是缺乏直观的、感性的特征,因而往往不易理解对象的全部含义。交互式原型系统能够提供生动活泼的规格说明,用户见到的是一个“活”的、运行着的系统。理解纸面上的系统和操作运行在机器上的系统,其差别是十分显著的。因此,当能够提供一个生动的规格说明成为可能的话,人们就不会满足于一个静止的、被动的规格说明。

  总之,当提供一个活生生的系统模型时,人们对它的了解将比说明性材料好得多。

 (5)需求一旦确定,就可以遵从严格的方法。

 (6)大量的反复是不可避免的、必要的,应该加以鼓励。


在信息系统设计的过程中,常用的各种不同形式的部分原型有:

  (1) 对话原型

  原型模拟预期的终端交互,使用户可以从屏幕上查看他们将接收什么、进行的操作,并提出遗漏之处,从而加深正确的理解。终端对话的设计效果直接影响着系统的可用性和用户对系统的接受程度。

 (2) 数据输入原型 

    建立数据输入的原型,可以检查数据的输入速度和正确性,还能进行有效性和完整性的检查。

 (3) 报表系统原型 

    提供给用户的各种报告应在整个系统实现之前给用户看,报表子系统需要经常进行大量修改以满足系统的需要,因此,可以把报表生成器作为原型。

  (4) 数据系统原型

  首先生成一个含有少量记录的原型数据库,这样用户和分析师与它可以进行交互,生成报表和显示有用信息。这种交互经常导致产生对不同的数据类型、新的数据域或不同的数据组织方式的需求,还可以在原型化工具的帮助下探索用户将如何使用信息以及数据库是什么样的。

 (5) 计算和逻辑原型

  有时一个应用逻辑或计算是复杂的。审计员、工程师、投资分析师和其他用户可以使用高级程序设计语言建立他们所需的计算实例。这些实例可以组合在一起构成一个大的系统,与其它应用系统、数据库或终端相连接,用户可以使用这些计算原型检验他们所求结果的准确性。

  (6) 应用程序包原型 

    在一个应用程序包和其它应用系统相连或实际使用之前,可以通过一个小组用户来鉴定这个应用程序包是否令他们满意,若不满意可以进行大量的修改,直到令他们满意。

  (7) 概念原型 

    原型法是近年来流行的软件需求捕获方法之一。我们应该明白原型法是手段而不是目的。需要回答的要点是,原型法的背景、概念、定义、意义、如何实现原型、最好能够举例说明。 

    能够回答这些问题才能说明你完全掌握了原型法。很显然,提出这种问题的企业对这种方法在实际工作中是会相当倚重的,因此您不仅要知之还要行之。 

    以一个简单的案例来说明,王五是某家大型电子商务贸易公司的系统分析师,他负责做了一个询盘系统。由于询盘系统牵涉到许多抽象专业知识,因此为了便于沟通,王五经过一番研究制作了界面原型设计,并给出了解决方案,领导和客户看了原型设计后通过该需求方案。这个案例说明,今天的需求分析,不再是分析师和客户之间的访谈,更是一种通过实际原型(模型)互相启发,从而发现需求,归纳总结需求的一个实践过程。但我们可以看到,原型法只是一种手段,与用户良好的互动和沟通是获得需求的基本点所在。

posted @ 2010-08-28 16:14  hibernate3例子  阅读(119)  评论(0编辑  收藏  举报