The software process

COMSATS University Islamabad

 A structured set of activities required to develop a

software system.
 Many different software processes but all involve:
Chapter 2 – Software Processes
▪ Specification – defining what the system should do;
▪ Design and implementation – defining the organization of the
system and implementing the system; Lecture 2
▪ Validation – checking that it does what the customer wants;
▪ Evolution – changing the system in response to changing
customer needs. Dr. Mahmood Qureshi Hashmi
 A software process model is an abstract representation Assistant Professor
of a process. It presents a description of a process from
some particular perspective.
Chapter 2 Software Processes 3 Department of Electrical & Computer Engineering

Software process descriptions Topics covered

 When we describe and discuss processes, we usually  Software process models

talk about the activities in these processes such as
 Process activities
specifying a data model, designing a user interface, etc.
and the ordering of these activities.  Coping with change
 The Rational Unified Process
▪ An example of a modern software process.

Chapter 2 Software Processes 4 Chapter 2 Software Processes 2

1.1 The waterfall model
Plan-driven and agile processes

 Plan-driven processes are processes where all of the

process activities are planned in advance and progress
is measured against this plan.
 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 approaches.
 There are no right or wrong software processes.

Chapter 2 Software Processes 7 Chapter 2 Software Processes 5

Waterfall model phases 1. Software process models

 There are separate identified phases in the waterfall  The waterfall model
model: ▪ Plan-driven model. Separate and distinct phases of specification
▪ Requirements analysis and definition (system services, constraints and development.
and goals)
 Incremental development
▪ System and software design (h/w or s/w ?)
▪ Specification, development and validation are interleaved. May
▪ Implementation and unit testing (each units meets its specification?) be plan-driven or agile.
▪ Integration and system testing
 Reuse-oriented software engineering
▪ Operation and maintenance (longest life cycle phase, correcting errors)
▪ The system is assembled from existing components. May be
 The main drawback of the waterfall model is the difficulty plan-driven or agile.
of accommodating change after the process is
underway. In principle, a phase has to be complete
before moving onto the next phase.
Chapter 2 Software Processes 8 Chapter 2 Software Processes 6
Incremental development benefits Waterfall model problems

 The cost of accommodating changing customer  Inflexible partitioning of the project into distinct stages
requirements is reduced. makes it difficult to respond to changing customer
▪ The amount of analysis and documentation that has to be requirements.
redone is much less than is required with the waterfall model. ▪ Therefore, this model is only appropriate when the requirements
 It is easier to get customer feedback on the development are well-understood and changes will be fairly limited during the
design process.
work that has been done.
▪ Few business systems have stable requirements.
▪ Customers can comment on demonstrations of the software and
see how much has been implemented.  The waterfall model is mostly used for large systems
engineering projects where a system is developed at
 More rapid delivery and deployment of useful software to
several sites.
the customer is possible.
▪ In those circumstances, the plan-driven nature of the waterfall
▪ Customers are able to use and gain value from the software
model helps coordinate the work.
earlier than is possible with a waterfall process.
Chapter 2 Software Processes 11 Chapter 2 Software Processes 9

1.2 Incremental development

Incremental development problems

 The process is not visible.

▪ Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
 System structure tends to degrade as new increments
are added.
▪ Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.
Incremental development is based on the idea of developing an initial
implementation, exposing this to user comment and evolving it through several
versions until an adequate system has been developed.

Chapter 2 Software Processes 12 Chapter 2 Software Processes 10

2.1. Software specification 1.3 Reuse-oriented software engineering

 The process of establishing what services are required  Based on systematic reuse where systems are
and the constraints on the system’s operation and integrated from existing components
development.
 Process stages
 Requirements engineering process
▪ Feasibility study
• Is it technically and financially feasible to build the system?
▪ Requirements induction and analysis
• What do the system stakeholders require or expect from the system?
▪ Requirements specification
• Defining the requirements in detail  Reuse is now the standard approach for building many
▪ Requirements validation types of business system
• Checking the validity of the requirements ▪ Reuse covered in more depth in Chapter 16.
Chapter 2 Software Processes 15 Chapter 2 Software Processes 13

The requirements engineering process

2. Process activities

 Software development involves a mix of technical work,

teamwork, and managing tasks. The main goal is to create,
design, build, and test a software system. There are four key
steps:
1. Specification: Figuring out what the software should do.
2. Design & Implementation: Planning and building the
software.
3. Validation: Checking if the software works correctly.
4. Evolution: Making changes and improvements over time.

Chapter 2 Software Processes 16 Chapter 2 Software Processes 14

2.4. Software evolution 2.2. Software design and implementation

 Software is inherently flexible and can change.  The process of converting the system specification into
