CQ---缺陷和需求同在CQ一个项目库中管理的设想

原创 2007年09月20日 09:20:00
   
缺陷和需求同在CQ一个项目库中走变更流程,最初的设想有两个。
一是将缺陷的变更流程和需求的变更流程综合考虑,综合后使用同一个流程,那么在CQ中也就只需要配置一个流程。
二是将缺陷和需求的变更流程分开,各自走各自的流程,可以配置成不同的流程,那么在CQ中就要配置两个流程。
 
初看起来,第一种方法要比第二种方法简单。如果不考虑到权限限制的话,比如缺陷确认人员也可以对需求进行确认,需求确认人员也可以对缺陷进行确认,至于他做不做这个错误的事情,由人为控制,CQ系统不做控制。如果是这样,第一种方法确实比第二种方法要简单,但如果要加上权限控制,则只有在界面上下功夫(最初这样想的,后面有第三种想法了),增多一个记录类型的字段,根据这个字段来检查这个记录是需求的还是缺陷的,如果缺陷的,所有需求的相关字段不可写,反正亦然,那么界面上所有字段都要写代码来做这个判断,相当于把CQ自带的“某个状态下哪些字段可选、必填、只读”这个权限控制重写,字段较多,非常麻烦,另外,对CQ加了这么多代码,在以后的工作中不能够保证它能够稳定运行,毕竟我不是专门编程的,经验还是不足,再就是以后加字段也还要添加代码,其他人维护起来难度相对加大。
所以我建议尽量利用CQ自带的权限管理方式,尽量少加代码,采用第二种方式。
第二种方式虽然看起来麻烦一点,但一劳永逸,以后变更提交缺陷、提交需求之后的流程和加字段都不用加代码,维护起来相对简单。并且虽然用这种方式也要加代码,但只第一次加到一个位置,其他地方都可以沿用CQ自带的权限管理方式配出来,只是第一次做的时候要麻烦点。另外,可以使缺陷变更流程和需求变更流程分离,也加大了灵活度。
 
采用第二种方式的考虑:
第一步,提交(以后可以改成其他名字)。
这里的提交要做改动,在界面上添加一个“记录类型”字段,本次操作时,只有这个字段为必填,其他所有字段只读,再以后的步骤中,这个字段一直为只读;这一步用来把将要提交的记录是缺陷还是需求分来,没有真正提交记录的内容。在下一步将根据这个字段值来判断是提交需求还是提交缺陷。
第二步,增加两个动作,暂定为“提交缺陷”和“提交需求”,对应的操作后的状态为“缺陷已提交”和“需求已提交”。
这一步是最关键的步骤,需要加代码重写这两个动作的操作权限,达到如下要求(已实现):
如果登入者属于缺陷组,那么他就只能进行“提交缺陷”的操作
如果登入者即属于缺陷组,又属于需求组,那么他要根据所选记录的“记录类型”来判断是缺陷还是需求,如果是缺陷,则只能进行“提交缺陷”操作,如果是需求,则只能进行“提交需求”操作。
 
第二步已经决定了记录的状态的类型,根据CQ自带的流程管理原则,记录在某个状态下,经过动作A、动作B、动作C三个动作到达三个不同的状态,那么用户登入系统对这个状态下的记录进行操作时,只能看到与这个状态相关的动作A、动作B、动作C,其他动作不显示。也就是说,现在需求和缺陷的流程是分开的,状态和动作也都是分开的,如果选中的是需求的记录,那么这个记录所处的是需求的某个状态,也就只能看到对需求记录该状态下的相关动作,不可能对它进行针对缺陷记录的相关操作,剩下来的权限控制就很简单了,只要按照CQ自带的权限配置方法,把这些动作的操作权配给需求组就可以了。问题,如果把这个动作也配给了缺陷组,那么缺陷组的人也就可以对这个需求记录进行需求的操作了,但是如果是不需要这样配,就不这样配嘛,自找麻烦,如果真的是需要这样配,需要缺陷组的某人同时也可以对需求的记录做某些操作,那么可以单独建一个组,专门放这些需要跨流程操作的人,类似于目前缺陷流程中的项目经理,既属于项目经理组可以分配缺陷,又属于开发组可以提交缺陷,应该可以解决这个问题。
 
写完了想起一个事情,能不能把第一种和第二种结合起来,用第一种的只走一个综合流程,用第二种的第二步,既然我一个动作可以将它的权限重写,那么每个动作我都可以根据记录的“记录类型”和组来控制,这样的话,我也只是把已经写好的代码拷贝到各个动作里面,然后改相关的东西,这样一来就比较简单了。
 
