SOFTWARE ENGINEERING

(CSE 2014)

Department of Computer Science and Engineering

School of Engineering,
PRESIDENCY UNIVERSITY
TEXT BOOK AND REFERENCE BOOKS

 REFERENCE MATERIALS:
 Text book(s):
 Roger S. Pressman, “Software Engineering – A Practitioner’s Approach”, VII
Edition, McGraw-Hill, 2017.
 Bob Hughes, Mike Cotterell, Rajib Mall, “Software Project Management”, VI
Edition, McGraw-Hill, 2018.
 Reference book(s):
 Ian Sommerville, “Software Engineering”, IX Edition, Pearson Education
Asia, 2011.
 Rajib Mall, “Fundamentals of Software Engineering”, VI Edition, PHI
learning private limited, 2014.

Dept. of CSE, SOE, Presidency University

2
CONTENTS
1. What is a software?
1. Characteristics of Software,
2. Types of software
2. Need for Software Engineering
3. Software Engineering Ethics
4. Software Engineering Practice-Essence of Practice,
5. General Principles Software Development Life Cycle
6. Waterfall Model
1. Classical Waterfall Model
2. Iterative Waterfall Model
7. Evolutionary model
1. Spiral
2. Prototype
8. Incremental model
9. RAD model
 What is a software?
• In 1970, less than 1 percent of the public could have
intelligently described what "computer software" meant.
Today, most professionals and many members of the
public at large feel that they understand software.
• A textbook description of software might take the
following form: Software is
• (1) instructions (computer programs) that when executed
provide desired function and performance,
• (2) data structures that enable the programs to adequately
manipulate information, and
• (3) documents that describe the operation and use of the
programs.
 Characteristics of Software
• To gain an understanding of software (and
ultimately an understanding of software
engineering), it is important to examine the
characteristics of software that make it different
from other things that human beings build.

• Software is a logical rather than a physical system

element. Therefore, software has characteristics
that are considerably different than those of
hardware:
 Characteristics of Software
1. Software is developed or engineered, it is not
manufactured in the classical sense.

Although some similarities exist between software

development and hardware manufacture, the two
activities are fundamentally different. In both
activities, high quality is achieved through good
design, but the manufacturing phase for hardware
can introduce quality problems that are nonexistent
(or easily corrected) for software.
 Characteristics of Software
2. Software doesn't "wear out."
 Characteristics of Software
2. Software doesn't "wear out."
Above Figure depicts failure rate as a function of time for
hardware. The relationship, often called the "bathtub curve,"
indicates that hardware exhibits relatively high failure rates early
in its life (these failures are often attributable to design or
manufacturing defects); defects are corrected and the failure rate
drops to a steady-state level (ideally, quite low) for some period of
time.
As time passes, however, the failure rate rises again as hardware
components suffer from the cumulative affects of dust, vibration,
abuse, temperature extremes, and many other environmental
maladies. Stated simply, the hardware begins to wear out.
 Characteristics of Software
2. Software doesn't "wear out."
Software is not susceptible to the environmental
maladies that cause hardware to wear out.
In theory, therefore, the failure rate curve for software
should take the form of the “idealized curve” shown in
Figure below.
Undiscovered defects will cause high failure rates early
in the life of a program. However, these are corrected
(ideally, without introducing other errors) and the curve
flattens as shown.
 Characteristics of Software
2. Software doesn't "wear out."
 Characteristics of Software
3. Although the industry is moving toward
component-based assembly, most software
continues to be custom built
As an engineering discipline evolves, a collection of standard
design components is created.
The reusable components have been created so that the engineer
can concentrate on the truly innovative elements of a design, that
is, the parts of the design that represent something new. In the
hardware world, component reuse is a natural part of the
engineering process. In the software world, it is something that
has only begun to be achieved on a broad scale
 Characteristics of Software
