DEBRE MARKOS UNIVERSITY

BURIE CAMPUS
DEPARTMENT OF COMPUTER SCIENCE
Fundamentals of Software Engineering
By:
Amare W.

1
 2

Chapter Two

Software processes
♥A process is an organized set of activities, which transforms inputs to outputs.
♥A software process is a sequence of activities that leads to the production of a software product.
♥The systematic approach that is used in software engineering is sometimes called a software process.
♥We can use synonyms of process such as: procedure, method, course of action, etc.. Software
engineering, as a discipline, has many processes. Software process: organizing a structured set of
activities to develop software systems.
 3 02/11/2022

♥ These processes help in performing different software engineering activities

in an organized manner.
♥ There are many different software processes but all must include four
activities that are fundamental to software engineering:-
1.Software specification: - Customers and engineers define the software that is
to be produced the functionality of the software and constraints on its operation
must be defined.
2. Software design and implementation: - designed and programmed; the
software to meet the specification must be produced.
3. Software validation: - where the software is checked to ensure that3/2/2018
it is what
the customer requires.
 4 02/11/2022

4. Software evolution: - where the software is modified to reflect

changing customer and market requirements.
♥ Different types of systems need different development processes. For
example, real-time software in an aircraft has to be completely
specified before development begins.
♥ In e-commerce systems, the specification and the program are
usually developed together.
♥ Consequently, these generic activities may be organized in different
ways and described at different levels of detail depending on the type
3/2/2018

of software being developed.

 5 02/11/2022

Characteristics process
♥ Produces intermediate and final products
♥ Each process activity has entry and exit criteria
♥ Activities are organized in sequence, so timing is clear
♥ Each process guiding principles, including goals of each activity
♥ Uses resources, subject to set of constraints (such as schedule,
no. of people working )
♥ May be composed of sub-processes with hierarchy or links
3/2/2018
 6 02/11/2022

Software Development Life Cycle (SDLC)

♥ The software development lifecycle begins with the

identification of a requirement for software and ends with the
formal verification of the developed software against that
requirement.
♥ So SDLC goes through a series of phases. It consists of a
detailed plan describing how to develop, maintain, replace and
alter or enhance specific software.
♥ The life cycle defines a methodology for improving the quality
3/2/2018
of software and the overall development process.
 7 02/11/2022

….cont’d
♥ The SDLC aims to produce a high quality software that meets or
exceeds client/customer expectations, reaches completion within
times and cost estimates.
♥ The SDLC is a framework defining tasks performed at each step
in the software development process.
♥ There are many SDLC used during software development process.
SDLC is used to
 Helps to understand the entire process
 Enables planning of resources in advance
 Enforces a structured approach to development 3/2/2018

 Helps to track progress of the system

 8 02/11/2022

Why do we need SDLC?

♥There are always a huge temptation to implement a software without
planning or designing especially for a small or medium size project.
♥Programmers tends to argue that the time that is spent on planning is
already good enough for them to do the programming work and deliver
the product.
♥Management also tend to focus on the efficiency and making use of least
amount of resource to get the same result.
♥However there are certain reasons to explain why we need SDLC.
3/2/2018
 9 02/11/2022

A. Quality assurance and quality control

♥ The definition of quality assurance is a set of activities for ensuring quality in the
process of the product development.
♥ Quality control is a set of activities for ensuring of the developed product.
♥ QA aims on preventing defects by focusing the process of the product
development, QC aims of identifying the defects by examining the finished
product.
♥ The goal of QA is to eliminate as defect as it can to improve the QC processes.
The goal of QC is to identify any defect that is missed in QA processes.
♥ Thus, with QA as a proactive quality process and QC as reactive quality process.
3/2/2018
 10 02/11/2022

B. Easier implementation control

♥ Within the 5 core stage in SDLC, multiple documentations
should be prepared to give guidelines and instruction for the
programmers and testers to follow and for the managements
and approvers to be acknowledged and approve on the
activities and action taken.
♥ Business case software requirement specification(SRS),design
document specification(DDS), functional specification, test
plan, deployment plan etc. are all well-defined at each3/2/2018
stage,
 11 02/11/2022

