直挂云帆济沧海,展翅遨翔登九天!

我要飞得更高...

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  19 随笔 :: 0 文章 :: 5 评论 :: 0 Trackbacks
        一个软件的开发是一个极其复杂的过程,其中设计分析,设计、编码、测试、维护等,而系统分析却往往是一个软件成败的关键。
        如何进行系统分析,以及如何传递分析的的结果文档等,又是系统分析师的首要任务。系统分析对于任何人来说都不是容易 ,它没有规则的限定,它需要系统分析师的应变,虽然有相应的指导,但指导往往是教课书般,没有一个项目一尘不变地去原用教课书上的东西,更多的是经验。
        系统分析的成品即软件需求分析说明书,此书到底需要包括什么内容,到底是什么。这个问题很难回答,也许有很多人不加思索地可以答出,但我认为这个问题很难。这个由不同公司不同项目的具体情况决定的。从我的角度来看我觉得这个文档中的内容要走够设计师们看懂并可以作出设计。既然是为设计作打算,那么设计需要什么内容呢,这又涉及到设计方面的东西。
        需求来源于用户的一些“需要”,这些“需要”被分析,确认后形成完整的文档,该文档详细地说明了产品必须或应当做什么。如果只有一些零碎的对话、资料或邮件,就认为掌握了需求,那就是自欺欺人。需求是一个产品的源头,它的好坏对产品的影响最大,就像一条河流,如果源头被污染了,那么整条河流就被污染了。“用户”是一种泛称,可分为“客户”,最终用户或间接用户。需求分为两类,一类属于需求开发,另一类属于需求管理。需求开发分为需求调查、需求分析和需求定义。需求管理分为需求确认、需求跟踪和需求变更控制。需求开发的目的是通过调查与分析,获取用户需求并定义产品需求。需求调查的目的是通过各种途径获取用户的需求信息,产生《用户需求说明书》。需求分析的目的是对各种需求信息进行分析,消除错误,刻画细节等,常见的需求分析方法有“问答分析法”和“建模分析法”等。需求定义的目的是根据需求调查和需求分析的结果进一步定义准确无误的产品需求,产生《产品需求规格说明书》,系统设计人员依据《产品需求规格说明书》开展系统设计工作。需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。需求确认是指在开发方和客户共同对需求文档进行评审,双方对需求达成共识后作出书面承诺,使需求文档具有商业合同效果。需求跟踪是指通过比较需求文档和后续工作之间的对应关系,建立与维护“需求跟踪矩阵”,确保产品依据需求文档进行开发。需求变更控制是指依据“变更申请—审批—更改—重新确认”的流程处理需求的变更,防止需求变更失去控制而导致项目发生混乱。
         如何进行需求分析是需求调研中最重要的一步。需求分析是指在需求开发过程中,对所获取的需求信息进行分析,及时排除错误和弥补不足,确保需求文档正确的反映用户的真实意图。分析方法大体有两类:“问答分析法”和“建模分析法”。问答分析法:刨根究底地问,如果问题都被解答了,那么需求也就分析清楚了。建模分析法是指用图形符号来表示、刻画需求。
         在系统分析中,用例的重要性不用多说。真正理解了用例,懂得利用用例来驱动项目的开发,才能真正把握住需求的精髓。每个用例是一组场景的集合,而每个场景又是一个步骤序列。用例图通常是供客户和开发组参考的设计文档的一部分。用例之间可以以两种方式相互关联,一种方式是包含,即在一个用例中重用另一个用例中的步骤。另一种方式叫扩展,允许通过对已有用例增加步骤创建一个新的用例。用例之间的另外两种关系是泛化和分组。泛化是指一个用例继承了另一个用例。分组是一组用例的简单组织方式。 
       用例可以解释为某个参与者要做的一件事。也可以解释为一系列完成一个特定目标的“功能”的组合。这一件事可以解释为:1.这件事是相对独立的。它不需要与其他用例交互而独自完成参与者的目的。2.这件事的执行结果对于参与者来说是可观测的和有意义的。3.这件事必须由一个参与者发起,不存在没有参与者的用例。4这件事是以短宾短语出现。即这件事必须有一个动作和动作的受体。用例的背后是一种需求方法论。用例的核心是以参与者为核心,从参与者的角度描述他的日常工作,并分析这些日常工作是如何交互的。用例的首要目的不是要弄清楚某项业务是如何一步步完成的,而是要弄清楚有多少参与者?每个参与者都做什么?
         需求分析需要经过业务建模、用例分析和系统建模三部分组成。1.业务建模的目标是通过用例模型的建立来描述用户需求,需求规格说明书通常在这个阶段产生。2.用例分析是分析员用OO的方法来分析业务用例的过程,这个阶段称为概念模型阶段,这个阶段通常使用无类型的用例。3.系统建模是将用户的业务需求转化为计算机实现的过程,这个阶段通常使用无类型的用例和用例实现两种类型。系统范围、项目计划和系统架构通常在这个阶段形成雏形。业务用例(business usecase),是用来描述用户原始需求的,它的含义是站在用户的角度,使用用户的业务术语来描述用户在其领域所做的事。业务用例命名,描述都必须采用纯业务语言,不能出现计算机术语。业务模型是系统分析员和用户讨论需求,达到一致理解的基础。只有完成下面的工作,才能算是业务模型已经建立完成。1.发现和定义
       
posted on 2008-06-18 11:35 周大侠 阅读(387) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航: