SOFTWARE ENGINEERING - UNIT 1

WHAT IS A SOFTWARE?

◼ Software is a collection of programs and data that tell a computer

what to do. It is not a physical part of the computer (like hardware),
but it makes the hardware useful.
◼ Examples of Software:
• Applications – Games, web browsers, music players
• Programming Software – Compilers, code editors
WHAT IS ENGINEERING?

◼ Engineering is the application of science and mathematics to design, build, and

improve things in a structured way. It focuses on solving problems efficiently.
◼ Examples of Engineering Fields:
• Civil Engineering – Building bridges, roads, and buildings
• Mechanical Engineering – Designing cars, machines, and engines
• Software Engineering – Creating reliable and efficient software
◼ Engineers follow a step-by-step approach to plan, design, build, and improve
things, making sure they work well and last long
SOFTWARE ENGINEERING
◼ Software engineering is the process of designing, building, testing, and
maintaining software in a structured and efficient way.
◼ Or
◼ Software is a program or set of programs containing instructions that
provide the desired functionality. Engineering is the process of designing
and building something that serves a particular purpose and finds a
cost-effective solution to problems.
◼ It’s like constructing a house—just as engineers follow blueprints to build
strong and reliable buildings, software engineers follow principles and
methods to create high-quality software.
OBJECTIVES OF SOFTWARE ENGINEERING
◼ Maintainability: The software should be easy to update and change as new needs or requirements
come up in the future.
◼ Efficiency: The software should use computer resources like memory and processing power wisely,
without wasting them.
◼ Correctness: The software should do exactly what was promised in its requirements (what the
software is supposed to do according to its design document).
◼ Reusability: Parts of the software (like modules or functions) should be able to be reused in other
projects without too much effort.
◼ Testability: The software should make it easy to test if it works correctly by providing clear ways to
check and measure its behavior.
◼ Reliability: The software should work correctly and consistently over time, performing its tasks as
expected without failure.
◼ Portability: The software should be able to run on different types of computer systems without
needing major changes.
◼ Adaptability: The software should be able to adjust and change to meet different user needs or
system requirements.
◼ compatibility: The software should work well with other software or systems, allowing them to
share and process data together.
SOFTWARE CRISES

◼ What is Software Crisis?

The Software Crisis refers to the difficulty of writing useful, efficient
computer programs within the required time frame.
• Why it happens:
Rapidly increasing demand for software, more complex software,
and outdated methods/tools.
PROBLEMS ARISING DUE TO SOFTWARE CRISIS

• Budget Problems: Projects go over budget.

• Efficiency Issues: Software becomes slow or doesn't meet
expectations.
• Quality Problems: Software often has low quality and bugs.
• Management & Delivery Issues: Projects are delayed, not delivered
on time.
CAUSES OF SOFTWARE CRISIS
• High Costs: Maintaining software costs as much as developing it.
• Overtime: Projects take longer than planned.
• Inefficient Software: Software doesn't work well.
• Low Quality: Software doesn't meet user needs or expectations.
• Scheduling Issues: Most software projects go past their deadline.
• Non-Optimal Resources: Resources like time and people are not
used effectively.
• Hard to Maintain: Difficult to alter, debug, or enhance.
FACTORS CONTRIBUTING TO SOFTWARE CRISIS

1. Poor Project Management

2. Lack of Proper Training in Software Engineering
3. Inexperienced Team Members
4. Low Productivity Improvements
GUIDELINES FOR PREVENTING SOFTWARE CRISIS

1. Control Over Budget: Keep the project within budget.

2. High Quality: Ensure software is of good quality and free of errors.
3. Time Efficiency: Complete the project in less time.
4. Experienced Team: Have skilled people working on the project.
5. Meet User Requirements: Software should solve the problems it’s
meant to.
CHARACTERISTICS OF SOFTWARE

◼ Software Development vs. Manufacturing:

1. Software is crafted through a process of coding and development.
2. Unlike physical products, it isn't produced in factories through a
manufacturing process.
◼ No Physical Wear and Tear
1. Software doesn't deteriorate over time like physical objects
2. Its performance does not degrade due to physical use
CHARACTERISTICS OF SOFTWARE

◼ Custom-Built Nature:
1. Most software is specially designed to meet specific needs.
2. It’s often not just a combination of pre-existing components but
requires unique coding and design.
◼ Intangibility of Software:
1. Software can’t be touched or handled physically.
2. It exists as code and functions within computers or digital devices.
MAJOR PROBLEMS IN SOFTWARE DEVELOPMENT
◼ Inadequate Requirements Gathering:
1. Ambiguous or incomplete requirements
2. Lack of communication between stakeholders
◼ Poor Project Management:
1. Inadequate planning, monitoring, and control
2. Lack of risk assessment and mitigation
3. Multiplicity of software development life cycles
4. Selection of wrong technology or tool for development
◼ Insufficient Time and Budget:
1. Unrealistic deadlines and resource constraints
2. Inefficient resource allocation and prioritization
◼ Lack of Skilled Personnel:
1. Inadequate expertise in the development team
2. High turnover rates and loss of experienced staff
◼ Resistance to Change:
1. Difficulty in adapting to new technologies or processes
2. Reluctance to modify established practices or mindsets
3. Rapid technology advancement
SIMILARITIES AND DIFFERENCE BETWEEN SOFTWARE ENGINEERING
AND CONVENTIONAL ENGINEERING
◼ Nature of the Product
• Similarity: Both aim to create high-quality, reliable products.
• Difference:
• Conventional engineering deals with physical systems (e.g.,
mechanical, electrical).
• Software engineering focuses on intangible software systems
(e.g., programs, applications).
◼ Design Flexibility and Iteration
• Similarity: Both involve iterative design and prototyping.
• Difference:
• Software engineering allows for greater flexibility and easier
modification because software is non-physical.
• Conventional engineering involves physical components, making
changes more complex and costly.
◼ Quality Assurance and Testing
• Similarity: Both emphasize testing and quality assurance to ensure
performance and reliability.
• Difference:
• Conventional engineering involves physical testing on
prototypes.
• Software engineering relies on various types of software testing,
such as unit testing, integration testing, and system testing.
◼ Project Management and Collaboration
• Similarity: Both require effective project management, teamwork,
and communication among stakeholders.
• Difference:
• Conventional engineering relies on physical collaboration in
workplaces like factories or offices.
• Software engineering often involves distributed teams and
heavily depends on digital collaboration tools like Slack, Jira, and
GitHub.
◼ Maintenance and Evolution
• Similarity: Both involve maintenance and support activities to
ensure the ongoing performance and reliability of the product.
• Difference:
• Conventional engineering: Maintenance is less frequent, with
scheduled check-ups and repairs.
• Software engineering: Requires frequent updates, patches, and
continuous evolution due to rapidly changing technology and
user requirements.
 Hardware Failure (Bathtub Curve)
•Follows a bathtub-shaped curve:
• Burn-in Phase: High initial failure rate due to
manufacturing defects.
• Useful Life: Stable failure rate during the normal operation
period.
• Wear-out Phase: Failures increase due to aging and
degradation.
Software Failure (Early Failure Curve)
•No physical wear-out like hardware.
•Follows a steep decreasing curve:
• High failure rate initially (due to bugs and errors in early
releases).
• Failure rate decreases over time as patches and updates
improve stability.
KEY SOFTWARE QUALITY ATTRIBUTES
1. Correctness – The ability of the software to perform its intended tasks
effectively and meet user requirements.
2. Usability – The ease with which users can learn, operate, and navigate the
software.
3. Reliability – The software’s consistency in producing accurate results and
maintaining performance over time.
4. Efficiency – The optimal use of system resources, such as memory and
processing power, to achieve desired outcomes.
5. Maintainability – The ease of updating, modifying, and fixing the software to
accommodate changing requirements or fix issues.
6. Portability – The ability of the software to operate on different platforms or
environments without significant modification.
 7. Scalability – The software’s capacity to handle increased workloads or users
without compromising performance.
8. Security – The software’s ability to protect against unauthorized access, cyber
threats, and other potential risks.
9. Modularity – The degree to which the software's components are organized into
separate, manageable units that can be independently developed or updated.
10. Reusability – The potential for the software's components to be used in other
applications or contexts, reducing development time and costs.
11. Testability – The ease with which the software can be tested to ensure it meets
its requirements and performs as expected.
SOFTWARE PROCESSES

