Lecture 2

Software Processes

Chapter 2 Software Processes 1

The Software Process
 A software process is a structured set of activities
required to develop a software system.
 Many different software processes but all involve:
 Specification
 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.

Chapter 2 Software Processes 2

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.

Chapter 2 Software Processes 3

Plan-driven Process Vs. Agile Process
 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 4

Software Process Models
 The waterfall model
 Plan-driven model. Separate and distinct phases of
specification and development.
 Incremental development
 Specification, development and validation are
interleaved. May be plan-driven or agile.
 Reuse-oriented software engineering
 The system is assembled from existing components.
May be plan-driven or agile.
 In practice, most large systems are developed using a
process that incorporates elements from all of these
models.
Chapter 2 Software Processes 5
Waterfall Model Phases
 There are separate identified phases in 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.

Chapter 2 Software Processes 6

Figure 1: The waterfall model
Chapter 2 Software Processes 7
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.

Chapter 2 Software Processes 8

Incremental development
 In incremental development, the cost of accommodating
changing customer requirements is reduced.
 The amount of analysis and documentation that has to be
redone is much less than is required with the waterfall model.
 It is also easier to get customer feedback on the
development work that has been done.
 Customers can comment on demonstrations of the software
and see how much has been implemented.
 More rapid delivery and deployment of useful software
to the customer is possible.
 Customers are able to use and gain value from the software
earlier than is possible with a waterfall process.

Chapter 2 Software Processes 9

Figure 2: Incremental development

Chapter 2 Software Processes 10

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.

Chapter 2 Software Processes 11

Reuse-oriented Software Engineering
 Based on systematic reuse where systems are
integrated from existing components or COTS
(COMMERCIAL-OFF-THE-SHELF) systems.
 Process stages
 Component analysis;
 Requirements modification;
 System design with reuse;
 Development and integration.
 Reuse is now the standard approach for building many
types of business system.

Chapter 2 Software Processes 12

Figure 3: Reuse-oriented software engineering

Chapter 2 Software Processes 13

Software Specification
 The process of establishing what services are required
on the system’s operation and development.
 Requirements engineering process
 Feasibility study
• Is it technically and financially feasible to build the system?
 Requirements elicitation and analysis
• What do the system stakeholders require or expect from the
system?
 Requirements specification
• Defining the requirements in detail – User requirement , System
Requirement
 Requirements validation
• Checking the validity of the requirements for realism, consistency
and completeness
Chapter 2 Software Processes 14
Figure 4: Requirements Engineering Process

Chapter 2 Software Processes 15

Software Design and Implementation
 The process of converting the system specification into
an executable system.
 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 16

Figure 5: A general model of the design process
Chapter 2 Software Processes 17
Design Activities
 Architectural design, where you identify the overall
structure of the system, the principal components
(sometimes called sub-systems or modules), their
relationships and how they are distributed.
 Interface design, where you define the interfaces
between system components.
 Component design, where you take each system
component and design how it will operate.
 Database design, where you design the system data
structures and how these are to be represented in a
database.

Chapter 2 Software Processes 18

Software Validation
 Verification and Validation (V & V) is intended to show that
a system conforms to its specification and meets the
requirements of the customer. It involves checking and
review processes and overall 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.

Figure 6
Stages of testing

Chapter 2 Software Processes 19

Testing Stages
 Development or component 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.

Chapter 2 Software Processes 20

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.

Figure 7: system evolution

Chapter 2 Software Processes 21

Software Prototyping
 A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
 A prototype can be used in:
 The requirements engineering process to help with
requirements elicitation and validation;
 In design processes to explore options and develop a
UI design;
 In the testing process to run back-to-back tests.

Chapter 2 Software Processes 22

The process of prototype development

Chapter 2 Software Processes 23

Prototype Development
 Based on rapid prototyping languages or tools
 May involve leaving out functionality
 Prototype should focus on areas of the product that
are not well-understood;
 Error checking and recovery may not be included in
the prototype;
 Focus on functional rather than non-functional
requirements such as reliability and security

Chapter 2 Software Processes 24

Benefits of Prototyping
 Improved system usability.
 A closer match to users’ real needs.
 Improved design quality.
 Improved maintainability.
 Reduced development effort.

Chapter 2 Software Processes 25

Throw-away Prototypes
 Prototypes should be discarded after development
as they are not a good basis for a production
system:
 It may be impossible to tune the system to meet non-
functional requirements;
 Prototypes are normally undocumented;
 The prototype structure is usually degraded through
rapid change;
 The prototype probably will not meet normal
organizational quality standards.

Chapter 2 Software Processes 26

Any Questions??

Chapter 2 Software Processes 27

 You can start now to change the ending.


Chapter 2 Software Processes 28