SOFTWARE ENGINEERING

(CSE 2014)

Presidency School of Computer Science and Engineering

(PSCS)

Presidency University
General Instructions
• Follow the below mentioned instructions throughout the semester:
1) Maintain complete discipline in the class room & Be on time to every class.
2) No student will be allowed if they are late (after the scheduled time). So, be in the class before
faculty arrives.
3) Students should start filling the seats from the front rows. There should not be any row left
empty in between and there should not be scattered seating of the students in the classroom.
4) Boys and girls should sit separately, Girls on the right side and boys on the left side as per
the faculty view from the dais.
5) Students should keep their bags beside their chairs, not on the desks or not on their laps.
6) Students should strictly switch off their Mobile phones and keep it in their bags (not even in
their pockets too)
TEXT BOOK AND REFERENCE BOOKS
Text book(s):
 Roger S. Pressman, “Software Engineering – A Practitioner’s
Approach”, VII Edition, McGraw-Hill, 2017.
 Bob Hughes, Mike Cotterell, Rajib Mall, “Software Project
Management”, VI Edition, McGraw-Hill, 2018.

Reference book(s)
 Ian Sommerville, “Software Engineering”, IX Edition, Pearson
Education Asia, 2011.
 Rajib Mall, “Fundamentals of Software Engineering”, VI Edition,
PHI learning private limited, 2014.

Dept. of CSE, SOE, Presidency University

3
 Assessment Schedule
S. Course Outcome Duration
Assessment type Contents Marks Weightage DATE
No Number In Hours

10.09.24 -
1 Surprise Test - 1 Module 1 CO1 30 Mins 10 5%
14.09.24
22.10.24 -
2 Assignment - 1 Module 2 CO2 1 week 10 5%
26.10.24
15.10.24 -
3 Mid Term Module 1 & 2 CO1 & CO2 90 Mins 50 25%
21.10.24
11.11.24 -
4 Surprise Test - 2 Module 3 CO3 30 Mins 10 5%
15.11.24
09.12.24 -
5 Assignment - 2 Module 4 CO4 1 week 10 5%
14.12.24
16.12.24 -
6 Presentation Module 3 & 4 CO3 & CO4 30 Mins 10 5%
20.12.24
CO1, CO2, 05.01.25 -
7 End Term Module – 1 to 4 180 Mins 100 50%
CO3,CO4 15.01.25
CO1: Describe the Software Engineering
principles, ethics and process models
 Module - 1
Introduction to Software Engineering
and
Process Models
Software, Need for Software Engineering, Software Engineering Ethics, Essence of
Software Engineering Practice, Software Development Life Cycle Model, Software
Process Models: Waterfall Model, Evolutionary model, Incremental model, RAD
model, A Process Framework – The Capability Maturity Model Integration (CMMI)
 1.What is a software?
• Instructions (computer programs) that when executed
provide desired function and performance

• Data structures that enable the programs to adequately

manipulate information

• Documents that describe the operation and use of the

programs.
Types of Software
• System Software
 Manages hardware and system resources.
• Includes Operating Systems (e.g., Windows, Linux), device drivers and
utilities.

• Application Software
 Designed for end-users to perform specific tasks.
 Examples: Word processors, web browsers and games.
Types of Software
• Development Software
 Tools for building and maintaining software.
 Includes compilers, debuggers and Integrated Development
Environments (IDEs).

• Embedded Software
 Specialized software for controlling devices and machines.
 Found in devices like microwaves, cars and IoT gadgets.
 What is Software & What is Engineering?

• Software is the programs and routines for a computer or

the program material for an electronic device which make
it run.

• Engineering on the other hand, is all about developing

products, using well-defined, scientific principles and
methods.
 What is Software Engineering?

• As per IEEE, in its standard 610.12-1990, defines

software engineering as the application of a systematic,
disciplined approach for the development, operation, and
maintenance of software
 Characteristics of Software
• To gain an understanding of software, it is important to
examine the characteristics of software that make it
different from other things that human beings build.

• Software is a logical rather than a physical system

element.

• Therefore, software has characteristics that are

considerably different than those of hardware.
 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 assembly, most software continues to be custom
built
L2: Need for Software Engineering

LO: Define Software, Software Engineering,

and need for Software Engineering
 2.Need for Software Engineering
The need of software engineering arises because of higher rate of
change in user requirements and environment on which the software
is working.

This includes:
• To manage Large software
• For more Scalability
• Cost Management
• To manage Dynamic Nature of software
• For better Quality Management
L3: Software Engineering Ethics

LO: State the User and Developer ethics

 3.Software Engineering Ethics - Eight Principles
• Public – Software engineers shall act consistently with the public
interest.

• Client and employer – Software engineers shall act in a manner

that is in the best interests of their client and employer consistent
with the public interest.

• Product – Software engineers shall ensure that their products and

related modifications meet the highest professional standards.

• Judgment – Software engineers shall maintain integrity and

independence in their professional judgment.
 Contd..
• Management – Software engineering managers and leaders shall
subscribe to and promote an ethical approach to the management of
software development and maintenance.

• Profession – Software engineers shall advance the integrity and

reputation of the profession consistent with the public interest.

• Colleagues – Software engineers shall be fair to and supportive of

their colleagues.

• Self – Software engineers shall participate in lifelong learning

regarding the practice of their profession and shall promote an
ethical approach to the practice of the profession.
L4: Essence of Software Engineering
Practice

LO: State the User and Developer ethics

 4.What is the essence of software engineering
practice?
• Essence intuitively describes all common aspects of a
software development endeavor.

• It helps teams understand where they are, what's missing

or what needs to be addressed.

• The essence of software engineering practice might be

described as: understand the problem, plan a solution,
carry out the plan, and examine the result for accuracy.
 Software Practice

• Practice is a broad array of concepts, principles, methods,

and tools that you must consider as software is planned
and developed.

• It represents the details of technical considerations that are

below the surface of the software process the things that
you’ll need to actually build high-quality computer
software.
 The Essence of Software Practice

George Polya, describes:

• Understand the problem (communication and analysis)

• Plan a solution (modeling and software design)

• Carry out the plan (code generation)

• Examine the result for accuracy (testing and quality

assurance).

Dept. of CSE, SOE, Presidency University

22
Understand the Problem

• Who has a stake in the solution to the problem? That is, who
are the stakeholders?
• What are the unknowns? What data, functions, and features
are required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to
represent smaller problems that may be easier to understand?
• Can the problem be represented graphically? Can an analysis
model be created?

Dept. of CSE, SOE, Presidency University

23
Plan the Solution
• Have you seen similar problems before? Are there patterns
that are recognizable in a potential solution? Is there existing
software that implements the data, functions, and features
that are required?
• Has a similar problem been solved? If so, are elements of the
solution reusable?
• Can subproblems be defined? If so, are solutions readily
apparent for the subproblems?
• Can you represent a solution in a manner that leads to
effective implementation? Can a design model be created?

Dept. of CSE, SOE, Presidency University

24
Carry Out the Plan

• Does the solution conform to the plan? Is source code

traceable to the design model?

• Is each component part of the solution provably correct?

Has the design and code been reviewed, or better, have
correctness proofs been applied to algorithm?

Dept. of CSE, SOE, Presidency University

25
Examine the Result

• Is it possible to test each component part

of the solution? Has a reasonable testing
strategy been implemented?

• Does the solution produce results that

conform to the data, functions, and
features that are required? Has the
software been validated against all
stakeholder requirements?

Dept. of CSE, SOE, Presidency University

26
L5: Software Development Life Cycle
Model

LO: Define general SDLC model

5.Core Principles of Software Development Life Cycle
• The Reason It All Exists: Provide value to the customer
and the user.

• KISS: Keep It Simple, Stupid! All design should be as

simple as possible, but no simpler.

• Maintain the product and project “vision”: A clear

vision is essential to the success of a S/W project.

• What you produce, others will consume: Always specify,

design, and implement knowing someone else have to
understand what you are doing.
 Contd..
• Be open to the Future: Never design yourself into a
corner. Always ask “what if,” and prepare yourself for all
possible answers.

• Plan Ahead for Reuse: Planning ahead for reuse reduces

the cost and increases the value of both the reusable
components and the systems.

• Think : Placing clear, complete thought before action

almost always produces better results.
 Software Development Life Cycle (SDLC)

• It is a process used by the software industry to design,

develop and test high quality software's.

• The SDLC aims to produce a high-quality software that

meets or exceeds customer expectations, reaches
completion within times and cost estimates.

• It is also called as Software Development Process.

Dept. of CSE, SOE, Presidency University

30
Software Development Life Cycle (SDLC)

Dept. of CSE, SOE, Presidency University

31
LIFE CYCLE STAGES

 Stage 1: Planning and Requirement Analysis

 Stage 2: Defining Requirements

 Stage 3: Designing the Product Architecture

 Stage 4: Building or Developing the Product

 Stage 5: Testing the Product

 Stage 6: Deployment in the Market and Maintenance

Dept. of CSE, SOE, Presidency University

32
L6: Software Process Models: Waterfall
Model

LO: Define waterfall Model

SDLC models followed in the industry

• Waterfall Model classical

• Iterative Model

• Prototype

• Spiral Model

• Incremental model

Dept. of CSE, SOE, Presidency University

34
 Software Process Model

• A software process model is an abstraction of the actual

process, which is being described.

• It can also be defined as a simplified representation of a

software process.

• Each model represents a process from a specific

perspective
 6.Classical Waterfall Model
• The classical waterfall model is the basic software
development life cycle model.

• It is very simple but idealistic.

• The classical waterfall model divides the life cycle into a

set of phases.

• This model considers that one phase can be started after

the completion of the previous phase.
 Contd..

• The output of one phase will be the input to the next

phase.

• The development process can be considered as a

sequential flow in the waterfall.

• Here the phases do not overlap with each other.

Classical Waterfall Model

Dept. of CSE, SOE, Presidency University

38
 Classical Waterfall model Phases
Feasibility Study:
• To determine whether it would be financially and
technically feasible to develop the software.
• This involves understanding the problem
• Determining the various possible strategies to solve the
problem.
• Identified solutions are analyzed based on their benefits
and drawbacks.
• The best solution is chosen and all the other phases are
carried out as per this solution strategy.
Feasibility Study:
 Classical Waterfall model Phases

Requirements analysis and specification:

• To understand the exact requirements of the customer and
document them properly.

• This phase consists of two different activities.

• Requirement gathering and analysis
• Requirement specification
• Software requirement specification (SRS) document.
 Classical Waterfall model Phases
Design:
• To convert the requirements acquired in the SRS into a
format that can be coded in a programming language.
• It includes high-level and detailed design as well as the
overall software architecture.
Coding and Unit testing:
• Software design is translated into source code.
• Unit testing - To check whether each module is working
properly or not.
 Classical Waterfall model Phases
Integration and System testing:
• Integration of different modules are undertaken soon after
they have been coded and unit tested.

System testing:
• Alpha testing - performed by the development team.
• Beta testing - performed by a friendly set of customers.
• Acceptance testing - customer performs acceptance testing
to determine whether to accept the delivered software or
reject it.
 Classical Waterfall model Phases

Maintenance:
• Most important phase of a software life cycle.
• The effort spent on maintenance is 60% of the total effort
spent to develop a full software.

Three types of maintenance :

• Corrective Maintenance - carried out to correct errors that
were not discovered during the product development phase.
 Classical Waterfall model Phases

• Perfective Maintenance - carried out to enhance the

functionalities of the system based on the customer’s
request.

• Adaptive Maintenance - carried out to port the software to

work in a new environment such as working on a new
computer platform or with a new operating system.
 Advantages of Classical Waterfall Model
• Simple and easy to understand.
• Phases are processed one at a time.
• Each stage is clearly defined.
• Very clear and well-understood milestones.
• Process, actions and results are very well documented.
• Reinforces good habits: define-before- design, design-
before-code.
• Works well for smaller projects and projects where
requirements are well understood
Drawbacks of Classical Waterfall Model

• No feedback path

• Difficult to accommodate change requests

• No overlapping of phases
Iterative Waterfall Model
• The classical waterfall model is hard to use.

• The Iterative waterfall model can be thought of as incorporating the

necessary changes to the classical waterfall model to make it usable
in practical software development projects.

• The iterative waterfall model provides feedback paths from every

phase to its preceding phases, which is the main difference from the
classical waterfall model.
Iterative Waterfall Model
Advantages of Iterative Waterfall Model :

• Feedback Path

• Simple

• Cost-Effective

• Well-organized
Drawbacks of Iterative Waterfall Model :

• Incremental delivery not supported

• Overlapping of phases not supported

• Risk handling not supported

• Limited customer interactions

L7: Evolutionary model

LO: Define the evolutionary model

 7. Evolutionary Models
• Usually a set of core product or system requirements is
known, but the details and extension have yet to be
defined.

• To accommodate a product that evolved over time.

• It is iterative that enables you to develop increasingly

more complete version of the software.

• Types: Prototyping and Spiral models.

Dept. of CSE, SOE, Presidency University

53
 Evolutionary Models - Prototyping

• When to use: Customer defines a set of general

objectives but does not identify detailed requirements.
Or
• Developer may be unsure of the efficiency of an
algorithm.

• Advantages: Both stakeholders and software engineers

like the prototyping paradigm.

Dept. of CSE, SOE, Presidency University

54
 Evolutionary Models - Prototyping
• Users get a feel for the actual system, and developers
get to build something immediately.

• Engineers may make compromises in order to get a

prototype working quickly.

• The less-than-ideal choice may be adopted forever after

you get used to it.

Dept. of CSE, SOE, Presidency University

55
Evolutionary Models - Prototyping
 Evolutionary Models - Prototyping
• One of the most popularly used Software Development
Life Cycle Models.

• When to use: when the customers do not know the exact

project requirements beforehand.

• Prototype of the end product is first developed, tested and

refined as per customer feedback repeatedly till a final
acceptable prototype is achieved.
Evolutionary Models - Prototyping

Quick
plan
communication

Modeling
Quick design

Deployment
delivery &
feedback Construction
of prototype

Dept. of CSE, SOE, Presidency University

58
Evolutionary Models - Spiral

Dept. of CSE, SOE, Presidency University

59
Cont..
• Spiral model is a risk driven process model.
• It is used for generating the software projects.
• In spiral model, an alternate solution is provided if
the risk is found in the risk analysis, then alternate
solutions are suggested and implemented.
• It is a combination of prototype and sequential
model or waterfall model.
• In one iteration all activities are done, for large
project's the output is small.
 Evolutionary Models - Spiral
• It couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model.

• Features:
• Cyclic approach
• Incrementally growing a system’s degree of
definition
• Implementation while decreasing its degree of
risk.
• Set of anchor point milestones for feasible
solutions.

Dept. of CSE, SOE, Presidency University

61
L8: Incremental model

LO: Define the Incremental model

8. Incremental Model

Dept. of CSE, SOE, Presidency University

63
 The Incremental Model

• Process of software development where requirements

divided into multiple standalone modules.

• Each module goes through the requirements, design,

implementation and testing phases.

• Every subsequent release of the module adds function to

the previous release.

• The process continues until the complete system

achieved.

Dept. of CSE, SOE, Presidency University

64
 The Incremental Model
• It combines elements of linear and parallel process flows.

• Each linear sequence produces deliverable increments of

the software.

• The first increment is often a core product with many

