Software processes

Vũ Thị Hồng Nhạn

([email protected])

Dept. of Software Engineering, FIT, UET

Vietnam National Univ., Hanoi

 Contents
 Software process vs. software development processes

 Fundamental activities

 Coping with change

 Process improvement

2/25/2025 Software processes Page 2

Software process

 A software process is a structured set of activities that cover all aspects of

software development, from early requirements for the system through
development, deployment, evolution once the system is in use, and finally
the system’s decommissioning

 There are several formal software processes, but all of them share
four fundamental activities, sometimes in different forms
 Specification: defining what the software should do

 Design: defining the organization and structure of the system

 Implementing & testing: developing the programs and testing to ensure they
are free of bugs and meet the requirements

 Evolution: modifying the system in response to changing customer needs

2/25/2025 Software processes Page 3

Software process

 These activities are part of various software development models, such as

the Waterfall model, Agile, and DevOps

2/25/2025 Software processes Page 4

 Plan-driven approach vs. Agile approach

 Plan-driven processes are processes where all of

the activities are planned in advance and
progress is measured against this plan

 Agile processes do not reply on a detailed project plan;

 instead, the software is developed in a series of increments, with the

functionality of each increment dependent on the overall progress of
development

2/25/2025 Software processes Page 5

Software development processes
 Software development processes
The waterfall model
 A plan-driven approach

 Incremental development
 Maybe plan-driven or agile

 Reuse-Oriented Software Engineering (ROSE)

i.e., integration and configuration

 The system is assembled from existing configurable components

 may also be plan-driven or agile

2/25/2025 Software processes Page 7

Common Plan-Based Models
Waterfall Model Spiral Model

V-Model (Verification & Validation)

 Waterfall model
 It’s the original, best-known, and still widely used process

 Was introduced around 1970

 This process was derived from a standard engineering approach that had been
used across the engineering industry for many years

2/25/2025 Software processes Page 9

 Problems with waterfall model
 It’s a document-driven process, so each phase in the
process produces an output

 If any change occurs in a later phase, significant effort

is required to modify documents created earlier in
the process

 This often leads to “freezing” the software after the

development process is complete, thereby avoiding
changes – even if such changes could provide benefits
to the company or organization purchasing the
software

2/25/2025 Software processes Page 10

 Problems with waterfall model...
 Waterfall model is only suitable when requirements are well-known,
meaning there will not be any changes in the system

 However, most business systems evolve rapidly, so the assumption of no

change is not typical for most business environments

 The waterfall process is widely used in engineering project where a system

is developed at different sites by different teams

 Informal coordination is very difficult in these settings

 Therefore, a document-driven process is used to coordinate the work

 However, elements of agile development are often incorporated as well

2/25/2025 Software processes Page 11

Agile processes

 Agile methods are an incremental or iterative approach to development,

based on a series of iterations,

 each typically lasts 2 or 4 weeks, during which discrete units of system

functionality are developed

 The aim of agile methods is to minimize documentation and communication

overhead, focusing primarily on developing the operational program

 It’s an approach that is generally much more responsive to change

 The goal is to deliver useful functionality to users more quickly than the
waterfall process

2/25/2025 Software processes Page 12

Agile processes…

 In agile approach, we still have 4 common activities

 However, instead of occurring in a strict sequence as seen in the waterfall
model, these activities are interleaved
 Perform a bit of specification
 Followed by a bit of design, then a bit of implementation
 And repeat the process iteratively

2/25/2025 Software processes Page 13

 Agile processes…

 Agile methods offer several benefits

 The cost of implementing changes to customer requirement is

reduced

 The amount of analysis and documentation that needs to be redone is

less than what is required with the waterfall model

 It’s easy to get customer feedback because there is always a

functional version of the system. Customers can see what’s going on
and check if it meets their needs

2/25/2025 Software processes Page 14

Problems with agile approach

 The process is invisible because documentation is avoided,

making it difficult to track the progress of the system

 Additionally, coordinating activities across different teams

becomes challenging

 Unless, time and money are spent on refactoring to improve

the software, frequent changes can degrade its structure

2/25/2025 Software processes Page 15

Reuse-oriented software process

 Over the last 15 years or so, we have seen a significant change

in the way software is developed, with much more emphasis
on reusing existing software rather than developing it from
scratch

 As a result, the approach to development is

 Find existing software systems or components and integrate them into

a new system

 Reused elements may need to be configured to adapt their behavior

and functionality to meet user requirements

2/25/2025 Software processes Page 16

What types of software can be reused?

 Standard-alone application systems can be configured for use in a specific

environment

 We can integrate reusable components with other reusable or specially

written components

 The 3rd type is web services which are developed according to service
standards and are available for remote invocation

2/25/2025 Software processes Page 17

