A presentation from June 20, 2000 Jim Brosseau The ‘How-To’ of Software Process Improvement.

Slides:



Advertisements
Similar presentations
DataSource & SEI’s Capability Maturity Model (CMM ® )
Advertisements

Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
More CMM Part Two : Details.
CMMI Overview Dr. Korson Software Engineering. 2 Immature organizations can be successful on occasion, but ultimately run into difficulties because –Success.
Software Process Improvement Robin B. Hunter, Ph.D. Vol 2., p Presented by: Andrew Wheeler.
CPIS 357 Software Quality & Testing I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010.
Stepan Potiyenko ISS Sr.SW Developer.
1 - Sudhir P, Balasubrahmanyam P Leveraging TSP SM /PSP SM Metrics to drive Predictability and Quality of product releases An Intuit Perspective.
IT Project Management Office
Software Development Process Models. The Waterfall Development Model.
Agile Software Development. Traditional Software Development 1.Initiation (RFP) 2.Feasibility study Technical – can we build it? Economic – should we.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
SE 470 Software Development Processes James Nowotarski 12 May 2003.
Capability Maturity Model (CMM) in SW design
Computer Engineering 203 R Smith Process/Plan Model 7/ Development Process Models Development Process Models are different ways to look at the processes.
1 R&D SDM 1 Software Project Management Capability Maturity Model 2009 Theo Schouten.
CMM Overview - 1 © Paul Sorenson CMPUT Software Engineering refs. IEEE Software, March 1988, 73-79, and IEEE Software, July 1993, (Capability.
Chapter 3 The Structure of the CMM
Software Process CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology December 17, 2002.
Software Management Plan (part I) Software management’s 7 deadly sins The “3 P’s” of software management Why big software projects fail: the key 12 questions.
How ISO 9001 Fits Into The Software World? Management of Software Projects and Personnel CIS 6516 March 6, 2006 Prepared by Olgu Yilmaz Swapna Mekala.
Using A Defined and Measured Personal Software Process Watts S. Humphrey CS 5391 Article 8.
Capability Maturity Model
Chapter : Software Process
Software Engineering II Lecture 1 Fakhar Lodhi. Software Engineering - IEEE 1.The application of a systematic, disciplined, quantifiable approach to the.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
Capability Maturity Model Part One - Overview. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First.
N By: Md Rezaul Huda Reza n
Project Management Chapter 3. Objectives Become familiar with estimation. Be able to create a project workplan. Understand why project teams use timeboxing.
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
J. R. Burns, Texas Tech University Capability Maturity Model -- CMM n Developed by the Software Engineering Institute (SEI) in 1989 –SEI is a spinoff.
CS3100 Software Project Management Week 26 - Quality Dr Tracy Hall.
Lecture 1 Introduction to Software Engineering
Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITHClass of 39 CS3600: Software Engineering: Standards in Process Modeling CMM and PSP.
Capability Maturity Models Software Engineering Institute (supported by DoD) The problems of software development are mainly caused by poor process management.
NDIA Systems Engineering Supportability & Interoperability Conference October 2003 Using Six Sigma to Improve Systems Engineering Rick Hefner, Ph.D.
By Ritesh Reddy Nagaram.  Organizations which are developing software processes are facing many problems regarding the need for change of already existing.
IIL’s International Project Management Day, 2007 The Power of the Profession: A Lesson Learned and Solution Implemented Becomes a Best Practice in Project.
Quality Concepts within CMM and PMI G.C.Reddy
Capability Maturity Model CS3300 Fall The Problem Contractors over budget and late. Need a way to rank how likely a software company is to deliver.
Georgia Institute of Technology CS 4320 Fall 2003.
Software Requirements: Overview and Motivation Gruia-Catalin Roman and Christopher Gill CSE 436 January 2007 Department of Computer Science and Engineering.
SWEN 5130 Requirements Engineering 1 Dr Jim Helm SWEN 5130 Requirements Engineering Requirements Management Under the CMM.
 Management ◦ The activities and tasks undertaken by one or more persons for the purpose of planning and controlling the activities of other in order.
Software Engineering - I
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
CSCI 521 Final Exam Review. Why Establish a Standard Process? It is nearly impossible to have a high quality product without a high quality process. Standard.
Implementation Phase CS4311 – Spring 2008 References: Shach, Object Oriented and Classical Software Engineering E. Braude, Software Engineering, an Object-Oriented.
Ch-1 Introduction The processes used for executing a software project have major effect on quality of s/w produced and productivity achieved in project…
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
SOFTWARE PROCESS IMPROVEMENT SHARATH CHANDAR REDDY ALETI CSC 532 TERM PAPER.
Introduction to the Personal Software Process. Overview Process Fundamentals PSP Concepts and Structure PSP Planning and Measurement PSP Quality Management.
Project Management Why do projects fail? Technical Reasons
Software Engineering (CSI 321) Software Process: A Generic View 1.
INNOVATE THROUGH MOTIVATION Mobile Computing & Your Business KEVIN KIRKPATRICK – OWNER, MSP INC LOGO.
Class-oriented metrics – Weighted methods per class, depth of the inheritance tree, number of children, coupling, response for class, lack of cohesion.
Capability Maturity Model. CS460 - Senior Design Project I (AY2004)2 Immature Organisations Software processes are often rigorously followed. Organisation.
Advanced Software Engineering Dr. Cheng
CS4311 Spring 2011 Process Improvement Dr
Software Engineering (CSI 321)
Information Technology Project Management – Fifth Edition
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
A possible solution: Personal Software Process (PSP)
CMM Overview A Focus on Level 2
By Jeff Burklo, Director
Software Engineering Lecture 16.
Software Engineering I
Capability Maturity Model
Capability Maturity Model
Presentation transcript:

a presentation from June 20, 2000 Jim Brosseau The ‘How-To’ of Software Process Improvement

© 2000 Software Productivity Center Inc. 2 Objectives Explain the importance of process 0to the individual 0to the project 0to the organization Introduce the concept of process as a way of life Discuss issues of practicality

© 2000 Software Productivity Center Inc. 3 Agenda Background Software development philosophy Process: myths and realities Process benefits at all levels Improvement approach and process models

© 2000 Software Productivity Center Inc. 4 Why Develop Software? A hierarchy of different objectives for developing software: Mission-critical systems Product development, custom software development Internal tools development Prototypes, course assignments Hacking, playing, investigating

© 2000 Software Productivity Center Inc. 5 Process applied to Development As development motivation matures, there is an increased need for process 0to stabilize the development lifecycle 0repeatability, predictability, manageability A single organization may be driven by all of these objectives at different times 0process needs are very different! Most companies are involved in the last 4 of these categories

© 2000 Software Productivity Center Inc. 6 Process Myths: Software Process is......inflexible, doesn’t fit organizational needs...just a documentation nightmare...stifles creativity: writing code is an art...adds overhead, extends project schedules...is not as effective as superstars...is just getting more code out the door …is no substitute for good tools Unfortunately, most of these myths are based on bad process improvement experiences

© 2000 Software Productivity Center Inc. 7 Process Realities When applied correctly, process improvement… …reduces software development risk …focuses creativity on the right areas 0design, schedule, coding challenges rather than how to explain to your customer you’re late this time... …pulls in development schedules 0effective oversight catches problems when they occur 0‘do the right things’, at the right time 0reduced rework

© 2000 Software Productivity Center Inc. 8 Process Realities Process improvement can… …bolster existing corporate and individual weaknesses 0‘improvement’ implies ‘deficiencies’...be applied across the organization 0through tailoring to meet needs …provide a framework for the injection/assessment of tools

© 2000 Software Productivity Center Inc. 9 Benefits for the Individual Reduced interruptions and surprises 0you can work on your planned tasks 0increased productivity Increased awareness of your surroundings 0greater mobility/flexibility 0increased opportunities for learning Improved morale 0more software, fewer bugs -> pride in your work

© 2000 Software Productivity Center Inc. 10 Benefits for the Project Improved ability to estimate tasks 0Higher predictability for project planning Reduced risk of surprises: 0‘requirements creep’ 0nasty integration bugs 0schedule breakdown - the 90% syndrome Improved chances of on-time delivery of a quality product

© 2000 Software Productivity Center Inc. 11 Benefits for the Organization Improved product stability 0increased customer satisfaction Reduced dependence on key individuals 0to pull projects out of trouble Increased repeatability of success 0facilitates more accurate strategic planning Improved quality and morale 0less staff turnover

© 2000 Software Productivity Center Inc. 12 Improving Process for You These benefits assume the IMPROVEMENT of process 0not merely the ADDITION of process Process needs to be applied to fix or avoid problems Needs ownership and commitment from all Is a continuous process, not a one-shot deal Is not a one-size-fits-all solution Is not magic - it is applied common sense

© 2000 Software Productivity Center Inc. 13 Typical Pains We’ve Seen Inability to predict ship dates 0poor control and estimation Requirements creep 0poor control Delivery of poor quality 0inadequate focus on review/test

© 2000 Software Productivity Center Inc. 14 Typical Improvement Areas Project management fundamentals Improved scope control More focussed quality control Closure on CM issues Measurement -> refined estimation Reviews as an extension of ‘test’

© 2000 Software Productivity Center Inc. 15 Success Factors for Process Improvement Projects Keep an open mind 0the old way isn’t always the only way Don’t get personal 0focus on process not people Perceived problems are just as real as actual problems Commit time to the process improvement project

© 2000 Software Productivity Center Inc. 16 Productivity Defined Traditional Productivity Improvement 0more widgets produced per minute Software Development Productivity is more than just “programmer productivity” (e.g LOC written per day) Have to measure productivity over the whole lifecycle of a project

© 2000 Software Productivity Center Inc. 17 Software Productivity Defined The rate of outputs vs. inputs 0e.g. LOC, function points per person-month Should consider the efficient use of inputs 0e.g. how much time spent finding defects using testing vs. code inspection NOTE: Measure teams, not people!

© 2000 Software Productivity Center Inc. 18 Software Productivity Defined A consideration of the quality of outputs 0e.g. number of defects 0Doing things right - avoid rework Time Cost of defect correction

© 2000 Software Productivity Center Inc. 19 How to Improve Productivity Optimize the Development Process 0maximize results in time spent 0make development predictable, repeatable 0streamline activities, reduce re-work 0make the job more enjoyable and professional

© 2000 Software Productivity Center Inc. 20 How to Improve Productivity? Optimize the Technology 0languages 0tools 0design techniques (e.g. OO) 0specification techniques (e.g. JAD) BUT: Avoid the silver bullet syndrome

© 2000 Software Productivity Center Inc. 21 The SEI Capability Maturity Model for Software A roadmap model for establishing improved software engineering process From the Software Engineering Institute (SEI) Has been in use for more than 10 years A framework for understanding industry “best practices”

© 2000 Software Productivity Center Inc. 22 SW-CMM : 5 Levels Initial (1) Standard, consistent process Disciplined process Predictable process Continuously improving process Repeatable (2) Defined (3) Managed (4) Optimizing (5)

© 2000 Software Productivity Center Inc. 23 SW-CMM Structure

© 2000 Software Productivity Center Inc. 24 Initial - “Code & Fix”

© 2000 Software Productivity Center Inc. 25 Repeatable - “Milestone-Driven” In Out

© 2000 Software Productivity Center Inc. 26 Defined - “Tasks & Milestones” Out In

© 2000 Software Productivity Center Inc. 27 Managed - “Measured Tasks and Milestones” Out In

© 2000 Software Productivity Center Inc. 28 Optimizing - “Tuned” Out In

© 2000 Software Productivity Center Inc. 29 ~ 60% at Level 1 ~ 25% at Level 2 ~ 15% at Level 3 Maturity Levels in Industry Biggest benefits realized in moving from Level 1 to Levels 2 and 3 0Estimated vs. Actual Cost and Schedule have been shown to get very close by Level 3 0Productivity improvement can be % 0Defects are reduced, sometimes dramatically Can take 1-2 years to move up one Level

© 2000 Software Productivity Center Inc. 30 Key Process Areas for Levels 2 and 3 Level 2 Requirements Management S/w Project Planning S/w Project Tracking & Oversight S/w Quality Assurance S/w Subcontract Management S/w Configuration Management Level 3 S/w Product Engineering Peer Reviews Integrated s/w Management Inter-group Coordination Organization Process Focus Organization Process Definition Training Program

© 2000 Software Productivity Center Inc. 31 Leveraging Assistance Leveraging models: generally accepted breadth of coverage Leveraging expertise: core competency issues objective viewpoint Leveraging peers: Been there, done that

© 2000 Software Productivity Center Inc. 32 Key Points in closing Goal is to reduce pain Continuous, gradual improvement Use an established model Leverage wherever possible Measure to provide feedback