3. Although the industry is moving toward
component-based assembly, most software
continues to be custom built
A software component should be designed and implemented so
that it can be reused in many different programs.
For example, today's graphical user interfaces are built using
reusable components that enable the creation of graphics
windows, pull-down menus, and a wide variety of interaction
mechanisms. The data structure and processing detail required to
build the interface are contained with a library of reusable
components for interface construction.
What is Software & What is
Engineering?
• The term is made of two words, software and
engineering.
• Software is the programs and routines for a
computer or the program material for an
electronic device which make it run.
• Example: Excel or Windows or iTunes.
• Engineering on the other hand, is all about
developing products, using well-defined, scientific
principles and methods.
What is Software Engineering?
• Software engineering is defined as a process of
analyzing user requirements and then designing,
building, and testing software application which will
satisfy those requirements.
• Software Engineering is an engineering branch related to the evolution of
software product using well-defined scientific principles, techniques, and
procedures. The result of software engineering is an effective and reliable
software product.
• As per IEEE, in its standard 610.12-1990, defines
software engineering as the application of a
systematic, disciplined approach for the development,
operation, and maintenance of software.
Need for Software Engineering

The need of software engineering arises because of higher rate

of change in user requirements and environment on which the
software is working.
This includes:
To manage Large software - It is easier to build a wall than to
a house or building, likewise, as the size of software become
large, engineering has to step to give it a scientific process.
For more Scalability- If the software process were not based
on scientific and engineering concepts, it would be easier to
re-create new software than to scale an existing one.
Contd..
Cost Management- As hardware industry has shown its skills
and huge manufacturing has lower down the price of computer
and electronic hardware. But the cost of software remains high
if proper process is not adapted.
To manage Dynamic Nature of software- The always growing
and adapting nature of software hugely depends upon the
environment in which user works. If the nature of software is
always changing, new enhancements need to be done in the
existing one. This is where software engineering plays a good
role.
For better Quality Management- Better process of software
development provides better and quality software product.
Software Engineering Ethics
• Software engineering ethics establishes principles of
conduct that members of the profession are expected
to observe in the practice of software engineering.
• Software engineering ethics covers a wide ethical
spectrum. It participates in general, professional, and
technical ethics.
Software Engineering Ethics
The software engineers shall adhere to the following Eight
Principles:
1. PUBLIC – Software engineers shall act consistently with
the public interest.
2. CLIENT AND EMPLOYER – Software engineers shall act
in a manner that is in the best interests of their client and
employer consistent with the public interest.
3. PRODUCT – Software engineers shall ensure that their
products and related modifications meet the highest
professional standards possible.
4. JUDGMENT – Software engineers shall maintain integrity
and independence in their professional judgment.
Contd..
5. MANAGEMENT – Software engineering managers and
leaders shall subscribe to and promote an ethical approach to
the management of software development and maintenance.
6. PROFESSION – Software engineers shall advance the
integrity and reputation of the profession consistent with the
public interest.
7. COLLEAGUES – Software engineers shall be fair to and
supportive of their colleagues.
8. SELF – Software engineers shall participate in lifelong
learning regarding the practice of their profession and shall
promote an ethical approach to the practice of the profession.
For details pls click this link
Software Engineering Code - ACM Ethics
What is the essence of software engineering practice?
• Essence intuitively describes all common aspects of
a software development endeavour and helps teams
understand where they are, what's missing or what
needs to be addressed - regardless of each team's
prescribed way of working.
• The essence of software engineering practice might
be described as: understand the problem, plan a
solution, carry out the plan, and examine the result
for accuracy.
Software Practice

• Practice is a broad array of concepts, principles,

methods, and tools that you must consider as
software is planned and developed.

• It represents the details—the technical

considerations —that are below the surface of the
software process—the things that you’ll need to
actually build high-quality computer software.
 The Essence of Software Practice

George Polya, in a book written in 1945 (!), describes the

