Chapter 2 – Software Processes

Lecture 2

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 1

Topics:

Software Process:-
✧Software process activities (revision from Lecture 1)
✧Software process models

Coping with change

Source: SE10 by Ian Sommerville 2

Software Process Definition

Software Process: A set of activities required to develop a

software system. When we describe and discuss about software
processes, we usually talk about the following:-
✧Software process activities (revision from Lecture 1) Including
sub-
activities
such as
specifying a
data model,
designing a
user
interface,
etc

✧Software process model is a simplified representation of a

software process activities and the ordering of these
activities and sub-activities. (Example: Waterfall Model, Incremental
Development, Reuse-oriented software engineering).
Source: SE10 by Ian Sommerville Chapter 2 Software Processes 3
Software Process Descriptions

✧ When we describe and discuss about software

processes, we also talk about:
▪ Products: outcomes of a software process activity.
(Example: outcome of activity “designing graphical user interface” is “user
graphical interface design”)
https://www.pngwing.com/en/search?
q=graphical+User+Interface#google_vignette

▪ Roles, who is responsible of a software process activity.

(Example: requirements engineer is responsible of activity “designing graphical
user interface”).

▪ Pre- and post-conditions, which are statements that are true

before and after a software process activity.
(Example: before activity “designing graphical user interface” begin,
requirements engineer must understand the defined requirements, user
preference related to GUI. Post-condition: user approve the design).

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 4

 Software Process Descriptions

Let’s test our understanding. Software process activity called “S/W

development”.
Products: (What is the outcome of S/W development activity)

A software design and computer program

Roles: (Who is responsible of S/W development activity?)

Developer: Design and writes code

Pre- and post-conditions, (What is the pre-condition and post
condition of S/W development activity)

Pre-conditions:
Requirements for the software are defined.
Development environment is set up.
Developer are available.
Post-conditions:
The software is functional and meets requirements.
Source: SE10 by Ian Sommerville Chapter 2 Software Processes 5
Software Process Descriptions (More example)

Process Description: Software process activity called “S/W development” for

Calculator Application
✧ Products: An application design and functional calculator application

✧ Roles:

▪ Developer: Design and writes code

✧ Pre-conditions:

▪ Requirements for the calculator application are defined.

▪ Development environment is set up.
▪ Developer are available.
✧ Post-conditions:

▪ The calculator application is functional and meets requirements.

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 6

Do you know that…

There is no ideal software process.

Most organizations have developed their own software development

processes depending on:

People involved in a
software project Characteristic of the software
being develop

(Example: critical systems such as aircraft system required Plan-driven approach.

For software with rapidly changing requirements, less formal, flexible software process
like agile likely to be more effective.

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 7

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.

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 8

Software process models
Related video: https://www.youtube.com/watch?v=laSrDtYtkXU&list=PLCku-ULHIQvlLC2gFqeoX-JtbEvmeoDhl&index=1

1. The waterfall model

▪ An example of a plan-driven process.
▪ Separate phases of specification and development.
2. Incremental development
▪ A fundamental part of agile approaches
▪ Specification, development and validation are interleaved.
▪ May be plan-driven or agile.
3. 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.
Source: SE10 by Ian Sommerville Chapter 2 Software Processes 9
 The waterfall model .1
:Take home assignment: Please watch this video on your own
https://edpuzzle.com/assignments/66d3ccda44a1a225db342edc/watch
‫هذي الحروف تعبر الفندمينتال الي تستخدمها‬

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 10

Waterfall model limitations

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.
But……!
Inflexible partitioning of the project into phases makes it
difficult to respond to changing customer requirements.

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 11

Waterfall model limitations – cont.

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. However, few business
systems have stable requirements! :(

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 12

2. Incremental development

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 13

Incremental development benefits

The cost of accommodating changing customer ✧

requirements is reduced as 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.
Source: SE10 by Ian Sommerville Chapter 2 Software Processes 14
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.
✧ The specification is developed in conjunction with the software.
In many organizations, the *complete* system specification is
part of the system development contract!!
Source: SE10 by Ian Sommerville Chapter 2 Software Processes 15
3. Reuse-oriented software engineering

Reuse-Oriented Software Engineering - Based on systematic reuse where

systems are integrated from existing components or COTS (Commercial-off-
the-shelf) systems

Source: SE10 by Ian Sommerville Chapter 2 Software Processes 16

Key process stages of reuse

✧ Requirements specification
✧ Software discovery and evaluation
✧ Requirements refinement
✧ Application system configuration
✧ Component adaptation and integration

✧ Those are the same at the previous slide!!

Source: SE10 by Ian Sommerville

30/10/2014 Chapter 2 Software Processes 17
Advantages and disadvantages

✧ Reduced costs and risks as less software is developed

from scratch
✧ Faster delivery and deployment of system
✧ But requirements compromises are inevitable so system
may not meet real needs of users
✧ Loss of control over evolution of reused system elements

Source: SE10 by Ian Sommerville

30/10/2014 Chapter 2 Software Processes 18
Any Questions

19