Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications
Подождите немного. Документ загружается.
[ Team LiB ]
Chapter Six. Step 6: Application
Prototyping
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
201/631
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
202/631
Chapter Overview
This chapter covers the following topics:
Things to consider about prototyping
How prototyping can provide an effective way to validate application
requirements
The concept of "time-boxing" prototyping activities
Best practices for prototyping
Prototyping considerations such as proper team structure, deadline
management, scope and deliverables, and business participation
The purposes and implications of the six different types of prototypes: show-
and-tell, mock-up, proof-of-concept, visual-design, demo, and operational
Guidelines for prototyping
An example of a skill survey used to determine the skill sets of the business
people who will participate in the prototype and will later use the BI application
Brief descriptions of the activities involved in application prototyping, the
deliverables resulting from those activities, and the roles involved
The risks of not performing Step 6
Things to Consider
Objectives
Are the objectives for this prototype clear?
Do we know what kind of prototype we want to build?
Have we developed a prototype in the past?
If we have, what was our experience? What lessons did we learn?
How will the business people benefit from prototyping this BI
application?
How will the organization benefit?
Scope and Schedule
What is the scope of the prototype?
How will we manage scope changes?
How much time do we have for this prototype?
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
203/631
How many versions (iterations) of the prototype are we planning to
create before starting real development work?
How will we time-box prototype activities? By version? By activity?
By deliverable?
Deliverables
Are the requirements clear about the prototype deliverables?
What reports do the business people expect from the BI
application? Will we prototype all of those reports? If not, which ones?
What queries will the business analysts write against the BI target
databases? Which of these queries should we prototype?
Are any business analysts currently using spreadsheets to satisfy
their query needs? Will the prototype include reports to replace all
those spreadsheets?
What data do we need for the prototype database?
Will a BI application interface be required? If so, are we
prototyping it? For how many business people? What do they have
now?
Are we going to include a Web front end in the prototype?
Business Participation
Who will use the BI application? How many of those business
people will be involved with the prototype?
Where are the business people located? How will they connect to
the BI application? By local area network (LAN)? By wide area
network (WAN)? Through the intranet?
Have we worked with these business people in the past?
What types of technical skills do they have? What technical skills
are needed to participate in the prototype?
How much will they participate in this prototype? Hands-on, full-
time involvement? Occasional demo reviews only?
Tools and Methods
What tools will we use to develop the prototype?
Will we use the same tools to develop the final BI application?
How will lessons learned be communicated to the
extract/transform/load (ETL) team?
There is nothing business people like more than to see their requirements turn into a
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
204/631
tangible deliverable they can "touch and feel" very quickly. A prototype accomplishes
that goal.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
205/631
[ Team LiB ]
Purposes of Prototyping
Prototyping can be an effective method for validating the project requirements and
finding missing pieces and discrepancies in the requirements. Business people
seldom think of all the details when they state their requirements. They often forget
to include dependent processes or related data. A prototype can also help them focus
on their access path requirements because they will see the capabilities of the BI
technology and the access and analysis portion of their BI application.
If time and budget permit, building a prototype for the original requirements allows
the business community to test, extend, or change those requirements at an early
stage when the impact on the project schedule is not yet high. The costs of
experimenting with different database designs, different visualization methods,
different development tools, or different application programming techniques are
much less during prototyping than during development because they do not affect a
full-scale application.
Another purpose for prototyping is to verify that the design as well as the selected
tools, database management system (DBMS), and other technology components will
be appropriate for the BI decision-support environment. If the functions of all
technology components perform as expected during the prototype development, then
the chances of having a successful BI implementation are increased. Therefore,
testing the technology features is a valuable benefit of prototyping, regardless of
whether you are using existing technology components or buying new ones.
Testing the technology for performance, however, is
usually not a valid purpose for a prototype. A prototype is
not a stress-test environment. It is usually loaded with
only small sets of data, and its main purpose is to try out
visual interfaces and functionality.
Time-Boxing
Everyone likes prototyping. It is fun and creative, dynamic and exciting—and it is
meant to be short. Thus, a word of caution: It is tempting to endlessly expand the
scope of the prototype. Prolonging the prototyping effort beyond its original purpose
reduces the cost-effectiveness of the prototype and produces diminishing returns, as
shown in Figure 6.1. It also reduces control over the project as the prototype starts
to feel like a runaway train.
Figure 6.1. Uncontrolled Prototyping Activity
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
206/631
Each prototype iteration should be limited in duration to just a few weeks, and the
activities within each prototype iteration should be time-boxed for every week, as
illustrated in Figure 6.2. Prototyping activities are carefully planned and monitored.
Each participant must know which tasks to perform and which task deliverables to
produce by the end of every week.
Figure 6.2. Controlled (Time-Boxed) Prototyping Activity
As unexpected discoveries arise (one main reason for prototyping is to find out what
does not work), the plan should be revised for every team member who is affected
by that discovery. The plan and schedule for the prototype can be extended or
shortened. A plan does not dictate what must be done; it is only a proposal for
activities that make the most sense at the time. If something does not make sense
anymore, change it.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
207/631
[ Team LiB ]
Best Practices for Prototyping
A few lessons learned regarding prototyping appear below.
Limit the scope: Limit the functional scope as well as the data scope of each
prototype iteration to a specific subset of the application. This helps to focus the
business people on one small piece of their overall requirements. They can
learn about the capabilities and limitations of the new environment without
getting bogged down with the complexities of the whole development effort. It
is also a good general training indoctrination in how to use the new technology
and the new application.
Understand database requirements early: The prototype will help the
database administrator understand the access path requirements to the BI
target databases, the reporting dimensions needed for application development
with online analytical processing (OLAP) tools, the levels of aggregation and
summarization needed, and what type of data is usually accessed together. The
database administrator will be able to start making some database design
decisions, such as how to cluster tables and where to place the data sets. The
database administrator will also get a sense of the performance expectations
and the anticipated size of the databases.
Choose the right data: Carefully select sample data for the prototype. The
sample data set should be a meaningful representation of the source data so
that all functions and features of the prototype can be tested. Keep the sample
data set small so as not to spend too much time on loading and testing. Try to
select clean data for the prototype. You do not want to have your prototype
results tarnished because of dirty data. You also do not want to take the time to
cleanse data while creating the prototype unless the purpose of the prototype is
to test your transformation logic or the transformation functionality of an ETL
tool or a data-cleansing tool.
Test tool usability: Test the usability of the access and analysis tools. Make
sure the query tools are easy to use and do not intimidate the business people
who need to use them. Test the features of the report writer on one of the more
complicated reports. Give the business people hands-on experience with the
OLAP tool. Although multidimensional analysis is relatively intuitive for most
business people, the capability of dynamically drilling down and rolling up with
a tool is still a new experience for many.
Involve the business people: Test the prototype with more than one
business person. Try it with a single business person first, then add more
business people from different business units or departments. Be sure to
measure the performance of the prototype as you add more people. Observe
the business people while they use the prototype. You will be able to see how
they react to the prototype when you test it with them. Address any difficulties
or misgivings immediately so that the problems do not become roadblocks
during application development.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
208/631
Considerations for Prototyping
To build a successful prototype and to produce the optimal physical database design,
the prototyping team must first understand how the business people will retrieve the
data and what they will do with it. The team members should ask such questions as
the following:
Are there frequently asked business questions?
What dimensions of the data are prevalent on reports?
Are there reporting patterns among departments?
Prototyping is a useful technique to ensure that the business people and the
prototyping team understand and agree on the functional business requirements. A
prototype could also ensure that everyone agrees on what is expected from the final
BI application. Important considerations about developing a prototype are briefly
described below.
Prototyping team: The prototyping team should be small. One of the many
reasons why some software companies have become successful is that their
project teams are very small. They do not staff their projects with more than
seven or eight people.
Deadline management: When project teams routinely miss deadlines, shrink
the size of the team. This is exactly the opposite of what many organizations
do. Most organizations put more people on the team, which usually backfires
because more people require more time for communication, and that slows
down the project even more. By shrinking the size of the team, the people
remaining on the team may have more work to do, but they will get things
done faster.
Scope: Try to build "slimware," that is, deliverables with the barest number of
features possible to satisfy the purpose of the prototype. This can head off
"code bloat" down the road when the application code needs to be written.
Deliverables: Each prototype should have a well-defined deliverable. Plan to
use an iterative process for prototyping, and try to control the activities on each
prototype iteration in weekly increments with weekly deliverables.
Delivery methods: Test the graphical user interfaces (GUIs), Web-enabled
interfaces, and other delivery methods.
Data integration: Try to have only a few data integration requirements in your
prototype scope. Prototyping should not be used to address all project
requirements but only to get a basic understanding of the major deliverables.
Business participation: The prototype should include at the most five to eight
business people. Consider the politics involved in selecting the right blend of
business people for the prototyping activities.
Success criteria: Encourage business participation in the prototyping process
from the beginning, especially during the activities of needs assessment and
GUI construction. Be sure to include the business representative and the
business sponsor when establishing the success criteria for the prototype.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
209/631
Remember, their definition of success or failure is the one that counts. You may
also consider building a coalition comprised of the business representative and
the business sponsor, IT managers, and other senior business managers who
will support the BI project beyond the prototype.
Before starting the prototype, review the Things to Consider section at the beginning
of this chapter to determine the overall scope of the prototype, the prototype's
purpose, how many business people will participate, and the level of complexity. Use
this information to carve out and focus on one or two essential functions that have
the highest payback.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
210/631