essence of software engineering practice and suggests:
1.Understand the problem
(communication and analysis).
2.Plan a solution
(modeling and software design).
3.Carry out the plan (code generation).
4.Examine the result for accuracy
(testing and quality assurance).

Dept. of CSE, SOE, Presidency University

22
Understand the Problem

• Who has a stake in the solution to the problem? That is, who
are the stakeholders?
• What are the unknowns? What data, functions, and features
are required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to
represent smaller problems that may be easier to understand?
• Can the problem be represented graphically? Can an analysis
model be created?

Dept. of CSE, SOE, Presidency University

23
Plan the Solution
• Have you seen similar problems before? Are there patterns
that are recognizable in a potential solution? Is there existing
software that implements the data, functions, and features
that are required?
• Has a similar problem been solved? If so, are elements of the
solution reusable?
• Can subproblems be defined? If so, are solutions readily
apparent for the subproblems?
• Can you represent a solution in a manner that leads to
effective implementation? Can a design model be created?

Dept. of CSE, SOE, Presidency University

24
Carry Out the Plan

• Does the solution conform to the plan? Is source code

traceable to the design model?

• Is each component part of the solution provably correct?

Has the design and code been reviewed, or better, have
correctness proofs been applied to algorithm?

Dept. of CSE, SOE, Presidency University

25
Examine the Result

• Is it possible to test each component part of the

solution? Has a reasonable testing strategy
been implemented?

• Does the solution produce results that conform

to the data, functions, and features that are
required? Has the software been validated
against all stakeholder requirements?

Dept. of CSE, SOE, Presidency University

26
Core Principles of Software Development Life Cycle
Seven Principles Of Software Development (c2.com)
• The Reason It All Exists: Provide value to the customer and
the user. If you can’t provide value, then don’t do it.
• KISS:Keep It Simple, Stupid! All design should be as simple
as possible, but no simpler. This facilitates having a more
easily understood and easily maintained system.
• Maintain the product and project “vision”: A clear vision is
essential to the success of a S/W project.
• What you produce, others will consume: Always specify,
design, and implement knowing someone else have to
understand what you are doing.
Contd..
• Be open to the Future: Never design yourself into a corner.
Always ask “what if,” and prepare yourself for all possible
answers by creating systems that solve the general problem,
not just the specific one.
• Plan Ahead for Reuse: Planning ahead for reuse reduces the
cost and increases the value of both the reusable components
and the systems into which they are incorporated.
• Think! : Placing clear, complete thought before action
almost always produces better results.
 II. Software Development Life
Cycle(SDLC)
• Software Development Life Cycle (SDLC) is a process used by the
software industry to design, develop and test high quality software's.

• The SDLC aims to produce a high-quality software that meets or exceeds

customer expectations, reaches completion within times and cost
estimates.

• It is also called as Software Development Process.

Dept. of CSE, SOE, Presidency University

29
Software Development Life Cycle(SDLC)

Dept. of CSE, SOE, Presidency University

30
LIFE CYCLE STAGES−

• Stage 1: Planning and Requirement Analysis

• Stage 2: Defining Requirements
• Stage 3: Designing the Product Architecture
• Stage 4: Building or Developing the Product
• Stage 5: Testing the Product
• Stage 6: Deployment in the Market and Maintenance

Dept. of CSE, SOE, Presidency University

31
 SDLC models followed in the industry
• Waterfall Model
• Iterative Model
• Spiral Model
• V-Model
• Big Bang Model

Dept. of CSE, SOE, Presidency University

32
Software Process Model

• A software process model is an abstraction of the

actual process, which is being described.
• It can also be defined as a simplified representation
of a software process.
• Each model represents a process from a specific
perspective
Waterfall Model

• The waterfall model is a classical model used in

system development life cycle to create a system
with a linear and sequential approach.
• It is termed as waterfall because the model develops
systematically from one phase to another in a
downward fashion.
Classical Waterfall Model