C. Fulfil user requirements or even exceeding their expectations

♥ As mentioned earlier Quality assurance and quality control helps to ensure
the product delivering as user required with zero to limited number of
defects in good quality.
♥ Nevertheless, very high chances that users would like to further enhance the
delivered product due to business change and technical upgrade is necessary
due to technology improvement.
♥ Hence, in the design stage designers not only give resolutions for the
requirement but also take considerations of integration with peer systems,
flexibility and availability of enhancement maximum system loads due to
3/2/2018

increasing of users, etc.

 12 02/11/2022

♥ The software development life-cycle can be divided into 5-9

phases:

3/2/2018
 13 02/11/2022

1. Planning/ Requirements Analysis

♥ Planning usually happens after there is an innovation and initiation

that come up from group of business and-users or sponsor whom
identify a need or an opportunity.
♥ Planning is the most important and fundamental stage in SDLC.
♥ This information is then used to plan the basic project approach and
to conduct product feasibility study in the economical, operational
and technical areas.
♥ Planning for the quality assurance requirements and identification of
the risks associated with the project is also done in the planning
3/2/2018

stage.
 14 02/11/2022

♥ The outcome of the technical feasibility study is to define the various technical
approaches that can be followed to implement the project successfully with
minimum risks.
♥ Also within the planning stage scope and boundary of concepts are defined.
♥ During this activity the developer attempts to understand the problem and
delimit its scope. Feasibility study focused on:
 Economic feasibility
 Operational feasibility
 Technical feasibility
 Political feasibility
3/2/2018
 Schedule feasibility
 15 02/11/2022

2. Design

♥ Once the requirement analysis is done the next step is to clearly define and
document the product requirements and get them approved from the
customer or the market analysts.
♥ This is done through Software Requirement Specification (SRS).SRS
document which consists of all the product requirements to be designed and
developed during the project life cycle.
♥ SRS is the reference for product architects to come out with the best
architecture for the product to be developed.
♥ Based on the requirements specified in SRS, usually more than one design
approach for the product architecture is proposed and documented
3/2/2018
in a
Design Document Specification (DDS).
 16 02/11/2022

3. Development

♥ In this stage of SDLC the actual development starts and the product
is built.
♥ The programming code is generated as per DDS. If the design is
performed in a detailed and organized manner, code generation can
be accomplished without much hassle.
♥ Developers have to follow the coding guidelines defined by their
organization and programming tools like compilers, interpreters,
debuggers etc. are used to generate the code.
♥ Different high level programming languages such as C, C++, Pascal,
3/2/2018

Java and PHP are used for coding.

 17 02/11/2022

4. Testing

♥ This stage is usually a subset of all the stages as in the modern SDLC models, the
testing activities are mostly involved in all the stages of SDLC.
♥ However this stage refers to the testing only stage of the product where products
defects are reported, tracked, fixed and retested, until the product reaches the quality
standards defined in the SRS.
♥ Testing is the major quality-control measure used during software
development.Testing is done by the programmers, end-users and quality assurance
experts.
♥ Programmers know the best of how the program works and therefor they can
identify the most vulnerable areas of the software.
♥ End-users would pay more attentions to their routine tasks which helps to3/2/2018
ensure the
software can fulfill the requirements.
 18 02/11/2022

5. Deployment and maintenance

♥ Once the product is tested and ready to be deployed it is

released formally in the appropriate market.
♥ Sometime product deployment happens in stages as per the
organizations business strategy.
♥ The product may first be released in a limited segment and
tested in the real business environment user acceptance testing
(UAT).
♥ This is the final life cycle phase (deploy and maintenance) the
software is put into use.
♥ Maintenance involves correcting errors which were not
discovered in earlier stages of the life cycle, improving the
implementation of system units and enhancing the system’s
3/2/2018
services as new requirements are discovered.
 19 02/11/2022

Software Development Life cycle Models

♥ Software Development Life Cycle is a well-defined, structured

sequence of stages in software engineering to develop the intended
software product.
♥ SDLC model is a simplified representation of a software process,
presented from a specific perspective.
♥ There are various software development life cycle models defined
and designed which are followed during software development
process.
♥ These models are also referred as Software Development3/2/2018
Process
Models (SDPM).
 20 02/11/2022

♥ Each process model follows a series of steps unique to its type,

in order to ensure success in process of software development.
♥ There are a number of different models for software
development lifecycles.
 Waterfall model
 prototype model
 incremental model
 V-shaped model
 Spiral model

3/2/2018
 21 02/11/2022

Waterfall Model
♥ The Waterfall Model was first process model to be introduced. It is also
referred to as a linear-sequential life cycle model.
♥ It is very simple to understand and use. The waterfall model is consistent
with other engineering process models and documentation is produced at
each phase.
♥ The waterfall model is an example of a plan-driven process—in principle,
you must plan and schedule all of the process activities before starting
work on them.
♥ In a waterfall model, each phase must be completed before the next phase
3/2/2018

can begin and there is no overlapping in the phases.

 22 02/11/2022

♥ The waterfall model illustrates the software development process

in a linear sequential flow; this means that any phase in the
development process begins only if the previous phases complete.
♥ In the waterfall approach, the whole process of software
development is divided into separate phases.
♥ In waterfall model, typically, the outcome of one phase acts as the
input for the next phase sequentially.
♥ Following is a diagrammatic representation of different phases of
waterfall model. 3/2/2018
 23 02/11/2022

The common software development phases are as follows:

1. Requirements Specification
♥ The aim of the requirements analysis and specification phase is to
understand the exact requirements of the customer and to document
3/2/2018

them properly.
 24 02/11/2022

♥ In this phase consists of two distinct activities, namely

 Requirements gathering and analysis
 Requirements specification
♥ The goal of the requirements gathering activity is to collect all relevant
information from the customer regarding the product to be developed.
♥ This is done to clearly understand the customer requirements so that
incompleteness and inconsistencies are removed.
♥ The requirements analysis activity is begun by collecting all relevant
data regarding the product to be developed from the users of the
product and from the customer through interviews and discussions.
3/2/2018
 25 02/11/2022

♥ For example, to perform the requirements analysis of a business

accounting software required by an organization, the analyst might
interview all the accountants of the organization to ascertain their
requirements.
♥ The data collected from such a group of users usually contain
several contradictions and ambiguities, since each user typically has
only a partial and incomplete view of the system.
♥ Therefore it is necessary to identify all ambiguities and
contradictions in the requirements and resolve them through further
3/2/2018

discussions with the customer.

 26 02/11/2022

♥ After all ambiguities, inconsistencies, and incompleteness have been

resolved and all the requirements properly understood, the
requirements specification activity can start.
♥ During this activity, the user requirements are systematically organized
into a Software Requirements Specification (SRS) document.
♥ The customer requirements identified during the requirements
gathering and analysis activity are organized into a SRS document.
♥ The important components of this document are functional
requirements, the nonfunctional requirements, and the goals of
3/2/2018
implementation.
 27 02/11/2022

2. Design
♥ The goal of the design phase is to transform the requirements
specified in the SRS document into a structure that is suitable for
implementation in some programming language.
♥ In technical terms, during the design phase the software architecture
is derived from the SRS document.
♥ Assigning responsibilities to objects and specifying detailed
dynamics of their interactions under different usage scenarios.
♥ Two distinctly different approaches are available: the traditional
3/2/2018
design approach and the object-oriented design approach.
 28 02/11/2022

· Traditional design approach -Traditional design consists of

two different activities; first a structured analysis of the
requirements specification is carried out where the detailed
structure of the problem is examined.
· This is followed by a structured design activity. During
structured design, the results of structured analysis are
transformed into the software design.
 Object-oriented design approach -In this technique, various
objects that occur in the problem domain and the solution
domain are first identified, and the different relationships that
exist among these objects are identified. The object structure is
further refined to obtain the detailed design.
3/2/2018
 29 02/11/2022

