I'll be back!

  Focus on BPM, celebrate PegaRULES Process Commander (PRPC)
posts - 76, comments - 161, trackbacks - 0, articles - 2
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

What is a Healthy PRPC System? -- Done

Posted on 2009-05-20 09:23 zolly 阅读(666) 评论(4)  编辑  收藏

我们做PRPC项目的维护,测试,优化,更新等等,都是在已有的产品上的一种后续服务,都是一种“发现问题,解决问题”的思路,这种方式往往使得项目周期变长,成本提高,这些都是客户不愿意看到的结果。

定义一套Healthy PRPC的准则,达到这个标准后的产品才允许发布到客户,或者在前期就按照这个标准严格实施,这才是防患于未然,未雨绸缪的最好方式,即便有大的变动,后期也会大大减少时间周期和人力财力。

这个问题我想也许不会找到标准答案,或许也只存在于BPM开发设计管理实施的人员之间经验的潜移默化。但是找到一个全面的检测标准,可以成为PRPC,甚至BPM所遵循的标准,这就是它的意义所在。

Following comes from Frank:
No entry in Pega-Alerts log
Normally check the alerts log file.
That's the benchmark from Pega...and normally 500ms is the standard...any SQL/Activity , if the execution exceeds 500ms, it's not normal., we need to find out why...
That needs some expericne, you should be very familar with the table structure, and needs advacned DB knowledge.

评论

# re: What is a Healthy PRPC? -- Pending...  回复  更多评论   

2009-05-20 20:37 by jeremy
一个强壮的prpc系统很关键的一点就是看代码的重用性,为了满足特定需求且仅满足该需求的功能模块是脆弱的,必须在设计之初就必须充分考虑到需求的变更,最大幅度扩大该模块的运用场景。
以创建组织地点下拉选择框(选择地域信息)为例子,脆弱的做法就是直接在property内对下拉选择框的值进行配置(Name, Value)。而一个好的做法就是创建一套对应的field value。 当然这个例子并不适用于那些特定模块的下拉选择框,
再举一个例子,我们在制作一个筛选用户的html property的时候,好的设计应该把筛选用户的条件作为parameter设在里面,例如OrgFilter, DivFilter,UntFilter,LocFilter等等。
如果项目在提交到客户之前就本项进行"Health"检测的话,可以让BA在原来的BRD基础上进行一定幅度合理的变更,然后有开发人员评估系统变更所需要的开发时间,由此来判断该系统代码是否拥有足够的灵活性(当然这个评判标准是一个经验值)。

# re: What is a Healthy PRPC? -- Pending...[未登录]  回复  更多评论   

2009-05-20 21:55 by lucy
我觉得题目开的很宏大,支持一下!!
但真正要提出一个标准来,是有相当的经验来作基础,并且要经过很多验证。我们可以从小的地方开始作:分享一些怎么作可以使prpc application 更加健康的case。
这样一来可以积累很多人的经验,二来可以使我们分享这些经验当工作中遇到问题时提供借鉴。

# re: What is a Healthy PRPC System? -- Pending...[未登录]  回复  更多评论   

2009-06-01 21:00 by howard
这个题目很好,不过就算是Pega公司本身也很难给一个满意的答复。
个人感觉,PRPC的开发不适合规模型的外包开发,只适合紧凑的精英型开发。而所谓开发,其实大部分的工作就是在分析和设计,而实际的代码工作量不会多到哪里去;相反一个系统如果没有很好的规划和设计而匆忙开发,那么最终的结果将是很闹心的。

# re: What is a Healthy PRPC System? -- Pending...  回复  更多评论   

2009-06-03 20:02 by Jeremy
如果长期规模化以及低素质的开发人员维持低效的开发,有可能最终产生大量的rule,这些rule的特点往往是高度冗余,通用性差,难以统一维护。
PRPC目前的一个很大问题就是对十万数量级以上的rule management很差。到这种程度上ruleset这个东西就显得很力不从心了。
所以我同意楼上的观点。

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


网站导航: