Software Engineering

By:
Dr. Dashrath Mahto
Assistant Professor
Computer Science & Engineering
NIT, Patna
Text/Reference Books:
1. Fundamentals of Software Engineering by Rajib Mall, PHI
2. Software engineering by James F. Peters, Wiley
3. Software engineering A Practitioner’s Approach by Pressman , MGH
4. Software Project Management From Concept to Deployment by
Kieron Conway, Dreamtech Press
5. Software engineering, by Sommerville, Pearson education.
 Note

• Marks Distribution
- Credits : 4
- Teacher Assessment (Class Test, Assignment): 10 Marks
- Mid Semester Exam : 30 Marks
- End Semester : 60 Marks
• Minimum Attendance: 75%
 Introduction
• Software : Executable code, designed for some computational purpose.

-Executable Programming code, associated libraries and documentation.

-Computational purpose like accounting software’s, media players etc.

• Software Product: When software is designed for the specific requirements.

• Engineering: It deals with developing products, using well defined scientific

products and methods.
 Cont’d
• Software Engineering: Application of engineering principles to develop software.
IEEE Definition: “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.”
❖ Objective: Produce reliable, maintainable and software within time and budget constraints.
❖ Steps: Plan, Design, Write Code, Test, and Maintain Software.
❖ Need: Handling big projects, managing the cost (by removing unnecessary things), Reliable
software delivery, Reduces complexity ( large challenges are broken down into smaller ones and
solve one at a time in engineering problems).
 Software Engineering Discipline: Evolution &
Impact
Evolution:
Origins: Began in the 1960 to solve the software development problems focusing on better
tools and methods.
Key Milestone:
✔ In 1968, term “Software engineering” was created at NATO (North Atlantic Treaty
Organization) conference.
✔ Structured and modular programming has been developed.
✔ Object oriented programming introduced.
 Cont’d
Principles/ Basic Idea:
Current Trends:
✔ Systematic approach for creating software
✔ Focus on quality, easy maintenance and ✔ Increased use of AI and ML.
guidance.
✔ Focus on cyber security and data theft
Impact:
✔ Expansion of cloud computing and SaaS
✔ Better software reliability and productivity
(software as a service)
✔ Improved team collaboration
✔ IoT, Microservices, Serverless
✔ Capability to build larger and complex
computing
system

✔ Shift from manual to automated process

 Program vs Software Product
Aspect Program Product
Set of instructions designed for Final manufacture and production of
Nature/Purpose completing specific task the project
Exist at a single and continues to Exist for a long period of time, it
Existence exist until it is deleted will stop existing if it is deleted and
uninstalled.
Lot of time required ( includes
Development Shorter period of time several stages like design, coding,
Time testing, maintenance etc. )
Doesn’t requires any resources,
Resource only need memory space for It need human, technology etc.
requirements storing instructions
 Cont’d
Aspect Program Product
Desired output is Main focus of a product is its capability
Focus generated or not to solve the problem that it was designed
for.
It needs lot of time (several steps
Development Shorter period of time involved : design, coding, testing etc.)
Time
 Need: Program vs Product
✔ Improving design and development

✔ Facilitates the development of products and software that work well with other systems
and technologies.

✔ Helps identify what users need and how to meet those needs effectively.

✔ Focuses on techniques to ensure that products and software are reliable, secure, and
perform well.

✔ Enhances the ability to create high-quality, user-friendly products and software.

 Emergence of Software Engineering
✔ In the beginning software programming is done by individuals/teams based on their previous
knowledge and experience.

✔ The above approach is termed as “ programming by intuition” or “hacking”.

✔ Later it was realized that more structured and systematic approach is required because as the
computing field grew it becomes apparent this approach was not sustainable.

✔ In the 1960s and 1970s the field of software engineering began to take shape.

✔ In 1968, a conference on “NATO software engineering conference” was held and the term
“software engineering” was officially coined.
 Cont’d
✔ 1980’s : Object oriented programming introduced led to a shift in how software designed
and developed.

✔ 1990’s: Emergence of the agile software development methodologies & tools.

✔ 2000’s: Widespread adoption of agile practices across the industry, Rise of open source
and collaborative models.

✔ 2010: Expansion of cloud services and infrastructure, Mobile development.

✔ 2020: Integration of AI & ML in software products, Cybersecurity

 (Cont’d)
• Early Computer Programming: Early commercial computers were very slow and
too elementary as compared to today’s standards
✔ Traditionally Build & Fix/ Exploratory approach has been used. Software is developed
without any specifications and it is then repeatedly modified until software satisfies the
user.