Implementation /Coding

♥ The purpose of the coding phase (sometimes called the

implementation phase) of software development is to translate the
software design into source code.
♥ Each component of the design is implemented as a program module.

Testing
♥ During this phase, each module is unit tested to determine the correct
working of all the individual modules.
♥ It involves testing each module in isolation as this is the most efficient
way to debug the errors identified at this stage. 3/2/2018
 30 02/11/2022

♥ Integration of different modules is undertaken once they have

been coded and unit tested.
♥ During the integration and system testing phase, the modules
are integrated in a planned manner.
♥ The different modules making up a software product are
almost never integrated in one shot.
♥ Integration is normally carried out incrementally over a
number of steps.
3/2/2018
 31 02/11/2022

♥ During each integration step, the partially integrated system is

tested and a set of previously planned modules are added to it.
♥ Finally, when all the modules have been successfully
integrated and tested, system testing is carried out.
♥ The goal of system testing is to ensure that the developed
system conforms to its requirements laid out in the SRS
document.

3/2/2018
 32 02/11/2022

Deployment and Maintenance

♥ Deployment: is providing directions for installing the

delivered software into the local computing environment,
configuring operating systems parameters and user access
privileges, and running diagnostic test cases to assure the
viability of basic system operation.
♥ Maintenance: of a typical software product requires much
more than the effort necessary to develop the product itself.
♥ Maintenance involves performing any one or more of the
3/2/2018
following three kinds of activities:
 33 02/11/2022

♥ Correcting errors that were not discovered during the product

development phase. This is called corrective maintenance.
♥ Improving the implementation of the system, and enhancing
the functionalities of the System according to the customer’s
requirements. This is called perfective maintenance.
♥ Porting the software to work in a new environment. For
example, porting may be required to get the software to work
on a new computer platform or with a new operating system.
3/2/2018
This is called adaptive maintenance.
 34 02/11/2022

When to use the waterfall model

 Requirements are very well documented, clear and fixed
 Product definition is stable
 Technology is understood and is not dynamic
 There are no ambiguous requirements
 Ample resources with required expertise are available to
support the product.
Pros
1. Simple and easy to understand 2. Easy to manage
3. Clearly defined stages 4. Easy to arrange tasks
5. Progress can be measured 6. Reduced development time
7. Increases reusability of components
8. Quick initial reviews occur 9. Encourages customer 3/2/2018
feedback
 35 02/11/2022

Cons
 High amounts of risk and uncertainty
 It is difficult to measure progress within stages
 Cannot accommodate changing requirements
 Adjusting scope during the life cycle can end a project
 No working software is produced until late during the life cycle
 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and automated
code
 Generation is very high
 Requires user involvement throughout the life cycle 3/2/2018
 36 02/11/2022

Prototype Model

♥ A prototype is a toy implementation of the system. A prototype

usually exhibits limited functional capabilities, low reliability, and
inefficient performance compared to the actual software.
♥ A prototype is usually built using several shortcuts. The shortcuts
might involve using inefficient, inaccurate, or dummy functions.
Need for a prototype in software development
♥ There are several uses of a prototype. An important purpose is to
illustrate the input data formats, messages, reports, and the
interactive dialogues to the customer. 3/2/2018
 37 02/11/2022

♥ This is a valuable mechanism for gaining better understanding

of the customer’s needs:
 How the screens might look like
 How the user interface would behave
 How the system would produce outputs
♥ Another reason for developing a prototype is that it is
impossible to get the perfect product in the first attempt.
♥ Many researchers and engineers advocate that if you want to
develop a good product you must plan to throw away the first
3/2/2018

version.
 38 02/11/2022

♥ The experience gained in developing the prototype can be

used to develop the final product.
♥ A prototyping model can be used when technical solutions are
unclear to the development team.
♥ A prototype of the actual product is preferred in situations
such as:
 User requirements are not complete
 Technical issues are not clear
3/2/2018
 39 02/11/2022

