The activities for application prototyping do not need to be performed linearly. Figure 6.3 indicates which activities can be performed concurrently. The list below briefly describes the activities associated with Step 6, Application Prototyping.
-
Analyze the access requirements.
Based on the business needs, determine the access requirements for reports and queries. Most access requirements will probably be multidimensional, which makes them perfect candidates for prototyping. Also, assess the skill sets of the business people participating in the prototype activities.
-
Determine the scope of the prototype.
The business representative and the project manager should determine the scope of the prototype. The scope should be small enough that the prototype can be built and tested in a matter of days or weeks. It should contain only a subset of data, just enough to support the functionality chosen for the prototype. Prototyping by definition is iterative, which allows functionality and data to be added with each prototype iteration.
-
Select tools for the prototype.
You may want to evaluate the existing suite of tools at your organization available for building the prototype. People are already trained on those tools and feel comfortable using them. The comfort factor is a big enabler . If you decide to select new tools, determine how much training is required, and schedule the training sessions as soon as possible.
-
Prepare the prototype charter.
Put together a short and informal prototype charter that outlines the main purpose for the prototype, the scope of the prototype, what platform it will be built on, how many iterations you are planning, the time frame for completing the prototype, and who will participate.
-
Design the reports and queries.
Based on the access requirements, design the prototype database and the reports and queries. If a Web front end is part of the prototype, design the Web pages as well. Select the relevant data for the prototype, and map the data from the source files and source databases to the prototype database. Be sure to consult with the data quality analyst to learn about source data problems. It is best to leave out poor-quality data rather than contaminate the prototype with it.
-
Build the prototype.
Build the prototype based on the initial database design, report and query designs, and Web page designs. Expect that the design will change several times. Use this opportunity to test various database and application tuning techniques. The database structures as well as the reports and queries developed during the prototype could be used as a yardstick to validate the time and cost estimates for the final BI application.
-
Demonstrate the prototype.
Prepare demonstrations with as much functionality as the type of prototype you have chosen allows. A show-and-tell prototype will have much less functionality than an operational prototype. Run the demonstrations for a short time and solicit approval for the BI project and additional support for the BI initiative as a whole. The demonstrations should be considered a BI marketing activity in addition to being a vehicle for validating the requirements and functionality of the BI application.
Repeat the process outlined above for additional prototype iterations.
