Software Process Maturity

Software maturity Framework, Principles of

Software Process Change, Software Process
Assessment, The Initial Process, The Repeatable
Process, The Defined Process, The Managed
Process, The Optimizing Process, Process Reference
Models Capability Maturity Model (CMM), CMMI,
PCMM, PSP, TSP).
 Software Process
Set of related activities to the production of software product.
There are many different software processes but all must include 4
activities that are fundamental to software engineering.

Software Specification – functionality of software and constrainsts on its

operations must be defined.

Software Design and Implementation – Specification must be met.

Software Validation – validated to ensure what customer wants.
Software Evolution – Must evolve to meet changing customer needs.
Software Maturity Framework:

• The software process -- set of tools, methods, and practices -software

product.
• The objectives of software process management are to produce products
+ improving the organization’s capability to produce better products.
• The basic principles are those of statistical process control.
• To obtain consistently better results, it is necessary to improve the process.
• If the process is not under statistical control, sustained progress is not
possible until it is.
• Lord Kelvin - “When you can measure what you are speaking
about, and express it in numbers, you know something about it;
but when you cannot measure it, when you cannot express it in
numbers, your knowledge is of a meager and unsatisfactory kind;
it may be the beginning of knowledge, but you have scarcely in
your thoughts advanced the stage of science.”
Software Process Improvement:

• To Improve software quality organization six steps are required:

• Understand the Current status of development process.
• Develop vision of desired process.
• Establish the list of required process improvement actions as per

• priority.
• Produce the plan to accomplish the required action.
• Commit the resources to execute the plan.
• Start over the first step.
Process Maturity Levels:

• At Initial stage Statistical control Progress is only possible until it

meets possibility , predicting ,scheduling and cost in a project.
• Repeatable is under stable process only if it meets statistical control
and also meet commitment, costs , schedules and charges planned
at initial stage.
• Defined
• Managed
• Optimizing
Principles of Software Process Change:

People:
• The best people are always in short supply
• Best team you can get right now.
• With proper leadership and support, people can do much better.

Design:
• Superior products have superior design.
• Successful products are designed by people who understand
the application.
• A program should be viewed as executable knowledge.
• Program designers should have application knowledge.
• Major changes to the process must start at the top by Senior
management.
• Team effort.
• Effective change ---great knowledge
• Change is continuous.
• Software process changes will not be retained without conscious
effort and periodic reinforcement.
• Software process improvement requires investment
---planning
---capital investment
---manage time
Continuous Change:

• Reactive changes - worse.

• Every defect is an improvement opportunity
• Crisis prevention is more important than crisis recovery
Software Processes Changes Won’t Stick by
Themselves
• The tendency for improvements to deteriorate is characterized by the
term entrophy
• Installation - Initial training
• Practice - perform as instructed
• Proficiency - Traditional learning curve
• Naturalness - performed without intellectual effort.
It Takes Time, Skill, and Money!

• To improve - software process, someone must work on it

• Automation --poorly defined process = poorly results
• Improvements should be made in small steps
• Train!!!!
Some Common Misconceptions about the Software Process

• Start with firm requirements.

• If it passes test it must be OK.
• Software quality can’t be measured.
• The problems are technical.
• We need better people.
• Software management is different.
Stratergy for implementing software process change

• Tools,methods and organizational structure -- care.

• Champions will be a blessing for sponser creditability.
• Agents - enthusiastic ,provide effective solutions .
respect colleagues.
Software Process Assessment

• Process assessments - identifying their crucial problems and establish

improvement priorities.

The basic assessment objectives are:

• How the organization works.
• Identify major problems.
• Opinion leaders -- change process.
• The essential approach -- series of structured interviews to learn
their problems, concerns, and creative ideas.
 ASSESSMENT OVERVIEW
• A software assessment is not an audit.
• Audit - senior managers.
• A software process assessment --review of a s/w organization to advise its management and
professionals – improve.

The phases of assessment are:

Preparation - Senior management take actions(Training program for the assessment team)

• Assessment - The on-site assessment period. (two or more weeks). Report to local management.

• Recommendations - Final recommendations are presented to local managers

plan and implement the recommendations.

 Assessment Principles:

• Vision on how to perform processes.

