Hi All,
I have one complex dashboard with 20 queris some body was developed but some enhancements come up, I have been take a look but unable to figure out last few days.
Any advice how to understanding some body developed BD and make changes ?
Amie (BOB member since 2005-08-01)
Having recently done this twice, here are my suggestions:
First, look through the whole dashboard for anything resembling documentation. It’s a faint hope, but you’ll feel stupid if you find everything you need 6000 rows down on the last sheet.
Second, start tracking where data in the dashboard comes from. Don’t worry yet about where it goes, just figure out how (and if) each cell gets written to. The basic breakdown is static (somebody just typed a value into the cell), calculated (somebody typed a formula into the cell), query (it is filled by a query connection), or object (it is filled when a user interacts with one or more components). I highly recommend color-coding the cells along these lines.
Once you’ve done this, you’ve probably already started to get an idea of the general data flow. So the next step is go through each of your queries. Make notes of any prompt values, destinations, load triggers, etc. As above, don’t worry about understanding all the other actions. Just get a handle on when each query is refreshed and where its data goes. Queries don’t have a LOT of elements, so it’s relatively easy to keep track of them.
Now do the same thing with each object. Don’t try to follow the visual flow on the canvas. Instead, just open the object browser, start at the top, and work your way down the list. Focus on how each object interacts with the data model. Look at every single property to see if there’s anything odd buried somewhere you would never think to use. Make notes. (Using comments in the data model is a good way to do this.)
Now the data model should, hopefully, make sense to you. I give it about an 80% chance. So start looking through the data model again and see if there are any pieces that didn’t get marked up in the above steps. Figure out what they mean. There’s a decent chance they are just leftovers from an earlier version, but don’t assume that.
Finally, start working your way around the canvas, trying to piece together how the developer expected the user to interact with it. This should make all the little odd bits suddenly make sense. Assuming, of course, that the previous developer was on the genius side of the genius/madness line.
It’s a lot like working your way through a particularly difficult maze. Trying to look at the whole maze and pick out the correct route is nearly impossible. You just have to pick a path and see how it works out.
Lugh (BOB member since 2009-07-16)
Colour-code it as you go along so you can remember what you’ve looked at. When I build dashboards now I always use the same format:
etc
Debbie
Debbie 
(BOB member since 2005-03-01)
I completely agree with Debbie. Color coding is a very good practice. Not only would I color code, but I would go ahead and create/document a standard for all developers within your company to follow.
Additionally, I would add some notes/comments to any changes that are made going forward.
greg.wayne 
(BOB member since 2010-09-28)