an executable system.
 Software must evolve with changing business needs.
 Software design
▪ Design a software structure that realises the specification;
 Implementation
▪ Translate this structure into an executable program;
 The activities of design and implementation are closely
related and may be inter-leaved.

Chapter 2 Software Processes 19 Chapter 2 Software Processes 17

System evolution 2.3. 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.
 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.

Chapter 2 Software Processes 20 Chapter 2 Software Processes 18

Prototype development 3. Coping with change

 May be based on rapid prototyping languages or tools  Change is inevitable in all large software projects.
 May involve leaving out functionality ▪ Business changes lead to new and changed system
requirements
▪ Prototype should focus on areas of the product that are not well-
▪ New technologies open up new possibilities for improving
understood;
implementations
▪ Error checking and recovery may not be included in the
▪ Changing platforms require application changes
prototype;
▪ Focus on functional rather than non-functional requirements  Change leads to rework so the costs of change include
such as reliability and security both rework (e.g. re-analysing requirements) as well as
the costs of implementing new functionality

Chapter 2 Software Processes 23 Chapter 2 Software Processes 21

3.2 Incremental delivery 3.1 Software prototyping

 Rather than deliver the system as a single delivery, the  A prototype is an initial version of a system used to
development and delivery is broken down into demonstrate concepts and try out design options.
increments with each increment delivering part of the
 Benefits of Prototyping
required functionality.
▪ Improved system usability
 Instead of giving the whole software at once, we make it ▪ A closer match to users’ real needs
in smaller parts. We start with the most important parts ▪ Improved design quality
first. Once we start working on a part, we don't change ▪ Improved maintainability
its plan, but we can still plan for future parts. ▪ Reduced development effort

Chapter 2 Software Processes 24 Chapter 2 Software Processes 22

Incremental delivery problems Incremental delivery

 As requirements are not defined in detail until an

increment is to be implemented, it can be hard to identify
common facilities that are needed by all increments.
 The key idea of making software in steps is that we
figure out what it should do while we build it.
▪ But some companies want to know everything about the
software before they start, which can be tricky when working
together.

Chapter 2 Software Processes 27 Chapter 2 Software Processes 25

3.3 Boehm’s spiral model Incremental delivery advantages

 Boehm's spiral model is a way to develop software by  Customer value can be delivered with each increment so
going through cycles, like a spiral. system functionality is available earlier.
 Each cycle involves planning, risk analysis, engineering,  Early increments act as a prototype to help elicit
and evaluation. This helps manage risks and improve requirements for later increments.
the software step by step.
 Lower risk of overall project failure.
 The highest priority system services tend to receive the
most testing.

Chapter 2 Software Processes 28 Chapter 2 Software Processes 26

4.0 The Rational Unified Process Boehm’s spiral model of the software process

 Rational Unified Process (RUP) is a software

engineering process framework that provides a set of
best practices and guidelines for developing high-quality
software systems.
 There are Four Steps in RUP Process

Chapter 2 Software Processes 31 Chapter 2 Software Processes 29

RUP phases Spiral model sectors

 Inception: To define the project's goals and identify the  Planning

requirements for the system. ▪ Specific objectives for the phase are identified and the project is
reviewed.
 Elaboration: To define the system's architecture and
design, and to establish a plan for the development of  Risk Analysis
the system. ▪ Risks are assessed and activities are put in place to reduce the
key risks.
 Construction: To develop the software system and to
ensure that it meets the requirements.  Engineering
▪ A development model for the system is chosen, which can be
 Transition: To deploy the system and ensure that it is any of the generic models. (waterfall, agile or incremental)
working correctly.
 Evaluation
▪ The project is reviewed and the next phase of the spiral is
planned.
Chapter 2 Software Processes 32 Chapter 2 Software Processes 30
RUP Example (E-Commerce System) (1/2)

 Inception: Gather information about the project, such as

the requirements and goals of the website.
▪ The team might determine that the website should allow
customers to browse products, add them to a cart, and checkout
with a payment processor.
 Elaboration: Create a use case model for the website,
outlining how different users would interact with the site.
▪ The team might create a use case for how a customer adds a
product to their cart and a functional specification for how the
product catalog should be displayed.

Chapter 2 Software Processes 33

RUP Example (E-Commerce System) (2/2)

 Construction: Develop the code for the website based on

the architecture and design.
▪ The team might develop the code for the product catalog and
implement the payment processing system.
 Transition: Deploy the website to a production
environment and perform user acceptance testing.
▪ The team might deploy the website to a server and perform
testing to ensure the payment processing is working correctly.

Chapter 2 Software Processes 34