• Assessment team has good experience and intuition.
• Confidentiality ----results with out problems.

• Senior management set organization priorities .

• Local managers typically gives final approval and answers to corporate.

• Senior managers = site managers ,who involve in assessment and follow up action.
• Site managers personally participate, assign qualified people and review the progress.
• Focus on Action
Assessment Process:

• Assessment team leader is selected

small groups (team members ).

• Team members (8-10 years exp) and worked for well respected
positions in organizations .

• They also hold team leader capabilities and be a good team player.
Self Assessment Consideration :
Organization - not rely on site managers.

Assessment ground rules:

• Assessment results confidential.
• Site managers responsible to open or close assessment meetings.

• designates a person (org) - member of assessment team.

Action plan:
 Involve leading professionals from several projects to prepare plan.
 Key manager.
 Site manager.

Reassessment:
Conduct follow up ,assessment after initial plan developed and
approved.

Implementation consideration:
Senior management quarterly review visibility , plan , crisis ,risks , conflicts
and inadequate support.
Assessment team trainings:
Training,on-site ,meetings as per requirement + Assessment guidelines
(written agreement)

On-site period:
• Assessment starts with presentation to site manager, staff senior
management ----overview of process functional area.
• Interaction with functionality, quessionare and risk areas will be discussed.

Assessment Report :
Written report + presentation (scope, assessment conduct and
summary.)

• Understanding and consequences

The Initial Process(Level1)
Nature of Initial process:
1. Unplanned priorities and changes occur.
2. Do not meet commitments as they are not well planned with
commitments.
[Link] managers frequently replaced and this will increase in issues
caused while handling problems.
4. Initial process is frustating.
• Usually ad hoc and chaotic –No clear plan cost estimates, and project
plans.
• Tools – not well integrated ,nor uniformly applied.
• Problems with Software installation and maintenance.
• Formal procedures -- planning and tracking work, no validation.
• Procedures are often abandoned in a crisis of coding and testing.
• Level 1 -design and code inspections not used and other techniques
not directly related to shipping a product.
Unplanned commitments

• When a new feature seems simple , management may just commit to

do it without planning.
• Change is far more complicated than thought.
• This results- confusion, changed priorities and stress.
• The users and senior management become frustrated and unwilling to
listen to excuses when this becomes a pattern.
Gurus:
• Gurus can make this worse because they run projects out of their
heads. With nothing written down, everyone comes to them for
guidance.
• At the breaking point ,the limits of this intuitive approach have been
reached and there is no simple recovery.

Magic
• “ No silver bullets”- Brooks.
Problems of scale:

As software products become larger, the progressive level of scale are

roughly as follows.
1. One person knows
2. A large software project is defined and understood --- product
management level.
3. Separate team understands the characteristics and design of each of
its component programs.
4. When the system is very large and has evolved through many version,
there may be no one who understands it.
As software knowledge is more widely distributed:

1. Common notations(documented, interpreted and updated) are

needed for precise communication.
2. Conflicts in standards must be identified and resolved.
3. Standards changes must be controlled and distributed(along
requirements , design, code and test.)
4. As software size increases, prototypes or multiple releases needed
because:

The total function cannot be implemented at one time.

With multiple releases ,new complications arise:

1. Meet requirements .
2. Synchronize design with needs
3. Product interdependencies are coordinated+ functional requirement

release
4. The builds and integration plans are scheduled around these interdependencies .
5. Components test needs.
6. Subsequent release development ..

Software process Entrophy:

The way out:
Organizations at Level 1 can improve their performance by instituting
basic project controls-

A) Project management - Plan the work.

- Track and maintain the plan .
- Divide the work into individual parts.

B) Management oversight - Precisely define the requirements for each part.

- Rigorously control the relationships among the parts.
- Fix gap between your knowledge and the task.

C) Quality assurance - Manage, audit and review the work.

- Commit to your work and work to your commitments.

D) Change control - Refine the plans as your knowledge improves.

The Repeatable Process (Level 2)
• Control over the way the organization establishes plans and commitments.
• Improvement to Level 1  people in the [Link] believe they
have mastered the software problem.

Level 2 org. faces major risks with new challenges.

1. New tools and methods will affect processes.
2. Major organizational change can be highly disruptive.
3. At Level 2, a new manager has no orderly basis – org. operation, new members
must learn.
4. Key actions required to advance from Repeatable to the next stage, the Defined
Process, are:
Establish a process group: A process group is a technical
resource that focuses heavily on improving software processes.

Establish a software development process architecture: technical and

management activities required for proper execution of the development process.
set of prerequisites, functional decompositions, verification procedures,
and task completion specifications.
Commitment discipline
Commitments - supported by plans, reviews and so forth but
commitments are met by people.

The elements of an effective commitments are:

• commitments does willingly.
• The commitments is not made lightly.
• Agreement between the parties
• The commitment is openly stated.
• Meet the commitment.
• Prior to the commitment date , if it is clear that is cannot be met,
advance notice is given and a new commitment is negotiated.
Software Commitment process:

These commitments are made only after successful completion of a

formal review and concurrence process.

•Work defined-- between the developers and the customer.

•A documented plan- resource estimate , schedule and cost estimate.

•Agreement between parties.

•Adequate planning -> ensure the commitment is a reasonable risk.

•An independent review -> planning work as per organization’s

standards and procedures.
Product and Period plans:

• Technical and business issues in annual and organizational terms.

(expenses , capital requirements and product delivery
commitments )

• Product plan focus ---------activities and objectives of each product .

The issues are functional, cost ,schedule and quality.

• Together with related resources and checkpoints.

Contention Process:

[Link] management -- parallel contention system to differences and their rational

resolution.
[Link] decisions are reviewed among parties are requested to agree.
3. Time comes for decision- parties state their views.
[Link] agreement , senior management determines agreement-until the necessary
homework is done.
5. It doesn't cause conflict — it shows where conflict already exists and makes it
helpful."
•6. Management  system for tracking projects and commitments
 Quaterly Review
Major Risks at Level 2:

• New tools or methods can disrupt existing processes.

• New product types bring unknown challenges.
• Organizational changes (like new managers or staff) can cause
confusion due to lack of formal structure.
Project planning principles
• It is technique that estimate the desired project on time with
sufficient resources.
• Project plan begins by mapping unclear and incomplete
requirements.
• Develop conceptual based design by estimating software delivery on
time.
Planning cycle of software Development
• Negotiate: Must ship a payments MVP by 30 Nov; must support cards +
refunds; ACH can wait.
• Decompose: 6 epics → 42 stories (auth, payment gateway, ledger, refund
flow, admin, reporting).
• Size: 18–22 KLOC (or 160 FP).
• Resources: 6 engineers, 1 QA, 1 SRE, 1 PM → ~24 person-months + perf
test env + PCI scans.
• Schedule: Critical path shows 14 weeks; target is 12 → No.
• Adjust: De-scope advanced reporting, buy a hosted ledger, add one senior
backend for 8 weeks → now 11.5 weeks → Yes.
• Build & Deliver.
• Compare: Actual effort 26 PM, defects higher in refund module →
calibrate future estimates for payment flows and strengthen test
automation estimates.
Various elements of software plan
• Goals and objectives
• Work Breakdown structures(WBS)
• Estimates of product size
• Estimates of resources
• Scheduling projects.
Lines of code(LOC)
• "Lines of code" (LOC)
• Difficult to find LOC at beginning ,so project manager adopted
technique by dividing project to modules -> submodules.

Functional Points

The Function Point (FP) metric is a software measurement technique

that quantifies the amount of business functionality an information
system provides to its users.
[Link] Inputs (EI):
User inputs that add, update, or delete system data.
Example: Entering a new customer record.
[Link] Outputs (EO):
Reports or messages the system produces.
Example: Generating an invoice.
[Link] Inquiries (EQ):
User queries that retrieve information without updating.
Example: Checking order status.
[Link] Logical Files (ILF):
Data that the system maintains internally.
Example: Customer database, Employee file.
[Link] Interface Files (EIF):
Data used from other systems but not maintained by the current system.
Example: Reading currency exchange rates from an external service.
Unadjusted function point
• Unadjusted Function Point (UFP) is the function size of a software
system, calculated before applying any environmental or complexity
adjustment factors in Function Point Analysis (FPA).
• It represents the total functional components the system delivers to
the user, weighted by their complexity.

How UFP is Calculated

UFP = (NI) *4 + (NO) * 5 + (NA) * 4 + (NF) *10 + (NT) *10

Component Low Average High
NI 3 4 6
NO 4 5 7
NQ 3 4 6
NF 7 10 15
NT 5 7 10

Example Calculation
5 NIs (Low complexity)
4 NOs (Average complexity)
2 NQs (High complexity)
3 NFs (Average complexity
1 NT (Low complexity)

UFP = (NI) *4 + (NO) * 5 + (NQ) * 4 + (NF) *10 + (NT) *10 )

UFP=20+20+8+30+10=88
Technical complexity factor:
In Function Point Analysis (FPA), the Technical Complexity Factor (TCF) is an
adjustment applied to the Unadjusted Function Points (UFP) to account for the
overall technical and operational complexity of the system.
(Adjust based on system characteristics (performance, security, portability, etc.).

• Sum all ratings to get DI (Degree of Influence).

• Calculate TCF using the formula:
TCF=0.65+(0.01×DI)
Where DI can range from 0 to 70, so TCF will range from 0.65 to 1.35.

Adjusted Function Points (AFP)

• Once TCF is calculated:
FP (or AFP)=UFP×TCF
Basic configuration management functions:
• 8. Store in Database (Baselines + Changes)
• Both baselines and changes are stored in a configuration management
database/repository.
• This allows tracking of:
• Which version is active
• What changes have been made
• Who approved them
• When they were implemented
• Cycle
• Every time new requirements or updates arise, the process repeats:
• Request → Authorize → Implement → Validate → Approve → Update baseline.
Software quality assurance
• Software Quality Assurance (SQA) is a set of activities and processes
used to ensure that software meets specified quality standards and
performs as intended.

Focus on preventing defects during the software development life

cycle instead of detecting them after they occur.
• Errors encountered during debugging– Logic error Eliminated by
- Runtime error 1. Error based testing
2. Scenario based
- syntax error testing
Key Actions to Move to Level 3 (Defined Level):

• Create a process group – A dedicated team to improve and manage

software processes.

• Build a development process architecture – Define all technical and

management tasks clearly, with steps and criteria.

• Adopt modern engineering methods – Use formal reviews, testing,

design practices, and modern tools/languages.
Defined Process
Software standard defines size,content,quality ,object and value.

Reasons for defining software standards

[Link] software is organized to single set of uniform procedures.

2. They allow professionals to move between projects.
3. Defines uniform method to review the work.
4. Specifies usage of better tools and methods.
5. Maintains the ability of product developed.
6. Provides standards for error reporting,test plans and estimations.
Most of common used standards are:
• Logical expression- mathematical based technique
• Program expression- program structure
• Program design- refinement process
• Program design verification.- theoretical technique to prove correctness.
• Program design practices- process depending on state machine ,allow creation
and documentation of software

Establishing software standard:

• Organization must consider- project status,planning,developing,tools
• Priority needs with in an organization.
• Project status.
• Standard enforcement mean- standards evaluated and reviewed
Standard development process.

• Develop standard based on reviews

• Review ,distributed and maintain the standard statergy..
• Creating top priority standards.
• Distribute and review the draft.
• Standards are to be evaluated based on actual price.
Principles of inspection:

Inspection is a process of verifying work or project . Focuses

on identifying errors at early stage. Predefined defined criteria met or
not.

• Focus on completing the technical task.

• Assist utilization of best talent in organization.
Types of software testing:

White Box Testing-- Internal logic and structure of program code.

Also known as glass – box and open box testing.
Statement coverage: checks each statement in module executed once.
Branch / Decision coverage: Each branch decision is executed atleast once or not.
Condition coverage : Test performed to check whether each condition in a decision accepts the
necessary outputs at least once.
Black box testing (functional testing or behavioural testing) It concentrates on inputs and outputs
and principle function of software module . Checks the overall functionality.
Inaccurate functions.
Interface errors.
Performance errors.
Data structure errors.
Initialization and termination errors.
Top down testing-find critical bugs early ,provide quality at end
Bottom up testing -lower modules tested first and integrated with higher modules until all
components integrated
Booch Methodology:

It includes many diagrams like class diagram, object diagram, state transition
diagram,process diagram and interaction diagram.

Macro development process:

Manages the technological areas in a [Link] takes place from weeks to

[Link] is applied to conceptualization,Analysis and development of model,Design
system architecture,implementation and maintenance.

Micro development process:

Works on semantic,relationship of classes and [Link] finds
relationship between classes and object .
Unified Approach proposed repository:

Repository is a place where previously defined data such as

objects,pattersn ,framework and user interfaces are stored.
This data comproises of the best practices of already completed
[Link] of best practices minimizes duplication and ensures
good quality.
Suppose and organization takes an initiative to develop new
applications or a software whoso requirements are almost similar to the
requirements of the projects that were designed earlier.
Then the developer can easily select only those
[Link] reduces cost and development time of the product.
Pattern and pattern templates:
Patterns are used in software development to provide documentation
which assists designers to classify and discuss about recurring problems.
Developers can exchange ideas and experiences on these problems to
identify similar patterns to produce better solution and applied in software
architecture.
If certain pattern of problem has occurred and may occur again then that is
called proto-pattern.
Good pattern consists of :
Solutions to problems.
Keep track of problems that were experimentally solved.
Discuss relationship between various system modules.
Good pattern begins with abstract to facilitate overview of pattern.
What are Patterns in Software?
•
pattern is like a reusable solution to a common problem in software design.
A

•Instead of solving the same problem again and again, developers use a "template" (pattern) that
worked well before.
•Patterns also help developers talk to each other using a common language (for example:
“singleton” or “observer”).

What is a Proto-pattern?
•
proto-pattern is like an early version of a pattern.
A

•It’s an idea or a solution that worked once and might work again, but it hasn’t been tested enough
in many situations.
•Once it’s used successfully in many projects, it can become a well-known “pattern.”
Pattern Templates:
Pattern templates are several attributes of a pattern which describes
existence of pattern. Templates or components of pattern are:
Name
Problem
Initial context.
Forces means motivation for generating the resulting pattern.
Solution.
Examples
Resulting Context
Rationale
Related pattern.
Known uses.
Models defined in Software Process:
U- process model(spiral model):
It enables development of efficient software process.
A- process model :
Detailed software model. It is automatic process model or
standardized methods to execute specific task. Also defines data functions,
algorithm, information flows procedures at each level.
W- Process Model (Worldly process model):
Defines sequence of tasks, prerequisites and [Link] helps
software engineers to track completion of work done on time.
This model is designed to describe results, measures and key checkpoints.
This model as a procedures in operational form as it specifies
Models defined in Software Process
• U- Process Model (Spiral Model):
• This model helps in developing efficient software processes.
• It combines design and prototyping in stages, allowing risk analysis at each step.
• Useful when the project is large, complex, and risky.
• A- Process Model:
• A detailed software model.
• It is an automatic process model, meaning it uses standard methods to execute tasks.
• Defines data functions, algorithms, and information flow clearly at each level.
• Ensures tasks are standardized and repeatable.
• W- Process Model (Worldly Process Model):
• Defines the sequence of tasks, their prerequisites, and the expected results.
• Helps software engineers track progress and ensure work is done on time.
• Focuses on results, measurements, and checkpoints to monitor progress.
• Works as a procedure in operational form, specifying clear steps to follow.
In short:
• U-Process Model (Spiral): Focuses on efficiency and handling risks.
• A-Process Model: Provides detailed, automatic, and standardized methods.
• W-Process Model: Defines sequence, results, and checkpoints to track timely
Critical process Issues:
Quality - Design, code, development, Improve testing and software
quality assurance.
Product Technology – New technology alogorithms,
goals ,configuration.
Instability of Requirment
If Requirments are Unknown.
Unstable Requirments
Misunderstanding of Requirements
Complexity.
Software Engineering Process Group( SEPG)

SEPG improves software processes by checking organization’s capability, plans,

and project results.
Software quality is improved by setting rules for each task.
Roles of SEPG:
1) Create process standards.
2) Keep a process database.
3) Introduce new technologies.
4) Provide training/education.
5) Help projects with advice.
6) Do regular assessments.
7) Prepare progress reports.
 The Managed Process:

Data Gathering and Analysis: To measure software process,based on key

events ,process and relationships.

Principles of Data Gathering:

•Collect data according to the goal and plan.
•Use a model or idea of the process as a guide.
•Data should cover the whole organization.
•Management should support the process.

Objectives of Data Gathering:

Understanding- Learn specific process
Evaluation – study product or activity.
Control – control of any particular activity
Prediction – data gathering is done to develop rate indicator.
Data gathering problems:

 Inaccurate Data-no proper database

 Delay in data- Data incorrect or not rapid.
 Improper measuring of data or data not indexed properly
 Huge amount of data is needed.
 Unavailability of required data.
Software quality principles: Checks overall software quality

1. Measures must be established by senior management.

2. Define, document software quality measures.
3. Design software quality- meeting requirements.
Critical elements of Software quality management:

Quality performance is monitored and reported to authority.

Resources gathered as per reports.
Timely manner product performance evaluated.
Based on results new plan is developed and reported to senior
management.
Plan prepared to improve performance and fullfill target.
The Optimizing Process:

Defect Prevention:
Techniques involved are:
Huge and complex programs are required to satisfy the user requirements
which might effect the society.
Team members are trained properly before assigning the project.
Even minute errors are reported to senior management in this process.
Software Defect Prevention Principles:

1. Self evaluation of errors by programmers.

2. Continuous feedback from users.
3. Problems eliminated step by step.
Software defects prevention:
• Defect Reporting:
• Cause Analysis:
• Action plan development and Implementation

Building trust in software contract:

Principles of software contract management :
1. Document of requirements is checked to validate the objectives and plan is
produced.
2. Design phase started with defined requirements.
3. Objectives are rechecked to be on right path.
4. Performance of contract is judged based on development and process
indicator
5. Implementing ,tracking ,auditing and quality assurance of project are done.
6. Four possible cases of buyer, vendor competence:
Technically, both buyer and vendor are competent.
Technically ,only vendor is competent.
Technically ,only buyer is competent.
Technically, neither buyer nor vendor is competent.
Quantitative process tracking:

Code size – LOC measure used to obtain weight and individual modules.

Planned resources and schedule – Time period assign for submission.

Number of modules and Tests completed – LOC measure along with

weight and way of testing.

Number of defects found : As defects cannot be evaluated till the end,

this measure is not preferable.
Process certification:

1. Managing the low maturity (level 1 ) process

 Senior management involved to check plan, approval , cost estimation, resources and
tracking.
 SCM is used to control process operations and its completion.
 SQA teams are also used for reviewing.

2. Managing the level 2 Maturity process

SQA reviews manage the workload.
SCM teams are used for development.
Standard code ,design and testing with proper inspections.
SEPG team monitors the work.
3. Managing the level 3 and above Maturity process.
Management will be working in an effective way but requires a program
that measures and analyses the data to track the quality, defects and support.
Process reference models

The process framework or reference model acts as an interface between

the way the content is organized and the way work is performed.
Capability Maturity Model (CMM)
• Broadly refers to a process improvement approach that is based on a
process model.
• CMM in Software Project Management refers to the Capability Maturity Model,
developed by the Software Engineering Institute (SEI)
• Higher the level, the better the software development process, hence
reaching each level is an expensive and time- consuming process.
• Frame work to improve software development process.
Aspect Software Maturity Framework (SMF) Capability Maturity Model (CMM)

A broader framework that assesses the A specific structured model developed by

Definition overall maturity of software processes in an SEI (Software Engineering Institute) to
organization. improve software processes through 5
maturity levels.

Focuses on general maturity assessment Focuses mainly on process maturity in

Focus across different dimensions like people, software engineering.
process, technology, and organization.

Defines stages of maturity (low maturity, Defines 5 maturity levels: Initial,

Levels / Stages intermediate maturity, high maturity) Repeatable, Defined, Managed, Optimizing.
depending on framework type.

Uses qualitative assessment methods (e.g., Uses quantitative and qualitative

Measurement maturity questionnaires, surveys, capability assessments based on Key Process Areas
rating). (KPAs) and metrics.

Broader—may include people management, Narrower—focuses specifically on software

