项目前期的系统分析.doc
项目前期的系统分析 在做 IT 项目的时候,往往难以把握,质量,时间进度,成本这三者之间的平衡。造成这三者之间的不平衡因素有很多,比方说用户需求的不停变更,项目的难度比较大,工作人员本身的原因等等。我们应该规避这些风险,让项目能够顺利的完成。如何规避这些风险呢 ? “困敌之势,不以战,损刚益柔“,这句话的意思就是以逸待劳,提前做好准备工作。 拿到一个项目的时候,如果首先不进行仔细的系统分析,到后期我觉的大部分的项目会让你痛苦。当然大部分的项目都是首先进行系统分析过的,但是少数的没有,或者做的很不仔细,或者是不够专业。如果你所在的项目组到后期没日没夜的加班修改,或者是没日没夜的赶进度,这时后你再好好想想,你们是不是做好前期的准备工作。 系统分析分析的方法很多,但是经过系统分析后得到的产物应该有:软件界面基本上确定,软件功能范围确定,系统性能,安全性级别确定,容错性确定。软件界面在这个阶段应该被确定下来,往往用户在这个阶段也不知道自己真正需要的界面是什么样子的,这个时候,我们应该也积极的态度去向用户提供方案,设计出好几种比较合适的界面,让用户去筛选。软件功能范围的确定也比较困难,往往用户也不知道自己要开发的系统需要实现什么功能,但是有明确的目的,这个时候的系统分析,我方应该采用积极的态度,关注客户所处的行业,到客户哪里去,用填写表格的形式,抛砖引玉,去得到客户的真正需求。准确的需求是我们应该开发系统应该实现的功能,然而某些模糊的需求,就会被排除在系统的范围以外,但是这些东西也应该需要考虑,可能是系统将来的扩展部分。系统的性能也比较重要,应该用 确切的,可以度量的参数来度量,性能的参数的确定,决定了后期开发中使用的技术与系统的组成方法等。 系统分析需要让客户参于进来,等需求完成后,应该由客户签字认收,这时候的需求应该已经是比较满足要求的了,这是以后进行开发的基本,如果以后有变动,都比较小,如果变化特别大,可以和客户进行交谈,拿到二期去做。 系统分析不能用平铺直述的语言去描述你的系统,应该语言结合图行,最好的方法是利用 UML 图对系统进行建立模型。要与客户一起去建立系统模型。问题的切入点首先是使用 UML 中的用例图去直接勾勒出系统的需要满足的功能 。因为用例图是一种图形语言,它能够更直接的体现出需要满足的功能。这个使用需要仔细定义每一个用例,最好是用表格来定义,一个用例一个表格。在表格中对用例进行详细的描述。通过用列图,这时候你已经可以了解系统大体上完成的工作。这个时候要全面,不能够有所遗漏,如果有所遗漏,对后序的操作都会有影响,这也你造成后期加班,或者系统报价遗漏的原因之一。 绘制用例图过后,可能你已经对系统的需要完成的功能已经有了大至的了解,但是还是不够确切,这时候应该使用 UML 活动图去描述你的每一个用例,通过UML 活动图,你会更明了系统需要 完成的工作。绘制完用例图过后,系统中基本的对象就已经确立下来了,可以确定基本的对象关系,你就可以对你要开发的系统进行分析了,集合该系统将要运行的实际环境,对系统进行性能方面的分析,在这个阶段可以得到系统的性能情况,通过这个阶段的研究,基本上可以提出几个满足要求的解决方案来。 通过研究活动图,和具体采用的技术,可以画出系统的时序图,时序图能够更加具体的表现出各个对象之间的通信关系,和整个系统的运行逻辑。系统架构师可以通过时序图定义出系统的类,接口。 通过对时序图的研究,可以得出系统的工作量,通过时序图 来确定系统进度表,最后通过进度表来进行系统的开发。通过这种开发方法,可以在早期就能够很好的遇见系统的复杂性,和系统中需要遇到技术难点,从全局的角度去考虑这个系统。从全局的范围去把握这个系统。 通过填写表格,或者是各种文档来确定开发范围,从而确定所要开发的系统中需要用的数据,即数据流,以及系统的业务流。了解系统的功能。通过用用例图,活动图,时序图,还有交互图的应用,其实是用一种简单的方法来对系统建立一个模型,通过用图纸的方法,来构建这么一个系统。通过这么一个图纸,我们可以大体的知道将来所要开发出来的系统看 以是个什么样子,它的性能到底符不符合用户的要求,如果不符合,我们可以在早期就规避这种风险。 往往失败的系统都不会进行全面的系统分析工作,因为大部分人会认为我们这样做会浪费系统的开发时间,我想这种想法是错误的,风险,我们是可以规避的,为什么非要等到我们开发到后期,或者是把系统提交给用户后,客户以系统功能不完全,或者是性能问题的原因,打发回来重做,然后再加班加点的累死自己兄弟姐妹们呢 ?