Software Processes

The software process

 A structured set of activities required to develop a
software system.
 Many different software processes but all involve:
 Specification –The functionality of the software and
constraints on its operation must be defined.
 Design and implementation – The software to meet
the specification must be produced
 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
 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; e.g.
model of software architecture
 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.
 Pre-condition- before architectural design begins, a pre-
condition may be that all requirements have been approved by
the customer.
 Post condition- after this activity is finished, a post-condition
might be that the UML models describing the architecture have
been reviewed.
 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.
 There are no right or wrong software
processes.
 Plan-driven and agile processes
Plan-driven methods Agile methods
High criticality Low criticality
Junior developers Senior developers
Requirements do not change
Requirements change often
often
Large number of developers Small number of developers
Culture that responds to
Culture that demands order
change
 Software process models
 The waterfall model
 Plan-driven model. Activities are planned in advance
and progress is measured against plan
 Incremental development
 Specification, development and validation are
interleaved.
 System is developed as a series of versions
(increments)
 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.
The Waterfall Model
 The waterfall model is an example of a
plan-driven process—in principle, you
must plan and schedule all of the
process activities before starting work
on them.
 The waterfall model
System services, constraints and goals are established
allocates the requirements to either hardware or
software, identify and describe the fundamental
software system abstractions and their
relationships
software design is realized
as a set of programs or
program units

The individual program units or

programs
are integrated and tested as a
complete system
The system is installed and put into practical use.
Maintenance involves correcting errors, improving the
implementation and enhancing system with new
requirements
 Waterfall model problems
 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 onto the next phase.
 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.
Incremental Development
 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.
 Specification, development, and validation activities
are interleaved rather than separate, with rapid
feedback across activities.
 Each increment or version of the system incorporates
some of the functionality that is needed by the
customer. Generally, the early increments of the
system include the most important or most urgently
required functionality.
Incremental development
 Incremental development benefits
 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
 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.
 Reuse-oriented software engineering
 Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems. e.g., Word
processor
 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
 Reuse-oriented software engineering
Component analysis: a search is made for components to
implement that specification. Usually, there is no exact match
Requirements modification the requirements are analyzed using
information about the components that have been discovered. They are
then modified

System design with reuse: Framework of the system is designed, or an

existing framework is reused by taking into account the components that are
reused. if reusable components not available, some new software may have to be
designed
Development and integration Software that cannot be externally
procured is
developed, and the components and COTS systems are integrated to
create the
new system.
Types of software component
that may be used in a reuse-
oriented process:
 Web services that are developed according to
service standards and which are available for
remote invocation.
 Collections of objects that are developed as a
package to be integrated with a component
framework.
 Stand-alone software systems (COTS) that
are configured for use in a particular
environment.
Reuse-oriented SE: Pros and
cons
 Reduce the amount of software to be developed and
so reducing cost and risks
 It usually also leads to faster delivery of the software.
 Requirements compromises are inevitable, and this
may lead to a system that does not meet the real
needs of users
 Some control over the system evolution is lost as
new versions of the reusable components are not
under the control of the organization using them.
Software Process activities
 Real software processes are 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. In the waterfall model, they are organized
in sequence, whereas in incremental development
they are inter-leaved.
Feasibility Software specification
study

 Software specification or requirements engineering is the process of

understanding and defining what services are required from the system
and identifying the constraints on the system’s operation and
development.
and analysis

Requirements engineering process

Req Elicit

 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?

This may involve the development of one or more system models and
Specification

prototypes. These help you understand the system to be specified

 Requirements specification
Req

 Defining the requirements in detail. User requirements are abstract

statements of the system requirements for the customer and end-user

of the system; system requirements are a more detailed description of
the functionality to be provided.
 Requirements validation
Validation

 Checking the requirements for consistency and completeness. During

Req

this process, errors in the requirements document are inevitably

discovered.
The requirements engineering process
 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; Designers do not arrive at a finished
design immediately but develop the design iteratively.
 Implementation
 Translate this structure into an executable program;
 The activities of design and implementation are closely
