Fundamental of Software Engineering

(CSEg3201)

Chapter Two
Software Processes

Sufian K
sufiankedir156@[Link]

9 March 2026
1
 Process
 Process is a series of steps involving activities, constraints and resources
that produce an intended output.

 Activities has following:

❖ communicate with customer

❖ identify the feasibility

❖ analyze the requirements

❖ make a design

❖ develop the software according to design

❖ test the developed software if the software is according to customer

specification and requirements, and free of errors implement unless

repeat all steps.
2
 Process
 Constraints contains the following:

❖ Requirement should be carefully identified.

❖ Feasibly should be checked for the suitability of project in

terms of:

✓ software and hardware

✓ Cost

✓ Time

❖ Problems should be carefully analyzed

❖ Testing should be done carefully

3
 Process

 Resources are:

❖ People

❖ Software

❖ Hardware

❖ Equipment

❖ Time

❖ Money

4
 The Software Process
 A structured set of activities required to develop a software
system
 Requirement Identification

 Specification

 Analysis, design and implementation.

 Validation

 Evolution

 A software process model is an abstract representation of a

process
 It presents a description of a process from some particular
perspective 5
 Software process characteristics
❖ Understandability

❖ Visibility

❖ Supportability

❖ Acceptability

❖ Reliability

❖ Robustness

❖ Maintainability

❖ Rapidity
6
 Process Model
1. Waterfall Model : is a sequential (non- iterative) design process
used for software development.

 This approach is one directional down

“ one should move to the next phase only when its preceding phase
is reviewed.”
Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance
7
 Waterfall model phases
 Requirements analysis and definition

 System and software design

 Implementation and unit testing

 Integration and system testing

 Operation and maintenance

❖ The drawback of the waterfall model is the difficulty of

accommodating change after the process is underway.

8
 Waterfall Model Requirement and Design

Artefacts produced in the requirements and Design phases

 SRS -Software Requirements specification document

 SRS might include:

 User usage stories (scenarios) – Use cases.

 Static analysis – class diagrams.

 Behavioural analysis – sequence diagrams, state charts.

The specification and design activities are heavily time consuming.

9
 Waterfall model problems
 Not changing friendly

 Inflexible partitioning of the project into distinct stages

 Difficult to respond to changing customer requirements

 No working model of the software will not be available for the users until
all phases completed.
This model is only appropriate when the requirements are well-understood
❖ Waterfall model describes a staged development process
 Based on hardware engineering models
 Change during development is unlikely
 Widely used in large systems: military and aerospace industries

10
 When to use the Waterfall Model

 Requirements are very well known

 Product definition is stable

 Technology is understood

 New version of an existing product

 Porting an existing product to a new platform.

11
 2. V-Shaped SDLC Model
 Extension of waterfall model.

 Demonstrates the relationships between

− each phase of the development life cycle and its associated

phase of testing.

 Emphasize on test driver software development.

 Testing of the software is planned in parallel with the

corresponding phase of the development.

12
V-Shaped SDLC Model
 A variant of the Waterfall that
emphasizes the verification and
validation of the product.

 Testing of the product is planned

in parallel with a corresponding
phase of development

13
 V-shaped model phases
 Requirement analysis: developers need to understand the
requirements from the customer, and establishing mutual
understanding.

 System design: analyze the requirements conduct feasibility study

and design complete design of the system.

 Architecture design: generate high level design document and take

all decision like which controller should be taken and which
programming language should be used, communication channel.

 Module design: generate low level design document

 Coding: where the construction of the software takes place.

14
 V-Shaped Steps
 Production, operation and maintenance –
 Project and Requirements Planning – allocate
provide for enhancement and corrections
resources
 System and acceptance testing – check the
 Product Requirements and Specification Analysis –
entire software system in its environment
complete specification of the software system
 Integration and Testing – check that modules
 Architecture or High-Level Design – defines how
interconnect correctly
software functions fulfill the design
 Unit testing – check that each module acts as
 Detailed Design – develop algorithms for each
