Process activities

30/10/2014 Chapter 2 Software Processes 1

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 of specification,
development, validation and evolution are organized
differently in different development processes.
 For example,
 waterfall model -> process activities are organized in sequence
 incremental development model -> interleaved.

30/10/2014 Chapter 2 Software Processes 2

The requirements engineering process

30/10/2014 Chapter 2 Software Processes 3

Software specification

 Its a 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
• Whether the requirement is valid or realistic?

30/10/2014 Chapter 2 Software Processes 4

Software design and implementation

 It’s a 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;
 design and implementation activities are closely related
and may be inter-leaved.
 Design may vary from system to system. As in real time
systems, database is not needed instead a timing
module is required to minimize delay, .
30/10/2014 Chapter 2 Software Processes 5
A general model of the design process

30/10/2014 Chapter 2 Software Processes 6

Design Inputs

 Inputs given to system.

 That could be any platform related information like OS ,
middleware. And any other application systems if
needed.
 Data descriptions include the data that is to be entered
to the system. What could be the appropriate form and
so on.
 All the specifications mentioned in requirements
elicitation phase are the requirements here i.e. the
ultimate functional requirements of software.

30/10/2014 Chapter 2 Software Processes 7

Design activities

 Architectural design
 identify the overall structure of the system,
 the principal components (subsystems or modules), their
relationships and how they are distributed.
 Database design
 design the system data structures
 how these are to be represented in a database.

30/10/2014 Chapter 2 Software Processes 8

Design activities

 Interface design
 define the interfaces between system components.
 Must encapsulate all the complexities
 Should be user friendly

 Component selection and design,

 you search for reusable components.
 If unavailable, then you design the component from scratch.
 Includes the list of changes to be done in the off the shelf
component
 or the proper technical UML diagram (if you are deigning from
scratch)
30/10/2014 Chapter 2 Software Processes 9
System implementation

 The software is implemented either by developing a program or

programs or by configuring an application system depending upon the
scale of software application.
 Design and implementation are interleaved activities for most types of
software system.
 Programming is an individual activity with no standard process. (e.g.,
variable definition) ~ depends on programmer feasibility.
 Debugging is the activity of finding program faults and correcting these
faults.

30/10/2014 Chapter 2 Software Processes 10

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.
 Alpha testing: testing & reviewing by the development
staff
 Beta testing: testing & reviewing by the real time user
30/10/2014 Chapter 2 Software Processes 11
Stages of testing

30/10/2014 Chapter 2 Software Processes 12

Testing stages

 Component testing
 Component tested by developers working on the system.
 Individual components are tested independently;
 Components may be functions or objects or coherent groupings of these entities.
 Test automation tools like Junit for java, Ponicode (VS Code plugin) for JS or python could be used
for unit/component testing.
 System testing
 Testing of the system as a whole.
 Testing of errors after different module interaction.
 In large systems multiple subsystems are integrated first and then on whole integrated as
a final system.

30/10/2014 Chapter 2 Software Processes 13

Testing stages

Customer testing
 Beta testing
 Testing with customer data to check that the system meets the
customer’s needs.
 It might reveal error in software requirements omission if any.

30/10/2014 Chapter 2 Software Processes 14

Testing phases in a plan-driven software process (V-model)

30/10/2014 Chapter 2 Software Processes 15

Software evolution

 Hardware changes are very expensive, as compare to that software is

inherently flexible and can be modified to larger & complex systems.
 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.

30/10/2014 Chapter 2 Software Processes 16

System evolution

30/10/2014 Chapter 2 Software Processes 17

 Coping with change

30/10/2014 Chapter 2 Software Processes 18

Coping with change

 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 :
 costs of change = cost of rework (analyzing previous req.)
+ cost of implementing new module

30/10/2014 Chapter 2 Software Processes 19

Reducing the costs of rework

 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. So that after
experiencing it they may modify their requirements if needed.
 Change tolerance, where the process is designed so that
changes can be accommodated at relatively low cost.
 Can be practiced using incremental development. Proposed
changes may be implemented in increments that have not yet
been developed.

30/10/2014 Chapter 2 Software Processes 20

Coping with changing requirements

 To make the road to these changes more smooth, there are two ideas given
below:
 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.
 Incremental delivery, where system increments are delivered to the
customer for comment and experimentation. This supports both change
avoidance and change tolerance.

30/10/2014 Chapter 2 Software Processes 21