Software Processes

Learning Objectives
We need to address the following…..
• What is a software process?
• What are generic framework activities that are present in every software
process?
• How processes are modeled and what are process patterns?
• What are prescriptive process models and what are their strengths and
weaknesses?
• Why is agility a watchword in modern software engineering work?
• What is agile software development and how does it differ from other
traditional process models?
Why software processes …
Fundamental Assumption:
Good process leads to good software
Good processes reduce risk
Good processes enhance visibility
What is a Process … ?
• When we provide a service or create a product (any) we always
follow a sequence of steps to accomplish a set of tasks
• You do not usually
• put up the drywall before the wiring for a house is installed or
• bake a cake before all the ingredients are mixed together
• A series of activities is referred to as a process
• Any process has the following characteristics
• It prescribes all the major activities
• It uses resources and produces intermediate and final products
• It may include sub-processes and has entry and exit criteria
• The activities are organized in a sequence
• Constraints or controls may apply to activities
(e.g., budget control, availability of resources, legislative requirements )
Variety of Software Processes
Software products are very varied...
Therefore, there is no standard process for all software
engineering projects
BUT successful software development projects all need to
address similar issues.
This creates a number of generic process steps that must
be part of all software projects
Software process framework
• Each framework activity is populated
by a set of software engineering
actions.
• Each software engineering action is
defined by a task set that identifies:
• the work tasks that are to be
completed,
• the work products that will be
produced
• the quality assurance points that
will be required.
• the milestones that will be used to
indicate progress
Software Processes
• When the process involves the building of some product, we refer to the
process as a life cycle
• Software development process – software development life cycle
(SDLC)

A coherent set of activities for

• Planning,
• Specifying, It is essential to distinguish
• Designing, among these aspects and to be
• Implementing, clear which one you are doing at
• Testing, any given moment of your SDLC.
• Deploying, and
• Maintaining software systems
Combining the Process Steps

Feasibility & Requirements

Planning

Design

Operation &
Implementation
Maintenance
The Software Process vs. Software process model

• A structured set of activities required to develop a

software system
• Planning to Maintenance
• A software process model is an abstract representation of a
process
• It presents a description of a process from some perspective
• Workflow activities
• Information flow
• User role – i.e., who does what
Software process models

1. Waterfall Model
2. Evolutionary Model
3. Component-based/Reuse-based SWE
4. Iterative Model
5. Agile Software Development
Methodologies
Traditional waterfall Model

Feasibility study Requirements

Requirements gathering Design

System design
Implementation
Program design

Coding
Acceptance tests
Testing
Acceptance
Operation & maintenance
Traditional Waterfall is not enough!
The Waterfall process model
Requirements
definition
Waterfall model
with feedback
System and
software design This is better!

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance
Phases of the Waterfall Model (1)
• Requirements definition and analysis
• The system’s services, constraints, and goals are established in
consultation with system users.
• These requirements are then defined in a manner understandable by
both users.
• During this phase, research about the system is conducted, which
includes brainstorming about the software,
• What it is going to be.
• What purpose it is going to fulfill – The Reason it all Exists PRINCIPLE
• What value-add will it provide to its users
• Defined requirements are presented in detail and produce a System
Requirements Document (SRD) / System Specification Document (SSD).
• SRD must be approved/ signed off.
• It is then that the next phase can proceed.
Phases of the Waterfall Model (2)
• System and Software Design
• Daft the basic system design – on paper
• Focus on major system building blocks
• Identify and describe the fundamental software system
abstractions and relationships.
• System design: Partition the requirements to hardware or
software systems. Establishes an overall system architecture
• Program design: Represent the software system functions in a
form that can be transformed into one or more executable
programs.
Phases of the Waterfall Model (2)
• System and Software Design

Daily transactions

POS Database Architecture

Products & services Customer & account External

database database services
 Phases of the Waterfall Model (3)
• System and Software Design (2)

Data

Web browser
html

Java PHP
Script Scripts
Web server
Phases of the Waterfall Model (4)
• Detailed design + Development
• After the basic design gets approved, more elaborate technical design is
planned.
• Functions of each part are decided and the engineering units (program
modules, functions, algorithms) are defined.
• Detailed design document must be signed-off before moving to the next
phase.

