University Institute of Engineering

DEPARTMENT OF COMPUTER SCIENCE

& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

INTRODUCTION TO SOFTWARE DISCOVER . LEARN . EMPOWER

ENGINEERING
 Topics covered
Software Development life Cycle models

Waterfall model

Iterative Waterfall model

Prototype model

Evolutionary model

Spiral model
2
 Software life cycle model

• A software life cycle model is a descriptive and diagrammatic

representation of the software life cycle.

• A life cycle model represents all the activities required to make a

software product transit through its life cycle phases.

• It captures the order in which these activities are to be undertaken.

3
CPU Classical Waterfall Model
• Classical waterfall model divides life cycle into phases:
• feasibility study,
• requirements analysis and specification,
• design,
• coding and unit testing,
• integration and system testing,
• maintenance.

4
CLASSICAL WATERFALL MODEL

Fig 1 Classical Waterfall Model

5
 FEASIBILITY STUDY
• Main aim of feasibility study: determine whether developing the
product
• financially worthwhile
• technically feasible.
• First roughly understand what the customer wants:
• different data which would be input to the system,
• processing needed on these data,
• output data to be produced by the system,
• various constraints on the behaviour of the system.

6
 FEASIBILITY STUDY
• Work out an overall understanding of the problem.
• Formulate different solution strategies.
• Examine alternate solution strategies in terms of:
• resources required,
• cost of development, and
• development time.

7
 REQUIREMENT ANALYSIS AND
SPECIFICATION
• Aim of this phase:
• understand the exact requirements of the customer,
• document them properly.
• Consists of two distinct activities:
• requirements gathering and analysis
• requirements specification.

8
 REQUIREMENT GATHERING
• Gathering relevant data:
• usually collected from the end-users through interviews and
discussions.
• For example, for a business accounting software:
• interview all the accountants of the organization to find out their
requirements.

9
 REQUIREMENT ANALYSIS
• The data you initially collect from the users:
• would usually contain several contradictions and ambiguities:
• each user typically has only a partial and incomplete view of the
system.

10
 DESIGN
• Design phase transforms requirements specification:
• into a form suitable for implementation in some programming
language.
• In technical terms:
• during design phase, software architecture is derived from the
SRS document.
• Two design approaches:
• traditional approach,
• object oriented approach.

11
 IMPLEMENTATION
• Purpose of implementation phase (aka coding and unit testing phase):
• translate software design into source code.
• During the implementation phase:
• each module of the design is coded,
• each module is unit tested
• tested independently as a stand alone unit, and debugged,
• each module is documented.

12
 INTEGRATION AND SYSTEM TESTING
• Different modules are integrated in a planned manner:
• modules are almost never integrated in one shot.
• Normally integration is carried out through a number of steps.
• During each integration step,
• the partially integrated system is tested.
• After all the modules have been successfully integrated and tested:
• system testing is carried out.
• Goal of system testing:
• ensure that the developed system functions according to its requirements as
specified in the SRS document.

13
 MAINTENANCE
• Maintenance of any software product:
• requires much more effort than the effort to develop the product
itself.
• development effort to maintenance effort is typically 40:60.

14
Advantages
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well
understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
15
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.
• Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.

16
Application
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the
product.
• The project is short.

17
 ITERATIVE WATERFALL MODEL
• 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.
• 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.

18
ITERATIVE WATERFALL MODEL

Fig 2 Iterative Waterfall Model

19
 PROTOTYPING MODEL
• Before starting actual development,
• a working prototype of the system should first be built.
• A prototype is a toy implementation of a system:
• limited functional capabilities,
• low reliability,
• inefficient performance.
• Start with approximate requirements.
• Carry out a quick design.
• Prototype model is built using several short-cuts:
• Short-cuts might involve using inefficient, inaccurate, or dummy functions.
• A function may use a table look-up rather than performing the actual computations.

20
PROTOTYPING MODEL

Fig 3 Prototype model

21
Prototype Model

Fig 4 Steps of prototype model

22
Advantages
• Users are actively involved in the development
• Since in this methodology a working model of the system is provided,
the users get a better understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily

23
Disadvantages
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as the
full system was designed Incomplete or inadequate problem analysis.

24
When to use
• Prototype model should be used when the desired system needs to
have a lot of interaction with the end users.
• Typically, online systems, web interfaces have a very high amount of
interaction with end users, are best suited for Prototype model. It
might take a while for a system to be built that allows ease of use and
needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the
system and provide a feedback which is incorporated in the prototype
to result in a useable system. They are excellent for designing good
human computer interface systems.

25
 Evolutionary Model
• Evolutionary model (aka successive versions or incremental model):
• The system is broken down into several modules which can be incrementally
implemented and delivered.
• First develop the core modules of the system.
• The initial product skeleton is refined into increasing levels of capability:
• by adding new functionalities in successive versions.
• Successive version of the product:
• functioning systems capable of performing some useful work.
• A new release may include new functionality:
• also existing functionality in the current release might have been
enhanced.
26
Evolutionary Model

Fig 5 Evolutionary Model

27
 Spiral Model
• Each loop of the spiral represents a phase of the software process:
• the innermost loop might be concerned with system feasibility,
• the next loop with system requirements definition,
• the next one with system design, and so on.
• The team must decide:
• how to structure the project into phases.
• Start work using some generic model:
• add extra phases
• for specific projects or when problems are identified during a project.
• Each loop in the spiral is split into four sectors (quadrants).

28
Spiral Model

Fig 6 Spiral Model

29
 Spiral Model
• Identify objectives of the phase,
• Examine the risks associated with these objectives.
• Risk:
• any adverse circumstance that might hamper successful
completion of a software project.
• Find alternate solutions possible.

30
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.

31
Disadvantages
• Management is more complex.
• End of the project may not be known early.
• Not suitable for small or low risk projects and could be expensive for
small projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive
documentation.

32
 APPLICATIONS
• Managing clients requirements in industry.
• Generating software for noticing health activities with novel smart
technologies.
• Content Management and to analyzing Fraud detection and Prevention
• Advertisements Targeting Platforms Managing content, posts, images and
videos on social media platforms
• Analyzing customer data in real-time for improving business performance
• Public sector fields such as intelligence, defense, cyber security and
scientific research

33
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
4. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson
and Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
5. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.

Reference Website
6. https://www.javatpoint.com/software-engineering-sdlc-models

34
 IMAGE REFERENCES
• Fig 1 https://www.javatpoint.com/software-engineering-sdlc-models
• Fig 2 https://flexagon.com/blog/7-software-development-models-
you-should-know/
• Fig 3 https://www.javatpoint.com/software-engineering-sdlc-models
• Fig 4 https://flexagon.com/blog/7-software-development-models-
you-should-know/
• Fig 5 https://www.javatpoint.com/software-engineering-sdlc-models
• Fig 6
http://swebokwiki.org/Chapter_9:_Software_Engineering_Models

35
THANK YOU