◼ Feasibility Study
◼ Evaluating whether the proposed software project is practical and viable.
◼ Key Aspects:
• Problem Definition: Understanding the abstract problem the software aims to
solve.
• Financial & Technical Feasibility: Checking cost, budget, and technical resources.
• Resource Availability: Assessing infrastructure and human resource needs.
• Alternative Solutions: Exploring different approaches to solving the problem.
◼ Requirement Analysis and Specification
◼ Understanding and documenting the exact requirements of the customer.
◼ Key Steps:
• Understanding Requirements: Gather and analyze all data related to the project.
• Requirement Documentation: Create a Software Requirement Specification
(SRS) document.
• SRS Document Contents:
• What the system will do (not how it will do it).
• Critical Phase: Errors here can impact later development stages significantly
◼ Software Design
◼ Transforming requirements into a structured format suitable for coding.
◼ Key Steps:
• System Architecture & Algorithmic Strategy:
• Define high-level architecture (e.g., layers, modules).
• Choose algorithmic strategies
• Software Design Description (SDD):
• A document describing how the system will function.
• Helps developers implement the system efficiently.
◼ Coding or implementation
◼ Convert the system design into an executable program using a programming
language.
◼ Key Aspects:
• Maintainability: Write clean, modular, and readable code.
• Efficiency: Optimize code for performance and resource usage.
• Testing & Debugging: Ensure the code functions correctly and is easy to
modify.
• Best Practices: Follow coding standards, documentation, and version control.
◼ Software Testing
◼ 🔹 Purpose: Identify and fix bugs/errors before deployment.
🔹 Key Aspects:
• Bug Detection: Finding faults caused by human errors.
• Failure Prevention: Ensuring software runs correctly under different
conditions.
• Types of Testing:
• Unit Testing: Testing individual components.
• Integration Testing: Ensuring modules work together.
• System Testing: Validating the complete system.
• Acceptance Testing: Checking if software meets user requirements.
◼ Deployment Phase
◼ Deploy the software to the user environment.
🔹 Key Steps:
• Installation: Software is set up on user systems.
• Configuration: Ensuring compatibility with hardware and existing
systems.
• User Training: Teaching users how to operate the software
efficiently.
• Initial Testing: Verifying that the software runs correctly
post-installation.
◼ Software Maintenance
◼ 🔹 Definition: Any change made to software after its release.
🔹 Types of Maintenance:
• Adaptive: Updating software to work with new environments or
platforms.
• Corrective: Fixing bugs or errors reported by users.
• Perfective: Improving performance, adding new features, or
enhancing usability.
Software Development Life Cycle (SDLC)
1. Planning & Requirement Analysis (Stage 1 - Green)
This phase ensures the project is feasible and aligns with business needs.
Sub-Steps:
✅ Planning – Identify objectives, budget, and resources.
✅ Define Project Scope – Determine what the software will and will not do.
✅ Set Objectives and Goals – Define what success looks like.
✅ Resource Planning – Assign developers, testers, and tools.
2. Defining Requirements (Stage 2 - Yellow-Green)
This step formalizes software needs into documents.
Sub-Steps:
✅ Defining – Write down what the software must do.
✅ Functional Requirement – Specify system behavior (e.g., login, transactions).
✅ Technical Requirement – Define technology stack (e.g., database, server, APIs).
✅ Requirement Reviews & Approval – Validate and finalize requirements.
High Level Low Level
Design Design
3. Design (Stage 3 - Red)

The system architecture and component-level design are created.

Sub-Steps:

✅ Design – Plan system layout and flow.

✅ High-Level Design (HLD) – Define overall architecture and
module relationships.
✅ Low-Level Design (LLD) – Detail each module’s internal structure.
4. Development (Stage 4 - Purple)

The coding process begins based on the design phase.

Sub-Steps:

✅ Development – Write code for system components.

✅ Coding Standard – Follow industry best practices.
✅ Scalable Code – Ensure the codebase supports future growth.
✅ Version Control – Track code changes using Git.
✅ Code Review – Peer review for error detection.
5. Testing (Stage 5 - Yellow)

Software is tested to find and fix defects.

Sub-Steps:

✅ System Testing – Check complete system functionality.

✅ Manual Testing – Test cases executed manually.
✅ Automated Testing – Use tools to speed up testing.
6. Deployment & Maintenance (Stage 6 - Gray)

Software is released and continuously monitored.

Sub-Steps:

✅ Deployment and Maintenance – Make the software available to users.

✅ Release Planning – Decide the rollout strategy.
✅ Deployment Automation – Automate updates and fixes.
✅ Maintenance – Provide long-term support.
✅ Feedback – Gather user responses for improvement.
DIFFERENT SDLC MODEL

◼ Waterfall Model
◼ Prototype Model
◼ Spiral Model
◼ V Model
◼ Agile Model
◼ Evolutionary Development Model
◼ Iterative enhancement model
Waterfall
Model
Waterfall Model in Software Development

The Waterfall Model is a linear and sequential approach to software

development, where progress flows in one direction—like a
waterfall—through different stages. Each phase must be completed
before moving to the next.
Main Features of the Waterfall Model 🚀

The Waterfall Model is a traditional sequential software development approach with

the following key features:

1⃣ Linear & Sequential Process: The development process follows a step-by-step

approach. Each phase must be completed before moving to the next. No overlapping
of phases.

2⃣ Rigid Structure: Once a phase is completed, going back is difficult. Changes in

requirements are not easily accommodated.
WATERFALL MODEL – ADVANTAGES AND DISADVANTAGES

Advantages
◼ Easy to Understand Disadvantages
◼ Step-by-Step Process ◼ No Feedback Path
◼ Well-Defined Stages ◼ Difficult to Accommodate
◼ Clear Goals Change Requests
◼ Good Documentation ◼ No Overlapping of Phases
◼ Encourages Best ◼ Limited Flexibility
Practices ◼ Limited Stakeholder
◼ Works for Simple Involvement
Projects ◼ Late Defect Detection
◼ Lengthy Development Cycle
Agile Model in Software Development 🚀

The Agile Model is a flexible, iterative, and customer-focused approach to software

development. Unlike traditional models like the Waterfall Model, Agile allows for
continuous improvement, frequent releases, and adaptability to changing
requirements.
How Agile Works?

1⃣ Requirement Gathering & Planning

● The team discusses requirements and breaks them into small, manageable tasks.

● Work is planned in short development cycles called Sprints (typically 1-4 weeks).

2⃣ Design & Development

● Developers build the software in small increments instead of all at once.

● Each sprint delivers a working version of the software.

Testing & Feedback

● Testing happens simultaneously with development.

● After each sprint, feedback is gathered and adjustments are made.

4⃣ Deployment & Release

● A working version of the software is released frequently (every sprint or every

few sprints).

● The product is continuously improved based on user feedback.

When to Use the Agile(move quickly) Model?

▪ When frequent modifications are required

▪ When a highly skilled and experienced team is available
▪ When the customer is actively involved throughout the process
▪ When the project needs to be delivered quickly
▪ For projects with uncertain or evolving requirements
▪ For projects using a flexible or less rigid methodology
▪ When the product owner is easily accessible
▪ When the project has flexible schedules and budgets
 AGILE MODEL – ADVANTAGES AND DISADVANTAGES
Advantages Disadvantages
◼ Improved Code Quality
◼ Lack of Formal Documentation
through Pair Programming
◼ Not Suitable for Complex
◼ Faster Development Time
Dependencies
◼ Better Collaboration
◼ High Dependence on Customer
through Face-to-Face
Involvement
Communication
◼ Difficulty in Planning and Forecasting
◼ Flexibility to Change
◼ Requires Skilled and Experienced Team
Requirements
Members
◼ Customer-Centric
◼ Challenges in Maintenance Due to
Approach
Limited Documentation
ITERATIVE WATERFALL MODEL
 When to use Iterative Waterfall Model?

1.The prerequisite of being well-defined and comprehended.

2.The development team is gaining knowledge about new
technologies.
3.Certain characteristics and objectives carry a significant chance
of failure in the future.
ITERATIVE WATERFALL MODEL – ADVANTAGES AND DISADVANTAGES