HelloWorld

paint() ‘g.drawString ("HelloWorld", 0, 10)"

Phases of the Waterfall Model (5)
• Detailed design + Development (2)
UML CLASS DIAGRAM FOR
WEATHER PROCESSING APPLICATION DigitizedMap

WeatherStation WeatherMap

location location
metereologicalData 1 date-time
1...*
geographicData
collectData() weather
getSummary() summary
gatherData()
printMap()
Phases of the Waterfall Model (5)
• Detailed design + Development (2)
UML CLASS DIAGRAM FOR Mobile Application
Application LocationManager

NetworkInterface
NetworkConnection
open()
send() close()
setNetworkInterface() send()

Ethernet WirelessNet

open() open()
close() close()
send() send()
Phases of the Waterfall Model (6)
• Implementation and Unit Testing

• Write source code for all programs designed

• During this stage, the software design is realized as a set of programs or
program units.
• Unit testing involves verifying that each unit meets its specification.
Phases of the Waterfall Model (7)
• Integration and System Testing
• Here the whole design and its construction are put under
rigorous tests to check its functionality.
• This is an example of a black box testing process
• The individual program units or programs are integrated and
tested as a complete system to ensure that the software
requirements have been met.
• This is where the correctness of the system (integrated
subsystems) will be verified.
• So, no matter how small your system is, conduct integration &
and system tests
Phases of the Waterfall Model (8)
• Acceptance Testing
• The complete system is tested against the requirements by the
client/customer in their own premises.
• Allow the customer to develop their own test cases (since they
know their requirements).
• Customer should give feedback on the parts of the system they
accept and those they reject.
Phases of the Waterfall Model (10)
• Operations & Maintenance
• This is the longest phase of the SDLC.
• Operations & Maintenance are needed to ensure that the system continues
to perform as desired throughout its lifetime in the production
environment.
• During this final life-cycle phase, the software is installed and put into
practical use.
• Definition: Software maintenance refers to the general-purpose process of
changing a system after it has been delivered such that it still fulfills its
purpose.
• The changes made to the software may be:
• Simple changes to correct coding errors.
• More extensive changes to correct design errors
• Significant enhancements to correct specification errors and/or accommodate new
requirements.
Phases of the Waterfall Model (11)
• 3 Types of Software Maintenance
• Maintenance to repair software faults
• A.k.a Corrective maintenance
• Maintenance to adapt the software to a different operating
environment
• A.k.a Adaptive maintenance
• Maintenance to add to or modify the system’s functionality
• A.k.a Perfective maintenance

• Note: In practice, there isn’t a clear-cut distinction between these

types of maintenance.
Discussion of the Waterfall process model (1)
Advantages:
• Process visibility
✓ The project requires the fulfillment of one phase before proceeding to the next
• Separation of tasks
✓ If there is a fault in this software, it will be detected during one of the initial phases and
will be dealt with and corrected right there.
• Quality control
✓ Waterfall leads to better-structured software systems than other models.
✓ Proper documentation is important for any long-life system
• Cost control
✓ As a result of clear boundaries between phases, it is easy to control costs.
✓ E.g., Developers can go ahead with development work in other projects, are not tied in
one project.
• Elaborate documentation
✓ New employees can easily refer to documents
Discussion of the Waterfall process model (2)
Disadvantages
• Inflexible partitioning of the project into distinct stages,
❑ One phase must be completed before moving onto the next phase,
❑ The drawback of the waterfall model is the difficulty of accommodating
change after the process is underway
• Each stage in the process reveals new understanding of the previous stages, that
requires the earlier stages to be revised.
• Real-world projects rarely follow the sequential flow that Waterfall model
proposes
• E.g. Inexplicit initial user requirements
• Too stiff for today’s SWE work which is fast-paced and subject to never-ending stream
of changes.
• Waterfall model takes a static view of requirements,
Applicability of Water model
• The Waterfall model should generally be used when the
requirements are:
• Well understood for the project
• Are unlikely to change during system development –
where requirements are static.
• When the software project is part of a larger systems
engineering project.
• There are certain portions of the project that may be based
on the Waterfall model.
WHY/WHERE NOT Waterfall model
• Where system requirements are likely to change.
• For smaller systems where elaborate documentation may
not required.
• Where prototyping is desired
• For many systems it is important to start off with
multiple versions of the systems of lesser
functionality
EVOLUTIONARY PROCESS MODEL
Evolutionary SW Process Model (1)
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
Evolutionary SW Process Model (2)
• It interleaves the activities of specification, development, and
validation.
• An initial system is rapidly developed from abstract specifications.
• This is then refined with customer input to produce a system that
satisfies customer’s needs.
• The evolutionary process model is based on the idea of developing
an initial implementation,
• Exposing this to user comments,
• Refining it through many versions until an adequate system has been
developed
Two (2) types of Evolutionary Development

