1

Chapter 2 –
Software
Processes
Topics covered 2

 Software process models

 Process activities
 Coping with change
 Process improvement
The software process 3
 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.
Software process descriptions 4
 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.
 Plan-driven and agile processes 5

 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.
 Inpractice, most practical processes include elements of
both plan-driven and agile approaches.
 There are no right or wrong software processes.
 6

Software process models

Software process models 7
 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.
 Integration and configuration
 The system is assembled from existing configurable 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.
The waterfall model 8
Waterfall model phases 9
 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 completed before moving
on to the next phase.
Waterfall model problems 10
 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.

11
The sequential phases in Waterfall model are −
1. Requirement Gathering and analysis −
 All possible requirements of the system to be developed are captured in this phase and
documented in a requirement specification document.
2. System Design −
 The requirement specifications from first phase are studied in this phase and the system
design is prepared.
 This system design helps in specifying hardware and system requirements and helps in
defining the overall system architecture.
3. Implementation −
 With inputs from the system design, the system is first developed in small programs
called units, which are integrated in the next phase.
 Each unit is developed and tested for its functionality, which is referred to as Unit
Testing.
4. Integration and Testing − 12
 All the units developed in the implementation phase are integrated into a
system after testing of each unit.
 Post integration the entire system is tested for any faults and failures.

5. Deployment of system −
 Once the functional and non-functional testing is done; the product is deployed
in the customer environment or released into the market.

6. Maintenance −
 There are some issues which come up in the client environment. To fix those
issues, patches are released.
 Also to enhance the product some better versions are released. Maintenance
is done to deliver these changes in the customer environment.
Waterfall Model - Application 13

 Every software developed is different and requires a suitable SDLC

approach to be followed based on the internal and external factors.
Some situations where the use of Waterfall model is most
appropriate are −
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the
product.
 The project is short.
Waterfall Model - Advantages 14
 Some of the major advantages of the Waterfall Model are as
follows −
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well
understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.
 Waterfall Model - 15

Disadvantages
The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.
Incremental development 16
Incremental development benefits 17
 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 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.
Incremental development problems 18
 The process is not visible.
 Managersneed 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.
 Systemstructure 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.
Integration and configuration 19
 Basedon software reuse where systems are integrated
from existing components or application systems
(sometimes called COTS -Commercial-off-the-shelf)
systems).
 Reusedelements may be configured to adapt their
behaviour and functionality to a user’s requirements
 Reuseis now the standard approach for building many
types of business system
Types of reusable software 20

 Stand-alone application systems (sometimes called COTS)

that are configured for use in a particular environment.
 Collections
of objects that are developed as a package to
be integrated with a component framework such as .NET
or J2EE.
 Web services that are developed according to service
standards and which are available for remote invocation.
Reuse-oriented software 21

engineering
Key process stages 22

 Requirements specification
 Software discovery and evaluation
 Requirements refinement
 Application system configuration
 Component adaptation and integration
Advantages and disadvantages 23

 Reduced costs and risks as less software is developed

from scratch
 Faster delivery and deployment of system
 But
requirements compromises are inevitable so system
may not meet real needs of users
 Loss
of control over evolution of reused system
elements
 24

Process activities
Process activities 25

 Realsoftware 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 of specification,
development, validation and evolution are organized
differently in different development processes.
 Forexample, in the waterfall model, they are organized in
sequence, whereas in incremental development they are
interleaved.
The requirements engineering 26

process
Software specification 27
 The process of establishing what services are required and the
constraints on the system’s operation and development.
 Requirements engineering process
 Requirements elicitation and analysis
 What do the system stakeholders require or expect from the system?
 Requirements specification
 Defining the requirements in detail
 Requirements validation
 Checking the validity of the requirements
Software design and 28
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;
 Theactivities of design and implementation are
closely related and may be inter-leaved.
A general model of the design process 29
Design activities 30
 Architectural design, where you identify the overall structure of the
system, the principal components (subsystems or modules), their
relationships and how they are distributed.
 Database design, where you design the system data structures and
how these are to be represented in a database.
 Interface design, where you define the interfaces between system
components.
 Component selection and design, where you search for reusable
components. If unavailable, you design how it will operate.
System implementation 31

 Thesoftware is implemented either by developing a

program or programs or by configuring an application
system.
 Designand implementation are interleaved activities for
most types of software system.
 Programming is an individual activity with no standard
process.
 Debugging is the activity of finding program faults and
correcting these faults.
Software validation 32

 Verificationand 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.
Stages of testing 33
Testing stages 34

 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.
 Customer testing
 Testing with customer data to check that the system meets the customer’s
needs.
Testing phases in a plan-driven 35

software process (V-model)

Software evolution 36
 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.
 Althoughthere has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems are
completely new.
System evolution 37
 38

Coping with change

 Coping with change 39

 Change is inevitable in all large software projects.

 Business changes lead to new and changed system requirements
 New technologies open up new possibilities for improving implementations
 Changing platforms require application changes
 Change leads to rework so the costs of change include both rework (e.g. re-
analysing requirements) as well as the costs of implementing new functionality
Reducing the costs of rework 40

 Change anticipation, where the software process includes activities that can
anticipate possible changes before significant rework is required.
 For example, a prototype system may be developed to show some key features of
the system to customers.
 Change tolerance, where the process is designed so that changes can be
accommodated at relatively low cost.
 This normally involves some form of incremental development. Proposed changes
may be implemented in increments that have not yet been developed. If this is
impossible, then only a single increment (a small part of the system) may have be
altered to incorporate the change.
 Coping with changing 41

requirements
1. System prototyping,
 where a version of the system or part of the system is developed quickly to check
the customer’s requirements and the feasibility of design decisions.
 This approach supports change anticipation.
2. Incremental delivery,
 where system increments are delivered to the customer for comment and
experimentation.
 This supports both change avoidance and change tolerance.
Software prototyping 42

 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.
Benefits of prototyping 43

 Improved system usability.

 A closer match to users’ real needs.
 Improved design quality.
 Improved maintainability.
 Reduced development effort.
The process of prototype 44

development
Prototype development 45

 May be 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
Throw-away prototypes 46

 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 organisational quality
standards.
Incremental delivery 47

 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.
Incremental development and 48

delivery
 Incremental development
 Develop the system in increments and evaluate each increment
before proceeding to the development of the next increment;
 Normal approach used in agile methods;
 Evaluation done by user/customer .
 Incremental delivery
 Deploy an increment for use by end-users;
 More realistic evaluation about practical use of software;
 Difficult to implement for replacement systems as increments have
less functionality than the system being replaced.
Incremental delivery 49
Incremental delivery advantages 50

 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.
Incremental delivery problems 51

 Most systems require a set of basic facilities that are used by different parts
of the system.
 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 essence of iterative processes is that the specification is developed in
conjunction with the software.
 However, this conflicts with the procurement model of many organizations, where
the complete system specification is part of the system development contract.
 52

Process improvement
Process improvement 53

 Many software companies have turned to software process improvement as a

way of enhancing the quality of their software, reducing costs or accelerating
their development processes.
 Process improvement means understanding existing processes and changing
these processes to increase product quality and/or reduce costs and
development time.
Approaches to improvement 54

 The process maturity approach, which focuses on improving process and project
management and introducing good software engineering practice.
 The level of process maturity reflects the extent to which good technical and
management practice has been adopted in organizational software development
processes.
 The agile approach, which focuses on iterative development and the reduction
of overheads in the software process.
 The primary characteristics of agile methods are rapid delivery of functionality and
responsiveness to changing customer requirements.
The process improvement cycle 55
Process improvement activities 56

 Process measurement
 You measure one or more attributes of the software process or product.
 These measurements forms a baseline that helps you decide if process
improvements have been effective.
 Process analysis
 The current process is assessed, and process weaknesses and bottlenecks are
identified.
 Process models (sometimes called process maps) that describe the process may
be developed.
 Process change
 Process changes are proposed to address some of the identified process
weaknesses.
 These are introduced and the cycle resumes to collect data about the
effectiveness of the changes.
Process measurement 57
 Wherever possible, quantitative process data should be collected
 However, where organisations do not have clearly defined process standards
this is very difficult as you don’t know what to measure.
 A process may have to be defined before any measurement is possible.
 Process measurements should be used to assess process
improvements
 But this does not mean that measurements should drive the improvements.
 The improvement driver should be the organizational objectives.
Process metrics 58
 Time taken for process activities to be completed
 E.g. Calendar time or effort to complete an activity or process.
 Resources required for processes or activities
 E.g. Total effort in person-days.
 Number of occurrences of a particular event
 E.g. Number of defects discovered.
Capability maturity levels 59
The SEI capability maturity model 60
 Initial
 Essentially uncontrolled
 Repeatable
 Product management procedures defined and used
 Defined
 Process management procedures and strategies defined
and used
 Managed
 Quality management strategies defined and used
 Optimising
 Process improvement strategies defined and used