 Slides adapted from multiple internet resources

mentioned at the end of file, copyright holds with the

corresponding authors.

 PS: This file is for reference only. Do not depend

solely on it for the content and topics covered in the
class, it is to supplement your lecture content. It is
recommended to go through suggested readings and
class lectures to have detailed knowledge of the
content.

1
 What is Process?
 What is Software Development Process (SDP) ?

3
  One or more steps.

 Each step is well defined.

 Input and output of each step is well defined and

observable.
 Start and end of a step can be identified.

4
 Steps correspond to one or more tasks related to software
development.

 Tasks:

o Requirements gathering o Integration

o Requirements analysis o Test
o Design o Delivery
o Coding o Maintenance
o Training

 Software life cycle: Software Life Cycle consists of all phases

from its inception until its retirement. These are (for Unified
Process): Inception, elaboration, construction, transition.

5
 Definition
 Describes an abstract collection of software processes that
share common characteristics such as timing between
phases, entry and exit criteria for phases.
 The models specifies
 the various phases of the process
 e.g., requirements, specification, design…
 the order in which they are carried out

6
 Provide guidance for project management
 what major tasks should be tackled next? milestones!
 what kind of progress has been made?
 The necessity of lifecycle models
 character of software development has changed
 early days: programmers were the primary users
 modest designs; potential of software unknown
 more complex systems attempted
 more features, more sophistication → greater complexity,
more chances for error
 heterogeneous users

7
 Build and fix: Acceptable for short programs that do not
require maintenance.

 Waterfall: Disciplined approach, document driven;

delivered product may not meet client needs.

 Rapid prototyping: Ensures that delivered product meets

client needs; might become a build-and-fix model.

 Incremental: Maximizes early return on investment;

requires open architecture; may degenerate into build-
and-fix.
8
 Spiral: Risk driven, incorporates features of the above
models; useful for very large projects

 UDP: Iterative, supports OO analysis and design; may

degenerate into code-a-bit-test-a-bit(CABTAB).

9
o Key features: Iterative development; OO analysis and
design.
o Development organized as a series of short iterations

o Each iteration produces a working, executable, product

that might not be a deliverable.

o No rush to code. Also, not a long drawn design process.

o Lots of visual modeling aids. Unified Modeling Language

(UML) used.
10
 Early iterations seek feedback from the customer. Risk
and value to customer is managed through early
feedback.

Customer is engaged continuously in evaluation and

requirements gathering.

Architecture is built during early iterations.

11
12
 Component based - meaning the software system is built as a set of
software components interconnected via interfaces
 Uses the Unified Modeling Language (UML)
 Use case driven
This is what makes
 Architecture-centric the Unified process
 Iterative and incremental Unique

Component: A physical and replaceable part of a system that

conforms to and provides realization of a set of interfaces.
Interface: A collection of operations that are used to specify a service
of a class or a component
13
 Software
User’s Software
Development
requirements System
Process

Based around the 4Ps - People, Project, Product, Process

14
 Use Case driven
 A use case is a piece of functionality in the system that
gives a user a result of value.
 Use cases capture functional requirements
 Use case answers the question: What is the
system supposed to do for the user?

15
 Architecture centric
 similar to architecture for building a house
 Embodies the most significant static and dynamic
aspects of the system
 Influenced by platform, OS, DBMS etc.
 Related as function (use case) and form
(architecture)
 Primarily serves the realization of use cases
 The form must allow the system to evolve from initial
development through future requirements (i.e. the
design needs to be flexible)

16
 What is Process?
 What is Software Development Process (SDP) ?
 Brief Overview of SDPs.

17
At the end of this module, you will be able to answer
 What is Software Process? -- done in lect1
 What are different Software Process Models? – done in
lect1
 What are the major categories of Software Process
Models?
 How the Changing requirements affect selection of
Software Process Models?
 What are the fundamental activities during Software
Development?

18
 A structured set of activities required to develop a
software system.
 Many different software processes but all involve:
 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.

19
 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.

20
 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.

21
 The waterfall model
 Plan-driven model. Separate and distinct phases of
specification and development.
 Incremental development
 Specification, development and validation are interleaved.
May be plan-driven or agile.
 Develop system as a series of versions, each version adding
some functionality to previous version.
 Integration and configuration
 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.
22
Classical Waterfall Model

23
Among all life cycle phases
maintenance phase 60
consumes maximum 50 Relative Effor t
effort.
40
Among development
phases, 30
testing phase consumes 20
the maximum effort.
10

Implementation
0

Design
Req.Def

Maintnce
Test
24
 Classical waterfall model is idealistic:
 assumes that no defect is introduced during
any development activity.
 in practice:
 defects do get introduced in almost every phase
of the life cycle.
 Defects usually get detected much later in the
life cycle:
 For example, a design defect might go unnoticed till
the coding or testing phase.

25
 Once a defect is detected:
 we need to go back to the phase where it was
introduced
 redo some of the work done during that and all
subsequent phases.
 Therefore we need feedback paths in the
classical waterfall model.

26
Iterative Waterfall Model

27
 The principle of detecting errors as close to its
point of introduction as possible:
 is known as phase containment of errors.

28
 Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
 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.

29
30
 The cost of accommodating changing customer
requirements is reduced.

 It is easier to get customer feedback on the

development work that has been done.

 More rapid delivery and deployment of useful

software to the customer is possible.

31
 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.

32
 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

33
34
35
 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.

 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

36
 Change anticipation, 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.
 Customer can experiment with this prototype and ask
the developers to refine products.

37
 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.
 Proposed changes may be implemented in increments
that have not yet been developed.
 If this is impossible, then only a single increment (a
small part of the system) may have be altered to
incorporate the change.

38
 System prototyping
 where a version of the system or part of the system is
developed quickly to check the customer’s
requirements and the feasibility of design decisions.
This approach supports change anticipation.
 Incremental delivery
 Where system increments are delivered to the
customer for comment and experimentation. This
supports both change avoidance and change
tolerance.

39
 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.

40
 Build Prototype

Requirements Customer Customer

Gather ing Quick Design Evaluation of satisfied Design
Prototype

Refine Implement
Requirements

Test

Maintain

41
 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

42
 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
organisational quality standards.

43
 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.

44
45
 https://www.cs.purdue.edu/homes/apm/courses/BITS
C461-fall03/process-slides/process.ppt
 - Sommerville I, Software Engineering, Pearson
Education, 10th Edition, Ch2 Intro, Section 2.1, 2.2, 2.3.
 - Mall R., “Fundamentals of Software Engineering”,
Fourth Edition, PHI, 2016. Section 2.2.

46