Got it!

I'll leave the first four slides and make the rest more detailed while keeping them
easy to understand. Here’s your refined version:

Introduction

 Software Engineering = Software + Engineering

Software

 More than just a program code.

 A program is executable code that serves a computational purpose.
 Software consists of:
1. Executable programming code
2. Associated libraries
3. Documentation
 Software Product: Software made for specific requirements.

Engineering

 Involves developing products using scientific principles and methods.

 Ensures efficiency, reliability, and structured development.

Software Engineering

 Definition: A branch of engineering for software development using scientific

principles, methods, and procedures.
 The goal is to produce efficient and reliable software products.
 IEEE Definition:
o A systematic, disciplined, quantifiable approach to software
development, operation, and maintenance.

Need for Software Engineering

1. Large Software:
o A single programmer cannot develop and maintain large systems.
2. Scalability:
 o Software must grow with user needs and business expansion.
3. Cost:
o Software development & maintenance are expensive.
4. Dynamic Nature:
o Technology and user requirements change frequently.
5. Quality Management:
o Ensures software is bug-free, efficient, and secure.

Characteristics of Good Software

1. Operational:
o How well the software works in practice.
o Measured by:
 Budget (cost-effectiveness)
 Usability (ease of use)
 Efficiency (fast execution)
 Correctness (delivers expected output)
 Functionality (performs required tasks)
 Dependability (consistent performance)
 Security (protected from threats)
 Safety (avoids harm to users/data)
2. Transitional:
o Determines how well the software adapts to changes in environment or
platform.
o Key factors:
 Portability (runs on different platforms)
 Interoperability (works with other systems)
 Reusability (components can be used in other software)
 Adaptability (modifications are easy)
3. Maintenance:
o Measures how well the software handles future changes.
o Includes:
 Modularity (organized, independent components)
 Maintainability (easy to update/fix bugs)
 Flexibility (supports new features)
 Scalability (handles more users/data over time)

Essential Attributes of Good Software

Attribute Description
Maintainability Can evolve with changing customer needs.
Dependability & Should be reliable and prevent data loss/hacking.
 Attribute Description
Security
Should not waste system resources like memory &
Efficiency
processing power.
Acceptability Must be usable and compatible with existing systems.

Software Costs

 Software costs are often higher than hardware costs.

 Maintenance costs exceed development costs.
 In long-term projects, maintenance may cost multiple times the initial
development cost.
 Software engineering aims to develop cost-effective solutions.

Software Project Failure

Reasons for Software Failure:

1. Increasing System Complexity

o Large, complex systems are difficult to manage.
2. Failure to Use Proper Software Engineering Methods
o Poor development practices lead to bugs, delays, and increased costs.

Software Products

1. Generic Products
o Standalone software sold to multiple customers.
o Examples:
 MS Office
 Photoshop
 Video editing software
2. Customized Products
o Built for specific customers based on their needs.
o Examples:
 Bank management software
 Airline ticket booking system

Product Specification
 Type Who Owns the Specification? Who Controls Updates?
Generic Products Software Developer Developer decides changes
Customized Products Client/Customer Customer requests updates

Frequently Asked Questions About Software Engineering

1. What is Software?
o Computer programs + documentation.
o Can be for individual customers or the general market.
2. What are the Attributes of Good Software?
o Should be functional, maintainable, dependable, and usable.
3. What is Software Engineering?
o The engineering discipline focused on designing, developing, and
maintaining software.
4. Fundamental Software Engineering Activities?
o Software Specification (Defining requirements)
o Software Development (Writing the code)
o Software Validation (Testing & fixing errors)
o Software Evolution (Updating & maintaining over time)
5. Software Engineering vs. Computer Science
o Computer Science: Focuses on theory & algorithms.
o Software Engineering: Focuses on practical application &
development.
6. Software Engineering vs. System Engineering
o System Engineering: Deals with hardware + software together.
o Software Engineering: Focuses only on software development.

More FAQs About Software Engineering

7. Key Challenges in Software Engineering?

o Handling diverse user requirements
o Reducing software delivery time
o Developing trustworthy and secure software
8. Software Engineering Costs?
o Development Cost: ~60%
o Testing Cost: ~40%
o For custom software, maintenance costs exceed development costs.
9. Best Software Engineering Techniques?
o Depends on the type of software:
 Games: Built using prototypes & testing.
 Safety-Critical Software (e.g., medical devices): Needs detailed
specifications & formal verification.
 10. How Has the Web Changed Software Engineering?