Advantage of prototype model

 The resulting software: more usable
 User needs are better accommodated
 The design is of higher quality
 The resulting software is easier to maintain
 Overall, the development incurs less effort
 Reduces time and cost as the defects can be detected much earlier
Weakness of prototype model 3/2/2018

Sometimes expensive, Overall maintainability may be overlooked and Process

may continue forever (scope creep)
 40 02/11/2022

Incremental Model

♥ The incremental model may be viewed as a modification to the waterfall

model.
♥ As software projects increased in size, it was recognized that it is much
easier, and sometimes necessary.
♥ To develop the software if the large projects are subdivided into smaller
components, which may thus be developed incrementally and iteratively.
♥ In the incremental model the components were developed in an
overlapping fashion.
♥ The components all had integrated and then tested as a whole in a final
3/2/2018
system test.
 41 02/11/2022

♥ The incremental model provided a certain amount of risk

containment.
♥ If any one component ran into trouble, the other component
were able to still continue to be developed independently.

3/2/2018
 42 02/11/2022

Pros
 Generates working software quickly and early during the software life
cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled
during it’d iteration
Cons
 Needs good planning and design.
 Needs a clear and complete definition of the whole system before it can be
broken down and built incrementally.
 Total cost is higher than waterfall model. 3/2/2018
 43 02/11/2022

V-shaped Model

♥ The V - model is SDLC model where execution of processes

happens in a sequential manner in V-shape.
♥ It is also known as Verification and Validation model. V - Model
is an extension of the waterfall model and is based on association
of a testing phase for each corresponding development stage.
♥ This means that for every single phase in the development cycle
there is a directly associated testing phase.
♥ This is a highly disciplined model and next phase starts only
after completion of the previous phase. 3/2/2018
 44 02/11/2022

♥ Under V-Model, the corresponding testing phase of the development

phase is planned in parallel.
♥ So there are Verification phases on one side of and Validation phases
on the other side. Coding phase joins the two sides of the V-Model.

3/2/2018
 45 02/11/2022

Verification Phases
Requirement analysis:
♥ This is the first phase in the development cycle where the
product requirements are understood from the customer
perspective.
♥ This is a very important activity and need to be managed well, as
most of the customers are not sure about what exactly they need.
♥ The acceptance test design planning is done at this stage as
business requirements can be used as an input for acceptance
testing. 3/2/2018
 46 02/11/2022

Product requirement and specification analysis:

♥ Once you have the clear and detailed product requirements,
it’s time to design the complete system.
♥ System design would comprise of understanding and detailing
the complete hardware and communication setup for the
product under development.
♥ System test plan is developed based on the system design.

3/2/2018
 47 02/11/2022

Architectural high level design:

♥ Architectural specifications are understood and designed in this
phase.
♥ Usually more than one technical approach is proposed and based
on the technical and financial feasibility the final decision is
taken.
♥ System design is broken down further into modules taking up
different functionality. This is also referred to as High Level
Design HLD. 3/2/2018

♥ Integration tests can be designed and documented during this

 48 02/11/2022

Detail design:
♥ In this phase the detailed internal design for all the system
modules is specified, referred to as Low Level Design LLD.
♥ It is important that the design is compatible with the other modules
in the system architecture and the other external systems.
♥ Unit tests are an essential part of any development process and
helps eliminate the maximum faults and errors at a very early stage.
♥ Unit tests can be designed at this stage based on the internal
module designs. 3/2/2018
 49 02/11/2022

Coding Phase
♥ The actual coding of the system modules designed in the design
phase is taken up in the Coding phase.
♥ The best suitable programming language is decided based on the
system and architectural requirements.
♥ The coding is performed based on the coding guidelines and
standards.
♥ The code goes through numerous code reviews and is optimized for
best performance before the final build is checked into the
3/2/2018

repository.
 50 02/11/2022

