快捷搜索:

关于项目建设需求分析阶段的IT监理工作机制和方

1、需求阶段监理的定位

原则上尊重承建方的项目治理和项目阐发能力,在详细的义务开展上,以不深入、不滋扰承建方的自立权为主,然则假如在项目相助历程中发明中软项目治理以及项目阐发能力在本项目的进行上存在很大年夜的差距和不够,为了包管项目的成功顺利开展监理内部必须加强项目治理能力和项目阐发能力,在详细的操作上可以坚持接受、同化、贯彻的措施和手段。

2、需求阐发的进展要领及监理角色的把握

需求阐发是一个项目的起头,也是项目扶植的基石,在以往的扶植掉败的项目中80%的是因为需求阐发的不明确而造成的,是以一个项目的成功的关键身分之一,便是对需求阐发的把握程度上,项目的整体风险详细体现要领在需求阐发不明确、营业流程分歧理上,用户不习气或者不乐意去用承建方的软件,或者很难去用,造成了项目掉败。是以作为第三方的监理公司,必须提醒承建方、客户方注重需求阐发的紧张性,采纳需要的手段和措施来进行需求调研。同时监理方也应深入详细的需求调研中去,只有这样才能万万实实的把握用户的需乞降偏向,才能在将来的功能界定、开拓范围上有谈话权。

?.1、为什么咨询监理方要对需求阐发进行重点监控

因为项目的特殊性和行业覆盖的广阔性,以及需求阐发的高风险性,以是在全部软件的开拓周期中,需求阐发的紧张性是不言而喻,需求阐起事做的切实着实确难做,这是基础是因为以下几种缘故原由造成的:(1)客户说不清楚需求;(2)需求自身常常更改;(3)阐发职员或客户理解有误。

2.1.1客户说不清楚需求

有些客户对需求只有朦胧的感到,当然说不清楚详细的需求。例如全国各地的很多部门、机构、单位在进行利用系统以及收集扶植,客户方的引导和办公职员大年夜多不清楚谋略机收集有什么用;短缺系统的IT扶植方面的专家和常识。这光阴就会要求软件系统阐发职员替他们设想需求。工程的需求存在必然的主不雅性,为项目扶植埋下潜在的风险。

2.2.2需求自身常常更改

根据以往的历史履历,跟着客户方对信息化扶植的熟识和自己营业水平的整合前进,会在不合的阶段和时期对项目的需求提出新的请乞降需求变化,其其实历史上没有一个软件的需求篡改少于三次的,以是必须吸收“需求会更改”这个事实,以是在进行需求阐发时就要防患于未然,尽可能地阐发清楚哪些是稳定的需求,哪些是易变的需求。以便在进行系统设计时,将软件的核心修建在稳定的需求上,同时留出变化空间。咨询监理方在需求阐发的功能界定上担负一其中心、公道、公正的角色,以是也必须介入到需求阐发的筹备中来,以便帮忙客户方和承建方来界定“做什么”、“不做什么”的系统功能边界。

2.1.3 阐发职员或客户理解有误

软件系统阐发职员弗成能都是全才,更弗成能是行业方面的专家。客户表达的需求,不合的阐发职员可能有不合的理解。假如阐发职员理解错了,可能会导致今后的开拓事情吃力不谄谀,记得一则笑话“有个外星人世谍匿伏到地球密查情报,它给上司写了一份申报:‘主宰地球的是汽车。它们喝汽油,靠四个轮子滚动提高。嗓门极大年夜,在夜里双眼能射出强光。……有趣的是,车里住着一种叫作‘人’的寄生虫,这些寄生虫完全节制了车。’”以是阐发职员的常识的埋头性也会造成需求阐发的误解和掉败。这光阴咨询监理公司就必须根据实际的项目需求调研计划,提醒承建方加强营业懂得水平和重视沟通技术。

2.2咨询监理公司若何进行需求阐发

需求阐发不象侦察推理那样从蛛丝马迹动手。应该先懂得宏不雅的问题,再懂得细节的问题,

一个利用软件系统(记为 S)的涉及面可能很广,可以按不合的问题域(记为D)分类,每个问题域对应于一个软件子系统。

S = { D1,D2,D3,… Dn }

问题域Di 由多少个问题(记为P)组成,每个问题对应于子系统中的一个软构件。

Di = { P1,P2,P3,… Pm }

问题Pj有多少个行径(或功能,记为F),每个行径对应于软构件中的实现接口。

Pj = { F1,F2,F3,… Fk }

按图布局写成的需求阐明书,对付那些只想懂得宏不雅需求的引导,和必要懂得细节的技巧员都相宜。在写需求阐明书时还应该留意两个问题:

(1)最好为每个需求注释“为什么”,这样可让法度榜样员懂得需求的本色,以便选用最相宜的技巧来实现此需求。

(2)需求阐明弗成有二义性,更不能前后相抵触。假如有二义性或前后相抵触,则要从新阐发此需求。

2.3咨询监理公司需求阐发措施论

根据以往的工程履历基础觉得需求阐发事情措施,应该定位在“三个阶段”(也称“三步法”)

首先:“访谈式”,这一阶段为和详细用户方的引导层、营业层职员的访谈式沟通上,主要目的基础是从宏不雅上把我用户的详细需求偏向和趋势,懂得现有的组织架构、营业流程、硬件情况、软件情况、现有的运行系统等等具表实际、客不雅的信息。建立起优越的沟通渠道和要领,针对详细的本能机能部门以及各委办局最好能指定本次项目的接口人。

实现手段:访谈、查询造访表格

输出成果:查询造访申报、营业流程申报

第三阶段:“确认式”,这一阶段是在上述两个阶段成果的根基上,进行详细的流程细化、数据项切实着实认阶段,这个阶段承建方必须供给原型系统和明确的营业流程申报、数据项表,并能清晰的向用户描述系统的营业流设计目标。用户方可以经由过程检察营业流程申报、数据项表;操作承建方供给的DEMO系统,来提出反馈意见,并对已经可吸收检察过的申报、文档具名确认。

实现手段:拜访(回首、确认),提交营业流程申报、数据项表;原型演示系统

输出成果:需求阐发申报、数据项、营业流程申报、原型系统反馈意见(后三者可以统一归入需求阐发申报中,提交用户方、监理方进行确认和存档)

整体来讲,需求阐发的三个阶段是需求调研中弗成漠视一个紧张的部分,三个阶段或者说三步法的实施和采纳,对用户、承建方来讲,都同样供给了项目成功的包管。当然在系统扶植的历程中,分外在采纳迭代法的开拓模式后,需求阐发的事情会不停进行下去,在后期的需求改进中,基础是处于今后两个阶段。

您可能还会对下面的文章感兴趣: