U & P U.

Patel Department of Computer Engineering

CE343 SOFTWARE ENGINEERING

Chapter 1 INTRODUCTION TO SOFTWARE & SOFTWARE ENGINEERING

Dr. Ashwin Makwana

Date:12th July , 2021

11/26/2021 1
  The software is collection of Integrated programs

 Software consists of carefully-organized instructions and code

written by programmers in any of various special computer
languages.

 Computer programs and associated documentation such as

requirements, design models and user manuals.

11/26/2021 2
 Where can you find software?

11/26/2021 3
 And even in…

11/26/2021 4
  Engineering is the application of scientific and
practical knowledge in order to invent, design,
build, maintain, and improve systems,
processes, etc.

11/26/2021 5
 Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of engineering to software.

A Layered Technology

11/26/2021 6
 Characteristics of software
• Software is developed or engineered; it is not manufactured
in the classical sense

• Software doesn’t “wear out.”

• Although the industry is moving toward component-based construction, most software continues to
be custom built.

11/26/2021 7
 U & P U. Patel Department of Computer Engineering

CE343 SOFTWARE ENGINEERING

Chapter 1 INTRODUCTION TO SOFTWARE & SOFTWARE ENGINEERING

Dr. Ashwin Makwana

Date:13th July , 2021

11/26/2021 8
  A framework that describes the activities performed at each stage of a
software development project.
 A set of activities whose goal is the development or evolution of
software.
 Generic activities in all software processes are:
 Specification - what the system should do and its development 
constraints.
 Development - production of the software system.
 Validation - checking that the software is what the customer  wants.
 Evolution - changing the software in response to changing
demands.

11/26/2021 9
11/26/2021 10
 Software Development Lifecycle in 9 minutes!

https://www.youtube.com/watch?v=i-QyW8D3ei0

11/26/2021 11
 Stages/Phases of SDLC

Feasibility
study

Requiremen
t analysis &
gathering

Design

Coding

Testing

Deployment

Maintenanc
e

11/26/2021 12
 1. Requirements Analysis
Find out what the client want the software to do

11/26/2021 13
 2. Design

Planning the software solution

11/26/2021 14
 3. Implementation

Coding…
11/26/2021 15
 4. Testing

Executing the application trying to find software bugs

11/26/2021 16
 5. Maintenance

Any activity oriented to change an existing software product.

11/26/2021 17
 6. Deployment

11/26/2021 18
 7. Documentation

11/26/2021 19
 U & P U. Patel Department of Computer Engineering

CE343 SOFTWARE ENGINEERING

Chapter 1 INTRODUCTION TO SOFTWARE & SOFTWARE ENGINEERING

Dr. Ashwin Makwana

Date:14th July , 2021

11/26/2021 20
  Waterfall Model
 Incremental Model
 RAD Model
 Spiral Model
 Prototype Model
 V- Model
 Agile (mindset/method)

11/26/2021 21
 .

11/26/2021 22
  Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Good for management control (plan, staff, track)
 Works well when quality is more important than cost or
schedule

11/26/2021 23
  All requirements must be known upfront
 Deliverables created for each phase are considered frozen inhibits
flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the system (until it
may be too late)
11/26/2021 24
  Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
 High risk for new systems because of specification and
design problems

11/26/2021 25
11/26/2021 26
  Whole requirement is divided into various builds
 Multiple development cycles take place here, making the life
cycle a “multi-waterfall” cycle.
 Cycles are divided up into smaller, more easily managed
modules.
 Each module passes through the requirements, design,
implementation and testing phases.
 A working version of software is produced during the first
module, so you have working software early on during the
software life cycle.
11/26/2021 27
  Generates working software quickly and early during the
software life cycle.
 More flexible – less costly to change scope and
requirements.
 Easier to test and debug during a smaller iteration.
 Customer can respond to each built.
 Lowers initial delivery cost.

11/26/2021 28
  Needs good planning and design.
 Needs a clear and complete definition of the whole system before
it can be broken down and built incrementally.
 Total cost is higher than waterfall.

11/26/2021 29
  Requirements of the complete system are clearly defined and
understood.
 Major requirements must be defined; however, some details
can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available

11/26/2021 30
11/26/2021 31
  Rapid Application Development model type of incremental model
 In RAD model the components or functions are developed in
parallel as if they were mini projects.
 The developments are time boxed, delivered and then
assembled into a working prototype.
 This can quickly give the customer something to see and use and
to provide feedback regarding the delivery and their
requirements.

11/26/2021 32
  Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback

11/26/2021 33
  Depends on strong team and individual performances for
identifying business requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.

11/26/2021 34
  RAD should be used when there is a need to create a system
that can be modularized in 2-3 months of time.
 It should be used if there’s high availability of designers for
