Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications

Подождите немного. Документ загружается.

[ Team LiB ]

Types of Prototypes

Prototyping is a visual communication technique used to help the BI project team

understand and refine the scope of the project requirements. There are different

types of prototypes, each with a different purpose and life expectancy. These

prototypes are discussed below in the order of least to most functionality,

sophistication, and reusability.

Show-and-Tell Prototype

A show-and-tell prototype serves as a demo for management and business people,

as described in Table 6.1. It could also be used to obtain budget approval or to get a

business sponsor for the BI application during Step 1, Business Case Assessment.

Table 6.1. Show-and-Tell Prototype

Purposes

Implications

Avoid costly coding by

only demonstrating

"look and feel."

Gain buy-in from

business people.

Gain business support

for the BI application.

Secure funding for the

BI application.

Business people may mistake the prototype for

a functioning system. Be sure to explain that

there is no functionality at all—it is only for

visual communication.

Concentrate on displaying the most important

screens to get business buy-in.

Mock-Up Prototype

The purpose of a mock-up prototype is to understand the access and analysis

requirements and the business activities behind them. Therefore, mock-up

prototypes are completed in a very short time, as mentioned in Table 6.2. Since the

mock-up prototype is just a front for a BI application, it is usually a throwaway.

Table 6.2. Mock-Up Prototype

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

211/631

Purposes

Implications

Understand the

application

requirements.

Understand the

business activities.

Initiate system

functions.

Speed is of the

essence.

Pay attention to interfaces: building interfaces gives

the impression of working code.

Use a less sophisticated programming language to

build the prototype faster. For example, you may

want to use Visual Basic for the prototype and write

the final access and analysis application in C++.

Proof-of-Concept Prototype

The purpose of a proof-of-concept prototype is to explore implementation

uncertainties. This method allows the identification of risks and unknowns, thereby

enabling the decision whether or not to proceed with the project, as indicated in

Table 6.3.

Table 6.3. Proof-of-Concept Prototype

Purpose

Implications

Explore implementation risks and

unknowns to decide whether or not to

proceed.

Stay narrow in scope.

Do not build any application

interfaces.

Build only enough functionality

to make a go/no-go decision.

Visual-Design Prototype

A visual-design prototype is a step up from a mock-up. It is ideal for developing

interface specifications for the access and analysis portion of the BI application. Good

interface specifications are mandatory, as listed in Table 6.4. Visually, it is important

for business people to have as much information as possible on the same screen to

avoid toggling between screens. Once the code is generated, this type of prototype

may survive and be incorporated into the final BI application. Therefore, unless you

are certain that this prototype is a throwaway, stay away from "quick and dirty"

code. There is no such thing as a one-time-use-only program. Once a program

works, even if it does not work well, it is liable to be used forever.

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

212/631

Table 6.4. Visual-Design Prototype

Purposes

Implications

Understand the

design of visual

interfaces.

Develop

specifications for

visual interfaces and

displays.

If the intent is to use the prototype like a mock-up

only, write it in a language different from the

delivery language so you can complete it faster.

If the intent is to potentially use the prototype for

the final BI application, write it in the delivery

language from the start so you can reuse it for the

real BI application. Allocate additional time for

writing quality code.

Demo Prototype

A demo prototype is used to convey vision and partial functionality to business

people, business managers, potential customers, or other external groups, as

indicated in Table 6.5. It is not fully functioning, but it is more sophisticated than

code stubs.

Table 6.5. Demo Prototype

Purposes

Implications

Convey the vision of the

BI application to the

business people or to

external groups.

Test the market for the

viability of a full-scale BI

application.

Test or demonstrate the

usability of the proposed

access and analysis

portion of the BI

application.

On the initial screen, graphically convey what

percentage of the application is represented

by the prototype so you set realistic

expectations. Otherwise, the business people

may mistake this prototype for a functioning

application.

Operational Prototype

An operational prototype is the most involved, most extensive, and most time-

consuming of all prototypes. As a result, it is also the most expensive, most

complete, most functional, and most likely to survive and evolve into the real access

and analysis portion of the BI application. The purpose of this prototype is to obtain

feedback from the business people who participate in the prototyping activities

through the actual use of the application's functionality. This is accomplished by

designing the entire access and analysis application up front but using only a basic

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

213/631

part of the code to generate the prototype. It can be considered a bare-bones

application, with just enough functionality to evoke feedback, as mentioned in Table

6.6. This type of prototype is also excellent for hands-on training.

Table 6.6. Operational Prototype

Purposes

Implications

Create an almost fully

functioning pilot for alpha or

beta use of the access and

analysis portion of the BI

application.

Obtain feedback through real

hands-on trials of the bare-

bones application.

On the initial screen, graphically

convey what percentage of the

application is represented by the

prototype so you can set realistic

expectations.

This prototype has a high potential for

evolving into the final access and

analysis portion of the BI application.

Write the prototype in the delivery

language. Allocate additional time for

writing quality code.

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

214/631

[ Team LiB ]

Building Successful Prototypes

Building a successful prototype starts with defining its purpose and setting its scope.

The purpose and scope of a prototype can never be the implementation of a full-scale

BI application, which is comprised of an ETL process, an access and analysis

application, and a meta data repository. There are two main reasons why a

prototype can never produce a complete BI application.

While portions of the ETL process and some functionality of the ETL tool can be

tested in a prototype, the entire ETL process is too complicated and would take

too long to be an appropriate scope for prototyping.

Similarly, the design and some functionality of the meta data repository can be

tested in prototyping, but developing a robust, production-worthy, enterprise-

wide meta data repository is outside the scope of prototyping.

Therefore, the most appropriate and the most common purpose and scope for

prototyping is to demonstrate the overall usefulness of the access and analysis

portion of a BI application by using a small subset of functionality and data.

Consequently, prototyping is the best way for the project team members of the

Application track to perform "systems analysis," which is systems-focused analysis of

functional requirements that leads to application design. To take it a step further, if

the BI project team chooses to build an operational prototype, it is conceivable that

after several prototyping iterations the operational prototype can evolve into the final

access and analysis application.

Once the prototyping activities are in progress, it is quite common to make new

discoveries that lead to new requirements, which can affect not only the scope of the

prototype but also the scope of the source data analysis activity, the ETL process,

and the meta data repository. Be sure to review and renegotiate the project

constraints when the scope changes, and be sure to communicate daily with the

project team members of the ETL track and the Meta Data Repository track.

Prototype Charter

Prepare a prototype charter, which is similar to a project charter but much smaller

and less formal. A prototype charter is an agreement between the business sponsor

and the IT staff for developing a prototype. It should include the following sections:

The primary purpose of the prototype, for example, whether the focus is on

testing queries for marketing analysis, demonstrating executive information,

running a financial analysis report, or fulfilling another specific purpose.

The prototype objectives, including a statement of what type of prototype

will be built. Each type of prototype takes a different amount of effort and

produces different results. It must be clear to the business people what the

limitations of the prototype will be.

A list of business people who will:

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

215/631

- Participate in building the prototype

- Sign off on the prototype

- Use (test) the prototype

The data, including information on the type of data, the amount of data, and

the consolidation level of data that will initially be brought into the prototype

The hardware and software platforms on which the prototype will be

constructed and the language in which it will be written.

The measures of success should be itemized for the prototype. How will you

know whether it was worthwhile to prototype portions of your BI application?

An application interface agreement is also important to cover the following:

- Compliance with standards (or development of standards if none exist)

- Necessary level of understanding and skills required

- Ease of use ("user-friendliness")

Regardless of how much we use the term "user-friendly system," it is still an

oxymoron, like a "simple programming change." In most cases, we seem to be

looking for "system-friendly users" instead of developing "user-friendly systems."

Express the goals for ease of use in terms of quantifiable criteria for:

The minimum time it takes to learn the new application.

The speed of task accomplishment (e.g., time to analyze a market condition).

The retention rate of queries over a period of time.

Subjective satisfaction; business people like applications that are intuitive and

forgiving.

The effectiveness of the help function (if included in the prototype). Is the help

function really helping people resolve problems? Are the business people

making use of the help function frequently? What is their feedback about the

content of the help function?

Guidelines for Prototyping

Create prototyping guidelines and communicate them to all prototype participants.

Table 6.7 lists some sample guidelines.

Additional considerations appear below.

With each prototype iteration, plan to expand the number of data types, and

plan to increase the functionality and the volume of data.

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

216/631

Keep the type and placement of GUI components consistent among prototypes.

If you are choosing a pull-down menu for certain types of displays, do not

switch to radio buttons on another prototype. The business people may need to

reach consensus on some basic standardization for the BI decision-support

environment.

Table 6.7. Prototyping Guidelines

Do not deviate from the basic purpose for which the prototype is being

developed.

Develop a working prototype quickly; therefore, keep the scope small.2.

Acknowledge that the first iteration will have problems.3.

Frequently demonstrate the prototype to stakeholders.4.

Solicit and document top-down as well as bottom-up feedback on the

prototype.

Ask for ongoing validation of the prototype results.6.

Continue to cycle between demonstrating and revising the prototype until its

functionality is satisfactory to all parties.

Review your prototyping approach and modify it if necessary before

proceeding with the next prototype iteration.

Skills Survey

The business people who will participate in the prototype and will later use the BI

application should be evaluated to determine their skill sets. What level of business

knowledge do they have about the business functions addressed by the BI

application? Are they experts in using computers but do not know much about the

business functions? Or are they experts in the business functions but have not used a

computer extensively before?

You may want to use a skills matrix, similar to Table 6.8, to assess the skill sets of

the business people in order to determine how simple or how sophisticated the

prototype and the final BI application need to be.

If the survey shows an overwhelming number of people with XX skill sets (expert in

computer skills and expert in application knowledge), build as many shortcuts as

possible. If the survey shows an overwhelming number of people with BB skill sets

(beginner in computer skills and beginner in application knowledge), provide as

much guidance and help functionality as possible. If the survey shows an

overwhelming number of people with any other skill set combination, you need to

take a hard look at your proposed solution and decide whether only one solution will

be sufficient. If the BI application is designed for only one level of skills but has to

satisfy everybody using the application, either it will be perfect for beginners but the

experts will be bored and frustrated, or it will be perfect for experts but the

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

217/631

beginners will be lost and frustrated.

Table 6.8. Skills Matrix

Computer Skill

Business Functions Knowledge

Beginning (B)

Advanced (A)

Expert (X)

Beginning (B)

Advanced (A)

Expert (X)

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

218/631

[ Team LiB ]

Application Prototyping Activities

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

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

219/631

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.

Figure 6.3. Application Prototyping Activities

Repeat the process outlined above for additional prototype iterations.

[ Team LiB ]

北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视仅供免费试用/版权原著所有

220/631