(1) Exploratory prototyping

(2) Throwaway prototyping

Exploratory prototyping
• The objective is to work with the customer to explore their
requirements and deliver a final working system.
• Practical way to design and develop user graphical interfaces
for software systems.
• Involving users in design and development is an essential
aspect of User-centered or User-oriented or User-centric
design philosophy.
• Key point: Start with parts of the system that are well-
understood
• Then evolve the system by adding new features proposed by the
user.
• In other cases, the developer may be unsure of the efficiency
of an algorithm, the adaptability of the OS, or the form that
human-machine interaction should take.
Exploratory prototyping paradigm

Quick plan
Communication
and design

Delivery of Construction
feedback of prototype
Prototyping (1)
• Iteration occurs as the prototype is tuned to satisfy user needs, while at the
same time enabling you (the developer) to better understand what needs to
be done.
• Ideally, prototyping is a mechanism for identifying and gathering more
software requirements.
• Prototyping allows users gain direct experience with the interfaces of the
system.
• It may be difficult to think abstractly about a user interface
• Prototyping is 2-stage process:
• (1) Very early in the process, you should develop paper prototypes –
mock-ups of screen designs – and walk through them with user.
• (2) Refine design using visual IDE tools; make it available to users for
testing activity simulation
Prototyping (2)
• Communication
• Meet with other stakeholders to define the overall objectives for the
software, identify whatever requirements are known, and outline areas
where further definition is mandatory.

• Quick plan and design

• A prototyping iteration is planned quickly, and modeling occurs.
• A quick design focuses on a representation of those aspects of the
software that will be visible to end-users, e.g.
• human interface layout,
• output display formats etc.
• The quick plan leads to the construction of the prototype.
• The prototype is deployed and evaluated by stakeholders who provide
feedback that is used to further refine requirements.
• Iteration occurs as a prototype is tuned to satisfy the needs of other
stakeholders
Throwaway prototyping/Vaporware/Rapid prototyping

• The throwaway prototype concentrates on experimenting

with the customer requirements that are poorly understood.
• Start with the poorly understood requirements.
• Develop quick and dirty system quickly;
• Expose it to user comment;
• And then refine;
• It is a good method to resolve any uncertainties in
requirements with the user.
• Throwaway prototyping is particularly suitable where:
• Detailed requirements are not possible
Inapplicability of software prototyping

• Systems where prototyping is generally not suitable

for:
• Software that involves too much data processing and
most of the functionality is internal, with very little or no
UI at all.
• Prototype development could be an extra overhead in such
projects and may need extra effort.
Advantages of Evolutionary Development

• An evolutionary approach to software development is often

more effective than the Waterfall approach in producing
systems that meet the immediate needs of the customer.
• A more clear advantage of a software process that is based
on an evolutionary approach is that the specification can be
developed incrementally.
• As users develop a better understanding of their problem, this
understanding can be reflected in the software system.
Disadvantages of Evolutionary Development
• From an engineering and management perspective, the evolutionary approach has
two problems:
1. The process is not visible (lack process of visibility) – due to lack/amount of
documentation required.
1. 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 (compare with the waterfall model).
2. Systems are often poorly structured
1. Continual change tends to corrupt the software structure.
2. Incorporating software changes becomes increasingly difficult and costly.