Model for Reuse-oriented SE

try to
look for • Go back to the In case where Integrate them
understand
reusable customer, the application with the adapted
what the
software • Modify the system is existing
system needs requirements
& Evaluate if it already components to
to do because the
meets the available, we create a new
reused
needs of the only need to system
software
customer doesn’t meet
adapt it by
the necessary making some
specification configuration to
ensure it works
in the current
context

2/25/2025 Software processes Page 18

 Mixed approach
 It involves a mix of plan-based and agile development
 It’s plan-based because requirements are planned in advance, but an
iterative and agile approach can be taken for design and implementation
incrementally
 There is no clear-cut line between plan-based and agile processes
 However, when it comes to critical systems, such as safety-critical
systems, we need to conduct a very detailed analysis of the requirements
 Therefore, an upfront requirements specification (in the form of documents)
is necessary to ensure that the work is done properly and to demonstrate that
the system is safe

 These types of systems are usually developed using a plan-based process

2/25/2025 Software processes Page 19

 Agile software products & apps
 Off-the-shelf products are typically developed using an agile
process

 This approach is suitable for this type of product because the

specifications are quite flexible

 The specifications are created by the company that is

developing the product

2/25/2025 Software processes Page 20

Fundamental activities in SE
 Fundamental activities

 Software specification involves defining what the system should do,

specifying what should be implemented, and describing the expected
behavior of the software

 Design and implementation focus on organizing the software and data

structures and implementing the system in a programming language

 Validation involves testing the system for bugs and verifying that it meets the
users’ requirements

 Software evolution occurs after the software has been deployed, when it is
modified to accommodate changing user requirements

2/25/2025 Software processes Page 22

1. Specification
 The first activity, specification, is sometimes called Requirement Engineering

 Basically, the requirements engineering process consists of several sub-

processes or activities, as represented in the figure

The 3rd phase is concerned with

Engineers work with checking whether the
customers/users to requirements are sensible,
understand what they want achievable, and implementable
from the system

The second phase involves

taking the analysis and
defining a document that
can be used by the
development team as a
basis for the system’s design

2/25/2025 Software processes Page 23

 2. Design process

Software design and

implantation starts with
actually working out an
architecture and major
components of the system

2/25/2025 Software processes Page 24

 2. Design activities
 Architectural design: this phase involves identifying the overall structure of
the system, including the principle components (subsystems or modules), their
relationships, and how they are distributed

 Database design: in this phase, you define the system’s data structures and
how they are represented in a database

 Interface design: This phase specifies the interfaces between system

components

 Component selection & design: in this phase, you search for and select
reusable components for the system

2/25/2025 Software processes Page 25

 3. System implementation
 The implementation phase involves adding details to the
design and programming the system
 Software can be implemented by developing either new
programs or by configuring a reusable application system
 Programming is typically an individual activity without a
standardized process, as people have different approaches to
programming
 Debugging, which involves using tests to reveal and correct
program faults, is a critical activity

2/25/2025 Software processes Page 26

 3.1 V&V and testing
 V&V aims to demonstrate that a system meets its specified requirements
(verification – based on document requirements) and also fulfills the actual
needs of the customer (validation – directly confirming accuracy with users)

 System testing involves executing the system using test cases derived
from data specifications to be processed by the system

 This data is not real but rather created by developers or the testing team to be
consistent with user specifications

2/25/2025 Software processes Page 27

 3.2. Testing process
 The testing process varies widely from one organization to another
 Within the testing process, there are generally three main activities:

This is done by This occurs at several levels,