related and may be inter-leaved.
A general model of the design process
Design inputs
Platform Information
 the environment in which the software will execute. Information

about this platform is an essential input to the design process,

as designers must decide how best to integrate it with the
software’s environment.
Requirement Specification
 The requirements specification is a description of the

functionality the software must provide and its performance and

dependability requirements.
Data Description
 If the system is to process existing data, then the description of

that data may be included in the platform specification;

otherwise, the data description must be an input to the design
process so that the system data organization to be defined.
 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.
Design activities

Interface design, where you define the interfaces between system

components.

Component design, where you take each system component and

design how it will operate. This may be a simple statement of the
expected functionality to be implemented or may be a list of changes
to be made to a reusable component or a detailed design model.

Database design, where you design the system data structures and
how these are to be represented in a database. Again, the work here
depends on whether an existing database is to be reused or a new
database is to be created.
 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.
Stages of testing
 Testing stages
 Development or component testing
 The components making up the system are tested by the people developing the
system.
 Individual components are tested independently;
 Test automation tools, such as JUnit that can re-run component tests when new
versions of the component are created, are commonly used.
 System testing
 Testing of the system as a whole.
 Finding errors that result from unexpected interactions between components and
component interface problems.
 Acceptance testing/alpha testing
 Testing with customer data to check that the system meets the customer’s needs.
 Beta testing
 When a system is to be marketed as a software product, a testing process called
‘beta testing’ is often used. Beta testing involves delivering a system to several
potential customers who agree to use that system. They report problems to the
system developers. This exposes the product to real use and detects errors that
may not have been anticipated by the system builders. After this feedback, the
system is modified and released either for further beta testing or for general sale.
Testing phases in a plan-driven software
process
 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.
 Although there has been a differentiation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems
are completely new.
System evolution
Key points
 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
development, and reuse-oriented
development.
 Key points
 Requirements engineering is the process of
developing a software specification.
 Design and implementation processes are concerned
with transforming a requirements specification into an
executable software system.
 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.
The software must evolve to remain useful.
Coping with change
 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.
 Therefore, whatever software process model is used, it is
essential that it can accommodate changes to the software
being developed.
 Change adds to the costs of software development
because it usually means that work that has been
completed has to be redone. This is called rework.
 Change leads to rework so the costs of change include
both rework (e.g., re-analyzing requirements) as well as
the costs of implementing new functionality.
 Reducing the costs of rework
 Change avoidance, 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.
 This supports change avoidance as it allows users to
experiment with the system before delivery and so
refine their requirements.
 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.
Two ways of coping with change
and changing system
requirements.
 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 some design decisions.
 Incremental delivery, where system
increments are delivered to the customer for
comment and experimentation.
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;
Benefits of prototyping
 Improved system usability.
 A closer match to users’ real needs.
 Improved design quality
 Improved maintainability.
 Reduced development effort.
 The process of prototype development

Objectives: (1) To develop a system to prototype the user

interface, (2) To develop a system to validate functional system
requirements
Functionality: etc Relax non-functional requirements such as
response
time and memory utilization, standards of reliability and program quality
may be reduced. Provision must be made for user training;
Evaluation:
prototype objectives should be used to derive a plan for evaluation;
Users need time to become comfortable with a new system and to settle into a
normal pattern of usage. Once they are using the system normally, they then
discover requirements errors and omissions.
Prototype development
 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
 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;
 Rapid change during development inevitably means that
prototypes are normally undocumented;
 The prototype structure is usually degraded through rapid
change;
 The prototype probably will not meet normal organizational
quality standards.
 Incremental delivery
 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 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
Incremental delivery advantages
 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
 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.
Boehm’s spiral model
 A risk-driven software process framework (the spiral
model) was proposed by Boehm (1988).
 Process is represented as a spiral rather than as a
sequence of activities with backtracking.
 Each loop in the spiral represents a phase in the process.
 No fixed phases such as specification or design - loops in