• Special skills are required

• E.g. You may require specialized languages for rapid prototyping.
• It may be difficult to establish a stable system architecture using this approach,
which makes it hard to integrate contributions from different teams.
Applicability of Evolutionary Development (1)
• For small to medium-sized systems – say up to 500, 000 lines of code (LOC) –
evolutionary development is the best approach.
• For highly interactive systems. Here user interaction is mandated (e.g.
regular feedback).
• For parts of large systems.
• For large systems, a mixed process that incorporates the best features of the waterfall
and the evolutionary development models is recommended.
• This may involve developing a throwaway prototype using an evolutionary approach to
resolve uncertainties in the system specification.
• You can then re-implement the system using a more structured approach – e.g.
Waterfall.
• Parts of the system that are well understood can be specified and developed using a
waterfall-based process.
• Other parts of the system, like the user interface (which is difficult to specify in
advance) should always be developed using an exploratory programming approach.
Applicability of Evolutionary Development (2)
• Most useful in the development of systems having high levels
of user interactions. E.g.
• Online/web-based systems.
• Systems that need users to fill out forms or go through
various screens before data are processed.
• Here prototyping can be used to give the exact look and feel
even before the actual software is developed.
• For short-life systems
Component-based software engineering (CBSE) (1)
• A.K.A Reuse-oriented software development
• CBSE is based on the existence of a significant number of reusable
components (Open Source software).
• The system development process focuses on integrating these
components into a system rather than developing them from scratch.
• In the majority of software projects, there is some software reuse
happening – whether properly acknowledged or not.
• This would usually happen informally when people working on
the project know of designs or code that is similar to that required
for their system.
CBSE diagram

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integration validation
Component-based software engineering (CBSE) (2)
• The CBSE relies on a large base of reusable software
components and some integrating frameworks for these
components,
• Sometimes these components are systems in their own right (COTS or
commercial-off-the-shelf systems) that may provide specific
functionality.

• The initial requirements specification stage and the validation

stage are comparable with other processes. Intermediate stages
are different.
Component-based software engineering (CBSE) (3)
• Component analysis
• Given the requirements specification, a search is made for components to
implement that specification.
• Key: Available component-based products are researched and evaluated for the
application domain in question.
• It may not be possible to always make an exact match, and the components that
may be used only provide some of the functionality required.

• Requirements modification
• Requirements are analyzed using information about the components that have
been discovered.
• They are then modified to reflect the available components.
• Where modifications are impossible, the component analysis activity may be re-
entered to search for alternative solutions.
• Key: Component integration issues are considered.
Component-based software engineering (CBSE) (4)
• System design with reuse
• During this phase, the framework of the system is designed or an existing framework
is reused.
• Take into account the components that are reused and organize the framework to
cater for this.
• New components may have to be designed if reusable components are not
available.
• Key: Software architecture is designed to accommodate the components.
• Development and integration
• Normal development for new components happens.
• These new components plus the COTS systems are integrated to create the new
system.
• System integration in this model may be part of the development process rather
than a separate activity.
• Key: Components are integrated into the architecture.
Component-based software engineering (CBSE) (5)

• Validation and verification

• Comprehensive testing is conducted to ensure proper functionality.
Advantages of Component-based software engineering
• Component-based software engineering has the obvious
advantage of reducing the amount of software to be developed
from scratch.
• Advantages are:
• Reduces development time.
• It leads to faster delivery of software.
• Leads to increased productivity.
• Improved quality of products.
Disadvantages of Component-based software engineering
• Requirements compromises are inevitable and this may lead to software
that does not meet the real needs of users.
• Some control over the system evolution is lost because new versions of the
reusable components are NOT under the control of the organization using
them;
• You still must refer to their owners for support and maintenance.
• Problems could arise if there is a lack of components.
• Component maintenance costs could skyrocket.
• Security: how secure are we if we rely on software reuse?
• It is only a matter of time that the owner of the re-used component attacks your
system – because they know each and every flaw in your system – by the way you
used their components – and they know them better than you do.