Module 1: Introduction to Software Engineering

What is Software Engineering?

Software Engineering is the systematic application of engineering principles to software

development. Instead of ad hoc programming, it’s about designing, building, testing, and maintaining
software in a disciplined, organized way.

Why is Software Engineering Important?

• Ensures software is reliable, efficient, and maintainable

• Helps manage complexity in large software projects

• Supports team collaboration and clear documentation

• Improves ability to handle changing requirements

Phases in Software Development

Software development typically follows these key phases:

1. Requirement Analysis
Understand what users need. Gather and analyze requirements.

2. Design
Plan the architecture and components of the software.

3. Implementation (Coding)
Write the actual program code.

4. Testing
Verify the software works correctly and meets requirements.

5. Deployment & Maintenance

Deliver software to users and fix issues or add features over time.

Software Process Models

A process model guides how these phases are organized and executed.

1. Linear Sequential Model (Waterfall)

• Phases happen in order, one after the other.

• Simple to understand and manage.

• Not flexible: difficult to go back and change earlier phases.

Diagram: Waterfall Model

plaintext

CopyEdit

Requirements → Design → Implementation → Testing → Deployment

2. Prototype Model

• Build a simple prototype early.

• Get user feedback to clarify requirements.

• Helps reduce misunderstandings.

3. Evolutionary Models

• Incremental: Develop software in pieces, each adding features.

• Spiral: Risk-driven, iterative cycles focusing on risk analysis each time.

4. Specialized Process Models

• Component-Based Development: Build from reusable components.

• Aspect-Oriented Software Development: Modularize cross-cutting concerns like security or

logging.

5. Agile Process

• Emphasizes flexibility, collaboration, and customer involvement.

• Iterative cycles with frequent delivery of working software.

• Values adaptability over rigid plans.

Industry Case Study: Choosing the Right Process Model

Scenario:
A startup developing a mobile app for food delivery.

• Requirements are not fully clear initially.

• Fast delivery and adaptability to user feedback is crucial.

• The team is small and needs close customer interaction.

Chosen Model: Agile process best fits because it supports quick iterations and customer
collaboration.
Quick Quiz (MCQs)

1. Which phase involves gathering and analyzing user needs?

a) Design
b) Implementation
c) Requirement Analysis
d) Testing

2. Which process model is the least flexible?

a) Prototype Model
b) Waterfall Model
c) Agile Process
d) Incremental Model

3. What is a key advantage of Agile?

a) Fixed plans
b) Frequent delivery of working software
c) Complete documentation before coding
d) One-time testing

Reflective Question

• How might the choice of process model affect the success of a software project in different
industries?

END OF MODULE 1

MODULE 2: Project Metrics

Overview

Project metrics help measure and track the progress, quality, and size of software projects.
Understanding these metrics is crucial for effective project management and quality assurance.

1. Software Measurement

• Why measure software?

To estimate effort, track progress, and improve quality.

• Types of Metrics:

o Size-Oriented Metrics:
 ▪ Lines of Code (LOC): Count of executable lines.

▪ Pros: Simple to count.

▪ Cons: Language-dependent, can be misleading.

▪ Function Points (FP): Measures functionality from the user's perspective.

o Function-Oriented Metrics:

▪ Focus on what software does, not how much code it has.

o Extended Function Point Metrics:

▪ Adjusts function points by considering system complexity.

o Object-Oriented Metrics:

▪ Class size, coupling (how classes interact), cohesion (relatedness within a

class).

o Web Application Metrics:

▪ Page views, response time, session duration.

2. Software Quality Metrics

• What do we measure?

o Reliability, maintainability, efficiency, usability.

• Defect Removal Efficiency (DRE):

o Formula: DRE = (Defects Found / Total Defects) × 100%

o Indicates effectiveness of testing and defect correction.

3. Integrating Metrics into Project Management

• Establish baseline metrics early on to track progress.

• Use metrics to predict project timelines and detect issues early.

4. Case Study: Metrics in Action - E-commerce Website Development

• The project team tracked LOC and Function Points to estimate effort.