o Led to distributed systems & cloud computing.
o Increased software service availability.

Importance of Software Engineering

 Modern life depends on software – from banking to healthcare.

 Ensures quality, reliability, and security in software systems.
 Saves long-term costs by reducing maintenance issues.
 Essential for businesses and industries worldwide.

Software Engineering & The Economy

 Software is a major part of a country's economy.

 Many industries rely on software-controlled systems.
 Developed nations invest heavily in software engineering.

This version keeps all important points while making it clear and easy to
understand. Let me know if you want any adjustments! 🚀

Software Process

 Good processes → Good software

 Benefits of a well-defined process:
o Reduces risk
o Increases visibility
o Improves teamwork

Variety of Software Processes

 Different projects require different processes.

 No universal process, but all successful projects follow some common steps.

Basic Steps in Software Development

 1. Feasibility & Planning – Is the project viable?
2. Requirements Gathering – What does the software need to do?
3. Design – Creating the system architecture.
4. Implementation – Writing the code.
5. Testing – Ensuring the software works correctly.
6. Deployment & Release – Delivering the software to users.
7. Operation & Maintenance – Fixing issues and making updates.

Feasibility

 Conducted before starting the project.

 Answers key questions:
o Scope – What is included in the project?
o Technical Feasibility – Can it be built?
o Benefits & Costs – Is it worth doing?
o Resources – Are enough people, tools, and time available?
o Risks – What challenges might arise?
 Outcome: Go or No-Go decision

Requirements

 Defines what the system should do (functionality, constraints, goals).

 Developed with the client and users.
 Three main types:
1. Requirements Analysis – Understanding the needs.
2. Requirements Definition – Clearly stating the system's purpose.
3. Requirements Specification – Writing detailed technical requirements.
 Poorly defined requirements → Major cause of software failure!

User Interface Design

 Usability is critical!
 Process:
1. Design the interface
2. Test with real users
3. Improve based on feedback
4. Repeat until user-friendly
System and Program Design

 System Design: Defines hardware & software architecture.

 Program Design: Breaks system into modules, making it easier to build.
 Uses UML (Unified Modeling Language) to represent:
o Requirements
o System structure
o Program logic

Implementation

 Coding Phase – Developers write the actual software.

 Sources of code:
o Developed from scratch
o Acquired from third parties
o Modified from existing components
 Program Testing:
o Individual components tested (unit testing).
o Components combined & tested (integration testing).

Acceptance and Release

 Acceptance Testing:
o System is tested against client requirements.
o Conducted with real users.
 Delivery & Release:
o If successful, software is delivered and released for use.

Operation and Maintenance

 Operation: System is used in the real world.

 Maintenance:
o Fixing bugs & errors.
o Updating system for new features & requirements.
 Evolution:
o Software adapts to new technology & business needs.
 Phase Out:
o System is retired when outdated or replaced.
 This is called the Software Life Cycle.
Quality Control in Software Development

 Ensures software meets high standards.

 Includes:
o Validating requirements.
o Validating system design.
o Usability testing.
o Bug fixing & maintenance.

Categories of Testing

1. User Testing – Tests interface & experience with real users.

2. Program Testing – Development team tests individual components.
3. Acceptance Testing – Client tests full system before approval.

Sequence of Process

 Steps are flexible:

o Can be formal or informal.
o Can be done in different orders based on project needs.

Software Development Process Models

1. Waterfall Model – Each step is fully completed before moving to the next.
2. Iterative Refinement – Build a rough version first, then improve it in cycles.
3. Spiral Model – Combines iterative refinement with risk analysis.
4. Agile Development – Small, fast development cycles (sprints) producing
working software quickly.

This ensures all key points are included while keeping it clear and easy to
understand. Let me know if you need any modifications! 🚀

SDLC Model
  Definition: A framework describing all activities in software development.

Introduction

 Why Study SDLC Models?

o They provide a disciplined approach to software development.
o Help in planning, tracking, and managing risks.
o Ensure Software Quality Assurance (SQA) is integrated into
development.

Classical and Modern Software Development Methodologies

 Waterfall Model
 Iterative Waterfall Model
 Spiral Model
 Prototyping Model
 Incremental Model
 Agile Model
 V-Model (Verification & Validation Model)
 Object-Oriented Model

Waterfall Model

 A sequential development model where each phase depends on the

completion of the previous phase.
 Phases:
1. Analysis – Feasibility study.
2. Requirements – Defining system functionality & constraints.
3. Design – Software architecture & algorithm details.
4. Development – Writing source code & creating databases.
5. Testing – Identifying and fixing errors before release.
6. Deployment – Installing the system for end-users.
7. Maintenance – Updates & modifications based on user needs.

Waterfall Model Strengths

✔ Simple & easy to understand

✔ Works well for projects with fixed requirements
✔ Clear milestones & structured process
✔ Best when quality is more important than speed

Waterfall Model Deficiencies

❌ Requires all requirements upfront

❌ Rigid structure – no flexibility
❌ Late testing – issues are found too late
❌ No customer feedback until the end

When to Use Waterfall Model

 Stable & well-defined requirements

 Technology is well understood
 Updating an existing product
 Porting software to a new platform

Iterative Waterfall Model

 An improved version of the Waterfall model with feedback loops for error
correction.
 Allows revisiting previous phases if issues are found.

Strengths of Iterative Waterfall Model

✔ Allows corrections through feedback paths

✔ Easy to understand & widely used
✔ Supports parallel development

Deficiencies of Iterative Waterfall Model

❌ May require more resources

❌ Difficult to handle change requests once development starts
❌ Cannot deliver software in intermediate phases
❌ Lacks a risk management mechanism
When to Use Iterative Waterfall Model

 Well-defined requirements
 Learning new technology
 High-risk features may change later

Spiral Model

 A risk-driven model combining iterative and waterfall approaches.

 Each loop of the spiral represents one phase of development.

Phases of the Spiral Model

1. Objectives & Alternative Solutions

o Identify customer requirements & explore different solutions.
2. Risk Analysis & Prototyping
o Evaluate risks & build prototypes.
3. Development & Testing
o Implement and test features.
4. Customer Review & Planning Next Phase
o Review with customers & plan improvements.

Strengths of Spiral Model

✔ Best for large & complex projects

✔ Effective risk management
✔ Flexible for changing requirements
✔ Customer feedback included at each stage

When to Use Spiral Model

 For large, high-risk projects

 When frequent releases are needed
 When requirements may change over time
 For long-term projects where economic priorities may shift
 Projects requiring extensive risk analysis
  When prototyping is needed before full development

This version keeps all key points while making it clear and easy to understand. Let me
know if you need any changes! 🚀

Verification & Validation (V&V)

 Verification: Have we built the software correctly?

o Ensures software is developed according to requirements.
o Activities: Reviews, walkthroughs, inspections.
 Validation: Have we built the right software?
o Ensures software meets the customer's needs.
o Activities: Unit testing, integration testing, system testing, user
acceptance testing.

V & V Model

 An extension of the Waterfall Model.

 Sequential – Next phase starts after the previous one is complete.
 Each development phase has a corresponding testing phase.
 Testing is planned in parallel with development.

Advantages of V & V Model

✔ Simple & easy to use.

✔ Clearly defined deliverables.
✔ Testing starts early, reducing defects.
✔ Well-structured & easy to manage.
✔ Works well for small projects with clear requirements.

Disadvantages of V & V Model

❌ High risk & uncertainty.
❌ Not suitable for complex & object-oriented projects.
❌ Rigid structure – Difficult to modify once testing starts.
❌ No working software until late stages.
❌ Expensive to make changes in later stages.

When to Use V & V Model

 Small to medium-sized projects.

 Stable and well-defined requirements.
 Projects requiring simple technical expertise & resources.

Prototype Model

 A prototype (working model) of the system is created first.

 Helps customers understand how the final product will look & work.
 The prototype is refined based on customer feedback until final development.

Strengths of Prototype Model

✔ Early user involvement improves usability.

✔ Detects defects early, reducing cost & time.
✔ Faster feedback → Better solutions.
✔ Identifies missing & difficult functions.
✔ Flexible design that adapts to user needs.
✔ Can be reused for future projects.

Deficiencies of Prototype Model

❌ Poor requirement analysis – Too much focus on the prototype.

❌ Users may confuse prototype with the final product.
❌ Scope creep – Features may expand beyond the original plan.
❌ Prototypes may not be technically feasible.
❌ Costly & time-consuming if not properly monitored.
❌ Lack of documentation due to continuous changes.
When to Use Prototype Model

 When requirements are unclear or frequently changing.

 Systems with high user interaction (UI/UX critical).
 Game development.
 Complex systems with unique interfaces.

Types of Prototyping Models

1. Rapid Throwaway Prototype

o Temporary model, built for quick feedback.
o Helps refine requirements early before actual development.
2. Evolutionary Prototyping
o Incremental improvements until final product is built.
o Useful when technology is new or requirements are unstable.
3. Incremental Prototyping
o Divides product into smaller parts (prototypes).
o Each prototype is developed separately & later merged.
4. Extreme Prototyping
o Used for web applications.
o Three phases:
1. Create basic HTML prototype.
2. Simulate backend services.
3. Implement final backend system.

This version keeps everything concise yet detailed. Let me know if you need
modifications! 🚀

Incremental Development Model

 Software is developed in small parts (increments).

 Each increment is built, tested, and reviewed before adding new features.
 The process continues until the complete system is developed.

Incremental Model Approaches

 1. Plan-Driven Approach
o All increments are planned in advance.
o Follows a structured and documented process.
2. Agile Approach
o Early increments are defined, but later increments are flexible.
o Development depends on customer feedback & priorities.

Benefits of Incremental Development

✔ Handles changing customer requirements easily.

✔ Less rework compared to Waterfall Model.
✔ Early user feedback improves software quality.
✔ Faster delivery – software can be used earlier.
✔ Users can see progress with each increment.

Problems of Incremental Development

❌ Lack of visibility – Managers struggle to track progress.

❌ System structure degrades over time due to continuous updates.
❌ Requires refactoring to maintain software quality.
❌ Costly if frequent modifications are needed.

Integration and Configuration (Software Reuse)

 Most modern projects reuse existing software to save time and cost.
 Instead of writing everything from scratch, pre-built components are integrated.
 Requires a framework for combining reusable software components.

Types of Reusable Software

1. Application System Reuse

o Whole applications are repurposed for different requirements.
o Example: A banking system reused for another financial service.
2. Component Reuse
o Some parts of an application are reused for different software.
o Example: A messaging system in a social media app reused in an e-
commerce website.
 3. Object & Function Reuse
o Libraries, functions, and object classes are reused in new applications.
o Example: Math libraries, authentication modules, API integrations.

Steps in Reuse-Oriented Model

1. Identify reusable components from old systems.

2. Understand how the components work.
3. Modify components to meet new requirements.
4. Integrate modified components into the new system.

Strengths of Reuse-Oriented Model

✔ Reduces development time & effort.

✔ Lower costs & risks.
✔ Higher software quality due to tested components.
✔ Faster software delivery.

Weaknesses of Reuse-Oriented Model

❌ May increase complexity.

❌ Old components may not be fully compatible with new systems.
❌ Difficult to find, understand, and adapt reusable components.
❌ Higher maintenance costs.
❌ Limited tool support for reuse-oriented development.

This version keeps everything concise yet detailed. Let me know if you need any
modifications! 🚀

Software Requirements

 Define features & functionalities expected in a software system.

 Describe customer needs & system constraints.
 Used for controlling devices, placing orders, retrieving information, etc.
Types of Software Requirements

1. User Requirements
o High-level description of what users need.
o Written in natural language (easy to understand).
o Talks about the problem domain (real-world usage).
2. System Requirements
o Detailed, formal definition of system functions.
o Includes technical details & exact implementation requirements.
o Defines how the software will work internally.
o Talks about the solution domain (software logic).

Example of User & System Requirements

 User Requirement: "The system should allow users to reset passwords."

 System Requirement: "Users can reset passwords using a registered email,
with a 6-digit verification code, within 10 minutes."

Stakeholders in Software Requirements

 Users – Who will use the system.

 Clients – Who owns the system.
 Developers – Who build the system.
 Testers – Who verify system functionality.
 Regulators – Who ensure compliance with legal standards.

Types of Software System Requirements

1. Functional Requirements
o Define what the system should do.
o Describe system services, operations & behaviors.
o Example: "The system shall allow users to search for products by name."
2. Non-Functional Requirements (NFRs)
o Define constraints & quality factors.
o Cover performance, security, usability, reliability, etc..
o Example: "The website must load within 3 seconds."
3. Domain Requirements
o Specific to a particular industry or environment.
o Example: Medical software must follow IEC 60601-1 safety standard.
Functional Requirements (Example: Mentcare System)

✔ Users can search appointment lists for all clinics.

✔ System generates daily patient lists for each clinic.
✔ Each staff member is identified by an 8-digit employee number.

Non-Functional Requirements (NFRs)

1. Product Requirements – Define system behavior at runtime.

