I'm not clear what you're asking for here. Just general words of advice for the whole software development life cycle in QlikView?
Treat your QVDs as a data warehouse rather than making application-specific loads. To the extent possible, PLAN how you want them to look and interact rather than just letting them come together organically. Do NOT build everything at once - only build what you need when you need it, but have a vision of where you're headed in the long term.
Understand and work towards a reasonable overall system architecture from the very beginning. A consultant might show up at your company and create a working dashboard in only two hours, but don't base your entire architecture on a two hour prototype, no matter how impressive.
As a developer, even if you don't understand what the users want, don't be afraid to create and install a simple prototype. Putting something in front of the users, even something wrong, is a great way to prompt user feedback. In my experience, I usually get far better requirements from just installing a prototype than I get from asking users directly about what they want. (Edit: To clarify, installing a prototype is not a replacement for talking to the users. You still need to talk to them about their needs.)
QlikView development is a highly iterative process, much more so than other software development that I've done.
QlikView development is almost never done. The frequency of requests merely diminishes over time as the application gets better and better.
Set analysis is NOT the solution to every problem. Yes, yes, I know you love set analysis. It's a wonderful tool, and when you master that tool, you may find yourself wanting to use it everywhere. Where you get into trouble is when you start doing things with set analysis that can instead be done with the data model itself. Data model solutions, where they are practical alternatives, are often faster to execute, as well as allowing the charts in your application to be better integrated with each other.
If complexity is required, put it in the script, not in the charts.
On the other hand, beware complicated data models and script. I violate this principle all the time, but after a year or two, I often don't remember exactly what I was doing and why, and find it more time consuming than it should be to make changes. I can only imagine the pain of other developers trying to maintain my script many years down the road. At the very least comment your code as clearly as possible.
Never aggregate in script except as the very last resort. If you're aggregating in script, you've lost the flexibility and power that QlikView provides for you. However, you often CAN do things in script that will significantly speed up your chart aggregations without actually aggregating. Consider carefully how you can split responsibility for calculations between script and your charts.
Take the time to read a book or two on dashboard design, displaying quantitative information visually, that sort of thing. Your job is not to IMPRESS your users with your amazing artistic prowess, or even your mastery of all of QlikView's ins and outs. Your job is to INFORM your users by providing the data they need as clearly and obviously as possible. Simpler is usually better.
.png "Luminary Alumni"){kind=icon}