expected
architectural component
 Coding – transform algorithms into software

15
 V-Shaped Strengths

 Emphasize planning for verification and validation of the product

in early stages of product development

 Each deliverable must be testable

 Project management can track progress by milestones

 Easy to use

16
V-Shaped Weaknesses

 Does not easily handle concurrent events

 Does not handle iterations or phases

 Does not easily handle dynamic changes in requirements

 Does not contain risk analysis activities

17
When to use the V-Shaped Model

 Excellent choice for systems requiring high reliability –

hospital patient control applications

 All requirements are known up-front

 When it can be modified to handle changing requirements

beyond analysis phase

 Solution and technology are known

18
[Link] Evolutionary Prototyping Model

 Developers build a prototype during the requirements phase

 Prototype is evaluated by end users

 Users give corrective feedback

 Developers further refine the prototype

 When the user is satisfied, the prototype code is brought up

to the standards needed for a final product.

19
Structured Evolutionary Prototyping Steps
 A preliminary project plan is developed
 An partial high-level paper model is created
 The model is source for a partial requirements specification
 A prototype is built with basic and critical attributes
 The designer builds
 the database

 user interface

 algorithmic functions

 The designer demonstrates the prototype, the user evaluates for

problems and suggests improvements.
 This loop continues until the user is satisfied
20
 Structured Evolutionary Prototyping Strengths

 Customers can “see” the system requirements as they are

being gathered
 Developers learn from customers

 A more accurate end product

 Unexpected requirements accommodated

 Allows for flexible design and development

 Steady, visible signs of progress produced

 Interaction with the prototype stimulates awareness of

additional needed functionality

21
Structured Evolutionary Prototyping Weaknesses

 Tendency to abandon structured program development for

“code-and-fix” development

 Bad reputation for “quick-and-dirty” methods

 Overall maintainability may be overlooked

 The customer may want the prototype delivered.

 Process may continue forever (scope creep)

22
When to use
Structured Evolutionary Prototyping
 Requirements are unstable or have to be clarified

 As the requirements clarification stage of a waterfall model

 Develop user interfaces

 Short-lived demonstrations

 New, original development

 With the analysis and design portions of object-oriented

development.

23
[Link] Application Model (RAD)
 High speed adaptation of linear/waterfall model

 Achieved by component-based construction.

 If fully functional dependent is understood it can be developed in a short

time.

 Requirements planning phase (a workshop utilizing structured discussion

of business problems)

 User description phase – automated tools capture information from users

 Construction phase – productivity tools, such as code generators, screen

generators, etc. inside a time-box. (“Do until done”)

 Cutover phase - installation of the system, user acceptance testing and

user training 24
 RAD Strengths
 Reduced cycle time and improved productivity with fewer people
means lower costs

 Time-box approach mitigates cost and schedule risk

 Customer involved throughout the complete cycle minimizes

risk of not achieving customer satisfaction and business needs

 Focus moves from documentation to code.

 Uses modeling concepts to capture information about business,

data, and processes.

25
RAD Weaknesses
 Accelerated development process must give quick responses to the
user

 Risk of never achieving closure

 Hard to use with legacy systems

 Requires a system that can be modularized

 Developers and customers must be committed to rapid-fire

activities in an abbreviated time frame.

26
When to use RAD
 Reasonably well-known requirements

 User involved throughout the life cycle

 Project can be time-boxed

 Functionality delivered in increments

 High performance not required

 Low technical risks

 System can be modularized

27
[Link] Development
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.

 User requirements are prioritised and the highest priority

requirements are included in early increments.

 Once the development of an increment is started, the

requirements are frozen though requirements for later
increments can continue to evolve.

28
Incremental Development

Define outline Assign requirements Design system

requirements to increments architecture

Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete

29
Incremental Development –Advantages

 Customer value can be delivered with each increment so system

functionality is available earlier.

 Early increments act as a prototype to help elicit requirements for

later increments.

 Lower risk of overall project failure.

 The highest priority system services tend to receive the most

testing.

