Research09
vivi_5488
Chapter10.pptxEffective BI Application Delivery
1
Refresher: The BI Life Cycle Components
Source: Howson
2
The Waterfall Development Process
| Characteristics |
| Defined requirements Solution built to specifications Often used on outsourced projects Reasonable for the “back end” strategic data movement projects (i.e. large databases and ETL) Unreasonable for “front end” business facing solutions with emerging requirements with regular changes |
Source: Howson
3
When scope cannot be determined in advance, traditional planning does not work
Agile project management was developed to deal with this problem in IT
Small teams are located at a single site
Entire team collaborates
Team deals with one requirement at-a-time with the scope frozen
Source: Meredith & Mantel
Agile Project Management
4
Iterative Project Management
| Characteristics |
| Emerging requirements Change is welcome Examples: prototyping and “wireframes” Two general types “iterative” (or “RUP the Rational Unified Process) and Agile |
5
Source: Howson
From the Agile Manifesto
6
Source: Howson
Agile Development Methods
“Agile software development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project.
It chooses to do things in small increments, with minimal planning, rather than plan at length. This helps to minimize the overall risk, and allows the project to adapt to changes more quickly. There is also an emphasis on stakeholder involvement. Meaning at the end of each iteration, the stakeholder is consulted about the product and comments are noted."
The Rational Unified Process (RUP) and Scrum are two types of agile methods (there are many others).
Source: Gladstone
7
Rational Unified Process (RUP)
“The creators of RUP focused on diagnosing the characteristics of different failed software projects; by doing so they tried to recognize the root causes of these failures. They also looked at the existing software engineering processes and their solutions for these symptoms.
A representative list of failure causes includes the following:
Ad hoc requirements management
Ambiguous and imprecise communication
Brittle architecture (architecture that does not work properly under "stress")
Overwhelming complexity
Undetected inconsistencies in requirements, designs, and implementations
Insufficient testing
Subjective assessment of project status
Failure to attack risks
Uncontrolled change propagation
Insufficient automation
Project failure is caused by a combination of several symptoms, though each project fails in a unique way. The outcome of their study was a system of software best practices they named the Rational Unified Process."
Source: Gladstone
8
RUP Phases
“The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003.
RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.
The following are phases of RUP, which align to business activities intended to drive successful delivery and deployment of projects. It also provides the taxonomy for blue printing and producing enterprise architecture artifacts across its different domains.
Inception - Identify the initial scope of the project, a potential architecture for the system, and obtain initial project funding and stakeholder acceptance.
Elaboration - Prove the architecture of the system.
Construction - Build working software on a regular, incremental basis which
meets the highest-priority needs of project stakeholders.
Transition - Validate and deploy the system into the production environment"
Source: Gladstone
9
RUP: Phases, Disciplines, and Iterations
Source: Gladstone
10
RUP and UML
“Unified Modeling Language (UML) is an essential set of object oriented tools (artifacts) used in RUP.
Use only necessary artifacts. Not all those listed are required.
Structure diagrams emphasize what things must be in the system being modeled:
Class diagram
Component diagram
Composite structure diagram (added in UML 2.x)
Deployment diagram
Object diagram
Package diagram
Behavior diagrams emphasize what must happen in the system being modeled:
Activity diagram
State Machine diagram
Use case diagram
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:
Communication diagram
Interaction overview diagram (added in UML 2.x)
Sequence diagram
Timing diagram (added in UML 2.x)"
Source: Gladstone
11
RUP and “Risk First” Planning
An important concept for RUP
Schedule the riskiest deliverables first
Schedule the next riskiest deliverables next
…And so on until you finish the project
The resulting “risk curve” looks like this:
Can also be applied to Scrum
Time
High Risk
Low Risk
12
13
Agile Events
Iteration Releases Future Releases
High Detail Lower Detail
High Priority Lower Priority
Source: Smits
Scrum Method
“Scrum (not an acronym) is a process skeleton that includes a set of practices and predefined roles. The main roles in Scrum are the ScrumMaster who maintains the processes and works similar to a project manager, the Product Owner who represents the stakeholders, and the Team which includes the developers.
During each sprint, a 15-30 day period, the team creates an increment of potential shippable software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done.
During sprint planning meetings the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. During the sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for a sprint."
Source: Gladstone
14
Going Agile With Scrum
Source: Gladstone
15
16
Agile Product Backlog
Desired product features
Each item value focused
Reprioritized continuously
Source: Smits
17
Agile User Stories
Traditionally written on 3x5 cards
Annotated with notes, pictures
Details emerge through conversation with product owner
Acceptance tests confirm story was developed correctly
Source: Smits
18
Agile Ranking
Stories and Backlog are Ranked
Rankings drive iteration and release content
Iterations are often known as “sprints”
Source: Smits
19
Agile Delivery Team
Typically 5-9 people Full-time members
Self-organizing
Self-managing
Cross functional
No egos
Source: Smits
20
Agile Project Manager
Removes impediments
Enforces values and practices
Servant leader
Not the decision maker
Doesn’t commit to dates or budgets
Facilitates with team and client
Source: Smits
The Daily Scrum Meeting
“Each day during the sprint, a project status meeting occurs. This is
called a scrum or the daily standup.
The scrum has specific guidelines:
The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)
All are welcome, but only "pigs" may speak
The meeting is time boxed at 15 minutes regardless of the team's size.
All attendees should stand (it helps to keep meeting short)
The meeting should happen at the same location and time every day
During the meeting, each team member answers three questions:
What have you done since yesterday?
What are you planning to do by tomorrow?
Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)"
Source: Gladstone
21
Waterfall, Iterative and Agile in Pictures
Repeat
!
!
!
WATERFALL
ITERATIVE (RUP)
SCRUM (AGILE)
KEY
= Migration to Production
= Project End
!
22
Situating Agile’s Success
Co – located projects are more successful than those that are not co-located
Offshored projects are least successful
On balance, agile is more successful than waterfall
That said, different types of methods are more effective in different situations with different components
23
Source: Howson
BI Component Change Frequency -> Apply the Appropriate PM Method
24
Source: Howson
Where to Apply Which Project Methodology in BI
Waterfall
Iterative (RUP)
Agile (Scrum)
Important: Watch the level of bureaucracy. A simple
report or field change requires at most “light scrum”
25
Source: Howson
13
Partner Re PM Training
A Guide to the Project Management Body of Knowledge (PMBOK Guide) Third Edition 2004 Project Management Institute (PMBok Page 40)
A Graphical Depiction of Where Your Delivery Methods Fit
Insert your delivery methodology here
The larger box is your overall project management and reporting framework
26
A Case of Misrepresented Agile BI
Situation
A prominent health insurer replaced a vendor’s proprietary BI solution with a “home grown” solution leveraging a best of breed technology stack
A leading professional services firm (PSF) managed development, selling their client an “agile” approach with a large (75 person) offshore team
The clients project managers confirmed a waterfall or iterative approach would have been less complex to manage and better suited for the database and ETL portions of the project. They agreed an “agile” process would be warranted for the “front end” development
Management did not listen and the project proceeded as the PSF represented it
What do you think happened?
27
A Case of Misrepresented Agile BI (Cont’d)
Results
As the project neared implementation, leaders with both the client and PSF confirmed the “back end” work appeared to be a modified waterfall and/or iterative project, despite reporting continually affirming it was an Agile project
The company proceeded with this modified waterfall/iterative approach, reporting it as an “agile” project, when it should have just proceeded with the right method for the right component and reported status in a business friendly way
The result “felt like” the PSF was saying “look at my sexy, innovative project methodology”
28
BI Project Triple Constraints Plus One
Balance
Cost
Schedule
Scope
+ Customer Satisfaction
29
BI Project Performance
30
Source: Howson
You Can’t Have Cheap, Fast and Good
If you want it cheaper, it will take longer and not be as good
If you want it faster, it will be more expensive and not be as good
If you want it to be good, it will cost you more money and time
31
Source: Howson
Agile’s Impact on BI Project Performance
32
Source: Howson
Trade Off Summary
ELT &
RDBMS
Note: RDBMS is spelled incorrectly in Howson’s
book and is replaced by the correct spelling
here. Her use of ELT is interchangeable with ETL
| Layer | Good Content | Bad Content |
| “Back End” Database | Granular details Corporate standards Content requiring extensive data preparation | Ratios Calculations |
| Extract Transformation and Load (ETL) | Preferably, “straight” data moves, source to target, with data confirmed cleaned at the source | Data cleansing (though bad, this is expected when data is not cleaned at its source) |
| “Front End” Presentation | Formatting Ratios Calculations | Data extracts |
Your Prof’s Rules of Thumb
Maximizes speed, localizes
impact for easier management
ELT &
RDBMS
33
Source: Howson
The “Ad Hoc” Conundrum
Part of the benefit of self service is providing users with ad hoc query capability
Ad hoc capability empowers users to develop complex reports
Users perceive these complex ad hocs as “home grown” production reports
This reinforces the need for a good IT and business relationship to
Communicate upgrades in advance
Coach and mentor to explain testing procedures and procure support and acceptance
Assisting users should provide an ad hoc inventory (infrequent per budget and time constraints)
If the BI team assumes partnership in supporting the business’ ad hoc reports and queries they can readily incorporate this functionality into enterprise artifacts and remove redundant artifacts
34
Reference List
Gladstone, S. (2014). An overview of various software development lifecycle (SDPC) methodologies.
[PowerPoint slides]. Retrieved from http://www.slideshare.net/SteveGladstone1/overview-of-sdlc-waterfall-agile?qid=89088e15-1c3a-40cb-8e1e-a6b595773ff9&v=default&b=&from_search=1
Howson, C. (2014). Successful business intelligence: Unlock the value of BI and big data. New York. McGraw
Hill Education.
ISBN: 9780071809184
Meredith, J. R., & Mantel, S. J. (2012). Project management: A managerial approach (8th ed.). Hoboken, NJ:
John Wiley & Sons, Inc.
Murphy, J. B., & Shaw, S. A. (2006). [PowerPoint slides]. Partner Re project management Zurich II. New York,
NY: New York University.
Smits, H. (2006). [PowerPoint slides]. An introduction to agile methods and practices. Boulder, CO: Rally
Software.
35