• DRE was used during testing phases to improve product quality.

• Web metrics like response time and session duration helped optimize user experience.

5. Embedded MCQs (Interactive)

 1. Which metric measures software functionality from the user’s perspective?
A) Lines of Code
B) Function Points
C) Coupling
D) Response Time

2. Defect Removal Efficiency (DRE) indicates:

A) Number of defects introduced
B) Effectiveness of defect detection and correction
C) Time taken to fix defects
D) Usability of the software

6. Diagram: Types of Software Metrics

(Insert diagram here showing categories: Size-Oriented, Function-Oriented, Object-Oriented, Web

Metrics, and Quality Metrics with examples in each.)

MODULE 3: Object-Oriented Concepts

Overview

Object-Oriented Programming (OOP) is a paradigm centered around objects rather than actions. It
helps manage complex software through modular, reusable, and maintainable code.

1. Core Concepts

• Class: Blueprint/template for objects. Defines attributes and behaviors.

• Object: Instance of a class with specific data.

• Attributes: Data members or properties of a class (e.g., color, size).

• Operations/Methods: Functions or services defined in a class to perform actions.

• Messages: Communication between objects via method calls.

2. Identifying Elements in OOP

• Recognize and define classes and objects based on problem domain.

• Determine operations and responsibilities of each class.

3. Object-Oriented Analysis and Design (OOAD)

• Use Cases:

o Describe user interactions with the system.

o Helps understand system requirements from a user perspective.

• CRC Modeling:

o Class-Responsibility-Collaborator cards used to define classes, their responsibilities,

and collaborating classes.

• Object-Relationship Models:

o Association: General relationship between classes.

o Aggregation: Whole-part relationship (e.g., Library and Books).

o Inheritance: “Is-a” relationship where one class inherits properties of another.

4. Case Study: Online Library Management System (Simplified)

• Classes identified:

o Book, Member, Library, Loan

• Responsibilities:

o Book: Store details like title, author.

o Member: Store member details, borrow/return books.

o Library: Manage books and members.

o Loan: Track borrowing transactions.

5. Embedded MCQs (Interactive)

1. What is an object in OOP?

A) A blueprint for a class
B) An instance of a class
C) A function inside a class
D) A data member

2. Which relationship is described as a “whole-part” in OOP?

A) Association
B) Aggregation
C) Inheritance
D) Encapsulation

6. Diagram: OOP Relationships

(Insert UML class diagram illustrating association, aggregation, and inheritance between classes in
the case study.)

MODULE 4: Project Planning

Overview

Project planning is critical to ensure successful software development by outlining scope, estimating
resources, scheduling, and managing risks.

1. Software Scope Identification (Feasibility Study)

• Assess Technical Feasibility: Can the technology support the project?

• Assess Operational Feasibility: Will users accept and use the system?

• Assess Economic Feasibility: Is the project cost-effective and within budget?

2. Resource Identification

• Human Resources: Developers, testers, analysts, managers.

• Reusable Software Assets: Libraries, frameworks, existing modules.

3. Estimation Models

• COCOMO Model:

o Cost and effort estimation based on project size and complexity.

• Object-Oriented Estimation: Tailored to projects using classes and objects.

• Agile Estimation: Uses story points and velocity for iterative planning.

• Web Application Estimation: Considers dynamic content, user interaction, security.

4. Human Resource Estimation and Team Structure

• Identify required roles and number of team members.

• Define responsibilities and communication channels.

5. Time Estimation and Scheduling

• Use Time-Line Charts and Gantt Charts for visual scheduling.

 • Track project milestones and deadlines.

• Special scheduling considerations for web app projects due to frequent updates.

6. Make / Buy Decision

• Use Decision Trees to evaluate whether to build software in-house or purchase off-the-shelf
solutions.

• Factors: cost, time, quality, and vendor reliability.

7. Project Monitoring Plan

• Monitor progress with Timesheets and Review Meetings.

• Use Cost Schedule Graphs and Milestone Graphs for tracking budget and timelines.

8. Risk Management