the spiral are chosen depending on what is required.
 Risks are explicitly assessed and resolved throughout the
process.
 Thus, the innermost loop might be concerned with system
feasibility, the next loop with requirements definition, the
next loop with system design, and so on.
Boehm’s spiral model of the
software process
 Spiral model sectors
 Objective setting
 Specific objectives for the phase are identified. Project risks are
identified
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the key
risks. For example, if there is a risk that the requirements are
inappropriate, a prototype system may be developed.
 Development and validation
 A development model for the system is chosen which can be any
of the generic models.
 For example, throwaway prototyping may be the best development
approach if user interface risks are dominant. If the main identified
risk is sub-system integration, the waterfall model may be the best
development model to use.
 Planning
 The project is reviewed, and the next phase of the spiral is planned.
 Spiral model usage
 Spiral model has been very influential in
helping people think about iteration in
software processes and introducing the
risk-driven approach to development.
 In practice, however, the model is rarely

used as published for practical software

development.
The Rational Unified Process
 A modern generic process derived from the work on
the UML and associated process.
 Brings together aspects of the 3 generic process
models discussed previously.
 Normally described from 3 perspectives
 A dynamic perspective that shows phases over
time;
 A static perspective that shows process activities;
 A practice perspective that suggests good
practice.
Phases in the Rational Unified
Process
 RUP phases
 Inception
 Establish the business case for the system.
 You should identify all external entities (people and systems)

that will interact with the system and define these interactions
 Elaboration
 Develop an understanding of the problem domain, requirement
model, key project risks, project plan, development plan and the
system architecture.
 On completion of this phase, you should have a requirements
model for the system, which may be a set of UML use-cases, an
architectural description, and a development plan for the software.
 Construction
 It involves system design, programming and testing. On completion
of this phase, you should have a working software system and
associated documentation that is ready for delivery to users.
 Transition
 Deploy the system in its operating environment. On completion of
this phase, you should have a documented software system that is
working correctly in its operational environment.
RUP iteration
 In-phase iteration
 Each phase is iterative with results
developed incrementally.
 Cross-phase iteration
 As shown by the loop in the RUP model,
the whole set of phases may be passed
incrementally.
Static View of RUP
 The static view of the RUP focuses on
the activities that take place during the
development process.
 These are called workflows in the RUP

description.
 There are six core process workflows

identified in the process and three core

supporting workflows.
 Static workflows in the Rational Unified
Process
Workflow Description
Business modelling The business processes are modelled using business
use cases.
Requirements Actors who interact with the system are identified and
use cases are developed to model the system
requirements.

Analysis and design A design model is created and documented using

architectural models, component models, and
sequence models.

Implementation The components in the system are implemented and

structured into implementation sub-systems.
Automatic code generation from design models helps
accelerate this process.
 Static workflows in the Rational
Unified Process
Workflow Description
Testing Testing is an iterative process that is carried out in conjunction
with implementation. System testing follows the completion of
the implementation.
Deployment A product release is created, distributed to users and installed in
their workplace.
Configuration and This supporting workflow managed changes to the system .
change management
Project management This supporting workflow manages the system development .
Environment This workflow is concerned with making appropriate software
tools available to the software development team.
 RUP good practice
 Develop software iteratively
 Plan increments based on customer priorities and
deliver highest priority increments first.
 Manage requirements
 Explicitly document customer requirements and
keep track of changes to these requirements.
 Use component-based architectures
 Organize the system architecture as a set of
reusable components.
RUP good practice
 Visually model software
 Use graphical UML models to present static and
dynamic views of the software.
 Verify software quality
 Ensure that the software meet’s organizational
quality standards.
 Control changes to software
 Manage software changes using a change
management system and configuration
management tools.
 Key points
 Processes should include activities to cope with
change. This may involve a prototyping phase 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.
 The Rational Unified Process is a modern generic
process model that is organized into phases
(inception, elaboration, construction and transition)
but separates activities (requirements, analysis and
design, etc.) from these phases.