supplementary features.

• Users use it and evaluate it with more modifications to

better meet the needs.

Dept. of CSE, SOE, Presidency University

65
 The Incremental Model
1. Requirement analysis:
• Identifies the requirements.
• The system functional requirements are understood by the
requirement analysis team.
• Develop the software under the incremental model.
2. Design & Development:
• The design of the system functionality and the development method
are finished with success.
• When software develops new practicality, the incremental model
uses style and development phase.

Dept. of CSE, SOE, Presidency University

66
 The Incremental Model
3. Testing:
• The testing phase checks the performance of each existing function
as well as additional functionality.
• Various methods are used to test the behavior of each task.

4. Implementation:
• After completion of this phase, the number of the product working
is enhanced and upgraded up to the final system product

Dept. of CSE, SOE, Presidency University

67
 The Incremental Model

When we use the Incremental Model?

• When the requirements are superior.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or
trained.
• When the customer demands a quick release of the
product.
• You can develop prioritized requirements first.

Dept. of CSE, SOE, Presidency University

68
 The Incremental Model - Advantages

• Errors are easy to be recognized.

• Easier to test, debug and more flexible.

• Simple to manage risk because it handled during its

iteration.

• The Client gets important functionality early.

 The Incremental Model - Disadvantages

• Need for good planning

• Total Cost is high.

• Well defined module interfaces are needed.

L9: RAD model

LO: : Define the RAD model

 9.The RAD Model

• RAD is a linear sequential model

• This emphasizes a concise development cycle using an
element based construction approach.
• If the requirements are well understood and described,
and the project scope is a constraint
• This model enables to create a fully functional system within a concise time
period.

Dept. of CSE, SOE, Presidency University

72
 The RAD Model

Products can be developed faster and of higher quality through:

• Gathering requirements using workshops or focus groups
• Prototyping and early, reiterative user testing of designs
• The re-use of software components
• A rigidly paced schedule that refers design improvements
to the next product version
• Less formality in reviews and other team communication

Dept. of CSE, SOE, Presidency University

73
The RAD Model
 The RAD Model

When to use RAD Model?

• To create the project that modularizes in a short span time
(2-3 months).
• When the requirements are well-known.
• When the technical risk is limited.
• It should be used only if the budget allows the use of
automatic code generating tools.

Dept. of CSE, SOE, Presidency University

75
 The RAD Model - Advantages

• Changes are adoptable.

• Each phase in RAD brings highest priority functionality

to the customer.

• Reduced development time.

• It increases the reusability of features.

 The RAD Model - Disadvantages

• Requires highly skilled designers.

• All application is not compatible with RAD.

• Can’t use for smaller projects.

• Required user involvement.

L10: A Process Framework – The
Capability Maturity Model Integration
(CMMI)

LO: Explain CMMI and it’s types

 10.Maturity Model
• A model with which Organizations can judge their process
and based on this judgment can improve their process.
 Started in 1986 by the Software Engineering Institute
(SEI)
 Developed Process Maturity Framework and a maturity
questionnaire
 Refined to Capability Maturity Model (CMM)
 Revised maturity framework (CMMI)
Immature Software Organization

 No objective basis for judgment of product quality

 No objective basis for improvement of product or

process quality

 Reviews and tests are often skipped when projects run

behind schedule

 Ad hoc management
Mature Software Organization
 Organization has wide knowledge to manage software
development, employment and improvement

 Processes are ‘fit-for-use’

 Processes are being adapted to the situation

 Tasks and responsibilities are clear for the project and

anyone in the organization
The staged CMMI model
Dig:
 Level 1: Initial
The software process can be described as ad-hoc

 Success depends on individual input and achievements

 Not predictable regarding results

 Schedules, budget, functionality and product quality is not

predictable

Can be successful in highly innovative environment.

84
 Level 2: Repeatable
The basic project management procedures are used
 Costs, schedules en functionality are ‘tracked’

 Planning and managing of new projects are based on experience