• The classical waterfall model is the basic software

development life cycle model.
• It is very simple but idealistic.
• Earlier this model was very popular but nowadays it is
not used. But it is very important because all the other
software development life cycle models are based on the
classical waterfall model.
• The classical waterfall model divides the life cycle into a
set of phases. This model considers that one phase can be
started after the completion of the previous phase.
Classical Waterfall Model

• That is the output of one phase will be the input to the next
phase.
• Thus the development process can be considered as a
sequential flow in the waterfall. Here the phases do not
overlap with each other.
• The different sequential phases of the classical waterfall
model are shown in the below figure:
Classical Waterfall Model

Dept. of CSE, SOE, Presidency University

37
Classical Waterfall model Phases

• Feasibility Study:
• The main goal of this phase is to determine whether it
would be financially and technically feasible to develop
the software.
• The feasibility study involves understanding the
problem and then determining the various possible
strategies to solve the problem.
• These different identified solutions are analyzed based
on their benefits and drawbacks, The best solution is
chosen and all the other phases are carried out as per
this solution strategy.
Classical Waterfall model Phases

• Requirements analysis and specification: The aim of

the requirement analysis and specification phase is to
understand the exact requirements of the customer and
document them properly. This phase consists of two
different activities.
• Requirement gathering and analysis: All the
requirements regarding the software are gathered from
the customer and then the gathered requirements are
analyzed.
• Requirement specification: These analyzed
requirements are documented in a software
requirement specification (SRS) document. SRS
document serves as a contract between the
development team and customers.
Classical Waterfall model Phases

• Design: The goal of this phase is to convert the requirements

acquired in the SRS into a format that can be coded in a
programming language.
• It includes high-level and detailed design as well as the
overall software architecture. A Software Design Document
is used to document all of this effort (SDD)
• Coding and Unit testing: In the coding phase software design
is translated into source code using any suitable
programming language.
• Thus each designed module is coded. The aim of the unit
testing phase is to check whether each module is working
properly or not.
Classical Waterfall model Phases

• Integration and System testing: Integration of different modules

are undertaken soon after they have been coded and unit tested.
• System testing consists of three different kinds of testing
activities as described below :
• Alpha testing: Alpha testing is the system testing performed by
the development team.
• Beta testing: Beta testing is the system testing performed by a
friendly set of customers.
• Acceptance testing: After the software has been delivered, the
customer performes acceptance testing to determine whether to
accept the delivered software or reject it.
 Classical Waterfall model Phases
• Maintenance: Maintenance is the most important phase of a
software life cycle. The effort spent on maintenance is 60% of the
total effort spent to develop a full software.
There are basically three types of maintenance :
• Corrective Maintenance: This type of maintenance is carried out to
correct errors that were not discovered during the product
development phase.
• Perfective Maintenance: This type of maintenance is carried out to
enhance the functionalities of the system based on the customer’s
request.
• Adaptive Maintenance: Adaptive maintenance is usually required
for porting the software to work in a new environment such as
working on a new computer platform or with a new operating
system.
Advantages of Classical Waterfall Model

• This model is very simple and is easy to understand.

• Phases in this model are processed one at a time.
• Each stage in the model is clearly defined.
• This model has very clear and well-understood milestones.
• Process, actions and results are very well documented.
• Reinforces good habits: define-before- design, design-before-
code.
• This model works well for smaller projects and projects
where requirements are well understood
Drawbacks of Classical Waterfall Model

• No feedback path
• Difficult to accommodate change requests
• No overlapping of phases
Iterative Waterfall Model

• the classical waterfall model is hard to use.

• The Iterative waterfall model can be thought of as
incorporating the necessary changes to the classical waterfall
model to make it usable in practical software development
projects.
• It is almost the same as the classical waterfall model except
some changes are made to increase the efficiency of the
software development.
• The iterative waterfall model provides feedback paths from
every phase to its preceding phases, which is the main
difference from the classical waterfall model.
Iterative Waterfall Model
Advantages of Iterative Waterfall
Model :