modeling and the budget is high enough to afford their cost along
with the cost of automated code generating tools.
 RAD SDLC model should be chosen only if resources with high
business knowledge are available and there is a need to produce the
system in a short span of time (2-3 months).

11/26/2021 35
 U & P U. Patel Department of Computer Engineering

CE343 SOFTWARE ENGINEERING

Chapter 1 INTRODUCTION TO SOFTWARE & SOFTWARE ENGINEERING

Dr. Ashwin Makwana

Date:19th July , 2021

11/26/2021 36
  Spiral Model is Meta Model (Why??)
 This model is similar to the incremental model,
with more emphasis placed on risk analysis.
 Four phases: Planning, Risk Analysis,
Engineering and Evaluation.
 A software project repeatedly passes through
these phases in iterations (called Spirals in this
model).
 The baseline spiral, starting in the
planning phase, requirements are
gathered and risk is assessed.
11/26/2021 37
  High amount of risk analysis hence, avoidance of Risk is
enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.

11/26/2021 38
  Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

11/26/2021 39
  When costs and risk evaluation is important
 For medium to high-risk projects
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and
exploration)

11/26/2021 40
 PROTOTYPE MODEL
• The basic idea here is that instead of
freezing the requirements before a design
or coding can proceed, a throwaway
prototype is built to understand the
requirements.
• This prototype is developed based on the
currently known requirements.

11/26/2021 41
 PROTOTYPE MODEL
• By using this prototype, the client can get an “actual feel” of the
system, since the interactions with prototype can enable the client
to better understand the requirements of the desired system.
• Prototyping is an attractive idea for complicated and large systems
for which there is no manual process or existing system to help
determining the requirements.
• The prototype are usually not complete systems and many of the
details are not built in the prototype. The goal is to provide a system
with overall functionality.

11/26/2021 42
 PROTOTYPE MODEL: 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
 Confusing or difficult functions can be identified

11/26/2021 43
 PROTOTYPE MODEL: 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.

11/26/2021 44
 PROTOTYPE MODEL: 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.
 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.
 “Prototype is not always throw-away”- Justification.

11/26/2021 45
 V Model
• The V-model is an SDLC model where
execution of processes happens in a
sequential manner in a V-shape.
• It is also known as Verification and
Validation model.

11/26/2021 46
 V Model
• The V-Model is an extension of the waterfall model
and is based on the association of a testing phase for
each corresponding development stage.
• This means that for every single phase in the
development cycle, there is a directly associated
testing phase.
• This is a highly-disciplined model and the next phase
starts only after completion of the previous phase.

11/26/2021 47
 V-Model Suitability
• V- Model application is almost the same as the waterfall
model, as both the models are of sequential type.

• Requirements have to be very clear before the project

starts, because it is usually expensive to go back and
make changes.

• This model is used in the medical development field, as it

is strictly a disciplined domain. (V&V is imp)

11/26/2021 48
 V-Model Suitability
Pointers suitable scenarios to use the V-Model
• Requirements are well defined, clearly documented and
fixed.
• Product definition is stable.
• Technology is not dynamic and is well understood by the
project team.
• There are no ambiguous or undefined requirements.
• The project is short.

11/26/2021 49
 Comparision of Process Models

Factors Water Iterative Prototype Evolution RAD Spiral

Fall Model Model Model Model Model Model

Cost Costly Low High Low Low Expensive

Simplicity Simple Intermediate Simple Complex Simple Intermediate

Risk Rigid Easily Medium Low Low Low

Managed

Involvement Less High, After High Medium Only at the High

Of user Each beginning
Iteration

Flexibility Rigid Much Highly Medium Easy Flexible

Flexible Flexible

Maintenance Least Maintainable High Less Easily Typical

Maintenance Maintenance Maintainable

Integrity - - - - - -

Security Medium Medium Medium Medium Vital High

Reusability Least Yes Weak Less Yes High

Possible
11/26/2021 50
 Evolutionary Iterative and
Factors Waterfall V-Shaped Spiral Agile
Prototyping Incremental
Unclear User
Poor Poor Good Excellent Good Excellent
Requirement
Unfamiliar
Poor Poor Excellent Excellent Good Poor
Technology
Complex
Good Good Excellent Excellent Good Poor
System
Reliable system Good Good Poor Excellent Good Good
Short Time
Poor Poor Good Poor Excellent Excellent
Schedule
Strong Project
Excellent Excellent Excellent Excellent Excellent Excellent
Management
Cost limitation Poor Poor Poor Poor Excellent Excellent
Visibility of
Good Good Excellent Excellent Good Excellent
Stakeholders
Skills limitation Good Good Poor Poor Good Poor
Documentation Excellent Excellent Good Good Excellent Poor
Component
Excellent Excellent Poor Poor Excellent Poor
reusability

11/26/2021 51