30
Incremental Model Strengths

 Each release delivers an operational product

 Customer can respond to each build

 Uses “divide and conquer” breakdown of tasks

 Lowers initial delivery cost

 Initial product delivery is faster

 Customers get important functionality early

 Risk of changing requirements is reduced

31
Incremental Development – Problems

 Lack of process visibility.

 Systems are often poorly structured.

 Applicability claims in the literature:

 For small or medium-size interactive systems.

 For parts of large systems (e.g. the user interface).

 For short-lifetime systems.

32
When to use the Incremental Model

 Risk, funding, schedule, program complexity, or need for

early realization of benefits.

 Most of the requirements are known up-front but are

expected to evolve over time

 A need to get basic functionality to the market early

 On projects which have lengthy development schedules

 On a project with new technology

33
Incremental means adding, iterative means
reworking (by Alistair Cockburn)
 Incremental development is a staging and scheduling
strategy in which the various parts of the system are developed
at different times or rates and integrated as they are completed.
The alternative is to develop the entire system with a big bang
integration at the end.
 Iterative development is a rework scheduling strategy in
which time is set aside to revise and improve parts of the
system. The alternative development is to get it right the first
time (or at least declare that it is right!).

34
Incremental means adding, iterative means
reworking (by Alistair Cockburn)

Iterate Increment
fundamentally means “change”. fundamentally means “add
onto”.
repeating the process on the repeating the process on a new
same section of work section of work.
repeat the process (, design, repeat the process (, design,
implement, evaluate), implement, evaluate),

35
Incremental Development

 The first increment delivers one slice of

functionality through the whole system.

 The second increment delivers another

slice of functionality through the whole system.

 The third increment delivers the rest of

the system

36
 Iterative Development

 The first iteration delivers enough of

feature 1 to evaluate what is correct

and what needs revision.

 After the second iteration, some revised

parts still need improvement.

 The third iteration produces the final

and stable feature

37
 Problems with incremental development
(from a waterfall eye…)
 Management problems
 Progress can be hard to judge and problems hard to find because
there is no documentation to demonstrate what has been done.
 Contractual problems
 The normal contract may include a specification; without a
specification, different forms of contract have to be used.
 Validation problems
 Without a specification, what is the system being tested against?
 Maintenance problems
 Continual change tends to corrupt software structure making it more
expensive to change and evolve to meet new requirements.

38
 [Link] Development
 Risk-driven software development model.

 Risk: in software development there could be many risk factors

like new technology, research work is required, lack of clear
requirements and etc.
 Spiral is an incremental model.

 Divide and conquer

 Requirements prioritization

 Good feedback mechanism.

 Require good planning.

39
Spiral Model

40
 Phases of Rapid Model
 1. Determine objectives: defining what will be objective of the
specific release and what will be its success criteria?

- Requirement gathering

- Functionality

- Performance

- Improvement

• Identifying alternatives and constraints

41
 Phases of Rapid Model
2. Identifying and resolve risk: review and validating objectives,
alternatives and constraints

Identifying and resolving risk:

- New technology

- Lack of experience

- Tight schedule

- Cost over-run

- Resource constraints.

42
 Phases of Rapid Model. . .
3. Development and test phase:

- Detail design

- Design review

- coding-

- Code review

- Testing

- integration

43
Phases of Rapid Model. . .
4. Plan next iteration:

 Activities performed in this phase are:

-Review the previous phase for its completion.

-Planning of next iteration

-Collecting backlogs and reviewing them

-Develop and review project plan

-Provide support

-Software installation if required.

44
 Strength of Spiral model
 Powerful model to identify and manage risks in early phase of
software development.

 Which reduces cost and time.

 Requirements need to be crystal clear.

 Provide flexibility to prioritize requirements.

 Users can see the system earlier because of rapid prototype.

 Provides mechanism to review and collect feedback from the

different stakeholders of the system.

45
 Spiral Model Weaknesses
 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 iteration

46
 When to use Spiral Model
 When creation of a prototype is appropriate

 When costs and risk evaluation is important

 For medium to high-risk projects

 Long-term project commitment unwise because of potential

