MODULE 2: SOFTWARE ENGINEERING PARADIGM

I. Title how it will be expected to

Subject Title: Software
Engineering
Subject Code: CPEN 110
Module Title: Software
Engineering Paradigm
II. Objectives
a. To be able to know the
different phases of a
Software Development Life
Cycle
b. To be able to identify the
different process models
used in developing a
software.
c. To be able to apply these
process models in
developing a software
project.
III. Definition of Terms
perform.
 Stakeholders – It refers to a
person, group or company
that is directly or indirectly
involved in the project and
who may affect or get
affected by the outcome of
the project.
 Unit Testing – It is a level of
software testing where
individual units or
components of a software
are tested.
 User Acceptance Testing –
It is the last phase of the
software testing process
wherein the actual software
users test the software to
make sure it can handle
required tasks in real-world
scenarios according to the
specifications.

 Users – It is the person that

a software project is
designed for.

 Software Project – It is the

complete procedure of
software development from
requirement gathering to
testing and maintenance,
carried out according to the
execution methodologies in a
specified period of time.

 Software Requirement
Specification (SRS) – It is a
document that describes
what the software will do and

Page | 1
MODULE 2: SOFTWARE ENGINEERING PARADIGM
IV. Discussion
SOFTWARE ENGINEERING PARADIGMS
It is also referred to as a software
development life cycle in which it is a
development strategy that encompasses the
process, methods, and tools.
SOFTWARE DEVELOPMENT LIFE
CYCLE
It is a framework that defines the steps
involved in the development of software at
each phase.
1.0 SDLC LIFE CYCLE
 Requirement Gathering and Analysis
 Design
 Implementation and Coding
 Testing
 Deployment
 Maintenance
1.1 Requirement Gathering and Analysis
During this phase, all the relevant
information is collected from the customer to
develop a product per their expectation.
1.2 Design
The requirement gathered in the Software
Requirement Specification document is
used as an input and software architecture
that is used for implementing system
development is derived.
1.3 Implementation and Coding
It starts once the developer gets the design
document. The software design is translated
into source code. All the components of the
software are implemented in this phase.
1.4 Testing
It starts once the coding is complete and the
modules are released for testing. In this
phase, the developed software is tested
thoroughly and any defects found are
assigned to developers to get them fixed.
Retesting, regression testing is done until
the point as per the software has satisfied
the customer’s requirements. Testers refer
to the SRS document to make sure that the
software is as per customer’s standard.
1.5 Deployment
Once the product is tested, it is deployed in
the production environment or first UAT
(User Acceptance Testing) is done
depending on the customer expectation.
1.6 Maintenance
When the software is deployed,
maintenance is next. In case that there are
any issues that comes up and needs to be
fixed or any enhancements to be done.
Page | 2
MODULE 2: SOFTWARE ENGINEERING PARADIGM
2.0 SDLC PROCESS MODELS
It is a descriptive representation of the
software development cycle.
Some of the process models are as follows:
 Waterfall Model
 Iterative Model
 Spiral Model
 V- Model
 Big Bang Model
 Agile Model
 RAD Model
 Prototyping Model
2.1 Waterfall Model
It is the simplest model of SDLC wherein all
the phases of SDLC will line up after
another that is when the first phase is
finished then only the second phase will
start and so on.
This model assumes that everything is
carried out and taken place perfectly as
planned in the previous stage and there is
no need to think about past issues that may
arise in the next phase.
The sequential phases in Waterfall Model
are:
 Requirement Gathering and
Analysis – it is where all the
possible requirements of the system
to be developed are captured in this
phase and documented in a
requirement specification document.
 System Design – The requirement
specifications from first phase are
studied in this phase and the system
design is prepared. This helps in
specifying the hardware and system
requirements and helps in defining
the overall system architecture.
 Implementation – The system is
first developed in small programs
called units which are integrated in
the next phase. Each unit is
developed and tested for its
functionality.
 Integration and Testing – All the
units developed in the
implementation phase are integrated
into a system after testing of each
unit. After integrating, the entire
system is tested for any faults and
failures.
 Deployment of system – Once the
testing is done, the product is
deployed in the customer
environment or released into the
market.
 Maintenance – There are some
issues which come up in the client
environment. Maintenance is done
to fix the issues and enhance the
product.
2.1.2. Waterfall Model – Application
 Requirements are very well
documented, clear and fixed.
 Product definition is stable.
 There are no ambiguous
requirements.
 The project is short.
Page | 3
MODULE 2: SOFTWARE ENGINEERING PARADIGM
2.1.2. Waterfall Model – Advantages
 Simple and easy to understand and
use.
 Easy to manage due to the rigidity of
the model.
 Phases are processed and
completed at one time.
2.1.3. Waterfall Model – Disadvantages
 No working software is produced
until late during the life cycle.
 High amounts of risk and
uncertainty.
 Not a good model for complex and
object-oriented projects.
 Poor model for long and ongoing
projects.
 Cannot accommodate changing
requirement.
2.2 Iterative Model
This model projects the process of
development in cyclic manner repeating
every step after every cycle of SDLC
process.
The software is first developed on very
small-scale and all the steps are followed
which are taken into consideration. Then, on
every iteration, more features and modules
are designed, coded, tested, and added to
the software.
Every cycle produces a software, which is
complete in itself and has more features
and capabilities than that of the previous
one.
2.2.1 Iterative Model – Applications
 Requirements of the complete
system are clearly defined and
understood.
 Major requirements must be defined.
 A new technology is being used and
is being learnt by the development
team while working on the project.
 Resources with needed skill sets are
not available and are planned to be
used on contract basis for specific
iterations.
2.2.2 Iterative Model – Advantages
 Some working functionality can be
developed quickly and early in the
life cycle.
 Results are obtained early and
periodically.
 Testing and debugging during
smaller iteration will be easy.
 Risks are identified and resolved
during iteration
 Risk analysis is better.
 It supports changing requirements.
2.2.3 Iterative Model – Disadvantages
 More resources may be required.
 Although cost of change is lesser,
but it is not very suitable for
changing requirements.
 System architecture or design issues
may arise because not all
requirements are gathered in the
beginning of the entire life cycle.
 Defining increments may require
definition of the complete system.
 Not suitable for smaller projects.
Page | 4
MODULE 2: SOFTWARE ENGINEERING PARADIGM
2.3 Spiral Model
It is a combination of iterative and
systematic, controlled aspects of the
waterfall model with a very high emphasis
on risk analysis.
This model has four phases:
 Identification – This phase starts
with gathering the business
requirements in the baseline spiral.
In the subsequent spirals as the
product matures, identification of
system requirements, subsystem
requirements and unit requirements
are all done in this phase.
 Design – The Design phase starts
with the conceptual design in the
baseline spiral and involves
architectural design, logical design
of modules, physical product design
and the final design in the
subsequent spirals.
 Construct or Build – It refers to the
production of the actual software
product at every spiral. In the
baseline spiral, when the product is
just thought of and the design is
being developed a POC (Proof of
Concept) is developed in this phase
to get customer feedback. Then in
the subsequent spirals with higher
quality on requirements and design
details a working model of the
software called build is produced
with a version number.
 Evaluation and Risk Analysis –
This includes identifying, estimating,
and monitoring the technical
feasibility and management risks.
After testing the build, at the end of
first iteration, the customer evaluates
the software and provides feedback.
2.3.1 Spiral Model – Application
 When there is a budget constraint
and risk evaluation is important.
 Long-term project commitment
because of potential changes to
economic priorities as the
requirements change with time.
 Customer is not sure of their
requirements which is usually the
case.
 Requirements are complex and
need evaluation to get clarity.
2.3.2 Spiral Model – Advantages
 Changing requirements can be
accommodated
 Allows extensive use of prototypes.
 Requirements can be captured more
accurately.
 Users see the system early.
 Development can be divided into
smaller parts and the risky parts can
be developed earlier which helps in
better risk management.
2.3.2 Spiral Model – Disadvantages
 Management is more complex.
 End of the project may not be known
early.
Page | 5
MODULE 2: SOFTWARE ENGINEERING PARADIGM
 Not suitable for small or low risk
projects and could be expensive for
small projects.
 Large number of intermediate stages
requires excessive documentation.
2.4 V-Model
It is where execution of processes happens
in a sequential manner in a V-shape. It is
also known as Verification and Validation
Model.
There are several verification phases in the
V-model, these are the following:
 Business Requirement Analysis –
It is where the product requirements
are understood from the customer’s
perspective.
 System Design – Once there is a
clear and detailed product
requirement, it is the time to design
the complete system.
 Architectural Design – It is where
the architectural specification is
understood and designed.
 Module Design – It is where the
detailed design for all the system
modules is specified.
 Coding Phase – This is where the