Validation Phases
Unit testing:
♥Unit tests designed in the module design phase are executed on the
code during this validation phase.
♥Unit testing is the testing at code level and helps eliminate bugs at an
early stage, though all defects cannot be uncovered by unit testing.
Integration testing:
♥Integration testing is associated with the architectural design phase.
♥Integration tests are performed to test the coexistence and
communication of the internal modules within the system.
3/2/2018
 51 02/11/2022

System testing:
♥ System testing is directly associated with the System design phase. System tests check
the entire system functionality and the communication of the system under
development with external systems.
♥ Most of the software and hardware compatibility issues can be uncovered during
system test execution.

Acceptance testing:
♥ Acceptance testing is associated with the business requirement analysis phase and
involves testing the product in user environment.
♥ Acceptance tests uncover the compatibility issues with the other systems available in
the user environment. It also discovers the non-functional issues such as load and
3/2/2018

performance defects in the actual user environment.

 52 02/11/2022

When to use the V-Shaped Model

♥ Excellent choice for systems requiring high reliability
♥ All requirements are well defined, clearly documented and
fixed.
♥ Product definition is stable.
♥ Technology is not dynamic and is well understood by the
project team.
♥ There are no ambiguous or undefined requirements.
3/2/2018
♥ The project is short
 53 02/11/2022

V- Model Pros and Cons

Pros
 This is a highly disciplined model and Phases are completed one at a time.
 Works well for smaller projects where requirements are very well
understood.
 Simple and easy to understand and use.
 Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process
Cons
 High risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and on-going projects.
 Not suitable for the projects where requirements are at a moderate to high
risk of changing.
 Once an application is in the testing stage, it is difficult to go back and
3/2/2018

change a functionality
 54 02/11/2022

Spiral Model

♥ The spiral model of software development and evolution represents

a risk driven approach to software process analysis and structuring.
♥ This approach incorporates elements of specification-driven,
prototype-driven process methods, together with the classic
software life cycle.
♥ It does so by representing iterative development cycles as an
expanding spiral, with inner cycles denoting early system analysis
and prototyping, and outer cycles denoting the classic software life
cycle. 3/2/2018
 55 02/11/2022

♥ The radial dimension denotes cumulative development costs, and

the angular dimension denotes progress made in accomplishing each
development spiral.
♥ The Spiral model of software development is shown in fig. The
diagrammatic representation of this model appears like a spiral with
many loops.
♥ The exact number of loops in the spiral is not fixed. Each loop of the
spiral represents a phase of the software process.
♥ For example, the innermost loop might be concerned with feasibility
3/2/2018

study, the next loop with requirements specification, the next one
 56 02/11/2022

♥ Each phase in this model is split into four sectors (or

quadrants) as shown in fig. The following activities are carried
out during each phase of a spiral model.

3/2/2018
 57 02/11/2022

 First quadrant (Objective Setting)

 During the first quadrant, it is needed to identify the objectives of the
phase. Examine the risks associated with these objectives.
 Second Quadrant (Risk Assessment and Reduction)
 A detailed analysis is carried out for each identified project risk.
 Steps are taken to reduce the risks. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed
 Third Quadrant (Development and Validation)
 Develop and validate the next level of the product after resolving the
identified risks.
 Fourth Quadrant (Review and Planning)
 Review the results achieved so far with the customer and plan the next
iteration around the spiral.
 Progressively more complete version of the software gets built with each
3/2/2018

iteration around the spiral.

 58 02/11/2022

Strength of spiral model

 Provides early indication of insurmountable risks, without
much cost
 Users see the system early because of rapid prototyping tools
 Critical high-risk functions are developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently

3/2/2018
 59 02/11/2022

Weaknesses of spiral model

 Time spent for evaluating risks too large for small or low-risk
projects
 Time spent planning, resetting objectives, doing risk analysis
and prototyping may be excessive
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-development phase
activities
 May be hard to define objective, verifiable milestones that
indicate readiness to proceed through the next iteration3/2/2018
 60 02/11/2022

Reading Assignment
1. Read other SDLC model like Agile Model,
iteration waterfall………etc..
2. Why study software engineering?
3. Difference between system analysis and
system design.
4. Characteristics of SRS