Advantages Disadvantages
◼ Phase Containment of Errors ◼ Difficult to Incorporate
◼ Collaboration Change Requests
◼ Flexibility ◼ Incremental Delivery Not
◼ Testing and Feedback Supported
◼ Faster Time to Market ◼ No Overlapping of Phases
◼ Risk Reduction ◼ Risk Handling Not Supported
◼ Limited Customer Interactions
Spiral Model
Spiral Model in Software Development 🔄
The Spiral Model is a risk-driven, iterative software development model that
combines elements of the Waterfall Model and Prototyping. It is best suited for
large, complex, and high-risk projects where frequent changes are expected.
How the Spiral Model Works?

The Spiral Model consists of four phases, which are repeated in a spiral form until the
project is completed. Each loop (or iteration) of the spiral represents one phase of
development.

Phases of the Spiral Model

🔹 1. Planning (Identify Objectives & Requirements)

● Define project objectives, constraints, and risks.

● Gather requirements from stakeholders.

● Estimate cost, schedule, and resource allocation.

2. Risk Analysis (Evaluate & Reduce Risks)

● Identify potential risks (technical, financial, security, etc.).

● Develop strategies to mitigate risks.

● Create a prototype to test uncertain requirements.

3. Engineering (Develop & Test the Product)
● Design and develop the software in increments.

● Perform coding, testing, and validation.

● Incorporate changes based on feedback.

🔹 4. Evaluation (Review & Get Feedback)

● Get feedback from stakeholders.

● Decide whether to continue, modify, or terminate the project.

● Prepare for the next iteration of the spiral.

✅ The process continues in multiple spirals until the final product is ready!
WHY IS THE SPIRAL MODEL CALLED A META-MODEL?

◼ Incorporates Other SDLC Models – It includes elements of different

software development models.
◼ Represents the Iterative Waterfall Model – A single loop of the spiral
resembles the Iterative Waterfall Model.
◼ Follows the Waterfall Model Approach – It adopts the stepwise
process of the Classical Waterfall Model.
◼ Uses Prototyping for Risk Management – Builds prototypes at each
phase to handle risks.
◼ Supports the Evolutionary Model – Iterations in the spiral act as
evolutionary stages of system development.
WHEN TO USE THE SPIRAL MODEL?
◼ For Large and Complex Projects
◼ where failure is costly, risk analysis is crucial and multiple
iterations are required before deployment eg. Defence Products
◼ When Prototyping Is Required
◼ When Risk and Cost Evaluation Is Crucial
◼ For Projects with Moderate to High Risk
◼ When Requirements Are Complex or Unclear
◼ When Modifications May Occur Anytime
◼ When Long-Term Commitment Is Challenging Due to Changing
Priorities
SPIRAL MODEL – ADVANTAGES AND DISADVANTAGES

Advantages
◼ Risk Handling Disadvantages
◼ Good for Large Projects ◼ Complex
◼ Flexibility in Requirements ◼ Expensive
◼ Customer Satisfaction ◼ High Dependence on Risk
◼ Iterative and Incremental Analysis
Approach ◼ Difficulty in Time
◼ Emphasis on Risk Management Management
◼ Improved Communication ◼ Time-Consuming
◼ Improved Quality ◼ Resource Intensive
V MODEL
V-Model (Verification and Validation Model) in Software
Development ✅🔄
The V-Model (Validation and Verification Model) is a structured software development
methodology that follows a sequential process, similar to the Waterfall Model, but with a strong
focus on testing at every stage.

It is called the V-Model because its process forms a “V” shape, where the left side represents
development stages (Verification) and the right side represents testing stages (Validation).
🛠 Phases of the V-Model
🔹 Left Side (Verification - Development Phases)
Verification ensures that each phase is correctly executed before moving forward.

System Design 🏗
Requirements Analysis 📝
● Gather software & system requirements
● Create high-level architecture of the
from stakeholders. system.

● Clearly define what the system should ● Define modules, data flow, interfaces,
do. and communication.

● Output: Software Requirement ● Output: System Architecture

Specification (SRS) Document. Document.
High-Level Design (HLD) 📐 Low-Level Design (LLD) 🔧
● Break down the system into smaller
● Design internal logic of each module.
modules.

● Define algorithms, database

● Define interactions between different
structures, and coding standards.
components.

● Output: Design Specifications. ● Output: Detailed Design Document.

Implementation (Coding) 💻

● Developers write the actual code based on

LLD.

● Coding standards and best practices are

followed.

● Output: Executable Software.