actual coding of the system modules
is done.
 Validation Phase – There are
different validation phases in a V-
Model. These are as follows:
- Unit Testing - Unit tests
designed in the module design
phase are executed on the code
during this validation phase. Unit
testing is the testing at code
level and helps eliminate bugs at
an early stage, though all defects
cannot be uncovered by unit
testing.
- Integration Testing – It is
associated with the architectural
design phase. It is performed to
test the coexistence and
communication of the internal
modules within the system.
- System Testing – It tests the
entire system functionality and
the communication of the system
under development with external
systems.
- Acceptance Testing – It
involves testing the product in
user environment.
2.4.1 V-Model Application
 Requirements are well defined,
clearly documented and fixed.
 Product definition is stable.
 There are no ambiguous or
undefined requirements.
 The project is short.
2.4.2 V-Model – Advantages
 This is a highly-disciplined model
and Phases are completed one at a
time.
 Works well for smaller projects
where requirements are very well
understood.
 Easy to manage due to the rigidity of
the model.
2.4.3 V-Model – Disadvantages
Page | 6
MODULE 2: SOFTWARE ENGINEERING PARADIGM
 High risk and uncertainty.
 Not a good model for complex and
object-oriented projects.
 Not suitable for the projects where
requirements are at a moderate to
high risk of changing.
 Once an application is in the testing
stage, it is difficult to go back and
change a functionality.
 No working software is produced
until late during the life cycle.
2.5 Big Bang Model
It is a process model wherein it does not
follow any specific process. The
development starts with the required money
and efforts as the input, and the output is
the software developed which may or may
not be as per customer requirement.
It comprises of focusing all the possible
resources in the software development and
coding, with very little or no planning.
2.5.1 Big Bang Model – Application
 It is ideal for small projects with one
or two developers working together
 It is also useful for academic or
practice projects.
 It is an ideal model for the product
where requirements are not well
understood.
2.5.2 Big Bang Model – Advantages
 This is a very simple model
 Little or no planning required
 Easy to manage
 Very few resources required
 Gives flexibility to developers
 It is a good learning aid for new
comers or students.
2.5.3 Big Bang Model – Disadvantages
 Very High risk and uncertainty.
 Not a good model for complex and
object-oriented projects.
 Poor model for long and ongoing
projects.
 It can be very expensive if
requirements are misunderstood.
2.6 Agile Model
It is a combination of iterative and
incremental process models with focus on
process adaptability and customer
satisfaction by rapid delivery of working
software product.
The Agile model believes that every project
needs to be handled differently and the
existing methods need to be tailored to best
suit the project requirements.
The Agile thought process had started early
in the software development and started
becoming popular with time due to its
flexibility and adaptability.
2.6.1 Agile vs Traditional SDLC Models
Page | 7
MODULE 2: SOFTWARE ENGINEERING PARADIGM
 Agile is based on the adaptive
software development methods
whereas the traditional SDLC
methods like the waterfall is based
on a predictive approach.
 Adaptive approach is where there
is no detailed planning and there is
clarity on future tasks only in
respect of what features need to be
developed while predictive
approach depends on the
requirement analysis and planning
done in the beginning of cycle.
2.6.2 Agile Model – Advantages
 It is a very realistic approach to
software development.
 Functionality can be developed
rapidly and demonstrated.
 Enables concurrent development
and delivery within an overall
planned context.
2.6.3 Agile Model – Disadvantages
 Not suitable for handling complex
dependencies.
 An overall plan, an agile leader and
agile PM practice is a must without
which it will not work.
 There is a very high individual
dependency, since there is
minimum documentation generated.
2.7 RAD Model
It is based on prototyping and iterative
development with no specific planning
involved.
These are the various phases of the RAD
Model:
 Business Modelling – It is
designed in terms of flow of
information and the distribution of
information between various
business channels.
 Data Modelling – The information
gathered in the Business Modelling
phase is reviewed and analyzed to
form sets of data objects vital for the
business.
 Process Modelling – The data
object sets defined in the data
modelling phase are converted to
establish the business information
flow needed to achieve specific
business objectives as per the
business model.
 Application Generation – The
actual system is built and coding is
done by using automation tools to
convert process and data models
into actual prototypes.
 Testing and Turnover – The
overall testing time is reduced in the
RAD model as the prototypes are
independently tested during every
iteration.
2.7.1 RAD Model – Application
 RAD should be used only when a
system can be modularized to be
delivered in an incremental manner.
 Should be used where the
