Process Maturity and Project Closeout - PowerPoint PPT Presentation

1 / 51
About This Presentation
Title:

Process Maturity and Project Closeout

Description:

First matrix called 'house of quality' Series of connected houses ... Doesn't stick to fabric 6 X BA. Provides enough steam 8 AB X. Doesn't spot fabric 6 X AB ... – PowerPoint PPT presentation

Number of Views:327
Avg rating:3.0/5.0
Slides: 52
Provided by: jamesr1
Category:

less

Transcript and Presenter's Notes

Title: Process Maturity and Project Closeout


1
Process Maturity and Project Closeout
  • James R. Burns
  • Tuesday, November 4, 2008

2
Maturity Models
  • Software Quality Function Deployment
  • Capability Maturity Model
  • Project Maturity Model
  • See pages 293-296?? of Schwalbe, 6rd Edition

3
Quality Function Deployment
  • Translates the voice of the customer into
    technical design requirements
  • Customer is King
  • Displays requirements in matrix diagrams
  • First matrix called house of quality
  • Series of connected houses

4
Quality House
5
(No Transcript)
6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
Capability Maturity Model
  • Developed in preliminary form by Watts Humphries
    (published in a book he wrote that appeared in
    1989)
  • Refined by the SEI (Software Engineering
    Institute) , a spin-off of Carnegie Mellon
    University in Pittsburgh
  • Known as the CMM
  • Discussed in Schwalbe, page 293-296 (approx)

10
Immature Software Organizations
  • Processes are ad hoc, and occasionally chaotic.
  • Processes are improvised by practitioners ON THE
    FLY.
  • Testing, reviews and walkthroughs usually
    curtailed under stress.
  • Quality is unpredictable.

11
Immature Software Organizations, Contd
  • Costs and schedules are usually exceeded.
  • Reactionary management is usually firefighting.
  • Success rides on individual talent and heroic
    effort.
  • Technology benefits are lost in the noise.

12
Mature Software Organizations
  • Processes are defined and documented.
  • Roles and responsibilities are clear.
  • Product and process are measured.
  • Processes and projects finish on time and within
    budget
  • Management has time to plan, monitor, and
    communicate.

13
Mature Software Organizations, Contd
  • Quality, costs, and schedules are predictable
  • Management committed to continuous improvement.
  • Technology is used effectively within defined
    processes.

14
Software Process Definition
  • Project Planning
  • Project Management
  • Software Engineering Procedures
  • Software standards
  • Software Quality Evaluation
  • Software Configuration management

15
The Five Levels of Software Process Maturity
  • INITIAL
  • REPEATABLE
  • DEFINED
  • MANAGED
  • OPTIMIZING

16
Five Levels
17
Initial
  • Software processes are ad hoc, even chaotic
  • The software processes are not defined
  • Success depends on individual effort
  • The environment is not stable

18
Initial, Continued
  • The benefits of software engineering practices
    are undermined
  • Planning is nonexistent or ineffective
  • Process capability is unpredictable because the
    software process is constantly changed or
    modified as the work progresses

19
Repeatable
  • Basic project management policies and procedures
    are established
  • Cost, schedule and functionality are tracked by
    module and task
  • A process discipline is put in place to repeat
    earlier successes
  • Managing new projects is based on experience with
    similar projects

20
Repeatable, Continued
  • Basic software management controls are installed
  • Estimations of cost and time to complete are
    based on history for similar projects
  • Problems are identified and documented
  • Software requirements are baselined (made tough
    to change)

21
Repeatable, Continued
  • Project standards are defined
  • Project teams work with their customers and
    subcontractors to establish stable, managed
    working environments
  • Process is under the control of a project
    management system that is driven by performance
    on previous projects
  • A project performance database is defined and
    populated

22
Defined
  • Software processes are documented
  • Software processes are standardized and
    integrated organization-wide
  • All projects use documented and approved versions
    of the organizations processes of developing and
    maintaining software
  • A Software Engineering Process Group (SEPG) is
    created to facilitate process definition and
    improvement efforts

23
Defined, Continued
  • Organization-wide training programs are
    implemented
  • Organization-wide standard software processes can
    be refined to encompass the unique
    characteristics of the project
  • A peer review process is used to enhance product
    quality
  • Process capability is stable and based on a
    common understanding of processes, roles, and
    responsibilities in a defined process

24
Managed
  • Quantitative quality goals are defined
  • Product quality and productivity are measured and
    collected
  • Both processes and products are quantitatively
    understood
  • Both processes and products are controlled using
    detailed measures
  • A productivity and quality database is defined

25
Managed, Continued
  • Projects achieve control by narrowing the
    variation in performance to within acceptable
    boundaries
  • Process variation is controlled by use of a
    strategic business plan that details which
    product lines to pursue
  • Risks associated with moving up the learning
    curve of a new application domain are known and
    carefully managed
  • Process capability is measured and operating
    within measurable limits

26
Optimizing
  • Continuous process improvement is enabled by
    quantitative feedback
  • Continuous process improvement is assessed from
    testing innovative ideas and technologies
  • Weak process elements are identified and
    strengthened
  • Defect prevention is explicit

