CS1SE16 SOFTWARE PROCESSES

Introduction
Process models are abstract representations of software process – they don't contain all the small
details.
There are many different processes but all include:
Specification – defining what the system should do
Design and implementation – defining the organization of the system and implementing it
Validation – checking that it does what the customer wants
Evolution – changing the system in response to changing customer needs
A step that is often forgotten is decommission – getting rid of the system when it's no longer needed – a
system is likely to contain a lot of personal data that must be disposed of in appropriate way

Software process description

Description of a software process is usually concerned with activities and data. It may also include:
Products – outcomes of the process activities
Roles – responsibilities of the people involved
Pre and post conditions

In a plan driven process everything is organized upfront and the progress is measured against the plan.
In agile process planning is incremental and it is easier to change to reflect the changing needs. In
practice, most processes involve a mixture of both approaches. People have preferences but usually as
long as the process works, it is not a wrong one.

Process models
Main process models are:
Waterfall model:
 Plan-driven – everything is planned in advance
 Separate phases – you move to the next step after the previous one is completed
 Not a very good way but used by some companies
Incremental delivery
 Can be plan-driven or agile
 Specification, development and validation are interleaved
Integration and configuration
 The system is assembled from existing configurable elements
 Can be plan-driven or agile

Waterfall model
Characteristics:
 Difficult to accommodate change after the process is underway
 Works best with software that has stable requirements
 Good for big and complicated systems, but not the only way to develop them (Linux was
developed using agile)

Process model:
Incremental delivery

Characteristics:
 Starts with a rough
description of the system
and builds on that
 Specification, development
and validation happen at the
same time
 The cost of change is
reduced – fewer things will
require to be changed
 Customers get something
useful as early as possible – it's also easier to get feedback in this way
 Problems:
 Process is not visible – managers like to know what the team is doing
 System structure tends to degrade as you add things

Integration and configuration

The system is integrated from existing components that are configured to adapt to the requirements
Standard approach for many business systems
Types of reusable software:
  Stand-alone application systems 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
 Web services that are developed according to service standards and which are available for
remote invocation
 Advantages:
o Reduced cost and risks as less software is developed
o Faster delivery
 Disadvantages:
o There is always some requirement compromise
o Loss of control over evolution of reused system elements

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 basic process activities are organized differently in different development processes.

Software specification – establishing what services are required and the constraints on the system's
operations and development

Software design and implementation

 Design – coming up with a
structure that realized the
specification
 Implementation – translating
the structure into a program
Activities of design and
implementation are closely related and
may be interleaved

A general model of the design process:

Architectural design – identifying the overall

structure of a system, the principal components,
their relationships and how they are distributed
Database design – designing the system data
structures
Interface design – defining the interfaces between
system's components
Components selection and design – a search for
reusable components
Software validation – intended to show that a system conforms to its specifications and meets the
requirements of the customer. Involves checking and review processes and system testing
Stages of testing

Testing phases in V-model:

Software evolution – as requirements change through changing business circumstance, the software
supporting the business must also evolve and change.

There is increasingly less difference between software evolution and developing the new software

Coping with change

Change is inevitable in all large projects:

o Businesses change
o New technologies emerge
o Platforms change
Change causes the need to rework – the cost of rework depends on how far back you have to
go
Ways of reducing the costs of change:
 Change anticipation – if a software is well designed it is easier to change and maintain
  Change tolerance – designing the process so that changes can be accommodated at low cost –
usually involves some form of incremental delivery

Coping with changing requirements:
o System prototyping
o Incremental delivery

A prototype is an initial version of a system used to demonstrate concepts and try out design options.
Benefits of prototyping:
 Improved system usability
 Better match to users' needs
 Improved design quality
 Improved maintainability
 Reduced development effort – but only if you don't throw the prototype away as you should
when it is no longer needed
Prototype development:
 May be based on rapid prototyping languages (e.g. visual basic)
 May involve leaving out functionality – focus on individual bits
 Often don't have error checking and recovery
 Focus on functional requirements but reliability and security are also good to test in prototype
Prototypes should be discarded after development (but often that doesn't happen) because:
 They're not good basis for production
 It may be impossible to meet non-functional requirements
 Normally they have no associated documentation
 They don't usually meet organizational coding standards

Prototyping allows you to create good quality products quickly with conjunction with customers.

Incremental delivery
 Development and delivery broken down into increments
 Highest priority requirements included in early increments
 Early increments act as prototypes to help elicit requirements for later increments
 Functionality available earlier

Process improvement
Process improvement means understanding existing processes and changing these processes to
increase product quality and/or reduce costs and development time. You need to understand what
already exists and whether change will improve it.
Enhancing quality, reducing costs or accelerating development process are ways of improvement.
Process maturity focuses on improving process and project management and introduce good
software engineering practice

Process metrics:
 Time taken for process activities to be
completed
 Resources required
 Number of occurrences of particular event

Summary
 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 delivery and reuse-oriented
development.
 Requirements engineering is the process of developing a software specification. Specifications
are intended to communicate the system needs of the customer to the system developers.
 Design and implementation processes are concerned with transforming a requirements
specification into an executable software system. Systematic design methods may be used as
part of this transformation.
 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. Changes are continuous and the software must evolve to remain useful.
 Processes should involve activities to cope with change. This may involve a prototyping phases
that helps avoid poor decisions on requirements and design. Processes may be structured for
iterative development and delivery so that changes may be made without disrupting the system
as a whole.