Software Processes

Objectives
 Software process models
 Process activities
 Coping with change
 The Rational Unified Process
 An example of a modern software process.
 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 for architecture design- All requirements has
been approved before design phase begins
 Post condition- UML models describing the architecture has
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 e 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
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 complete
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 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 take 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
 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

 The process of establishing what services are required and the

constraints on the system’s operation and development.
 Requirements engineering process
 Feasibility study
and analysis
Req Elicit

 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 prototypes. These help you understand the
system to be specified
Specification

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

Req

During 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.
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 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
 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.
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 etc
Functionality: Relax non-functional requirements such as
response
time and memory utilization, standards of reliability and program
Evaluation:
quality Provision must be made for user training;
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
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:
 Itmay 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.
 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
 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
 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 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.