0% found this document useful (0 votes)
8 views

02 - Software Processes (Part 1)

Uploaded by

4cxjvvj6qf
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

02 - Software Processes (Part 1)

Uploaded by

4cxjvvj6qf
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

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=graphi
cal+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


1. The waterfall model
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


Key process stages of reuse

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

Source: SE10 by Ian Sommerville


30/10/2014 Chapter 2 Software Processes 16
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 17
Any Questions

18

You might also like