• Identify Risks: Technical, operational, financial, legal.

• Prioritize Risks based on impact and likelihood.

• Mitigate Risks: Strategies to reduce risk impact.

• Monitor and Control: Continuous assessment and response to new risks.

9. Case Study: Planning an E-commerce Website Project

• Scope: Online product catalog, shopping cart, payment gateway.

• Resources: Team of 6 (developers, testers, UI designers).

• Estimation: Use COCOMO to estimate effort, Agile story points for sprints.

• Schedule: 6-month timeline with 4 two-week sprints.

• Risk: Security vulnerabilities, payment gateway integration delays.

• Mitigation: Regular security audits, contingency for third-party API issues.

10. Embedded MCQs

1. What does technical feasibility assess?

A) User acceptance
B) Budget constraints
C) Technology capability
D) Market demand
 2. Which tool is commonly used for scheduling in project planning?
A) Use Case Diagram
B) Gantt Chart
C) Class Diagram
D) Risk Matrix

3. In risk management, what is the first step?

A) Mitigation
B) Prioritization
C) Identification
D) Monitoring

MODULE 5: Software Architecture

Overview

Software architecture defines the high-level structure of a software system — how components
interact and are organized to meet requirements efficiently.

1. Fan-Out and Fan-In

• Fan-Out: Number of modules a single module calls.

• Fan-In: Number of modules that call a particular module (reuse indicator).

• Why Important? Helps understand dependencies and potential reuse or complexity

hotspots.

2. Structural Partitioning

• Horizontal Partitioning: Layered architecture separating concerns such as:

o User Interface (UI) Layer

o Business Logic Layer

o Data Access Layer

• Vertical Partitioning: Partition based on control flow or functionality (e.g., modules

responsible for specific features).

3. Functional Independence

• High Cohesion: Modules perform closely related functions.

 • Low Coupling: Modules have minimal dependencies on each other.

• Aim: Easier maintenance, testing, and evolution.

4. Design Heuristics for Software Architecture

• Limit Fan-Out to reduce complexity.

• Maximize Cohesion to group related functionality.

• Minimize Coupling to reduce module dependencies.

• Use Abstraction and Information Hiding to conceal module internals.

• Design for Changeability and maintain Simple Interfaces.

5. Case Study: Architecture of an Online Banking System

• Layers: Presentation, Business Logic, Data Storage.

• Fan-In: Core security module reused by multiple services.

• Fan-Out: Payment processing module calls multiple external APIs.

• Use of layered structure for scalability and maintainability.

6. Embedded MCQs

1. What does high cohesion in software modules ensure?

A) Increased dependencies
B) Related functionality grouped together
C) More complexity
D) Multiple unrelated tasks

2. Fan-In measures:
A) Number of modules called by a module
B) Number of modules calling a module
C) Lines of code in a module
D) Number of users accessing the module

3. Which structural partitioning separates UI, logic, and data?

A) Vertical Partitioning
B) Horizontal Partitioning
C) Circular Partitioning
D) Functional Partitioning

MODULE 6: Software Design

Overview

Software design transforms requirements and architecture into detailed plans for coding. It focuses
on data structures, components, interfaces, and user experience.

1. Data Design

• Organizing and structuring data to support software functions.

• Choosing appropriate data structures (arrays, lists, trees, hash tables).

• Designing database schemas for persistent data.

2. Architectural Design and Data Flow

• Transform Flow: Sequential transformation of data from input to output.

• Transactional Flow: Control-driven, with decision points influencing flow paths.

• Use data flow diagrams (DFDs) to visualize data movement.

3. Class-Based Component Design

• Core OOP principles:

o Encapsulation: Bundling data and methods.

o Inheritance: Creating new classes from existing ones.

o Polymorphism: Methods behaving differently based on object type.

• Use UML class diagrams to model classes, attributes, methods, and relationships.

• CRC cards help identify class Responsibilities and Collaborators.

4. Component-Level Design for Web Applications

• Client-server architecture: Separating frontend and backend.

• MVC Pattern: Model (data), View (UI), Controller (logic).