三种方法比较下来,好像第一种方法最不可取,太麻烦;第二种开始配置起来比较麻烦,但只有一处写代码,其他地方都沿用了CQ自带的权限管理,以后维护起来相对简单一点,另外就是流程之间无关联,灵活度较大;第三种这次做起来比较简单,主要要考虑的是需求和缺陷流程的融合,另外就是以后维护的人可能麻烦一点,另外就是以后改流程都要兼顾缺陷和需求的。如果两个流程差别比较大或者以后差别比较大的话,建议还是用第二种,如果现在及以后都差不多,就用第三种算了,顶多再教一下接手维护的人。
    
 
 
 

PMP-项目管理笔记(四)-项目范围管理-收集需求

项目范围管理包括确保项目做且只做成功完成项目所需的全部工作的个过程。 管理项目范围只要在于定义和控制哪些工作应该包括在项目内,哪些工作不应该包括在项目内。 项目范围管理包括的过程:     1....
  • rommel2171226
  • rommel2171226
  • 2014年03月13日 19:52
  • 1790

软件缺陷跟踪管理

软件缺陷跟踪管理(戴金龙、谢敏)郑重申明:本文版权归计算机世界,任何转载和大幅刊用,务必征得作者同意。1为什么要做软件缺陷的跟踪管理考察一个典型的软件开发流程:需求分析—概要设计—详细设计—程序编码—...
  • quickblade
  • quickblade
  • 2005年04月08日 15:18
  • 7238

软件项目开发过程中的需求分析和范围管理

0 引言    对于一个软件系统的开发来说,最困难的部分就是准确说明开发什么,最困难的概念性工作就是编写出详细的需求,包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦出现纰漏,将会给系统带来...
  • chz_cslg
  • chz_cslg
  • 2010年07月30日 15:12
  • 3244

酒店管理系统-需求说明书

 需求分析说明书1.引言1.1编写的目的本文档为**酒店管理系统需求分析报告,为**酒店管理系统的设计的主要依据,主要针对**酒店管理系统的概要设计和详细设计人员,作为项目验收的主要依据。1.2背景本...
  • chenzhanhai
  • chenzhanhai
  • 2010年12月04日 14:01
  • 3246

需求管理和范围管理的区别和联系

需求管理不是范围管理,他们之间的差别从各自的定义和所包括的过程就可以知道: 范围管理包含一系列子过程,用以确保项目包含且只包含达到项目成功所必须完成的工作,范围管理主要关注项目内容的定义和控制,...
  • kingmax54212008
  • kingmax54212008
  • 2015年05月04日 11:07
  • 709

需求缺陷表缺点及优化建议

运维人员作为连接客户和需求人员的桥梁,在项目中是十分重要的一环。一方面,作为产品或项目的代言人,可以直接接触到用户的问题,舒缓用户的情绪,直接或间接的解决用户的问题,另一方面,作为客户代表,收集用户问...
  • happymatilian
  • happymatilian
  • 2017年05月16日 11:33
  • 421

【笔记】PMBOK第5章项目范围管理

【5】项目范围管理:项目边界、做且只做 产品范围-产品、服务或成果所具有的特性和功能。 项目范围-为交付产品而进行的工作,有时包含产品范围。 【5.1】规划范围管理:制定范围管理计划,定义、确认、控制...
  • mashang123456789
  • mashang123456789
  • 2016年07月23日 09:54
  • 1305

一个完整项目的实现

一个完整项目的实现分为: 1,整体流程的描述(书面语言的过程流畅描述等的流程描述) 2,划分为步骤的详细描述(用各种不同的方法划分) 3,将步骤块划分为类封装(方法任意) 4,类之间的数据流接口定义 ...
  • u010081730
  • u010081730
  • 2015年10月26日 17:30
  • 176

项目管理---项目经理如何应对客户的需求变更?

相信做软件开发的我们,大家都有这样的体会,当我们辛辛苦苦的熬了几个月的通宵、加班后,终于完成了客户提出的V1.0功能需求,当我们大家准备按部就班的进行系统上线时,客户、企业用户突然改变了需求,不想这么...
  • lishehe
  • lishehe
  • 2014年03月25日 20:04
  • 8553

需求管理与分析——需求池

产品经理会聆听用户声音进行需求收集,但是真正的需求需要我们去优化。真正优化的应该是从需求的收集到最终形成功能融入到产品中的这个过程。下面做一个简单科学的流程。 一、需求收集 · 从用户、市场、竞品...
  • qiansanjia
  • qiansanjia
  • 2016年09月20日 15:43
  • 1247
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:CQ---缺陷和需求同在CQ一个项目库中管理的设想
举报原因:
原因补充:

(最多只允许输入30个字)