SOFTWARE ENGINEERING

PRINCIPLES

Lecture 2: Software Processes

 Learning objectives
Describe Software process models
Understand the Process activities
Analyzing the strategies for Coping with
change
 The Software Process
A structured set of activities required to
develop a software system.
There are many different software processes
but all involve four engineering activities:
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.
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;
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
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.
In practice, most practical processes include
elements of both plan-driven and agile
approaches.
There are no right or wrong software
processes.
Software Process Models
 Software Process Models
Software process model is a simplified
representation of a software process.

It presents a description of a process

from some particular perspective.
 Generic Software Process
Models
Waterfall model
Plan-driven model. Separate and distinct phases of
specification and development.
Incremental development (Evolutionary Model)
Specification, development and validation are interleaved.
May be plan-driven or agile.
Reuse-oriented software engineering (Component-
based)
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
 Waterfall Model Phases
1. Requirements analysis and definition
2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance

In principle, a phase has to be complete

before moving onto the next phase.
 Requirement Analysis and
Definition
Systems functionality, constraints and
goals are established by consultation
with the users
This phase can be subdivided into:
Feasibility study (could be done separately)
Requirements analysis
Requirements definition
Requirement specification
Programming and Unit Testing
Implementation Stage
Programs are written – coding
Each unit is verified
To make sure that it meets its specification
 Integration and System
Testing
Individual program units are:
Integrated and tested as a complete
system
Tested against the requirements as
specified
Delivered to the user/client
Operation and Maintenance
Operation
The system is installed and put to use
Maintenance
Identifying and correcting errors
Evolution
The system evolves over time as
requirements change
Phase out
The system is withdrawn from its use if
necessary
Discussion on Waterfall model
Advantage
Process Visibility
Dependence on individuals
Quality and cost control
Disadvantages
Difficulty to respond to changing user
requirements
Appropriate when the requirements are well
understood
However, few business systems have stable
requirements
 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.
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
Lack of process visibility;

Systems are often poorly structured –

System structure tends to degrade as
new increments are added;

Special skills (e.g. in languages for rapid

prototyping) may be required.
 Incremental Development
Applicability
For small or medium-size interactive
systems;

For parts of large systems (e.g. the user

interface);

For short-lifetime systems.

 Reuse-oriented Software
Engineering
In the majority of software projects, there is
some software reuse.
This often happens informally when people
working on the project know of designs or
code that are similar to what is required.
They look for these, modify them as needed,
and incorporate them into their system.
Reuse-oriented approaches rely on a large
base of reusable software components and an
integrating framework for the composition of
these components.
 Reuse-oriented Software
Engineering
Based on software reuse where systems are
integrated from existing components or
application systems (sometimes called COTS -
Commercial-off-the-shelf) systems).
Reused elements may be configured to adapt
their behaviour and functionality to a user’s
requirements.
Reuse is now the standard approach for
building many types of business system.
Reuse-oriented Software
Engineering
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 such as .NET or J2EE.

Web services that are developed according to

service standards and which are available for
remote invocation.
 Reuse-oriented Software
Engineering – Advantages

Reducing the amount of software to be

developed and so reducing cost and
risks.
It usually also leads to faster delivery of
the software.
 Reuse-oriented Software
Engineering – Disadvantages
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.
Process Activities
 Process Activities
Real software processes are interleaved
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 interleaved.
 Process Activities
Software Elicitation and Specification
(Requirements Engineering)
Software Design and Implementation
Software Validation
Software Evolution
 Five Generic Process
Framework (GPF)
Communication: with customers/stakeholders) and
encompasses requirement gathering and other related
activities
Planning: Establishes a plan; describes technical tasks,
risks, resources, products to be produced
Modeling: Creation of models –> better understand
software requirements and the design.
Construction: Code generation (programming) and testing
Deployment: Delivering a complete entity or partially
completed to the customer who evaluates and gives
feedback.
 Umbrella Activities for GPF
1. Software project tracking and control: progress
as.
2. Risk management: assess risks
3. Measurement: defines & collects process,
project,& product measures
4. Reusability management: reusable components
5. Work product preparation and production:
create products e.g. models, doc.,logs, forms,&
lists
6. Software configuration management: manages
the effect of change
7. Formal technical reviews: remove and umber
errors Software quality assurance: ensure
quality
 The Adaptability of the
Process Models
The framework activities can always be
applied on every project activities
The tasks (and degree of rigor) for each
activity can be based on
type of project
characteristics of the project
 Capability Maturity Model