developers, and including testing the API,
Customers
sometimes techniques verifying that the system
determine
such as test-first meets customer
whether the
development are requirements, and checking
software
applied the system’s non-functional
meets their
behaviors (such as
needs
performance, reliability, etc….
2/25/2025 Software processes Page 28
 3.2 Testing process...
 In a plan-driven process, we sometimes use a testing model called the V model (a software
development model that extends the Waterfall Model by emphasizing testing at every
development phase)

 Each stage of the development process has a corresponding testing activity

2/25/2025 Software processes Page 29

 4. Software evolution process
 Requirements change as business circumstances evolve, and software must adapt
to support the business, so it must evolve and change

 Sometimes changes introduce new bugs into the system or reveal existing bugs
that were previously hidden. This means the system must be modified and
redeployed the cycle again

2/25/2025 Software processes Page 30

Coping with change
 Coping with change
 Change is inevitable in all large software projects.

 Business changes lead to new or modified system

requirements, while new technologies create opportunities to
improve implementations

 Changing platforms also necessitate application adjustments

 Change results in rework, so the costs of change include both

rework (e.g., reanalyzing requirements) and the costs of
implementing new functionality

2/25/2025 Software processes Page 32

Reducing the costs of rework
 Change anticipation involves incorporating activities in the software
process that anticipate potential changes, allowing for adjustments before
significant rework is needed
 E.g., a prototype system may be developed to demonstrate key features to
customers

 Change tolerance refers to designing the process so that changes can be

accommodated at relatively low cost
 This approach typically involves some form of incremental development, where
proposed changes can be implemented in increments that have not yet been
developed

 If any change cannot be implemented, only a single increment may need to be

altered to incorporate it

2/25/2025 Software processes Page 33

 Coping with changing requirements

 System prototyping involves quickly developing a version of the system,

or part of it, to verify customer requirements and asses the feasibility of
design decision
 This approach support anticipating changes

 Incremental delivery involves delivering parts of the systems (increments)

to customer for feedback and experimentation
 This approach support both change avoidance and change tolerance

2/25/2025 Software processes Page 34

Software prototyping
 A prototype is an initial version of a system used to demonstrate concepts
and test design options

2/25/2025 Software processes Page 35

 Software prototyping
 A prototype can be used in ….
 The requirement engineering process to assist with requirements elicitation and
validation
 The design process to explore options and develop a UI design
 The testing process to conduct back-to-back tests

smart energy monitoring system

2/25/2025 Software processes Page 36
 Benefits of prototyping
 Improved system usability
 Closer alignment with users’ real needs
 Enhanced design quality
 Better maintainability
 Reduced development effort

2/25/2025 Software processes Page 37

 The process of prototype development

2/25/2025 Software processes Page 38

 Prototype development
 Prototyping may use rapid development languages or tools and may
involve omitting some functionality

 The prototype should focus on areas of the product that are not
well understood

 Error checking and recovery might be excluded from the prototype,

with an emphasis on functional rather than non-functional
requirements, such as reliability and security

2/25/2025 Software processes Page 39

Prototype development: example

2/25/2025 Software processes Page 40

 Throw-away prototype
 Prototypes should be discarded after development, as they are not a
suitable foundation for a production system

 It may be difficult or even impossible to optimize them to meet non-

functional requirements

 Prototypes are usually undocumented, and their structure often

deteriorates due to rapid changes

 Additionally, prototypes are unlikely to meet typical organization quality

standards

2/25/2025 Software processes Page 41

 Incremental delivery
 Instead of delivering the system in a single release, development and delivery
are divided into increments, with each increment delivering part of the
required functionality

 User requirements are prioritized with the highest- priority requirements

included in the early increments

 Once development of an increment begins, its requirements are frozen, while

requirements for later increments can continue to evolve

2/25/2025 Software processes Page 42

 Incremental development & delivery

 Incremental development

 Develop the system in increments, evaluating each increment before moving on

to the next

 The approach commonly used in agile methodology

 Evaluation is typically conducted by a user or customer proxy

 Incremental delivery

 Deploy each increment for end-user use, allowing for a more realistic evaluation
of the software’s practical application

2/25/2025 Software processes Page 43

 Incremental delivery of a system

2/25/2025 Software processes Page 44

 Incremental delivery advantages
 Customer value( features, functionalities, outcomes that are valuable) can
be delivered with each increment, making system functionality available
earlier

 Early increments serve as prototypes to help gather requirements for later

stages

 This approach reduces the overall risk of project failure

 The highest-priority system services usually undergo the most rigorous

testing

2/25/2025 Software processes Page 45

 Incremental delivery problems
 Most systems require a set of basic facilities that are used by different parts
of the system

 Since requirements are not defined in detail until an increment is to be

implemented, it can be difficult to identify the common facilities needed by
all increments

 The essence of iterative processes is that the specification is developed

alongside the software

 However, this conflicts with the procurement model of many organizations,

where the complete system specification is a part of the system
development contract

2/25/2025 Software processes Page 46

 Process improvement
 Many software companies have turned to software process improvement as a
way to enhance the quality of their software, reduce costs, or accelerate their
development processes

 Process improvement involves understanding existing processes and

modifying them to increase product quality and/or reduce costs and
development time

2/25/2025 Software processes Page 47

 Approach to improvement
 Process maturity in software development measures how well an
organization has implemented and refined its processes over time.

 The process maturity approach focuses on improving process and

project management, as well as introducing good software
engineering practices

2/25/2025 Software processes Page 48

 The process of improvement cycle

2/25/2025 Software processes Page 49

 Process improvement activities
 Process measurement
 You measure one or more attributes of the software process or product

 These measurements create a baseline that helps you determine if process

improvements have been effective

 Process analysis
 The current process is assessed, and process weakness and bottlenecks are
identified
 Process models that describe the process may be developed

 Process change
 Changes are made to address some of the identified process weakness

 These changes are implemented

 and the cycle resumes to collect data on the effectiveness of the changes

2/25/2025 Software processes Page 50

 Process measurement

 Whenever possible, quantitative process data should be collected

 However, if organizations don’t have clearly process standards, this

becomes very difficult, as it is unclear what should be measured

 Process measurements should be used to assess improvements in

processes, but this does not mean that measurements should
directly drive the improvements

 The primary driver of improvements should be the organization’s

objectives

2/25/2025 Software processes Page 51

 Maturity Model
Processes are optimized and
continuously improved

Processes are quantitatively

measured and managed

Processes are defined,

standardized, and documents

Basic processes are in place, but they

are not standardized or documented

processes are undefined or chaotic

2/25/2025 Software processes Page 52

The Rational Unified Process (RUP)

 a modern process model derived from the work on UML and associated processes
is typically described from 3 perspectives
 A dynamic perspective that shows phases over time
 A static perspective that show process activities
 A practice perspective that suggests good practices
RUP phases
 Inception
 Establish the business case
for the system

 Elaboration
 Develop an understanding
of the problem domain and
the system architecture

 Construction
 Design, program, and test
the system

 Transition
 Deploy the system into its
operating environment

2/25/2025 Software processes Page 54

 RUP good practice
 Develop software iteratively

 Manage requirements

 Use component-based architectures

 Visually model software

 Verify software quality

 Control changes to software

2/25/2025 Software processes Page 55

Static workflows
Workflow Description
Business modeling The business processes are modeled using business use cases
Requirements Actors who interact with the system are identified, and use cases are
developed to model the system’s requirements
Analysis and design A design model is created and documented using architectural models,
component models, object models, and sequence models
Implementation the components in the system are implemented and organized into sub-
systems. Automatic code generation from design models helps accelerate this
process
Test Testing is an iterative process that is conducted in parallel with implementation
Deployment A product release is created, distributed to users
Configuration and maintaining system stability and ensuring that changes are applied in a
change mgnt controlled and systematic way
Project management This supporting workflow manages the system development
Environment This workflow focuses on providing the appropriate software tools to the
software development team

2/25/2025 Software processes Page 56

 Computer-aided software engineering

 Computer-aided software engineering (CASE) is software to support software

development and evolution processes

 Activity automation

 Graphical editors for system model development

 Data dictionary to manage design entities

 Graphical UI builder for user interface construction

 Debuggers to support program fault finding

 Automated translators to generate new versions of a program

2/25/2025 Software processes Page 57

 CASE technology
 CASE technology had led to significant improvements in the software
process

 However, there are not the order of magnitude improvements that were once
predicted

 SE requires creative thought- this is not readily automated

 SE is a team activity

 For large projects, much time is spent in team interactions

 CASE technology does not really support these

2/25/2025 Software processes Page 58

 CASE classification
 Classification helps us understand the different types of CASE tools and their
support for process activities

 Functional perspective

 Tools are classified according to their specific function

 Process perspective

 Tools are classified according to process activities that are supported

 Integrated perspective

 Tools are classified according to their organization into integrated units

2/25/2025 Software processes Page 59

Functional tool classification
Tool type
Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems
Configuration management Version management system, system building tools
tools
Prototyping tools Very high-level languages, user interface generators
Method-support tools Design editors, data dictionaries, code generators
Language processing tools Compilers, interpreters
Program analysis tool Cross reference generators, static analyzers, dynamic analyzers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems

2/25/2025 Software processes Page 60

 Activity-based tool classification

2/25/2025 Software processes Page 61

 CASE integration
 Tools

 Support individual process tasks such as design consistency checking, text

editing, etc.

 Workbenches

 Support a process phase such as specification or design, normally include a

number of integrated tools

 Environments

 Support all of a substantial part of an entire software process

 Normally include several integrated workbenches

2/25/2025 Software processes Page 62

 Tools, workbenches, environments

2/25/2025 Software processes Page 63

 Key points
 Software processes are the activities involved in producing a software system
 Software process models are abstract representations of these processes

 General process models describe the organization of software processes

 Examples of these general models include the waterfall model, incremental
development, and reuse-oriented development

 Requirements engineering is the process of developing a software

specification

2/25/2025 Software processes Page 64

 Key points (cont)
 Design and implementation processes are concerned with transforming a
requirements specification into an executable software program

 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

 Processes should include activities such as prototyping and incremental

delivery to cope with changes

2/25/2025 Software processes Page 65

 Key points
 Processes may be structured for iterative development and delivery so that
changes may be made without disrupting the system as a whole

 The principal approaches to process improvements are agile approaches,

geared to reducing process overheads, and maturity-based approaches based
on better process management and then the use of good SE practice

 The SEI process maturity framework identifies maturity levels that essentially
correspond to the use of good SE practice

2/25/2025 Software processes Page 66