• Feedback Path
• Simple
• Cost-Effective
• Well-organized
Drawbacks of Iterative Waterfall Model :

• Difficult to incorporate change requests

• Incremental delivery not supported
• Overlapping of phases not supported
• Risk handling not supported
• Limited customer interactions
 Evolutionary Models
• Software system evolves over time as requirements often
change as development proceeds.

• Usually a set of core product or system requirements is well

understood, but the details and extension have yet to be defined.
• You need a process model that has been explicitly designed to
accommodate a product that evolved over time.
• It is iterative that enables you to develop increasingly more
complete version of the software.
• Types: Prototyping and Spiral models.

Dept. of CSE, SOE, Presidency University

49
 Evolutionary Models - Prototyping
• When to use: Customer defines a set of general objectives but
does not identify detailed requirements for functions and features.
Or Developer may be unsure of the efficiency of an algorithm,
the form that human computer interaction should take.

• Advantages: Both stakeholders and software engineers like the

prototyping paradigm. Users get a feel for the actual system, and
developers get to build something immediately. However,
engineers may make compromises in order to get a prototype
working quickly. The less-than-ideal choice may be adopted
forever after you get used to it.

Dept. of CSE, SOE, Presidency University

50
Prototyping Model
Prototyping Model
• The Prototyping Model is one of the most popularly
used Software Development Life Cycle Models
(SDLC models).
• This model is used when the customers do not know
the exact project requirements beforehand.
• In this model, a prototype of the end product is first
developed, tested and refined as per customer
feedback repeatedly till a final acceptable prototype
is achieved which forms the basis for developing the
final product.
Evolutionary Models - Prototyping

Quick
plan
communication

Modeling
Quick design

Deployment
delivery &
feedback Construction
of prototype

Dept. of CSE, SOE, Presidency University

53
B) Evolutionary Prototyping –
• In this method, the prototype developed initially is
incrementally refined on the basis of customer
feedback till it finally gets accepted.

• In comparison to Rapid Throwaway Prototyping, it

offers a better approach which saves time as well as
effort. This is because developing a prototype from
scratch for every iteration of the process can
sometimes be very frustrating for the developers.
Evolutionary Models - Spiral

Dept. of CSE, SOE, Presidency University

55
 Evolutionary Models - Spiral
• It couples the iterative nature of prototyping with the controlled
and systematic aspects of the waterfall model and is a risk-driven
process model generator that is used to guide multi-stakeholder
concurrent engineering of software intensive systems.

• Two main distinguishing features: one is cyclic approach for

incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk. The other is a
set of anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory system
solutions.

Dept. of CSE, SOE, Presidency University

56
The Incremental Model

Dept. of CSE, SOE, Presidency University

57
The Incremental Model

• Incremental Model is a process of software development where

requirements divided into multiple standalone modules of the software
development cycle.

• In this model, each module goes through the requirements, design,

implementation and testing phases. Every subsequent release of the
module adds function to the previous release. The process continues until
the complete system achieved.

Dept. of CSE, SOE, Presidency University

58
The Incremental Model

• When initial requirements are reasonably well defined, but the overall
scope of the development effort precludes a purely linear process. A
compelling need to expand a limited set of new functions to a later system
release.
• It combines elements of linear and parallel process flows. Each linear
sequence produces deliverable increments of the software.
• The first increment is often a core product with many supplementary
features. Users use it and evaluate it with more modifications to better
meet the needs.

Dept. of CSE, SOE, Presidency University

59
 The Incremental Model