✔ Two phases:

Build: Software code is developed and passed on to the next phase.

Fix: Code implemented/developed in above phase made error free, and also code is
modified according to the user’s need.

Objective: To identify the issue and then fix it as soon as possible.

 (Cont’d)
Steps Involved:
1. Start
2. Initial product development
3. Delivery to user
4. Function present ?
if yes, Software accepted
if No, Modify software
5. Repeat delivery and evaluation

Fig 1: Build and Fix Model step until user is satisfied

(source:
https://ecomputernotes.com/images/Build-and-Fix-Model.jpg)
 (Cont’d)
• Software life cycle has two stages:

1. Inception: Customers feels the need for the software and forms rough ideas about the
required features.

2. Maintenance: Only concerned with bug-fix and change request from the user.
Module II : Software Life Cycle
Models
 Introduction : Software Development Life Cycle
Models (SDLC)
• In contrast to the build and fix style, the software engineering approach emphasize software development through a well defined
and ordered set of activities. Software engineering techniques are based on the principles of error prevention.

• These set of activities when graphically modeled/represents and textually described are called as software life cycle model or
software development life cycle (SDLC) model or software development process.

• SDLC is a framework defining tasks performed at each step during software development process.

• Purpose: To ensure the development process is systematic, efficient and meets user requirements and quality standards.

• Benefits:
Facilitates better project management and control
Provides clear strategic plan defining goal and includes the major steps needed to fulfil the objective.
Helps in identifying and mitigating the risk early.
 SDLC Phases

Fig 2. Phases of SDLC

(Source: https://www.geeksforgeeks.org/software-development-life-cycle-sdlc/)
 (Cont’d)
✔ Requirement analysis, Planning & Defining: Gather and document user requirements
followed by requirement identification of customers.
✔ Designing: Create architectural and detailed design specifications followed by
development of prototypes and models.
✔ Building /Product Development: The programming code is generated as per the DDS
(Design document specifications).
✔ Testing: At this stage product defects are reported, tracked, fixed and retested until the
product reaches the quality standards.
✔ Deployment: After the functional and non-functional testing, the product is deployed
in the customer environment or released into the market.
 SDLC Models
There are following types of software development models having series of unique steps
ensuring success during software development. These are:

❖ Waterfall
• Classical and Iterative
❖ Prototype

❖ Evolutionary

❖ Spiral
 Waterfall Model
It is one of the simplest and oldest SDLC models. It is called as "Waterfall" because the
process flows in a linear, sequential manner, similar to how water flows down a waterfall.

✔ Key Characteristics
▪ Linear & Sequential: Each phase of the development process flows into the next
phase
▪ Defined Stages: Model consists distinct phases with specific deliverables and review
process.
▪ No Overlapping: Phases do not overlap. Each phase is complete before starting of
next phase.
 Classical Waterfall Model

Fig 3. Phases of Classical Waterfall Model

(Source: https://www.geektonight.com/classical-waterfall-model-software-engineering/ )
 Classical Waterfall Model (Cont’d)
• Classical waterfall model is intuitively the most obvious way to develop software.
• It simple but idealistic.
• Classical waterfall model has no provision to go back to modify the artifacts
produced during an earlier phase.
• The classical waterfall model divides the life cycle into six phases.
• The six different phases are—feasibility study, requirements analysis and
specification, design, coding and unit testing, integration and system testing, and
maintenance.
• The phases starting from the feasibility study to the integration and system
testing phase are known as the development phases.
• The last phase is also known as the maintenance phase of the life cycle.
 Classical Waterfall Model (Cont’d)

• In the waterfall model, different life cycle

phases typically require relatively different
amounts of efforts to be put in by the
development team.
• Among all the life cycle phases, the
maintenance phase normally requires the
maximum effort.
• On the average, about 60 per cent of the
total effort put in by the development team in
the entire life cycle is spent on the
maintenance activities alone.
• Therefore % effort ratio of development and
maintenance phase is 40:60

Fig 4. Relative effort distribution among different phases of a typical product

(Source: Mall, Rajib. Fundamentals of software engineering. PHI Learning Pvt. Ltd., 2018.)
 Feasibility Study
• The main focus of the feasibility study stage is to determine whether it would be financially and
technically feasible to develop the software.
-Financially worthwhile
-Technically feasible

• The feasibility study involves carrying out several activities such as collection of basic information
relating to the software such as the different data items that would be input to the system.
• The processing required to be carried out on these data, the output data required to be produced by the
system, as well as various constraints on the development.
• These collected data are analyzed to perform the following:
✔ Development of an overall understanding of the problem
✔ Formulation of various possible strategies for solving the problem
✔ Evaluation of the different solution strategies
 Requirement Analysis & Specification
• Aim: understand the exact requirements of the customer

- Document them properly.

• It consists of two distinct activities:

1. Requirements gathering and analysis

2. Requirement specification
 1. Requirements gathering and analysis
❖ Requirements Gathering: Possible requirements of the system to be developed are
captured and documented in a requirement specification document.

• Goal: To collect all relevant information regarding the software to be developed from the
customer with a view to clearly understand the requirements and document all functional and
non-functional requirements from customers.
• For this, first requirements are gathered from the customer and then the gathered requirements
are analysed.
- usually collect 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.
 Cont’d
❖ Requirement Analysis: Collect all related data from the customer.

-analyze the collected data to clearly understand what the customer wants

-find and resolve any inconsistencies and incompleteness in the requirements.

• An inconsistent requirement is one in which some part of the requirement contradicts.

• An incomplete requirement is one in which some parts of the actual requirements

have been omitted.

• Goal: To weed out the incompleteness and inconsistencies in these

gathered requirements
 2. Requirement Specification
❖ Requirement Specification:

-documenting the analyzed requirements in a clear, detailed and structured format.

-resulting in a formal document that serves as a reference for the design and development
phases.

• After the requirement gathering and analysis activities are complete, the identified
requirements are documented. This document is called a software requirements
specification (SRS) document.

• The SRS document is written using end-user terminology. This makes the SRS
document understandable to the customer.
 Design
• System Design: After the analysis of requirement specification phase system design is prepared. This system design
helps in specifying hardware and system requirements and helps in defining the overall system architecture.

• Goal: To transform the requirements specified in the SRS document into a structure that is suitable for implementation
in some programming language.

• In technical terms, during the design phase the software architecture is derived from the SRS document.

• Two design approaches:

1. Procedural / Traditional design approach: It consists of two important activities:
• Structured analysis: the data flow structure of the problem is examined and modelled.
• Structured design: the functional requirements specified in the SRS document are decomposed into subfunctions and the
data-flow among these subfunctions is analyzed and represented diagrammatically in the form of DFDs.

2. Object-oriented design approach:

 Cont’d
• Structured analysis
- identify all the functions to be performed
-identify dataflow among the functions
- structured analysis is carried out using Data Flow Diagram

• Data Flow Diagram (DFD): Representation of the flow of data through a process or
system. It is used to show:
- where data comes from and goes
- which activity transform data
- which outputs are stored in system
- which outputs are utilized by other activities/entities
Fig 5: Example for DFD : Railway Reservation System
 Cont’d
• Structured Design:
- architectural design/high level design
- detailed design/low level design
• High level design:
-Decompose the system into modules.
-Represent the relationship between the module
• Low Level Design:
- different modules designed in greater detail
-data structures and algorithms for each module Fig 6: HLD vs LLD
are designed
 Cont’d
• Object Oriented Design

- identify various objects (real world entities) occurring in the problem

- identify the relationship among the objects

For Example: the objects in a payroll software may include: employees, managers,
working hour, department.
 Coding and unit testing (Implementation Phase)
• The coding phase is also sometimes called the implementation phase, since the design is
implemented into a workable solution.

• Each component of the design is implemented as a program module. The end-product of

this phase is a set of program modules that have been individually Unit Tested.

• Implementation: With inputs from the system design, the system is first developed in
small programs called units, which are integrated in the next phase. (Divide & Conquer)
 Coding and unit testing (Cont’d)
• Unit Testing: Each unit is developed and tested for its functionality, which is referred to as Unit Testing.

• The main objective of unit testing is to determine the correct working of the individual modules.

• The specific activities carried out:

✔ designing test cases,

✔ testing,

✔ debugging to fix problems,

✔ management of test cases.

 Integration and System Testing
Integration of different modules is undertaken soon after they have been coded and unit
tested.

During the integration and system testing phase, the different modules are integrated in a
planned manner. Post integration the entire system is tested for any faults and failures.

During each integration step, previously planned modules are added to the partially
integrated system and the resultant system is tested.

Finally, after all the modules have been successfully integrated and tested, the full working
system is obtained. System testing is carried out on this fully working system.
 Integration and System Testing (Cont’d)
• System testing usually consists of three different kinds of testing activities:

1. α-testing: a testing is the system testing performed by the development team.

2. β-testing: This is the system testing performed by a friendly set of customers.

3. Acceptance testing: After the software has been delivered, the customer performs

• System testing to determine whether to accept the delivered software or to

reject it.
 Maintenance
• There are some issues which come up in the client environment. To fix those issues,
patches are released. For product enhancement better versions are released. Maintenance is
done to deliver these changes in the customer environment.
• The ratio of relative effort of developing a typical software product and the total effort
spent on its maintenance is roughly 40:60
• Maintenance is required in the following three types of situations:
• Corrective maintenance: This type of maintenance is carried out to correct errors that
were not discovered during the product development phase.
• Perfective maintenance: This type of maintenance is carried out to improve the
performance of the system, or to enhance the functionalities of the system based on
customer’s requests.
• Adaptive maintenance: Adaptive maintenance is usually required for porting the software
to work in a new environment.
• For example, porting may be required to get the software to work on a new computer platform or with a new
operating system.
Shortcomings of the classical waterfall model
• No feedback paths: the evolution of a software from one phase to the next is
analogous to a waterfall. Just as water in a waterfall after having flowed down cannot
flow back, once a phase is complete, the activities carried out in it and any artifacts
produced in this phase are considered to be final and are closed for any rework.
• Difficult to accommodate change requests: This model assumes that all customer
requirements can be completely and correctly defined at the beginning of the project.
There is much emphasis on creating an unambiguous and complete set of
requirements.
• Inefficient error corrections: This model defers integration of code and testing
tasks until it is very late when the problems are harder to resolve.
• No overlapping of phases: This model recommends that the phases be carried out
sequentially—new phase can start only after the previous one completes.
 Concluding Remarks
✔ Suitable for simple projects

✔ Risk of delays: If issues are discovered late in the process, they cause significant
delays because earlier phase needs revisiting.

✔ Easy to Manage: It is easy to mange because it has sequential design enabling easy
management and understanding for the projects having well defined requirements and
objectives.

✔ Limited flexibility due to its rigid structure.

 Iterative Model

Fig 7. Phases of Iterative Waterfall Model

(Source: https://www.geeksforgeeks.org/software-engineering-iterative-waterfall-model/)
 Iterative Model (Cont’d)
• The feedback paths introduced by the iterative waterfall model are shown in Figure 7.

• The feedback paths allow for correcting errors committed by a programmer during some phase, as and when these are

detected in a later phase.

❖ Phase containment of errors: It is advantageous to detect these errors in the same phase in which they take place, since
early detection of bugs reduces the effort and time required for correcting those. The principle of detecting errors as close
to their points of commitment as possible is known as phase containment of errors.

❖ Phase overlap: In spite of the best effort to detect errors in the same phase in which they are committed, some errors
escape detection and are detected in a later phase. These subsequently detected errors cause the activities of some already
completed phases to be reworked.
 Prototyping Model
• It is a software development approach where a prototype or a preliminary version of the
final system—is built, tested, and refined based on user/customer feedback until an
acceptable prototype is achieved.

• Another name is Throwaway Model.

• Purpose: Primary goal is to allow users to interact with the prototype and provide
feedback during the early stages of development.

• Applications: Particularly useful for systems with unclear or rapidly changing

requirements and in situations where user feedback is crucial for the system’s success.
Fig 3 : Prototyping Model
 Cont’d
Importance of a Prototype Model
✔ Validation: Helps validate the feasibility and functionality of an idea.
✔ Feedback: Provides an opportunity to gather feedback from users.
✔ Risk Reduction: Identifies potential issues early in the development process.
✔ Cost Efficiency: Saves costs by identifying and solving problems before full-scale
production.
✔ Communication: Aids in effectively communicating ideas and concepts to
stakeholders.
Development process:
✔ Select appropriate tools and technologies for creating the prototype
✔ Develop in stages allowing for continuous improvement and iteration
 Spiral Model
• Best suited for complex embedded product development & situations where the
requirements are changing from customer side.

• It supports risk handling by evaluating the risk in each stage

• The exact number of loops of the spiral is unknown and can vary from project to
project.

• Each loop of the spiral is called a phase of the software development process.

• Purpose: To provide a more flexible and adaptable approach to software

development, allowing for refinement and improvement at each iteration.
 Phases:
1. Define project objective and goal: In the
first phase of the spiral model project aims,
functional and non functional requirements
are identified.
2. Risk Analysis: The risk associated with the
project are identified and evaluated.
3. Engineering: The software is developed
based on the requirements gathered in the
previous iteration.
4. Assess progress and adjust plans: The
software.
Fig 4: Prototyping Model
(Source:https://www.geeksforgeeks.org/why-spiral-model-is-calle
d-meta-model/)