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)