Chapter 2 discusses various software processes and models essential for software development, outlining key activities such as specification, design, validation, and evolution. It contrasts plan-driven processes, like the waterfall model, with agile methods, emphasizing their advantages and limitations. Additionally, the chapter highlights requirements engineering, design strategies, and the importance of software validation in ensuring systems meet user needs.

1. Chapter 2 Software Processes
Software Process Model
Dr.G.Jasmine Beulah
Assistant Professor, Dept. Computer Science,
Kristu Jayanti College,Bengaluru.
1

2. Chapter 2 Software Processes
The Software Process
 A structured set of activities required to develop a
software system.
 Many different software processes but all involve:
Specification – defining what the system should do;
Design and implementation – defining the organization of the system
and implementing the system;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing customer
needs.
 A software process model is an abstract representation
of a process. It presents a description of a process from
some particular perspective.
3

3. Chapter 2 Software Processes
Software Process Descriptions
 When we describe and discuss processes, we usually
talk about the activities in these processes such as
specifying a data model, designing a user interface, etc.
and the ordering of these activities.
 Process descriptions may also include:
Products, which are the outcomes of a process activity;
Roles, which reflect the responsibilities of the people involved in
the process;
Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a product
produced.
4

4. Chapter 2 Software Processes
Plan-driven and Agile Processes
a.k.a. Heavy-Weight versus Light-Weight Models
 Plan-driven processes are processes where all of the
process activities are planned in advance and progress is
measured against this plan.
Plan drives everything!
 In Agile Processes planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
 In practice, most practical processes include
elements of both plan-driven and agile.
 There are no right or wrong software processes.
5

5. Software Development Life Cycle (SDLC)
 A software life cycle model (also termed process model) is a pictorial
and diagrammatic representation of the software life cycle.
 A life cycle model represents all the methods required to make a
software product transit through its life cycle stages.
 It also captures the structure in which these methods are to be
undertaken.

6. SDLC Cycle

7. SDLC Models

8. Chapter 2 Software Processes
Software Process Models - heavyweight model
 Example: The Waterfall Model
Plan-driven model.
Separate and distinct phases of specification and development.
Heavily oriented toward documentation (documentation-intensive)
Progress often measured thru documentation completion and
reviews (many)
Garnett charts
Lockstep approach
Little chance for Change!
Oftentimes discover major flaws too late.
Delivered as Big Bang
Still exists in spades – but modified to a degree.
6

9. Chapter 2 Software Processes
The Waterfall Model
8
Notice the feedback loops

10. Chapter 2 Software Processes
Waterfall Model Phases
 There are separate identified phases in the waterfall
model:
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
 The main drawback of the waterfall model is the
difficulty of accommodating change after the process is
underway. In principle, a phase has to be complete
before moving onto the next phase.
 But many issues are true too, such as risk addressing.
9

11. Chapter 2 Software Processes
Waterfall Model Problems
 Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
Therefore, this model is only appropriate when the requirements
are well-understood and changes will be fairly limited during
the design process.
Few business systems have stable requirements.
 The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.
10

12. Prototype Model
 The prototype model requires that before carrying out the
development of actual software, a working prototype of the system
should be built.
 A prototype is a toy implementation of the system.
 A prototype usually turns out to be a very crude version of the actual
system, possible exhibiting limited functional capabilities, low
reliability, and inefficient performance as compared to actual
software.
 In many instances, the client only has a general view of what is
expected from the software product.
 In such a scenario where there is an absence of detailed information
regarding the input to the system, the processing needs, and the
output requirement, the prototyping model may be employed.

14. Steps of Prototype Model
1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

15. Advantage of Prototype Model
1. Reduce the risk of incorrect user requirement
2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is
made side by side.

16. Disadvantage of Prototype Model
 An unstable/badly implemented prototype often becomes the final
product.
 Require extensive customer collaboration
Costs customer money
Needs committed customer
Difficult to finish if customer withdraw
May be too customer specific, no broad market
 Difficult to know how long the project will last.
 Easy to fall back into the code and fix without proper requirement
analysis, design, customer evaluation, and feedback.
 Prototyping tools are expensive.
 Special tools & techniques are required to build a prototype.
 It is a time-consuming process.

17. Chapter 2 Software Processes
Boehm’s Spiral Model - heavyweight model
 Process is represented as a spiral rather than as a
sequence of activities with backtracking.
 Each loop in the spiral represents a phase in the process.
 No fixed phases such as specification or design - loops in
the spiral are chosen depending on what is required.
 Risks are explicitly assessed and resolved throughout the
process.
 This was the motivation behind developing the Spiral Model - Risk
11

18. Chapter 2 Software Processes
Boehm’s Spiral Model of the Software Process
12

19. Chapter 2 Software Processes
Spiral Model Sectors
 Objective setting
Specific objectives for the phase are identified.
 Risk assessment and reduction
