WHAT ARE THE DELIVERABLES?

only for RuBoard - do not distribute or recompile

WHAT ARE THE DELIVERABLES?

One thing that we absolutely have to get right in any project is to ensure that the customer gets what they expect to get. In Chapter 1 we discussed the business goals approach to expectation setting but there is still the problem of sign off. A project manager has to get acceptance from the customer before the project can officially be closed down. This is important because, in a consultancy organization, this is when we get paid. Even in an internal project, closure is important because it signals the point at which the system is accepted. This event is always greeted with a huge sigh of relief by the members of the project team and is usually the trigger for some kind of end-of-project bash. It also enables the team members to be reassigned to the next project in line. For some, hopefully, this will be the next increment of the data warehouse.

So how do we get sign off? It is certainly the case that most quality project managers will insist on some kind of acceptance criteria before they themselves will accept responsibility for the project. This is one of those intractable problems that we just have to deal with. The fact is that, as long as the data warehouse has been built on sound principles and firmly focused on the business goals, the fact that the data warehouse physically materializes at the end of the process should be sufficient. However, usually, more is required.

It's just because data warehouses are different. If it were not a data warehouse but, instead, say, an order processing system, we could get the customer to define some acceptance criteria and provide some acceptance test cases and some test data. Then we could process the order, make sure that the customer account is properly updated, that the delivery note generates an invoice, etc. This is because most systems are process oriented and what actually gets tested is that the processes perform the way they should and that the data used in the process gets transformed properly. In a data warehouse development, the processes are all about getting the data out of the source systems and into the data warehouse in the appropriate form. We can and should provide quality control checks to ensure that all records that have been extracted from the source system can be accounted for in the data warehouse, but that can hardly fulfill the requirements of a user acceptance test, can it? No, what matters is the content. Each case, unfortunately , will probably be different but here are a couple of suggestions:

Tie the data warehouse into one of the applications.   For instance, the campaign management system. What we can do is to agree a set of segmentation criteria for the selection of customers to be targeted in a campaign and build the system so that the campaign management system, if you have one, is fed with the list of appropriate customers. The acceptance criteria could be the selection parameters. Our users can then validate the selection.

Select some of the queries that were specified in the information strategy workshop.   If we can execute a selection of those queries it will prove that the warehouse is able to provide information that is valuable to the organization. Be careful that the queries selected as acceptance criteria are in line with the first increment being delivered. It's no use asking for queries relating to customers' changing circumstances if we have only delivered wine sales behavior.

One thing to be very careful about when putting together acceptance criteria is system performance. It is common for our customers to demand blanket performance metrics such as:

All queries will take no longer than 10 seconds.

This can be a huge gotcha because acceptance criteria like these will kill us. Under no circumstances should we accept this type of condition. We have to explain to our customer that data warehouses are different from conventional applications. It is reasonable, in most cases, in an OLTP application to expect virtually instantaneous response times. All these transactions have to do, usually, is:

  1. Look up a single database record (using a unique key)

  2. Change some value

  3. Rewrite the record

As everyone knows , this sort of thing can be done in the twinkling of an eye. A data warehouse query might have to:

  1. Read several millions of records

  2. Try to match them to thousands of other records using a sort merge join or a nested loop join

  3. Calculate sub totals

  4. Present the results in a readable format

This, as anyone who has experienced it will testify, can take a very long time indeed. It is a good idea to avoid performance-based acceptance criteria if at all possible. That does not mean we should ignore performance, simply that the system should not be judged on it.

The attitude we should adopt is that, previously, the answers to such questions were either impossible or nearly impossible to obtain. The fact that we are now able to get an answer at all is a sign of success. Performance tuning is something that should always be addressed afterward, using standard RDBMS performance tuning techniques as well as data warehouse specific techniques such as summary tables.

only for RuBoard - do not distribute or recompile


Designing a Data Warehouse . Supporting Customer Relationship Management
Designing A Data Warehouse: Supporting Customer Relationship Management
ISBN: 0130897124
EAN: 2147483647
Year: 2000
Pages: 96
Authors: Chris Todman

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net