Process Orientation business alignment, and organizational engineering and development processes.
culture as part of maturity.
CMM defines five maturity levels for software development processes.
Each level indicates how well-defined, repeatable, and optimized the
processes in an organization are.
It provides a path for process improvement so that organizations can
develop software with higher quality, predictability, and efficiency.
Both CMM (Capability Maturity Model) and Software Maturity Framework (SMF)
deal with process maturity, but they differ in scope, structure, and usage.

The Five Maturity Levels of CMM:

Level 1 – Initial
Ad hoc, chaotic processes.
Success depends on individual effort, not process.
No stable environment for software development.
Level 2 – Repeatable
Basic project management processes are established.
Past successes can be repeated on similar projects.
Key Process Areas (KPAs):
• Requirements Management
• Project Planning
• Project Tracking & Oversight
• Quality Assurance
• Configuration Management
Level 3 – Defined
• Organization-wide standard processes are documented and used.
• Processes are tailored for each project but follow organizational standards.
• KPAs include:
• Organizational Process Focus → Establishing process improvement activities.
• Training Programs → Building skills and knowledge across the organization.
• Integrated Software Management → Coordinating across teams with standard practices.
• Product Engineering → Following structured engineering practices for development.
Level 4 – Managed
• Processes are measured and controlled using metrics.
• Software quality and productivity can be predicted.
KPAs:
• Quantitative Process Management
• Software Quality Management

Level 5 – Optimizing
• Focus on continuous process improvement.
• Uses innovation and new technologies to prevent defects.
KPAs:
•Defect Prevention
•Technology Change Management
•Process Change Management
Importance of CMM in Project Management

• Provides a roadmap for process improvement.

• Ensures better quality software with fewer defects.
• Improves predictability of cost, schedule, and performance.
• Helps organizations achieve global recognition (many companies
demand CMMI certification from vendors).
• Encourages continuous improvement and better project
management practices.
CMMI
1. Developed by the Software Engineering Institute (SEI), Carnegie Mellon
University.

2. Purpose: To combine different CMMs (Software CMM, Systems

Engineering CMM, People CMM, etc.) into one single framework.

Managing multiple models created to overcome confusion and duplication.

SEI integrated them into a single model → CMMI.

3. An organization can go for one of the following two improvement paths.

Continuous Representation → measures each process separately (capability
levels).
Staged representation→ measures organization-wide maturity (maturity
levels).
Feature CMM CMMI
Covers software, systems
Scope Focused only on software process maturity engineering, people, acquisition,
development
Multiple models (SW-CMM, SE-CMM, People-CMM, etc.)
Focus: Systems engineering (integrating hardware,
software, people, processes).
Models Single integrated framework
Ensures that large, complex systems are developed in a
disciplined and predictable way.

More flexible, industry-wide

Approach More rigid, focused on software KPAs
application
Offers two representations: 1.
Staged (like old CMM levels) 2.
Structure 5 Maturity Levels (Initial → Optimizing)
Continuous (assess specific process
areas)

Improve overall organizational

Goal Improve software development
processes
 Level Focus Key Process Area Result

5 Continuous Process Organizational,Innovation and Deployment Highest

Improvement Causal Analysis and Resolution Quality
Optimizing / Lowest
Risk
4 Quantitatively Managed Higher
Organizational Process Performance Quality
Quantitatively / Lower
Managed Quantitative Project Management
Risk
3 Process Standardization Medium
Requirements Development Technical
Quality
Defined Solution / Medium
Product Integration Verification Risk
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Mgmt (with
IPPD extras)
Risk Management
2 Basic Project Management Low Quality
Requirements Management Project Planning
Project Monitoring and Control / High Risk
Managed

Supplier Agreement Management

Measurement and Analysis

Process and Product Quality Assurance

Configuration Management

1 Process is informal and Adhoc Lowest

Quality
Initial
/ Highest Risk
PCMM
1. The People Capability Maturity Model (People CMM, P-CMM) is part
of the CMMI product family of process maturity models.

2. Guide organizations in improving their processes for managing and

developing human workforces.
3. Just like CMM (Capability Maturity Model) focuses on software
processes, PCMM focuses on people (employees, teams, HR
practices).
Objectives :
• Attract, develop, motivate, organize, and retain talent.
• Enhance workforce competencies needed for business goals.
• Create a culture of continuous workforce development.
• Reduce risks related to people dependency ("guru problem").