with comparable projects

 Software requirements and work products are ‘baselined’

Planning and tracking are stable and thus previous successes can be
repeated

85
 Level 3: Defined
 Processes are documented, standardized and integrated in a
standard software development process

 Use an approved, adapted version of the standard software process

for the development and maintenance

 More effective

 The software process is stable and well defined and is able to

operate more effectively

86
 Level 4: Quantitatively managed
 Detailed metrics of the software processes and quality of products
are gathered

 Quantitative goals are set for the software process and the product
quality

 Projects have a control over the software process and product

quality

 Risks of development in new technical environments are

recognized and managed

87
Level 5: Optimizing
 Software process improvements are realized by feedback

 The whole organization is focused on continuous improvement

 Data regarding performance of the processes are used for cost-

benefit analyses

 Best software engineering practices - spread over the whole

organization
 Software project teams analyze errors & ‘Lessons learned’ are
shared with other projects

88
 Topic Names Unit Number Mapping with Text Books Mapping with Website Links Mapping with NPTEL

Software Page 33, Software Engineering: A Practitioner's

Unit 1 Approach By Pressman https://www.geeksforgeeks.org/s
oftware-engineering-introduction-
to-software-engineering/

Page 41, Software Engineering: A Practitioner's

Need for Software Engineering, Unit 1 Approach by Pressman https://www.geeksforgeeks.org/w
 Page 867, Software Engineering: A Practitioner's
Software Engineering Ethics Unit 1 Approach by Pressman https://www.computer.org/educati
on/code-of-ethics

Essence of Software Engineering Page 46, Software Engineering: A Practitioner's

Practice Unit 1 Approach by Pressman https://www.summaryplanet.com/i
nformation-technology/Software-En
gineering-Practice.html#google_vig
nette

Page 67, Fundamentals of Software Engineering,

Software Development Life Cycle Model Unit 1 Fourth Edition, Rajib Mall https://www.geeksforgeeks.org/sof https://www.youtube.com/wa
tware-development-life-cycle-sdlc/ tch?v=OT2O7uNldQk&list=PLb
RMhDVUMngf8oZR3DpKMvYh
ZKga90JVt&index=6

https://www.youtube.com/
watch?
v=zKWeXjpFeRw&list=PLbRMh
Page 38, Fundamentals of Software Engineering, DVUMngf8oZR3DpKMvYhZKga
Software Process Models: Waterfall Model Unit 1 Fourth Edition, Rajib Mall https://www.javatpoint.com/softwa 90JVt&index=8
 https://www.youtube.com/
watch?
v=XKW9TWrxxPo&list=PLbRM
Page 57, Fundamentals of Software Engineering, hDVUMngf8oZR3DpKMvYhZKg
Evolutionary model Unit 1 Fourth Edition, Rajib Mall https://www.javatpoint.com/evoluti a90JVt&index=11
onary-model-in-software-engineeri
ng

https://www.youtube.com/
watch?
v=xl9Rtc4Ga1U&list=PLbRMhD
Page 55, Fundamentals of Software Engineering, VUMngf8oZR3DpKMvYhZKga9
Incremental model Unit 1 Fourth Edition, Rajib Mall https://www.javatpoint.com/softwa 0JVt&index=10
re-engineering-incremental-model

Page 59, Fundamentals of Software Engineering,

RAD model Unit 1 Fourth Edition, Rajib Mall https://www.tutorialspoint.com/sdl https://www.youtube.com/wa
c/sdlc_rad_model.htm tch?v=XKW9TWrxxPo&list=PLb
RMhDVUMngf8oZR3DpKMvYh
ZKga90JVt&index=11

A Process Framework – The Capability Page 826, Software Engineering: A Practitioner's

Maturity Model Integration (CMMI) Unit 1 Approach by Pressman https://www.geeksforgeeks.org/cap https://www.youtube.com/wa
ability-maturity-model-integration-c tch?v=OXd1IwTW2So
mmi/