3/2/2018
 61 02/11/2022

Software Process assessment model

♥ A software process assessment is a disciplined examination of the

software processes used by an organization, based on a process
model.
♥ The assessment includes the identification and characterization of
current practices, identifying areas of strengths and weaknesses, and
the ability of current practices to control or avoid significant causes
of poor (software) quality, cost, and schedule.
♥ A software assessment (or audit) can be of three types.
♥ A self-assessment (first-party assessment): - is performed internally
3/2/2018

by an organization's own personnel.

 62 02/11/2022

♥ A second-party assessment: - is performed by an external

assessment team or the organization is assessed by a customer.
♥ A third-party assessment: - is performed by an external party
or (e.g., a supplier being assessed by a third party to verify its
ability to enter contracts with a customer).

3/2/2018
 63 02/11/2022

♥ The software industry has embraced the impotence of software

processes for years.
♥ One of the key organizations that has contributed, advanced, and
advocated the software development processes is the software
engineering institute (SEI), and another organization that has
contributed to software engineering is the international standard
organization (ISO).
♥ Both the SEI and ISO contributed greatly to assisting the maturity
of the organization in their software development and support.
3/2/2018
 64 02/11/2022

A. SEI’s Capability Maturity Model

♥ The capability maturity model (CMM), initially proposed by SEI, is
a framework that is used to help a software organization define its
level of maturity in software development.
♥ The model presents five levels of maturity and based on the concept
of continuous improvements.
♥ The level of maturity of a software organization is determined by its
practice of different sets of key software development process
activities.
3/2/2018
♥ CMM-based assessment approach uses a six-step cycle. They are −
65 02/11/2022

3/2/2018
 66 02/11/2022

♥ Select a team - The members of the team should be professionals

knowledgeable in software engineering and management.
♥ Maturity Questionnaire - The representatives of the site to be
appraised complete the standard process maturity questionnaire.
♥ Response Analysis - The assessment team performs an analysis of
the questionnaire responses and identifies the areas that warrant
further exploration according to the CMM key process areas.
♥ On-site Visit - The assessment team conducts a site visit to gain an
understanding of the software process followed by the site.3/2/2018
 67 02/11/2022

♥ Findings - The assessment team produces a list of findings that

identifies the strengths and weakness of the organization's software
process.
♥ KPA Profile - The assessment team prepares a Key Process Area
(KPA) profile analysis and presents the results to the appropriate
audience.
♥ The assessment team must be led by an authorized SEI Lead Assessor.
♥ At least, one team member must be from the organization being
assessed, and all team members must complete the SEI's Introduction
3/2/2018
to the CMM course (or its equivalent).
 68 02/11/2022

♥ Team members must also meet some selection guidelines.

♥ With regard to data collection, the CBA IPI relies on four methods
−
 The standard maturity questionnaire
 Individual and group interviews
 Document reviews
 Feedback from the review of the draft findings with the
assessment participants
The five levels of CMM are listed below
 Level 1 at initial level
 An organization has no process, and any success is 3/2/2018
probably
attributed to a strong and experienced leader.
 69 02/11/2022

Level 2 repeatable level

There are six key processes that an organization must master:
Requirements management
Software project tracking and oversight
Software quality assurance
Software project planning
Subcontract management
Software configuration management
Level 3 Defined
♥In order for an organization to elevate level 2 to level 3 it must master seven more
key processes:
♥Organization process focus, Training program, Software product engineering, Peer
reviews, Organization process definition, Integrated software management and Inter
3/2/2018

group coordination.
 70 02/11/2022

 Level 4 Managed
♥ An organization moves up to level 4 when it focuses its effort
on quantities and quality management in addition to all the key
process of level 2 and 3. Such two more key processes are
added
 Quantitative process management
 Software quality management
♥ Quantitative management of attributes such as quality,
productive, or efficiency is part of the organization at this level.
3/2/2018
 71 02/11/2022

 Level 5 optimizing