Right Side (Validation - Testing Phases)
Validation ensures the software meets user requirements and functions as expected.

Unit Testing 🧪
Integration Testing 🔄
● Tests individual components/modules of
● Tests interactions between multiple
the system. modules.

● Ensures correctness of functions and ● Ensures data flow and communication

logic. work properly.

● Corresponds to: Low-Level Design ● Corresponds to: High-Level Design

(LLD). (HLD).
System Testing 🖥 User Acceptance Testing (UAT) 👥

● Tests the entire system as a whole. ● Performed by end-users or clients.

● Ensures software meets business

● Validates that the software meets
needs.
specified requirements.
● Corresponds to: Requirements
● Corresponds to: System Design. Analysis.
When to Use the V-Model?
🔹 For small to medium-sized projects with well-defined and stable
requirements.
🔹 When quality is a top priority (e.g., medical, aerospace, banking
software).
🔹 For safety-critical applications where early testing is crucial.
When to Use the V-Model?
• When Requirement Traceability Is Needed – Ensures clear links
between requirements and test cases.
• For Complex Projects – Helps manage testing and reduce integration
risks in large systems.
• For Waterfall-Like Projects – Works well with a step-by-step
development process.
• For Safety-Critical Systems – Used in industries like aerospace,
automotive, and healthcare where strict testing is required.
Advantages of V-Model Disadvantages of V-Model
◼ Highly Disciplined and Sequential ◼ High Risk and Uncertainty
◼ Suitable for Small, Well-Defined ◼ Not Suitable for Complex or
Projects Object-Oriented Projects
◼ Simple and Easy to Use ◼ Not Ideal for Changing Requirements
◼ Early Verification and Validation for ◼ No Iteration of Phases
Quality Assurance
◼ Does Not Handle Concurrent Events
◼ Accurate Project Tracking Well
◼ Clear and Structured Process ◼ Inflexible and Difficult to Adapt
◼ Strong Emphasis on Testing ◼ Time-Consuming Due to Extensive
◼ Improved Traceability of Requirements Documentation

◼ Better Communication Between Teams ◼ Overreliance on Documentation

PROTOTYPE
MODEL
Types of Prototyping Models

1. Rapid Throwaway Prototyping

2. Evolutionary Prototyping
3. Incremental Prototyping
Advantages of Prototyping Model

● Early customer feedback and satisfaction

● Accommodates new requirements easily
● Identifies missing functionalities
● Early error detection, saving time and cost
● Reusable prototypes for future projects
● Flexible design and improved quality
● Reduces risk of project failure
● Enhances communication among stakeholders
Disadvantages of Prototyping Model

● Costly in terms of time and resources

● Frequent requirement changes
● Poor documentation due to evolving needs
● Difficult for developers to accommodate all changes
● Uncertain number of iterations before final acceptance
● Customers may expect early delivery after seeing a prototype
● Customers may lose interest if initial prototype is unsatisfactory
● Scalability issues for future needs
● Risk of premature product release
● Technical feasibility and business requirements may be overlooked
 EVOLUTIONARY PROTOTYPE MODEL

Develops a working
prototype and gradually
improves and refined that
until it evolves into the
final product over time
INCREMENTAL PROTOTYPING
● Module by Module working
● Customer Interaction Maximum
● Large Projects
● Chances of error are very less
● Early Release Product demand
THROWAWAY PROTOTYPING
Also known as Rapid or exploratory prototyping, involves creating a temporar, simplified version of the
software to validate the feasibility of specific features, test ideas, or gain user feedback on the initial design.
The throwaway prototype is not intended to be used in the final product; instead , it is discarded once it has
served the purpose.
 Model When to Use?

Waterfall Model When requirements are well-defined, stable, and unlikely to change. Suitable
for small projects with clear scope.

Prototype Model When requirements are unclear or evolving. Useful for UI/UX-intensive
applications.

Spiral Model When high-risk projects need frequent evaluation. Suitable for large, complex
projects with changing requirements.

V-Model (Validation & Verification When high reliability and rigorous testing are required, such as in healthcare,
Model) aerospace, or safety-critical systems.

Agile Model When rapid development is needed, and requirements change frequently. Ideal
for startups and dynamic projects.

Evolutionary Development Model When requirements are unclear and need progressive refinement over multiple
releases.