changes to economic priorities
 Users are unsure of their needs

 Requirements are complex

 New product line

 Significant changes are expected (research and exploration)

47
 7. The (Rational) Unified Process

 A modern process model derived from the work on the UML.

 Normally described from 3 perspectives

 A dynamic perspective that shows phases over time;

 A static perspective that shows process activities;

 A practice perspective that suggests good practice.

48
 (R)UP phase model

Phase iteration

Inception Elaboration Cons truction Transition

49
 (R)UP phases
 One cycle consists of four phases:
 Inception
 Establish Scope
 Build a business case
 Get stakeholder buy-in
 Elaboration
 Identify and manage risks
 Build an executable architecture
 Focus only on high risk items
 Construction
 System design, programming and testing.
 Iteratively build operational version
 Develop support docs and training materials
 Transition
 Fine-tune Resolve configuration, installation and usability issues

50
(R)UP phases and iterations

Picture taken from: [Link]

term2/
51
(R)UP
 In each phase many different workflows (like management,
environment, design, implementation workflow, etc.) can be
addressed simultaneously.
 At the end of each cycle some kind of prototype or artifact are
produced.
 The phases can be repeated many times (i.e. iterations), producing
one or many prototypes or artifacts.
 During the cycles the requirements are stable which offers
possibilities to plan the development process for this cycle.
 Between the cycles the requirements change.
52
(R)UP good practice
 Develop software iteratively

 Manage requirements

 Use component-based architectures

 Visually model software

 Verify software quality

 Control changes to software

53
[Link] Development
File:Agile Software Development [Link]

54
Project Failure – the trigger for Agility

 One of the primary causes of project failure was the

extended period of time it took to develop a system.

 Costs escalated and requirements changed.

 Agile methods intend to develop systems more quickly

with limited time spent on analysis and design.

55
What is an Agile method? (1)
 Focus on the code rather than the design.

 Based on an iterative approach to software development.

 Intended to deliver working software quickly.

 Evolve quickly to meet changing requirements.

 There are claims that agile methods are probably best suited to
small/medium-sized business systems or PC products.

 Most popular Agile methods are scrum , extreme programming

and KANBAN

56
Scrum

57
Extreme Programming

58
KANBAN

59
Summary of Principles of Agile Methods

60
When to use Agile method
 When you have best programmers

 Full participation of User sand decision makers

 At least one experienced and competent staff

 rapid feedback on decisions from user and decision maker

 The system is not complex

 The design is flexible when ever the requirements are change

61
 Summary
 Iterative model - This model iterates requirements, design, build
and test phases again and again for each requirement and builds
up a system iteratively till the system is completely build.
 Incremental model - It is non integrated development model.
This model divides work in chunks and one team can work on
many chunks. It is more flexible.
 Spiral model - This model uses series of prototypes in stages,
the development ends when the prototypes are developed into
functional system. It is flexible model and used for
large and complicated projects.
 Evolutionary model - It is more customer focused model. In this
model the software is divided in small units which is delivered
earlier to the customers.
 V-Model - It is more focused on testing. For every phase some
testing activity are done.

62
 Process Assessment(PA)

• Process Assessment is systematic evolution of an organizations

processes to identify strengths, weaknesses and areas for
improvement.
✓ It involves assessing of the effectiveness, efficiency, and
maturity of processes to ensure they align with
organization goal.

63
Software Process Improvement Efforts

• In the Capability Maturity model(CMM), the maturity level of

an organization tells us to

− what extent an organization can produce low cost, high

quality software.

• Having known the current maturity level, an organization can

work to reach the next higher level.

64
Cont.….
 Capability Maturity model(CMM), is the methodology used to
develop and refine an organizations software development
process.

 The model describes a five level evolutionary path of

increasingly organized and systematically more mature
processes.

65
 Cont.….
 CMM was developed and is promoted by the Software Engineering
Institute (SEI), a research and development center sponsored by the
U.S. Department of Defense (DOD) and now part of Carnegie Mellon
University.

 SEI was founded in 1984 to address software engineering issues and,