Structure :
• PCMM is organized into five maturity levels, similar to CMM:
Level 1 – Initial
• Ad-hoc workforce practices.
• Success depends on individual effort, not on organizational systems.
Level 2 – Managed
• Basic people management practices (job roles, performance management, training).
• Managers ensure their teams have required skills.
Level 3 – Defined
• Workforce competencies are defined across the organization.
• Standard training and career development paths exist.

Level 4 – Predictable
•Capability is measured quantitatively.
•Workforce performance and competency growth become predictable.

Level 5 – Optimizing
•Continuous improvement in workforce practices.
•Focus on innovation, knowledge sharing, and workforce agility.
Benefits of PCMM
Stronger alignment of people with business goals.
Improved employee satisfaction and retention.
Better team productivity and innovation.
Reduced dependency on a few experts ("guru problem").

•Process → How the work is done.

•People → Who does the work.
•Technology → With what tools the work is done.
•Together, they ensure high-quality outcomes.
• This triangle model shows the three pillars required for delivering
high-quality products and services:
1. People (Top of the triangle)
• Skilled, motivated, and capable employees are the most critical
factor.
• Without the right people, even the best processes and technologies
won’t succeed.
• Relates to PCMM (People Capability Maturity Model) → focusing on
developing workforce capabilities.
2. Process (Bottom-left corner)
• Defines how the work is done (methods, standards, practices,
workflows).
• Ensures consistency, repeatability, and quality in execution.
• Related to CMMI (Capability Maturity Model Integration) →
improving organizational processes.
[Link] Quality Products & Services (Center outcome)
• Achieved only when People + Process + Technology are balanced and
aligned.
• If one element is weak (e.g., poor processes, unskilled people, or
outdated technology), overall quality suffers.
Personal Software Process (PSP)
• PSP is a structured software development process designed for individual
software engineers.
Help developers measure, analyze, and improve their personal work
practices.

Objectives :

• Improve individual performance in software development.

• Increase quality of software by reducing defects.
• Provide a data-driven approach for planning and tracking.
• Encourage personal responsibility for schedules and quality.
• Build a foundation for team-level processes (TSP – Team Software Process).
Key Activities :

1. Planning: Estimate size, time, and resources.

2. Development: Follow defined coding, compiling, and testing steps.
3. Measurement: Collect data (time spent, defects found, code size).
4. Analysis: Review and analyze performance.
5. Improvement: Apply lessons learned to improve next project.
PSP Process Levels:
• PSP has defined maturity levels, just like CMMI, but focused on individuals:
• PSP0 – Baseline Process
• Measure current performance.
• Track time, defects, and size.
• PSP0.1 – Personal Improvement
• Add coding standards, size measurement, and process improvement proposals.
• PSP2 – Quality Management
• Add design and code reviews to prevent defects.
• Focus on improving product quality.
• PSP2.1 – Advanced Quality
• Add design specifications and analysis methods.
• PSP3 – Cyclic Development
• Apply PSP to large projects using iterative (incremental) development
Benefits of PSP

Better time and effort estimation.

Higher quality code (fewer defects).
More predictable schedules.
Encourages self-improvement.
Builds discipline useful in team projects (TSP).
Team Software Process

Improve software quality (reduce defects early).

Ensure on-time delivery of projects.
Increase team productivity and morale.
Provide accurate project planning and tracking.
Create a culture of self-directed teams.
•
Key Features
• Team Formation & Roles
• Teams are self-directed and take ownership.
• Roles include Team Leader, Development Manager, Planning Manager, Quality Manager,
Support Manager, Process Manager.
• Detailed Planning
• Teams estimate size, effort, cost, and schedule.
• Planning is bottom-up and highly data-driven.
• Quality Focus
• Teams measure defects at every stage.
• Strong emphasis on defect prevention rather than defect removal.
• Tracking & Measurement
• Regular tracking of effort, time, defects, progress.
• Uses earned value and metrics-based tracking.
• Process Improvement
• Teams analyze results at the end of each cycle.
• Improvements are fed into future projects.
Uses of TSP:
1. Better quality (fewer defects).
2. More predictable schedules & costs.
3. Higher team motivation & ownership.
4. Improved customer satisfaction.
5. Fits well with CMMI Level 5 organizations (continuous
improvement).