Integration (CMMI)
Established by Software Engineering Institute (SEI)
It is a comprehensive meta-model that is predicated
on set of system and software engineering
capabilities that should be present as organisations
reach different levels of process capability and
maturity.
CMMI is a process improvement approach that
provides organizations with the essential elements of
effective processes that ultimately improve their
performance
CMMI Process Area Profile
 Capability Maturity Model
Integration (CMMI)
Level 0 - Incomplete - process area is either not
performed or does not achieve all specified goals.
Level 1 - Performed - All specific CMMI defined
goals of the process area have been satisfied
Level 2 - Managed - All level 1 have been
satistied.
In addition all work conforms to an
organizationally policy; all people doing the work
have access to adequate resources to get the job
done; work tasks are monitored, controlled and
reviewed, evaluated for adherence to the process
description
 Capability Maturity Model
Integration (CMMI)
Level 3 - Defined - All criteria of level 2 - achieved.
In addition, the process is tailored according to organization’s
tailoring guidelines. Work products, measurements, etc are
contributed to the organizational process assets
Level 4 - Quantitatively managed - All level 3 criteria -
achieved. In addition, process area uses quantitative
measurement to control and improve the process area.
Quantitative objectives for quality and performance are
established and used.
 Capability Maturity Model
Integration (CMMI) cont…
Level 5 - Optimized - All level 4 criteria -
achieved. In addition, process area
adapted and optimized to meet
changing customer’s needs and
continually improve the process area
 Process Assessment
The existence of software process does
not guarantee that software will be
delivered on time, and that it will meet
customer’s needs
The process should be assessed to be
sure that it meets a set of basic process
criteria that have been shown to be
essential for a successful software
engineering
Process Assessment and
Processes
The Requirements Engineering
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.
Requirements engineering is a particularly
critical stage of the software process as errors
at this stage inevitably lead to later problems
in the system design and implementation.
The Requirements Engineering
Process
The Requirements Engineering
There are four main activities
1. Feasibility study:
Assess on software and hardware
technologies, cost-effectiveness of
the system.
The result should inform the decision
of whether or not to go ahead with a
more detailed analysis.
The Requirements Engineering
2. Requirements elicitation and analysis:
The process of deriving the system
requirements through observation of
existing systems, discussions with potential
users and procurers, task analysis, and so
on.
This may involve the development of one
or more system models and prototypes.
These help you understand the system to
be specified.
The Requirements Engineering
3. Requirements specification:
Requirements specification is the activity of
translating the information gathered during
the analysis activity into a document that
defines a set of requirements.
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.
The Requirements Engineering
4. Requirements validation:
This activity checks the requirements for
realism, consistency, and completeness.
During this process, errors in the
requirements document are inevitably
discovered.
It must then be modified to correct these
problems.
 Software Design and
Implementation
The process of converting the system
specification into an executable system.
Software design
Design a software structure that meets the
specification.
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 Activities
1. Architectural design, where you identify the overall
structure of the system, the principal components
(subsystems or modules), their relationships and
how they are distributed.
2. Interface design, where you define the interfaces
between system components.
3. Database design, where you design the system data
structures and how these are to be represented in a
database.
4. Component selection and design, where you search
for reusable components. If unavailable, you design
how it will operate.
 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;
In the testing process to run back-to-back
tests.
 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
 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;
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 proxy.
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.
 Extreme Programming

an
agile project management methodology
that supports frequent releases in short
development cycles to improve software
quality and allow developers to respond
to changing customer requirements.
 Values of extreme
programming methodology
Simplicity
Streamlined communication
Consistent, constructive feedback
Respect
Courage
 When to use extreme
programming
Expect their system’s functionality to change every
few months.
Experience constantly changing requirements or work
with customers who aren’t sure what they want the
system to do.
Want to mitigate project risk, especially around tight
deadlines.
Include a small number of programmers (between 2
and 12 is preferable).
Are able to work closely with customers.
Are able to create automated unit and functional
tests.
Dynamic System Development
 Spiral Model
The spiral model is similar to the incremental
development for a system, with more
emphasis placed on risk analysis.
The spiral model has four phases: Planning,
Design, Construct and Evaluation. A software
project repeatedly passes through these
phases in iterations (called Spirals in this
model).
 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.
Requirements engineering is the process of
developing a software specification.
 Key points
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.
 Key points
Software evolution takes place when you
change existing software systems to meet
new requirements. The software must evolve
to remain useful.
Processes should include activities such as
prototyping and incremental delivery to cope
with change.
Processes may be structured for iterative
development and delivery so that changes
may be made without disrupting the system
as a whole.