in a broad sense, to advance software engineering methodologies.

 More specifically, SEI was established to optimize the process of

developing, acquiring and maintaining heavily software-reliant
systems for the DOD.

— The CMM model is still widely used as well.

66
Cont.….

 Carnegie Mellon University’s Software Engineering

Institute’s Capability Maturity Model - (SEI’s CMM)

 International Standards Organization’s 9001 Specification

(ISO 9001)

 Proprietary SPI’s from consulting firms

67
 < 1% Optimizing

Process Control

2-3% Managed

Process Measurement

20% Defined

Process Definition

30% Repeatable

Basic Management Control

45% Initial
68
 CMM - Initial (Level 1)
• At this level, the software process is characterized as
disorganized, ad hoc, and occasionally even chaotic.
• Success likely depends on individual efforts and is not considered
to be repeatable.
• This is because processes are not sufficiently defined and
documented to enable them to be replicated.
✓ few processes are defined

“BASICALLY NO CONTROL”

69
 CMM - Repeatable (Level 2)

• In this, necessary processes are established, defined and

documented.
• As a result, basic project management processes are established,
to track cost, schedule and functionality
• Success achieved through basic project management; not
advanced technologies
✓ and successes in key process areas(KPA) are able to be
repeated.

“BASIC MANAGEMENT CONTROL”

70
 CMM - Defined (Level 3)
• The software process for both management and engineering
activities is documented, standardized, and integrated into a
standard software development process for the organization.
— thus, an organization develops its own standard software
development process.
• All projects use an approved, tailored version of the organization’s
standard software process for developing and maintaining
software.
• Formality lends itself to improvement

“PROCESS DEFINITION” 71
 CMM - Managed (Level 4)
• At this level, an organization monitors and controls its own processes
through data collection and analysis.
— Detailed measures of the software process and product quality
are collected
— Both the software process and products are quantitatively
understood and controlled.
— A software metrics program is in use

“PROCESS MEASUREMENT”
72
 CMM - Optimizing (Level 5)

• At this level, continuous process improvement is enabled by

quantitative (metrics) feedback from the process
• Continuous process improvement is enabled by piloting
innovative ideas and technologies

“PROCESS CONTROL”
73
CMM - Summary (Level 1-5)

74
SW-CMM Process Assessment

• General Classes of SW-CMM Appraisal

1. Software Process Assessment
• Determine state of organization’s software
process
2. Software Capability Evaluations
• Identify contractors qualified to perform
software work

75
SW-CMM Process Assessment …

• Software Process Assessment:

- Identify improvement priorities within organization
- Assessment team uses CMM to guide identifying &
prioritizing findings
- Findings & key process areas (KPA) guidance used to
plan improvement strategy for organization

76
SW-CMM Process Assessment …
• Software Capability Evaluations:
- Identify risks associated with a project or contract to build
high quality on schedule & budget
- During acquisition process, capability evaluation may be
performed on bidders (users)
- Findings of an evaluation may be used to identify risk with
using a contractor
- Performed on existing contracts to monitor process
performance

77
Software Process Assessment &
Capability Evaluation Steps:

78
SW-CMM Process Assessment …

• Common Steps:
- Team Selection
➢ Select team trained in CMM
➢ Knowledgeable in SE & mgmt
- Maturity Questionnaire
➢ Site reps complete questionnaire
- Response Analysis
➢ Analyze results of questionnaire
➢ Investigation areas = KPAs
79
 SW-CMM Process Assessment …
• Common Steps …
- On-site Visit
➢ Using results analysis, conduct on-site visit to view
process areas
➢ Using KPAs as guide, question, listen, review &
synthesize info
➢ Apply professional judgment
➢ Document rationale for situations where KPAs not met

80
SW-CMM Process Assessment …
• Common Steps …
- Findings
➢ At end of on-site period, team produces list of
findings
➢ Identifies strengths & weaknesses of org’s
software processes
➢ Software Process Assessment -> Basis for PI
recommendations
➢ Software Capability Evaluation -> Findings part of
risk analysis
81
SW-CMM Process Assessment …