27
Optimizing, Contd
  • Statistical evidence is available on process
    effectiveness
  • Innovations that exploit the best software
    engineering practices are identified
  • Improvement occurs from
  • INCREMENTAL ADVANCEMENTS IN EXISTING PROCESSES
  • INNOVATIONS USING NEW TECHNOLOGIES AND METHODS

28
How are firms doing??
  • Very few U.S. firms have reached the highest
    level, OPTIMIZING
  • 75 of firms are still at the INITIAL level
  • AS OF THE YEAR 2001

29
(No Transcript)
30
Project Management Maturity Model
  • 1. Ad-Hoc The project management process is
    described as disorganized, and occasionally even
    chaotic. The organization has not defined systems
    and processes, and project success depends on
    individual effort. There are chronic cost and
    schedule problems.
  • 2. Abbreviated There are some project management
    processes and systems in place to track cost,
    schedule, and scope. Project success is largely
    unpredictable and cost and schedule problems are
    common.
  • 3. Organized There are standardized, documented
    project management processes and systems that are
    integrated into the rest of the organization.
    Project success is more predictable, and cost and
    schedule performance is improved.
  • 4. Managed Management collects and uses detailed
    measures of the effectiveness of project
    management. Project success is more uniform, and
    cost and schedule performance conforms to plan.
  • 5. Adaptive Feedback from the project management
    process and from piloting innovative ideas and
    technologies enables continuous improvement.
    Project success is the norm, and cost and
    schedule performance is continuously improving.

31
The official PMM has yet to appear
  • The PMM suggested above was developed by
    MicroFrame Technologies and Project-Management
    Technologies, Inc.
  • See page 295 of your Schwalbe text

32
Use of this tool has shown
  • The Engineering and Construction Industries have
    a higher level of maturity than do the
    information systems and software development
    disciplines

33
Completing and Terminating a Project
  • James Burns
  • Tuesday, November 4, 2008

34
Completing
  • Integration Testing
  • Regression methods
  • Final Testing
  • Acceptance Testing
  • Installation/Conversion
  • Training

35
Acceptance Testing
  • to get paid

36
Final, Thorough Test
  • Do beta testing??
  • Run some old integration tests
  • Devise true-to-life tests
  • Try to overload the system
  • Try to break it by entering wrong inputs, out of
    range values, etc.
  • Test user documentation as well.

37
Installation
  • going live

38
Training
  • Usually, not enough budget is set aside for
    training
  • At the mid-market level and lower, training
    budgets are slim
  • On-line, context-sensitive help is one answer

39
Conversion
  • Crash
  • Parallel
  • Pilot

40
Customer Survey
  • Degree to which objectives were achieved?
  • Degree to which users accepted and endorsed the
    product
  • Overall satisfaction level
  • Best if done by an outside survey agency or firm

41
Lessons LearnedHERE ARE SOME POSSIBILITIES
  • Allow enough time?
  • Make it fun?
  • Beginnings are important!
  • Top management support is critical!
  • Managing change is 50 percent of project
    management!
  • Make management reviews interactive!
  • Set realistic milestone dates, but stick to the
    schedule!
  • Plan at a workable level!

42
Closing Bash
  • Party?
  • Rap song?
  • Actor?

43
Practices
  • A walkthrough after every design phase is a good
    practice
  • Architectural design
  • Then a walkthrough
  • Medium-level design
  • A walkthrough
  • Database design
  • A walkthrough
  • Detailed design
  • A walkthrough

44
Software Tools--use them
  • Librarians--keep track of who changed what when
  • also called Code Management Systems
  • Module Management Systems
  • automate the building of an entire software
    system
  • Performance Coverage analyzer
  • determines where all the computing time is being
    spent
  • traces sections of the system that were executed,
    their frequency and duration

45
More Tools
  • Source code analyzers
  • Tells you where youre doing strange or
    inefficient things in the source code
  • Lets you find all usages of a particular variable
    or string
  • Test Manager
  • makes regression testing very simple
  • Debugger
  • Program stop, trace, and step through

46
Closing
  • The closing process
  • Provide a warranty
  • Be willing to address any problems that crop up
    within a six-month period of installation

47
Termination
  • Get paid
  • History Database
  • Lessons Learned
  • Post project review (also called a POSTMORTEM)
  • Write down what went well, what could have been
    improved, make suggestions for follow on
    projects, gather more statistics on actual vs.
    planned performance
  • Produce a formal report
  • Write follow-on proposal for next project
  • Sell the next project

48
Maintenance
  • Should be considered as a separate project,
    separately funded, so you can get paid for all of
    the development work

49
Checklist for Closeout Termination Stage
  • New system is up and running smoothly
  • Conversion and cutover from any older systems is
    complete
  • End users are trained and comfortable with new
    system
  • Warranty is provided
  • The next project is sold
  • A post project review (POSTMORTEM) is held
  • Responsibility and method of ongoing maintenance
    is defined

50
User documentation
  • Run/installation manual
  • Users Guide
  • Maintenance Guide
  • Training documentation

51
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com