• Considerations: security, performance, reusability.

5. User Interface (UI) Design

• Minimize user memory load: prefer recognition over recall.

• Ensure consistency: same patterns and layout throughout the app.

 • Documentation: wireframes and prototypes for user testing.

6. Interface Design Steps

• Identify users and their tasks.

• Define interaction styles (e.g., direct manipulation, form-based).

• Apply UI design patterns (e.g., navigation bars, breadcrumbs).

• Address responsiveness, accessibility, error handling.

• Iterate design through user feedback and testing.

7. Case Study: Online Library Management System Design

• Data Design: Book records, user accounts, borrowing logs.

• Architecture: Client-server with MVC.

• Classes: Book, User, Loan, Notification.

• UI: Search, borrow, return book interfaces.

8. Embedded MCQs

1. What principle bundles data and methods together in OOP?

A) Polymorphism
B) Inheritance
C) Encapsulation
D) Abstraction

2. Which architectural pattern separates data, UI, and logic?

A) Client-Server
B) MVC
C) Layered
D) Pipeline

3. What is a key goal in UI design?

A) Complex interfaces
B) Minimize user memory load
C) Maximize user input
D) Avoid prototypes

MODULE 7: Software Testing

Overview

Testing ensures software works as intended by detecting defects, validating requirements, and
improving reliability.

1. Objectives of Software Testing

• Detect software defects early.

• Verify software meets functional and non-functional requirements.

• Improve software reliability, performance, and user satisfaction.

2. Testing Principles (PIMPLER mnemonic)

• P: Testing shows presence of defects, not their absence.

• I: Impossible to test everything exhaustively.

• M: Early testing saves cost and effort later.

• P: Defects tend to cluster in few modules.

• L: Repeating the same test does not find new defects.

• E: Testing depends on context (project goals, risks).

• R: Error-free code may still not be correct software.

3. Test Case Design Types

• Unit Testing: Testing individual modules/functions.

• Integration Testing: Testing interactions between modules.

• Path Testing: Using control flow to test all possible execution paths.

• Cyclomatic Complexity: Metric to determine number of independent paths to test.

4. Testing Strategy for Object-Oriented Software

• Test classes individually (methods and state).

• Test polymorphic behavior and state transitions.

• Use mock objects to isolate dependencies.

5. Web Application Testing

• Cross-browser compatibility testing.

 • Client-server communication tests.

• Session management and security testing.

6. Validation Testing

• Confirms software meets user requirements.

• Includes functional testing and user acceptance testing (UAT).

7. System Testing Types

• Recovery Testing: Software’s ability to recover from crashes.

• Security Testing: Identify vulnerabilities and protect data.

• Stress Testing: Test under extreme workloads.

• Performance Testing: Check responsiveness and stability.

8. Case Study: E-Commerce Website Testing

• Unit tests for product catalog module.

• Integration tests for payment gateway and order processing.

• Cross-browser UI tests on Chrome, Firefox, Safari.

• Stress tests simulating heavy user load during sales.

Embedded MCQs

1. What does unit testing focus on?

A) Entire system behavior
B) Interaction between modules
C) Individual modules/functions
D) User acceptance

2. Which testing type evaluates software under extreme workload?

A) Performance Testing
B) Stress Testing
C) Recovery Testing
D) Security Testing

3. Why is early testing important?

A) Saves cost and effort later
B) Finds all possible defects immediately
C) Eliminates need for later tests
D) Ensures software is error-free
 MODULE 8: Quality Management

Overview

Quality management ensures software meets requirements, satisfies users, and is reliable,
maintainable, and efficient.

1. What is Software Quality?

• Software that meets requirements and expectations.

• Satisfies users by being functional and user-friendly.

• Is reliable (works correctly over time).

• Is maintainable and efficient.

2. McCall’s Quality Factors

• Operation Factors: correctness, reliability, efficiency, integrity, usability.

• Revision Factors: maintainability, flexibility, testability.

• Transition Factors: portability, reusability, interoperability.

3. ISO 9126 Quality Attributes

• Functionality