• Common Steps …
- KPA Profile
➢ Team prepares KPA profile, showing where KPAs
satisfied / not satisfied by organization
➢ KPA can be satisfied and still have associated
findings, as long as findings don’t identify major
problems achieving goals of KPA

82
SW-CMM Process Assessment …

• Differences: Process Assessments & Capability Evaluation

- Results of process assessment or capability evaluation
may differ
- Assessment / evaluation scope may vary:
➢ Different definitions of ‘Organization’
➢ Org may be based on senior management, geo
location, common app, profit/loss center, etc.
➢ Sample of selected projects

83
SW-CMM Process Assessment …

• Differences …
- Motivation, objective, outcome & results ownership differ
➢ These factors lead to differences in dynamics of
interviews, scope of inquiry, info collected, &
results
➢ Assessment & evaluation methods are different
➢ Assessment training doesn’t prepare team to do
evaluation, vice versa

84
 SW-CMM Process Assessment …
• Differences …
- Process Assessment – performed in open, collaborative
environment
➢ Commitment from mgmt. & staff to do process
improvement
➢ Objective: surface problems & help improve
organization
➢ Emphasis on interviews as tool for understanding
organization’s software process
85
 SW-CMM Process Assessment …
• Differences …
- Capability Evaluation – performed in audit-oriented
environment
➢ Objective tied to monetary considerations
➢ Emphasis on documented audit trail that reveals
software process actually implemented by
organization

86
 Why Measure Software?

 Metric - quantitative measure of degree to which a system,

component or process possesses a given attribute. “A handle
or guess about a given attribute.”

 E.g., Number of errors found per person hours expended

 Determine the quality of the current product or process

 Predict qualities of a product/process

 Improve quality of a product/process

87
 Motivation for Metrics

 Estimate the cost & schedule of future projects

 Evaluate the productivity impacts of new tools and techniques

 Establish productivity trends over time

 Improve software quality

 Forecast future staffing needs

 Anticipate and reduce future maintenance needs

88
 Metrics in the Process Domain
 a metric as " a quantitative measure of the degree to which a system,
component, or process possesses a given attribute”.

 Process metrics are collected across all projects and over long periods of time

 They are used for making strategic decisions

 The intent is to provide a set of process indicators that lead to long-term

software process improvement

 The only way to know how/where to improve any process is to

 Measure specific attributes of the process

 Develop a set of meaningful metrics based on these attributes

 Use the metrics to provide indicators that will lead to a strategy for

improvement
89
 Metrics in the Process Domain (continued)

 We measure the effectiveness of a process by deriving a set of metrics

based on outcomes of the process such as
 Errors uncovered before release of the software

 Defects delivered to and reported by the end users

 Work products delivered

 Human effort expended

 Calendar time expended

 Conformance to the schedule

 Time and effort to complete each generic activity

90
Cont.…
Private metric

 There are "private and public" uses for different types of process data :

 Data private to the individual

 serve as an indicator for the individual only

Examples of metrics private to the individual

 defect rates (by individual)

 defect rates (by module)

 errors found during development

91
Cont.…
Public metrics
 Public metrics assimilate information that originally was private to
individuals and teams.
 Project-level defect

– rates ,
– effort,
– calendar times,
– related data
 are collected and evaluated in an attempt to uncover indicators that can
improve organizational process performance.

92
 Protocol of Process Metrics
 Use common sense and organizational sensitivity when interpreting metrics data

 Provide regular feedback to the individuals and teams who collect measures
and metrics

 Don’t use metrics to evaluate individuals

 Work with practitioners and teams to set clear goals and metrics that will be used
to achieve them

 Never use metrics to threaten individuals or teams

 Metrics data that indicate a problem should not be considered “negative”

 Such data are merely an indicator for process improvement

 Don’t obsess on a single metric to the exclusion of other important metrics

93
Thank You!
Any Q?

94