tools and rules extraction

Narayan is asking about experience people have had with rules extraction using current tools.  I would like to share our experience in that regard and open it up to other experiences and insights.

We have used various tools (Seec, Becubic, Relativity, as examples).  I have found that there are three very important (and therefore, challenging aspects, as follows:

(1)Archeology: To do the archeology step (registering artifacts into a tool) and generating functionality or reports that assist in finding where to start digging for rules and where not to dig.  The most difficult part is estimating the digging, even when you obtain complexity metrics from the tool during archeology because most current complexity metrics are aimed at maintenance not at rules extraction.  You may want to come up with your own estimation formulas once you peruse the archeology reports to see what kinds of factors will impact your finding the right code and the time it takes to "mine" from it.. 

(2) Programming Languages: As for specific languages, some tools process more languages than others.  So, this is imortant in selecting a tool.

(3) Selecting the Right Tool: During archeology, we usually compare the functionality we need for each task in the rule extraction process.  There are specific reports or specific dynamic capabilities that can speed up the process.

(4) Finding the Rules: Isolating target program code means knowing, ahead of time, where rules are buried and then either slicing out little snippets of code containing a few rules (and operating on these individual snippets), or dynamically using the tool to move forward and backward through the code, in search of boundaries for targetted rules and

(5) Translating code snippets into real rules (you make an excellent point in this regard): Finally, translating those little code snippets (once you have them) into real business-oriented rule statements…today this is mostly manual, although the OMG standards may result in more intelligent parsing….let’s see what Paul Vincent predicts in that regard for the short-term future.  Nevertheless, regardless of how functional a specific legacy understanding tool is for rules extraction, it usually is much better than doing it without a tool.  (We have often worked with vendors in producing reports specific for rules extraction.  Our STEP™ license now includes our BR Mining and contains a list, by task, of the functionality/reports needed from a tool at each step in the rules extractionprocess, which helps in estimating difficulty and timeframes).  Please share any experience you have had, whether good or bad or just starting!

The esimations for project planning depend on so many things (a) quantity of software artifacts (b) skill of rule extractor humans <g> (c) knowledge of underlying software (d) quality of the software and its documentation (e) functionality of tool set.  (We find it best to do a PoC of 4-8 weeks just to get metrics for estimating the full job).

Comments

[Jeremiah]

What is interesting about this question and answers is that we tend to hear and see that most people would prefer to use tools vs using something that is built and condusive more towards their business.

Now I am not one to discount any tool out there, I just find that the use of one toolset or another sometimes seems to lag in some aspects while accel in others. What works well for one does not necessarily work well for others. In my opinon, the toolset market for this seems to be very much in a infancy stage where a good deal of them try to find one form or fashion that works well from one or two approaches, but still needs to be cleaned up from other angles.

Utilizing, Barbara Von Halles, S.T.E.P. approach from Business Rules Applied, works exceptionally well for getting the thought process together when starting to mine and organizing business logic. The guidelines outlined in Chapter 6 particularly, Discovering Initial Requirements, should be required reading for any rule analysts, subject matter expert and/or business requirements "miner". Reading this material and making sure the understanding of these principals are key. Thus facilitating a easier path to selecting the right tool that will work best for the business at hand.

I guess what I am trying to say is the toolsets work well, when the business can adapt easily enough to fully utilize the strength of them. However, we see too many times in the past that there is usually pushback for adopting a new tool to use and integrate with, regardless of the necessity for it.

[Barbara von Halle]

Jeremiah,

Thank you for your thoughtful comments. Your comments hinting at tools first, business sometimes second, ring all too true. I find that the best way to benefit the business (with business rules) is often the simplest way - talk to business people, lead them through structured thinking, capture what they say, publish it - tools can help along the way, but should be selected to fit the function and culture.

I think that the mining of rules from code is becoming very crucial because companies want to migrate existing functionality to BRMS/BRE environments and because knowledge of current system logic is scarce. I find it a challenge to mine rules from code and then convince people that business people ought to review those rules to see if the rules are still good. (It is insightful how many times there is resistance to this! Goodness!)

I also agree with you that today's tools are in their infancy for mining rule logic from existing code, but they can add structure to the process and they do save time.

Have you (or anyone else) had success following the S.T.E.P. approach where the business people are in the drivers' seat (thinking of new rules, analyzing them, all before automation concerns?) Have you (or anyone else) mined rules from code and then reviewed them with business people who want to change them?

Barb