Risks are assessed and activities put in place to reduce the key
risks.
 Development and validation
A development model for the system is chosen which can be any
of the generic models. Development takes place.
 Planning
The project is reviewed and the next phase of the spiral is
planned.
13

20. Chapter 2 Software Processes
Spiral Model Usage
 Spiral model has been very influential in helping people
think about iteration in software processes and
introducing the risk-driven approach to development.
 In practice, however, the model is rarely used as
published for practical software development.
14

21. Great Dissatisfaction with Heavy-
Weight Models
Delivered late,
over budget,
Failure to meet functional and non-functional requirements,
not responsive to change,
poor assessment of risk, ....
Discovery of major problems late….
Thinking about Process…..
Want to refine the way we develop systems
Hierarchy:
Successful, Challenged; Failed
Few systems totally successful
Many ‘challenged’
Too many failures
Many famous practitioners starting at Process in more detail
How can we do better?

22. Chapter 2 Software Processes
Process Activities
 Real software processes are inter-leaved sequences of
technical, collaborative and managerial activities with the
overall goal of specifying, designing, implementing and testing
a software system.
 The four basic process activities (specified in your book) of
specification, development, validation and evolution are
organized differently in different development processes.
 In the waterfall model, they are organized in sequence,
whereas in incremental development they are inter-leaved.
16

23. Chapter 2 Software Processes
Software Specification
 Is: The process of establishing what services are required and
the constraints on the system’s operation and development.
 Requirements Engineering Process
Feasibility study
• Is it technically and financially feasible to build the system?
• ROI, product Vision, what market share are we after? Urgency of development?
Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
• Recognition that the client must be satisfied. Have checkbook.
Requirements Specification
• Defining the requirements in detail. These are the ‘whats’ of a system!!!
Requirements Validation
• Checking the validity of the requirements
• Are they feasible, testable, sufficient, necessary, ...
17

24. Chapter 2 Software Processes
The Requirements Engineering Process
18

25. Chapter 2 Software Processes
Software Design and Implementation
 The process of converting the system specification into
an executable system.
 Software Design (inputs: specifications)
Design a software structure that realizes the specification;
 Implementation
Translate this model / structure into an executable app;
Programming is the implementation of the design.
 The activities of design and implementation are closely
related and may be inter-leaved and definitely are using
many modern development processes. (more to come)
19

26. Chapter 2 Software Processes
A General Model of the Design Process
20

27. Chapter 2 Software Processes
Design Activities
 Architectural design, where one identifies the overall structure of
the system, the principal components (sometimes called sub-
systems or modules or layers, etc…), their relationships and how
they are distributed.
Example: Such as Model View Controller (MVC )pattern; others.
 Interface design, where one defines the interfaces between system
components. (interface to controller; controller to database; external
device (sensor) to analyzer…)
 Recognize that to the end user, the UI is the application.
 Component design, where one takes each system component and
design how it will operate.
 This is what we are often used to
 Database design, where one designs the system data structures and
how these are to be represented in a database.
21

28. Chapter 2 Software Processes
Software Validation
 Verification and validation (V & V) is intended to show
that a system conforms to its specification and meets the
requirements of the system customer.
Look up the difference between verification and
validation. Be able to explain clearly.
 Involves checking and review processes and system
testing.
 System testing involves executing the system with test
cases that are derived from the specification of the real
data to be processed by the system.
 Testing is the most commonly used V & V activity.
22

29. Chapter 2 Software Processes
Stages of Testing
23
What does this mean??

30. Chapter 2 Software Processes
Testing Stages
 Development or component testing. (Unit testing)
Individual components are tested independently;
Components may be functions or objects or coherent groupings of
these entities.
 System testing
Testing of the system as a whole. Testing of emergent properties
is particularly important.
 Acceptance testing
Testing with customer data to check that the system meets the
customer’s needs
Some models have various other kinds of testing; subsystem testing,
integrated system testing, and much more.
24

31. Chapter 2 Software Processes
Testing Phases in a Plan-driven Software Process
25

32. Chapter 2 Software Processes
Software Evolution
 Software is inherently flexible and can change.
 As requirements change through changing business
circumstances, the software that supports the business
must also evolve and change.
 Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems are
completely new (greenfield).
26

33. Chapter 2 Software Processes
Key points
• Understand the principles of software engineering
• Understand what we mean by a software process
• Note the two major classifications of processes and note also
that there are numerous hybrid classifications within these.
• Software processes are the activities involved in producing a
software system.
• Software process models are abstract representations of these
processes.
33

34. Chapter 2 Software Processes
Key points
• Requirements engineering is the process of developing a
software specification.
• Design and implementation processes are concerned
with transforming a requirements specification into an
executable software system.
• Software validation is the process of checking that the
system conforms to its specification and that it meets the
real needs of the users of the system.
• Software evolution takes place when you change existing
software systems to meet new requirements. The
software must evolve to remain useful.
34