• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Why BI needs CMMI-5
 

Why BI needs CMMI-5

on

  • 3,188 views

High level presentation of why CMMI-5 is needed for BI development

High level presentation of why CMMI-5 is needed for BI development

Statistics

Views

Total Views
3,188
Views on SlideShare
3,186
Embed Views
2

Actions

Likes
3
Downloads
159
Comments
0

1 Embed 2

http://mgmt.talkingvillage.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Gerd Vi vil konsentrere oss om hovedpunktene, ikke detaljer!!!! Vi vil ikke snakke om rollefordeling
  • Gerd Vi vil konsentrere oss om hovedpunktene, ikke detaljer!!!! Vi vil ikke snakke om rollefordeling

Why BI needs CMMI-5 Why BI needs CMMI-5 Presentation Transcript

  • Presented by: Alain Charpentier Why BI needs CMMI-5
  • Table of content
    • Introduction
    • Basic Process Thinking
    • Basic of BI development
    • Basic of CMMI
    • Why the BI process need CMMI-5
  • Introduction
    • This document present a high-level justification why the BI development process need a CMMI-5 approach.
      • We first introduce some basic Process Thinking concepts
      • Then we highlight the difference between the BI development process and the development of transactional application
      • We then present a summary view of the CMMI
      • And we concluded on why the BI development approach is a good fit for CMMI-5
  • Basic Process Thinking
  • Basic Process Thinking
    • We use a simplified Ketchup factory to introduce Processes Thinking
    • If all our tomatoes are of uniform size and have the same "maturity", we will have a very simple manufacturing process, variability will be low.
    10 tomatoes 1 bottle
  • Basic Process Thinking (cont's)
    • If the size and the "maturity" varies then we introduce a lot a variability in our process.
      • We need to adjust de number of tomatoes by bottle, the cooking time, the quantity of spice, etc.
    ? tomatoes 1 bottle
  • Complex Process = Small batch
    • The complexity of the process has an impact on the size of the "batch" we can process.
      • Intuitively we can see that the more often we need to adjust the cooking time or the spice of a process the smaller the "batch" will need to be.
      • This can be demonstrated mathematically using Queuing Theory and Little's Law*.
    * George and Wilson (2004),Conquering Complexity in Your Business,McGraw Hill
  • Impact of many variables
    • As we raise the number of control variables (ie. complexity) we reach a point were the deterministic approach (ie. a fix recipe) will not work.
      • Intuitively we know that if we have a few variables we could devise a fix recipe. But, if the number of variable is large, than the multiple combination of variables (n x n) make it impossible to have a "fix recipe".
    * Sterman, John D. (2000). Business Dynamics . McGraw Hill.
  • The need for feedback
    • We need to introduce feedback to control complex process.
      • This can be demonstrated using Theory of System and System Dynamic*.
    * Sterman, John D. (2000). Business Dynamics . McGraw Hill. Input Output
  • Controlling Complex Process
    • Production cycle will be short.
      • Trying to implement long production cycle is doomed for failure.
    • Feedback is essential
      • The quality of the input will trigger adjustment to the process
      • Feedback from the customer and feedback from within the process will be required
    Input control Customer feedback Process feedback
  • Basic of BI development
  • Basic BI development
    • BI development is more complex that Transactional development
    • A over simplified example: develop a system with 5 screens
      • Effort to develop the screen
        • H1: Effort and complexity is equivalent
      • Effort to develop the database
        • Relational model vs Dimensional model
        • H2 : Effort and complexity is equivalent
      • Effort to develop the extract and load
        • No equivalent for the transactional system
    • For an application of the same size (5 screens), BI development is more complex.
    ETL
  • Other BI differences
    • Transactional
      • Automate business process
      • Design for efficiency
      • React to events
      • Analysis process
        • Decompose the process (create, read, update, destruction)
        • Identify the validations
      • Development process
        • By adding function (linear)
        • Project, clear start and stop date, fix budget
      • Data
        • Short transaction
        • Current data
        • Sources specific
        • Detail
      • Life cycle : 10-15 years
    • BI
      • Automate decision process (accelerate recurring decision)
      • Design for effectiveness
      • Anticipate events
      • Analysis process
        • Understand the process
        • Identify recurring questions
        • Define the context
        • Identify how to make the information actionable
      • Development process
        • Additive iteration
        • More of a repetitive process, no clear definition when we have enough information
      • Data
        • Long query
        • Historical data
        • Integrate multiple sources
        • Detail, summarized & derived
      • Life cycle : 5-7 years
  • Process Thinking applied to BI development
    • Because the BI development process is more complex
      • We should use series of short cycle (short batch)
      • Make greater use of feedback
        • Need to have more attention to input
        • Need more feedback from customers
        • Need more feedback from the process (the team)
    • Because of the shorter life cycle, BI solution will need to be re-architected more often
      • Need to separate the infrastructure (Data backplane) architecture from the data flow architecture.
    Data flow Data backplane
  • Basic of CMMI
  • History of CMMI
    • 1984 – SEI founded
    • 1988 – Watts Humphrey report
    • 1991 – Publication of SW-CMM version 1.0
    • 1995 – Work start on SW-CMM version 2.0
    • 1998 – SW-CMM work stop, start CMMI
    • 2000 – Publication of CMMI version 1.0
    • 2003 – Publication of CMMI version 1.1
    • 2006 – Publication of CMMI version 1.2
  • Structure of CMMI
    • Four disciplines
      • System Engineering (SE)
      • Software Engineering (SW)
      • Integrated Product and Process Development (IPPD)
      • Supplier Sourcing (SS)
    • Two representations
      • Staged
      • Continuous
    • Module
      • CMMI Acquisition module
    • Appraisal Method
      • Appraisal Requirements for CMMI (ARC)
      • SCAMPI Method Definition Document (MDD)
    • Four Courses
      • Introduction to CMMI
      • Intermediate Concepts of CMMI
      • CMMI Instructor training
      • SCAMPI Lead appraiser Training
    CMMI product team, CMMI for Development (CMMI-DEV), Version 1.2, Carnegie Mellon Univ., Aug. 2006.
  • CMMI Two representations
    • Stage representation
      • Level – 5
        • OID, CAR
      • Level – 4
        • OPP, QPM
      • Level – 3
        • REQS, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR
      • Level – 2
        • REQM, PP, PMC, SAM, MA, PPQA, CM
    • Continuous representation
      • Support
        • CM, PPQA, MA, CAR, DAR
      • Engineering
        • REQM, REQS, TS, PI, VER, VAL
      • Project Management
        • PP, PMC, SAM, IPM, RSKM, QPM
      • Process Management
        • OPF, OPD, OT, OPP, OID
    CMMI product team, CMMI for Development (CMMI-DEV), Version 1.2, Carnegie Mellon Univ., Aug. 2006.
  • CMMI Maturity level Level 1 Initial Level 2 Managed Level 3 Defined Level 4 Quantitatively Managed Level 5 Optimized Process unpredictable, poorly controlled, and reactive Process characterized for project and is often reactive Process characterized for the organisation and is proactive Process measured and managed Focus on continuous process improvement
  • CMMI Maturity level - 5
    • Level 3
      • You document the process and insure everybody follows the process
    • Level 4
      • You measure the process as documented in the level 3
    • Level 5
      • You use the measurement captured in level 4 to optimised the process
      • Level 5 introduce formal feedback to the process. It is define in the CAR – Causal Analysis and Resolution process area.
  • Why BI needs CMMI-5
  • Why BI need CMMI-5
    • BI is a complex process that requires feedback
    • Only CMMI-5 has formal feedback
    • But CMMI-5 is hard to achieve ?
  • How hard is CMMI-5
    • The average CMMI process uses ~400 "objectives evidences" or control point
    • Template, form or document are always the obvious answer
      • A CMMI Appraiser will typically examines ~1000 documents
    • But they are other options
      • Digital photo (standard on many phone)
      • White board printout
      • Videos (Captured by cheap web cam)
      • Scanned drawing, documents including napkins
      • Database entry
      • Code comments
  • Examples of "objective evidence"
    • Code reviews can be evidenced directly in the code library with comments.
    • Configuration Planning documents can be consolidated within a single document (Tailoring checklist, Configuration audit checklist, Sizing and Estimating evidence).
    • Meeting Log can be used to consolidate: Meeting minute, Notice of decision, Stakeholder Involvement Report, Status Report, Stakeholder Communication.
    • Story Card can be used to consolidate: Customer Requirements, Product Component Requirements, Concepts and Scenario, Definition of Requirements Functionality.
    • Requirements Log can be used to consolidate: Change Request Log, Change Request Approval Form, Bi-Directional Traceability Matrix.
    • Test Driven Development can be use to consolidate : User Acceptance, Detail Specification, Customer signoff.
  • Consolidating CMMI-5 evidences
    • For process that are repetitive, like braking a BI project in a series of smaller "sprints", the CMMI-5 evidences can be consolidate:
      • From ~400 "objectives evidences"
      • To ~70 "objectives evidences"
    • With tools like code libraries, collaborative task board, user story management, automated test the resulting consolidation can reach down to:
      • ~ 50 "objectives evidences"
    CMMI or Agile : Why Not Embrace Both: H. Glazer, J. Dalton, D. Anderson, M. Konrad et S. Shrum
  • How to achieve BI CMMI-5
    • Because of the nature of BI development
      • Complex process
      • Short development cycle
      • Greater need for feedback
      • Need a rigorous process
    • By CMMI-5 combine with modern practices like
      • Product Backlog and planning meeting
      • Daily review
      • Short sprint
      • Review and retrospective meeting
    • Not only does it make CMMI-5 achievable, it make it a requirement for BI development.
    Scrum and CMMI Level 5 : The Magic Potion for Code Warriors: Jeff Sutherland, Carsten Ruseng Jakobsen , Kent Johnson, Agile 2005
  • Questions