♥ The highest level of CMM is level 5 (optimizing level). The emphasis here is
on continuous improvement.
♥ In order to facilitate such improvement, three key processes must be included:
 Detect prevention, Technology change management and Process change
management
♥ All the key processes at this ultimate level contribute to an organization
poised for changes and improvements.
♥ SEI’s CMM has been used by thousands of software organizations across
multiple countries. 3/2/2018
 72 02/11/2022

SEI’s Capability Maturity Model Integrated

♥ In 2001, the CMM was upgraded to Capability Maturity

Model Integrated (CMMI).
♥ Again, the improvement factor to remember is that CMMI’s
purpose is to provide guidance for improving the processes of
an organization and its ability to develop, manage, and support
the software product and services.
♥ The CMMI-SW model has two representations:
 Continuous
 Staged 3/2/2018
 73 02/11/2022

♥ The continuous representation model is more applicable to the

assessment and improvement of processes.
♥ The staged representation model is, like the CMM, better applied to
assessing the maturity of an organization.
The process area of CMMI
♥ The first key concept related to both continuous and staged
representations in CMMI is that there are 25 major process areas
covering four major categories of processes.
1. Process management:- the five process area fall under process
3/2/2018

management
 74 02/11/2022

2. Project management:- eight process area fall project

management
3. Engineering:- six process areas fall under engineering
4. Support:- six process areas fall under support
♥ Level in CMMI

3/2/2018
 75 02/11/2022

♥ Note: - the key difference between maturity assessment an

capability assessment
♥ A maturity assessment is done at an enterprise or
organizational level and uses a difference measurement
scales than a capability assessment and difference criteria and
attributes.
♥ A capability assessment is done at a process level and is
done for purpose of process improvement.
3/2/2018
 76 02/11/2022

Software Metrics

♥ Software metrics is a standard of measure that contains many

activities which involve some degree of measurement.
♥ Metrics is a quantitative measure of the degree to which a
system, component or process possesses a given attribute. It
relates measure in some way.
♥ Example: defects found in component testing/line of code/ of
code tested.

3/2/2018
 77 02/11/2022

♥ SW Metrics refers to a range of measurements for computer software

that enable software people to gain insight into the project:
 To improve the Process and the Product
 Assist in Estimation
 Productivity Assessment
 Quality Control
 Project Control
♥ Software metrics can be classified into three categories: product
metrics, process metrics, and project metrics. 3/2/2018
 78 02/11/2022

♥ Product metrics: - describe the characteristics of the product such as size,

complexity, design features, performance, and quality level.
♥ Examples: code, design docs, test plan, user manual LOC (line of code), # of
objects, # of pages, # of files.
♥ Process metrics: - can be used to improve software development and
maintenance.
♥ Examples include the effectiveness of defect removal during development, the
pattern of testing defect arrival, and the response time of the fix process.
♥ Project metrics:- describe the project characteristics and execution. Examples
include the number of software developers, the staffing pattern over the life
3/2/2018
cycle of the software, cost, schedule, and productivity.
 79 02/11/2022

Two types of uses for process metrics

♥ Private metrics – measures taken of an individual's software
process. – Examples of metrics private to the individual
 defect rates (by individual)
 defect rates (by module)
 errors found during development
♥ Public metrics –measures taken at a team level. These are made
public to the organization. Used to improve an organizations
process maturity. – Example: defects found after release per KLOC
3/2/2018
 80 02/11/2022

Reasons for measuring SW processes, products, and resources:

♥To characterize: To gain understanding of Product, Process, and to establish baseline

for future comparisons.
♥To evaluate: To determine status within the plan
♥To predicate: So that we can plan. Update estimates
♥To improve: We would have more information “quantitative” to help determine root
causes.

Scope of Software process Metrics

♥Software metrics contains many activities which include the following: -
♥Cost and effort estimation, Productivity measures and model, Data collection, Quantity
models and measures, Reliability models, Performance and evaluation models,
Structural and complexity metrics, Capability – maturity assessment, Management
3/2/2018
by
metrics, Evaluation of methods and tools
 81

Thank you