• 1. Requirement analysis: In the first phase of the incremental model, the product analysis
expertise identifies the requirements. And the system functional requirements are understood
by the requirement analysis team. To develop the software under the incremental model, this
phase performs a crucial role.
• 2. Design & Development: In this phase of the Incremental model of SDLC, the design of
the system functionality and the development method are finished with success. When
software develops new practicality, the incremental model uses style and development phase.
• 3. Testing: In the incremental model, the testing phase checks the performance of each
existing function as well as additional functionality. In the testing phase, the various methods
are used to test the behavior of each task.
• 4. Implementation: Implementation phase enables the coding phase of the development
system. It involves the final coding that design in the designing and development phase and
tests the functionality in the testing phase. After completion of this phase, the number of the
product working is enhanced and upgraded up to the final system product

Dept. of CSE, SOE, Presidency University

60
 The Incremental Model
When we use the Incremental Model?
• When the requirements are superior.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product.
• You can develop prioritized requirements first.

Dept. of CSE, SOE, Presidency University

61
Advantage and Disadvantage of
Incremental Model
• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.
Disadvantage of Incremental Model
• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.
 The RAD Model
RAD (Rapid Application Development) Model
• RAD is a linear sequential software development process model that emphasizes
a concise development cycle using an element based construction approach.
• If the requirements are well understood and described, and the project scope is a
constraint, the RAD process enables a development team to create a fully
functional system within a concise time period

Dept. of CSE, SOE, Presidency University

63
 The RAD Model
RAD (Rapid Application Development) is a concept that products can be developed faster and of higher
quality through:

• Gathering requirements using workshops or focus groups

• Prototyping and early, reiterative user testing of designs
• The re-use of software components
• A rigidly paced schedule that refers design improvements to the next product version
• Less formality in reviews and other team communication

Dept. of CSE, SOE, Presidency University

64
RAD model
 The RAD Model
When to use RAD Model?
• When the system should need to create the project that modularizes in a short span time
(2-3 months).
• When the requirements are well-known.
• When the technical risk is limited.
• When there's a necessity to make a system, which modularized in 2-3 months of period.
• It should be used only if the budget allows the use of automatic code generating tools.

Dept. of CSE, SOE, Presidency University

66
 Advantage & Disadvantage of RAD
•Model
This model is flexible for change.
• In this model, changes are adoptable.
• Each phase in RAD brings highest priority functionality
to the customer.
• It reduced development time.
• It increases the reusability of features.
• Disadvantage of RAD Model
• It required highly skilled designers.
• All application is not compatible with RAD.
• For smaller projects, we cannot use the RAD model.
• On the high technical risk, it's not suitable.
• Required user involvement.
What is a maturity model?
‘A maturity model is a model with which organizations can judge their (software
engineering, hrm, service, etc.) process (including comparing it to other organizations) and
based on this judgment can improve their process.’
– started in 1986 by the Software Engineering Institute (SEI) (Carnegie Mellon
University) and the Mitre Corporation
– SEI started with a Process Maturity Framework and a maturity questionnaire
– the software Framework developed into the Capability Maturity Model (CMM) for
Software (1991)
– Revised maturity framework (CMMI) introduced in 2001

68
 Process Maturity Framework
Goal is the improvement of the software engineering process
– Success should not be based on incidental individual achievements
– Success should be based on repeatable and proven successful work
methods
Immature Mature
Software Software
Organization Organization

-No objective basis for judgment of

product quality
- No objective basis for improvement of
product or process quality
- Reviews and tests are often skipped
when projects run behind schedule
- Ad hoc management
-Organization wide knowledge to
manage software development,
employment and improvement
- Processes are ‘fit-for-use’
- Processes are being adapted to the
situation
-Tasks and responsibilities are clear for
the project and anyone in the
organization
69
Software Process
Software Process:

‘the whole of activities, methods, practices, communication

and changes that people use in order to develop and
maintain software and associated products (e.g. plans,
design documents, code, test cases and user manuals)’

CMM gives an organization a way

to get and improve control over the software
process and provides it with a route to achieve excellence
in software engineering

