.NET技术支持者

  博客园 :: 首页 :: 博问 :: 闪存 :: :: 联系 :: 订阅 订阅 :: 管理 ::

我最近想写一篇关于国内项目开发过程分析的总结,目前列出了这些项目的一些阶段,希望得到大家的支持,多提意见。我会近期完善本文的。

希望dudu让我放首页收集下各位朋友的意见 谢谢!!!



一 、方案阶段
     在方案阶段首先从两个阶段分析项目的风险:1、公司是否对本项目所处的行业很熟悉或者对本项目的业务很熟悉以及是否做过类似的项目;2、本项目客户的业务是否规范,也就是客户的业务流程是否规范话。如果有其中的任意一条,那么风险之大可想而知,更不用说两天皆有了。那么我们怎么克服防止这些风险呢?如果是第一条公司在组建团队的时候就该考虑招聘熟悉相关业务的人员了;如果是第二条,我认为这时候公司的管理人员和客户接触时就该给客户打预防针了,再就是在合同中下点功夫了。
二、合同阶段
       在合同阶段主要注意的是以下几点:1、项目的功能模块范围;2、客户需求的变动;3、 对项目中某些功能模块做特殊的说明;4、开发进度和成本。
三、调研阶段
        在调研阶段主要注意的是以下几点:1、客户是否已运行系统以及运行环境等;2、客户的操作习惯;3、业务流和数据流;4、客户的主要干系人。
四、团队建设阶段
五、分析设计阶段
     业务需求的两下两上:
       对项目的业务需求的分析是一个项目的入口和最重要的事情,但是很多人员并不知道怎么考虑项目的业务需求。反而受项目范围管理的束缚走进了教条主义。自己认为,用户给多少钱就干多少事这句话本身没有问题,但是如果是基于这句话来管理范围、分析业务需求就容易走进了“只见树木不见森林”的陷阱。导致最后的返工、重做,用户的不满意、系统的不灵活,甚至修改一个小功能而牵动全身,或是根本就不能动设计的局面。
       一上:是指第一次自顶向下,先从全局了解业务,从更高的层面来分析模型。目前我们的大部分项目是企业或者政府的业务管理系统。那我们首先要了解企业的管理模式。这时候思维要开阔,不能只是局限在项目的范围之内。通过分析管理模式,找出问题。第一“上”,概括为:把握全局,寻找问题;
       第二步就是由上而下,找出了问题,从大的方面了解透彻后,要根据这些问题,对应到具体的需求的调研和设计实现。看一下如何满足和解决问题?由于有了前面的一下,我们在调研和分析的时候就不至于遗漏,考虑就会比较周全。这个时候你仍然不要关心范围。二“下”概括为:寻找答案,了解细节;
       第三“上”是真的二“下”掌握的具体的需求对应到大的模式看是否能够对应,理解和分析是否是合适的?三“上”概括为:对应答案,连通上下;这个时候可以考虑范围,但是还不能确定范围;
       四“下”:这一步是最关键的,也是落实的一步。经过了前面的步骤后,再从更高的角度来审视细节,从全局的眼光来透射项目的业务范围,从而比较准确地把握项目范围,形成正确的业务理解和需求定义。从而能够建立起完整的业务概念模型和比较稳定的需求设计模型。
       需求获取过程(两上两下):
    一上:找方向
    二下:抠细节
    三上:找差距(操作层面与管理决策层面的理解差距)
    四下:落实到实现
       需求评审:客户和用户对需求理解和确认是非常重要,评审确认是业务人员与技术人员之间的理解桥梁
第一上、下:分析“明”的需求,把握项目范围、把握方向,避免走偏;
第二上、下:分析隐含的、潜在的需求,防止遗漏需求,导致后期发生无谓的变更。
上是指:上升到管理层的高度;
下是指:落实到实际的业务中发现问题、解决问题。
 
       经过这四步,在头脑中建立起完整的概念模型,如果是实现的管理系统,应该有清晰的管理模型,并且能够清楚模型中的共性的需求和个性的需求分别是什么?然后对应到项目应该实现的功能需求上,就会在设计的时候有全局观,所实现的功能之间不是孤立的、不是物理的堆砌,而是有机的逻辑的结合

六、开发测试阶段
七、实施维护阶段
posted on 2007-08-30 19:37  LDAR泄漏检测与修复  阅读(5020)  评论(22编辑  收藏  举报