o Example: Speed, memory usage, security, usability.
2. Organizational Requirements – Set by company policies.
o Example: Development must follow ISO coding standards.
3. External Requirements – Derived from laws & regulations.
o Example: Data protection laws (GDPR, HIPAA compliance, etc.).

Metrics for Non-Functional Requirements

Property Measure
Speed Transactions/sec, Response time
Size MB of memory used
Reliability Failure rate, Availability %
Portability Number of supported platforms

Functional vs. Non-Functional Requirements

Category Functional Non-Functional

Focus What the system does How the system works
Example "User can reset password" "System must be 99.99% available"

Domain Requirements

 Define industry-specific software constraints.

 Examples:
o Railway System: Must follow safety protocols for train operations.
o Medical Software: Must ensure data security & patient safety.
Key Takeaways

✔ Requirements define what the system should do and set constraints on

implementation.
✔ Functional requirements describe system services & actions.
✔ Non-functional requirements define quality attributes like speed, security, and
usability.
✔ Domain requirements apply to specific industries.

This version keeps all key concepts while making it clear and easy to understand.
Let me know if you need modifications! 🚀

Requirements Engineering

 Process of gathering, analyzing, documenting, and validating system

requirements.
 Ensures the software meets customer needs and follows constraints.
 Outcome: A Software Requirements Document (SRD).

Requirements Engineering Process

1. Requirements Elicitation & Analysis

o Identifying system needs from users, customers, and stakeholders.
2. Requirements Specification
o Writing clear, detailed, and structured system requirements.
3. Requirements Validation
o Ensuring requirements are complete, consistent, and realistic.

Requirements Elicitation & Analysis Process

 Discovering requirements through user interactions.

 Organizing requirements into structured categories.
 Prioritizing & negotiating conflicting requirements.
 Documenting requirements for future use.
Requirements Elicitation Techniques

1. Interviewing
o Closed Interviews: Predefined set of questions.
o Open Interviews: Flexible discussions to explore user needs.
2. Ethnography (Observation Method)
o Watching users perform tasks in real-world environments.
o Helps identify hidden or informal requirements.

Requirements Specification

 Converts user requirements into clear, structured documents.

 Must be: Clear, Unambiguous, Complete, and Consistent.
 Includes: Text, Diagrams, and Tables.

Problems with Natural Language Specification

❌ Lack of Clarity – Difficult to make precise statements.

❌ Confusion – Functional & Non-functional requirements may mix.
❌ Overlapping Requirements – Multiple requirements in a single statement.

Software Requirements Document (SRD)

 Official statement of what developers must implement.

 Includes both:
1. User Requirements – High-level system goals.
2. System Requirements – Technical details of system behavior.

Requirements Validation

 Ensures requirements are correct and realistic.

 Checks for:
✔ Validity – Do requirements match actual user needs?
✔ Consistency – No conflicting requirements.
✔ Completeness – No missing system functionalities.
✔ Realism – Can it be implemented within budget & technology limits?
✔ Verifiability – Requirements must be testable.
Techniques for Requirement Validation

1. Requirements Reviews – Systematic team analysis of requirements.

2. Prototyping – Creating a model for user feedback.
3. Test-Case Generation – Ensuring requirements can be tested.

This version keeps all key points concise yet detailed. Let me know if you need any
modifications! 🚀

Requirements Change

 Software requirements evolve over time due to various factors:

✔ New hardware or technology updates.
✔ Changing business priorities.
✔ Modifications in technical environment.
✔ Integration with other systems.
✔ Legal or regulatory changes.
✔ Feature enhancements or updates.
✔ Changes in user needs or roles.
✔ Requirement re-prioritization.

Requirements Evolution Process

 Requirements are not static and change due to external and internal factors.
 Managing requirement changes effectively ensures software remains relevant
and functional.

Requirements Management Planning

 Defines how evolving requirements are handled during software

development.
 Key considerations:
1. Requirements Identification – Each requirement is uniquely labeled for
tracking.
 2. Change Management Process – Evaluates cost & impact of
requirement changes.
3. Traceability Policies – Defines relationships between requirements &
system design.
4. Tool Support – Automated tools help in storing, managing, and
tracking changes.

Requirements Change Management

 A structured process to handle requirement modifications.

 Three Stages of Change Management:
1. Problem Analysis & Change Specification – Understanding why
change is needed.
2. Change Analysis & Costing – Evaluating feasibility, impact, and cost.
3. Change Implementation – Making necessary updates in the system.

This version keeps all key concepts concise yet detailed. Let me know if you need
modifications! 🚀