70
Fundamental concepts for
Process Maturity
Software Process Capability
– How good it can predict the expected outcome of a next
software project
Software Process Performance
– Actual results of a software project
Software Process Maturity
– The level in which a software process is explicitly defined,
managed, measured and controlled in order to achieve results
Software Process Institutionalization
– The level in which the software process is institutionalized with
respect to methods, standards and organizational structure

71
 Levels of software maturity
Maturity level:
– A well defined level on the way to achieve an adult, a
mature software process
– A foundation for realizing continuous improvements
– Every level contains a group of process goals that, when
stable, form an important part of the software process
– Every level leads to the improvement of the process
capability of the organization

72
The staged CMMI model
Level 5
Optimizing

Level 4
Quantitatively
managed

Level 3
Defined

Level 2
Managed

Level 1
Initial

73
 Initial
The (1)process can be described as ad-hoc, or even
software
chaotic
There are practically no processes defined
Success depends on individual input and achievements
The software process is not predictable regarding results
Schedules, budget, functionality and product quality is not
predictable
Works disastrous in crises situations
Can be successful in highly innovative environment
(e.g. start of the web-design world)

74
 Managed
The (2)
basic project management procedures are used
Costs, schedules en functionality are ‘tracked’
Planning and managing of new projects are based on experience
with comparable projects
Needed process discipline is enforced such that earlier success can
be repeated with building an comparable application
Software requirements and work products are ‘baselined’
Disciplined environment in which planning and tracking are stable
and thus previous successes can be repeated

75
 Defined
Processes for (3)
management and software engineering are
documented, standardized and integrated in a standard software
development process
All projects use an approved, adapted version of the standard
software process for the development and maintenance of software
Processes are used to let software managers and engineers be more
effective
There is a group responsible for the software process
There is training in the software process
The software process is stable and well defined and is able to
operate more effectively

76
 Quantitatively
Detailed metrics of themanaged (4) and quality of products
software processes
are gathered
Quantitative goals are set for the software process and the product
quality
Use is made of a software process database in which the metrics
are gathered and analyzed
Projects have a control over the software process and product
quality such that the can work in defined limits
Risks of development in new technical environments are
recognized and managed
Software process is predictable and trends can be predicted

77
 Optimizing
Continuously (5) process improvements are realized by
software
quantitatively feedback of the process and by trying out of
innovative ideas and technologies
The whole organization is focused on continuous improvement
Data regarding performance of the processes are used for cost-
benefit analyses
Innovations that make use of the best software engineering
practices are identified and spread over the whole organization
Software project teams analyze errors in order to find out how to
improve
‘Lessons learned’ are shared with other projects (team rooms,
Communities of Practice)

78
 Operational use of CMM
How do you determine in practice the maturity of an organization?

Maturity
Indicate
Level
Contain
Process
Capability Key Process
Achieve Areas
Organized by
Goals
Common
Address Features Contain

Implementation or Key
Institutionalization

Describe
Practices
Infrastructure or
Activities

79
Key Process Areas Optimizing (5)
-Process change management
-Technology change management
-Defect prevention
Quantitatively
Managed (4) -Software quality management
-Quantitative process management
-Peer reviews
-Intergroup coordination
Defined (3) -Software product engineering
-Integrated software management
-Training program
-Organization process definition
Managed (2) -Organization process focus

-Software Configuration Management

-Software Quality Assurance
-Software Subcontract Management
Initial (1) -Software project tracking & oversight
-Software project planning
-Requirements Management 80
 Example
Maturity Level 2
Managed
Indicates
Contains Key Process Area
Disciplined
Processes Software
Achieves Project Planning
Organized by Common
Software estimates are Feature
Activities
documented for use
Performed
Address
in planning and tracking Contain Key Practice

ImplementationActivity 9. Estimates for the size of t

software work products (or changes t
Describe
are derived according to
Activity a documented procedure
81
This is the end of Module 1