• Reliability

• Usability

• Efficiency

• Maintainability

• Portability

4. Achieving Software Quality

• Applying software engineering best practices (coding standards, reviews).

• Strong project management: planning, risk management, periodic reviews.

5. Quality Control vs. Quality Assurance (QA)

• Quality Control: Defect detection via testing, inspections.

• Quality Assurance: Process-focused, proactive approach including standards, audits, training.

6. Software Quality Assurance (SQA)

• Goals: Ensure compliance to standards and prevent defects.

• Tasks: Define standards, perform reviews, plan tests, use metrics.

7. Quality Metrics

• Defect density: Number of defects per unit size.

• Mean Time to Failure (MTTF): Average operational time before failure.

• Test coverage: Percentage of code exercised by tests.

8. Six Sigma in Software Engineering

• DMAIC Cycle: Define, Measure, Analyze, Improve, Control.

• Tools: Control charts, fishbone diagrams, Pareto analysis to improve processes.

9. Case Study: Quality Management in a Banking Software Project

• Use McCall’s factors to set quality goals.

• Apply ISO 9126 for system evaluation.

• Implement SQA with code reviews and automated testing.

• Use Six Sigma tools to reduce defect rates over project phases.

Embedded MCQs

1. Which of the following is NOT a McCall’s quality factor?

A) Usability
B) Maintainability
C) Portability
D) Scalability

2. Quality Assurance focuses on:

A) Finding defects after development
B) Process improvement and defect prevention
C) Testing only
D) Coding standards only

3. What is the main goal of Six Sigma in software?

A) Increase speed of coding
 B) Improve process quality and reduce defects
C) Automate all testing
D) Remove documentation

MODULE 9: Software Configuration Management (SCM)

Overview

SCM is the discipline of tracking and controlling changes in software to maintain integrity and
traceability throughout the software lifecycle.

1. Elements of SCM System

• Configuration Identification: Define items under control (code, documents, test cases).

• Configuration Control: Procedures to manage changes with approvals.

• Status Accounting: Recording and reporting the status of configuration items.

• Configuration Audit: Verify compliance with specifications and standards.

• Build Management: Automating software build and release processes.

2. Baseline

• A baseline is a formally reviewed and agreed-upon version of software or documents used as

a reference point.

3. Software Configuration Items (SCIs)

• Can include: source code, documentation, executables, test scripts, configuration files.

4. SCM Features

• Version Control: Track changes and support branching/merging.

• Change Management: Manage approval and implementation of changes.

• Build and Release Management: Automate and control software builds and deployments.

• Audit and Reporting: Ensure compliance and traceability.

• Access Control and Automation: Secure and streamline SCM processes.

5. SCM Processes

• Version Control: Record every change to configuration items to allow rollback and
concurrent development.

• Change Control: Ensure changes are reviewed and approved before implementation.

• Configuration Audit: Check that configuration items conform to requirements.

• Status Reporting: Regular reports on configuration status to stakeholders.

6. SCM for Web Applications

• Configuration objects include HTML, CSS, JavaScript, media files, and database schemas.

• Content Management Systems (CMS) often integrate SCM features.

• Integration with CI/CD pipelines automates builds, tests, and deployments ensuring rapid
delivery.

7. Case Study: SCM Implementation in E-commerce Platform Development

• Identify SCIs: front-end, back-end code, documentation, test cases.

• Use Git for version control and branching strategy for feature development.

• Apply change control with peer reviews and approval workflows.

• Automate build and deployment with Jenkins (CI/CD).

• Regular configuration audits ensure code quality and deployment consistency.

Embedded MCQs

1. What is the purpose of a baseline in SCM?

A) To provide a starting point for new projects
B) To serve as a formally agreed reference version of software
C) To record defects found in testing
D) To document user requirements

2. Which of the following is NOT an element of SCM?

A) Configuration Audit
B) Status Accounting
C) Code Optimization
D) Configuration Control

3. In web application SCM, what is typically included as configuration items?

A) HTML and CSS files
B) Database schemas
C) JavaScript files
D) All of the above