requirements change during the
project and working prototypes are
to be presented to customer in small
iterations of 2-3 months.
2.7.2 RAD Model – Advantages
 Changing requirements can be
accommodated.
Page | 8
MODULE 2: SOFTWARE ENGINEERING PARADIGM
 Iteration time can be short with use
of powerful RAD tools.
 Productivity with fewer people in a
short time.
 Integration from very beginning
solves a lot of integration issues.
 Increases reusability of
components.
2.7.3 RAD Model – Disadvantages
 Dependency on technically strong
team members for identifying
business requirements.
 Only system that can be
modularized can be built using
RAD.
 Inapplicable to cheaper projects as
cost of Modelling and automated
code generation is very high.
 Suitable for systems that are
component based and scalable.
 Requires user involvement
throughout the life cycle.
2.8 Software Prototyping
It refers to building software application
prototypes which displays the functionality
of the product under development, but may
not actually hold the exact logic of the
original software.
The following is a stepwise approach
explained to design a software prototype:
 Basic Requirement Identification
– It involves the understanding the
very basics product requirements
especially in terms of user interface.
 Developing the Initial Prototype –
The initial prototype is developed in
this stage, where the very basic
requirements are showcased and
user interfaces are provided.
 Review of the Prototype – The
prototype developed is presented to
the customer and other important
stakeholders in the project.
 Revise and Enhance the
Prototype – The feedback and the
review comments are discussed
during this stage and some
negotiations happen with the
customer based on factors like time
and budget constraints and
technical feasibility of the actual
implementation.
2.8.1 Software Prototyping – Types
There are different types of software
prototypes used in the industry. These are
as follows:
 Throwaway/Raping Prototyping –
It is also called as rapid or close
ended prototyping. This type of
prototyping uses very little efforts
with minimum requirement analysis
to build a prototype. Once the actual
requirements are understood, the
prototype is discarded and the
actual system is developed with a
much clear understanding of user
requirements.
 Evolutionary Prototyping – It is
also called as breadboard
prototyping which is based on
building actual functional prototypes
with minimal functionality in the
beginning. The prototype developed
forms the heart of the future
prototypes on top of which the entire
system is built
 Incremental Prototyping – It refers
to building multiple functional
prototypes of the various sub-
systems and then integrating all the
available prototypes to form a
complete system.
Page | 9
MODULE 2: SOFTWARE ENGINEERING PARADIGM

 Extreme Prototyping – It is used in A. Identification

the web development domain.  It
__________1. It refers to building software
consists of three sequential phases.
application prototypes.
First, a basic prototype with all the
existing pages is presented in the __________2. It is a process model
HTML format. Then the data wherein it does not follow any specific
processing is simulated using a process.
prototype services layer. Finally, the
services are implemented and __________3. The requirement gathered in
integrated to the final prototype. the Software Requirement Specification
document is used as an input and software
2.8.2 Software Prototyping – Application architecture that is used for implementing
 It is most useful in development of system development is derived.
systems having high level of user
__________4. It is also referred to as a
interactions such as online
software development life cycle in which it
systems. 
is a development strategy that
 Systems which need users to fill out encompasses the process, methods, and
forms or go through various screens tools.
before data is processed.
__________5. It tests the entire system
functionality and the communication of the
2.8.3 Software Prototyping – Advantages system under development with external
systems.
 Increased user involvement in the
product even before its B. Essay
implementation. 1. Briefly explain each phases of a
 Since a working model of the Software Development Life Cycle.
system is displayed, the users get a
better understanding of the system
being developed.
 Reduces time and cost as the
defects can be detected much
earlier.
2.8.4 Software Prototyping –
Disadvantages
 Risk of insufficient requirement
analysis owing to too much
dependency on the prototype.
 Users may get confused in the
prototypes and actual systems.
 Practically, this methodology may
increase the complexity of the
system as scope of the system may
expand beyond original plans.

V. Test Yourself

Page | 10
MODULE 2: SOFTWARE ENGINEERING PARADIGM

References:

 Software Engineering
Tutorials. Retrieved
from
www.tutorialspoint.co
m/software_engineeri
ng
 SDLC Tutorials.
Retrieved from
https://www.tutorialsp
oint.com/sdlc/
 SDLC (Software
Development Life
Cycle) Phases,
Methodologies,
Process, and Models.
Retrieved from
www.softwaretestingh
elp.com/software-
development-life-
cycle-sdlc/

Page | 11