Software Engineering (4353202) - Summer 2025 Solution

Question 1(a) [3 marks]

#

Enlist Software Application Domain and explain Embedded Software

Answer:

Software Application Domains:

Embedded Software is specialized software that runs on embedded systems with dedicated hardware. It controls specific functions in devices like washing machines, cars, and medical equipment.

• Real-time operation: Must respond within strict time limits
• Resource constraints: Limited memory and processing power
• Hardware dependency: Closely integrated with specific hardware

Mnemonic: “SAEEWA” - System, Application, Engineering, Embedded, Web, AI

Question 1(b) [4 marks]

#

Explain Generic Framework activities and umbrella activities

Answer:

Generic Framework Activities:

Umbrella Activities:

• Framework activities: Core sequential activities in every project
• Umbrella activities: Continuous activities throughout project lifecycle

Mnemonic: “CPMCD” for Framework, “PRQCW” for Umbrella

Question 1(c) [7 marks]

#

Recreate the software development life cycle diagram and explain it’s phases

Answer:

SDLC Diagram:

graph TD
    A[Requirements Analysis] --> B[System Design]
    B --> C[Implementation]
    C --> D[Testing]
    D --> E[Deployment]
    E --> F[Maintenance]
    F --> A

SDLC Phases:

• Systematic approach: Each phase has specific inputs and outputs
• Quality gates: Reviews between phases ensure quality
• Iterative nature: Feedback improves subsequent cycles

Mnemonic: “Real Systems Implement Tests During Maintenance”

Question 1(c) OR [7 marks]

#

List software development models and explain any two models with necessary diagrams

Answer:

Software Development Models:

1. Waterfall Model:

graph TD
    A[Requirements] --> B[Design]
    B --> C[Implementation]
    C --> D[Testing]
    D --> E[Deployment]
    E --> F[Maintenance]

2. Spiral Model:

graph TD
    A[Planning] --> B[Risk Analysis]
    B --> C[Engineering]
    C --> D[Evaluation]
    D --> A

• Waterfall: Simple, suitable for well-understood requirements
• Spiral: Handles high-risk projects with iterative risk assessment

Mnemonic: “WIRRAV” - Waterfall, Iterative, RAD, Risk-driven, Agile, V-model

Question 2(a) [3 marks]

#

Differentiate SCRUM Agile process model with SPIRAL process model

Answer:

• SCRUM: Emphasizes rapid delivery and customer feedback
• SPIRAL: Focuses on risk identification and mitigation

Mnemonic: “SCRUM=Speed, SPIRAL=Safety”

Question 2(b) [4 marks]

#

List requirement gathering techniques and explain anyone

Answer:

Requirement Gathering Techniques:

Interview Technique Explained:

• Structured interviews: Predetermined questions, formal approach
• Unstructured interviews: Open-ended discussion, flexible
• Semi-structured: Combination of both approaches

Benefits: Direct stakeholder input, clarification possible, detailed information Challenges: Time-consuming, interviewer bias, incomplete information

Mnemonic: “IQDPBB” - Interview, Questionnaire, Document, Prototype, Brainstorm, Observe

Question 2(c) [7 marks]

#

Define use case diagram. Explain it with example

Answer:

Use Case Diagram Definition: A use case diagram shows the functional requirements of a system by depicting actors and their interactions with use cases.

Components:

Example: Library Management System

graph LR
    A[Librarian] --> B(Issue Book)
    A --> C(Return Book)
    A --> D(Add Book)
    E[Student] --> B
    E --> C
    E --> F(Search Book)

Relationships:

• Include: Common functionality shared by use cases
• Extend: Optional functionality added to base use case
• Generalization: Inheritance between actors or use cases

Benefits: Clear functional overview, communication tool, basis for testing

Mnemonic: “Actors Use Cases Inside Systems”

Question 2(a) OR [3 marks]

#

Compare Water fall model and Iterative waterfall model

Answer:

• Waterfall: Suitable for stable, well-defined requirements
• Iterative Waterfall: Better for evolving requirements with feedback

Mnemonic: “PFRTFD” - Phases, Feedback, Risk, Testing, Flexibility, Delivery

Question 2(b) OR [4 marks]

#

Define Functional and non-Functional Requirement and give examples of both

Answer:

Functional Requirements: Requirements that define what the system should do - specific behaviors and functions.

Non-Functional Requirements: Requirements that define how the system should perform - quality attributes and constraints.

Functional Examples:

• User authentication and login
• Calculate total bill amount
• Generate monthly reports

Non-Functional Examples:

• System response time < 2 seconds (Performance)
• 99.9% system availability (Reliability)
• Support 1000 concurrent users (Scalability)

Mnemonic: “Functional=What, Non-Functional=How”

Question 2(c) OR [7 marks]

#

Define cohesion. Explain classification of cohesion

Answer:

Cohesion Definition: Cohesion measures how closely related elements within a module are. High cohesion indicates a well-designed module.

Classification of Cohesion (Strongest to Weakest):

graph TD
    A[Functional - Strongest] --> B[Sequential]
    B --> C[Communicational]
    C --> D[Procedural]
    D --> E[Temporal]
    E --> F[Logical]
    F --> G[Coincidental - Weakest]

Goal: Achieve functional cohesion for maintainable, reliable modules

Mnemonic: “Frank’s Smart Cat Plays Tennis Like Crazy”

Question 3(a) [3 marks]

#

List characteristics of good software design

Answer:

Characteristics of Good Software Design:

• High cohesion: Related elements grouped together
• Low coupling: Minimal dependencies between modules
• Reusability: Components can be reused in other systems

Mnemonic: “MAEHSF” - Modularity, Abstraction, Encapsulation, Hierarchy, Simplicity, Flexibility

Question 3(b) [4 marks]

#

Explain Project Estimation Techniques using intermediate COCOMO model

Answer:

Intermediate COCOMO Model: Extends basic COCOMO by considering cost drivers that affect productivity.

Formula: Effort = a × (KLOC)^b × EAF

Cost Drivers:

Effort Adjustment Factor (EAF): EAF = Product of all cost driver multipliers

Steps:

1. Estimate KLOC (thousands of lines of code)
2. Select appropriate a, b values based on project type
3. Evaluate cost drivers (scale 0.70 to 1.65)
4. Calculate EAF
5. Apply formula to get effort in person-months

Mnemonic: “PHPP” - Product, Hardware, Personnel, Project drivers

Question 3(c) [7 marks]

#

Draw and explain level-1 Data flow diagram for Online shopping system

Answer:

Level-1 DFD for Online Shopping System:

Processes:

Data Stores:

• Product Database: Store product information
• Order Database: Store order details
• Customer Database: Store customer profiles

External Entities:

• Customer: Places orders, makes payments
• Payment Gateway: Processes payments
• Inventory Manager: Updates stock levels

Mnemonic: “PPMI” - Process order, Process payment, Manage inventory

Question 3(a) OR [3 marks]

#

Differentiate analysis and design

Answer:

• Analysis: Problem-focused, understanding requirements
• Design: Solution-focused, creating system architecture

Mnemonic: “Analysis=WHAT, Design=HOW”

Question 3(b) OR [4 marks]

#

Explain Project Estimation Techniques using basic COCOMO model

Answer:

Basic COCOMO Model: Estimates software development effort based on lines of code.

Formula:

• Effort = a × (KLOC)^b person-months
• Time = c × (Effort)^d months

Project Types:

Steps:

1. Estimate KLOC (thousands of lines of code)
2. Identify project type (organic/semi-detached/embedded)
3. Apply appropriate coefficients
4. Calculate effort and development time

Example: 10 KLOC organic project

• Effort = 2.4 × (10)^1.05 = 25.2 person-months
• Time = 2.5 × (25.2)^0.38 = 8.4 months

Mnemonic: “OSE” - Organic, Semi-detached, Embedded

Question 3(c) OR [7 marks]

#

Draw and explain Class Diagram for Library Management system

Answer:

Class Diagram for Library Management System:

classDiagram
    class Library {
        +name: String
        +address: String
        +addBook()
        +removeBook()
        +searchBook()
    }
    
    class Book {
        +bookId: String
        +title: String
        +author: String
        +ISBN: String
        +isAvailable: Boolean
        +getDetails()
    }
    
    class Member {
        +memberId: String
        +name: String
        +email: String
        +phone: String
        +issueBook()
        +returnBook()
    }
    
    class Transaction {
        +transactionId: String
        +issueDate: Date
        +returnDate: Date
        +fine: Double
        +calculateFine()
    }
    
    Library ||--o{ Book : contains
    Member ||--o{ Transaction : has
    Book ||--o{ Transaction : involved_in

Relationships:

Key Features:

• Attributes: Data members of each class
• Methods: Functions that operate on class data
• Associations: Relationships between classes showing how they interact

Mnemonic: “LBMT” - Library, Book, Member, Transaction

Question 4(a) [3 marks]

#

List Project Size Estimation Metrics and define them

Answer:

Project Size Estimation Metrics:

Function Points Components:

• External Inputs: Data entry screens
• External Outputs: Reports, messages
• External Inquiries: Interactive queries
• Internal Files: Master files
• External Interfaces: Shared data

Benefits: Early estimation, technology-independent, standardized approach

Mnemonic: “LFFOU” - LOC, Function Points, Feature Points, Object Points, Use Case Points

Question 4(b) [4 marks]

#

Explain Risk identification in detail

Answer:

Risk Identification: Process of finding, recognizing, and describing potential risks that could affect project success.

Risk Categories:

Identification Techniques:

• Brainstorming: Team discussions to identify risks
• Checklists: Standard risk categories review
• Expert judgment: Experience-based identification
• SWOT analysis: Strengths, Weaknesses, Opportunities, Threats

Risk Register: Document containing identified risks with:

• Risk description
• Probability of occurrence
• Impact severity
• Risk category
• Responsible person

Mnemonic: “TPBE” - Technical, Project, Business, External risks

Question 4(c) [7 marks]

#

Prepare Gantt Chart for any system of your choice

Answer:

Gantt Chart for Online Banking System:

Project Tasks:

Benefits: Visual progress tracking, resource allocation, dependency management

Mnemonic: “RSDUBtd” - Requirements, System design, Database, UI, Backend, Testing, Deployment

Question 4(a) OR [3 marks]

#

List Responsibilities of Project manager

Answer:

Project Manager Responsibilities:

Key Activities:

• Project initiation: Define objectives and constraints
• Schedule management: Create and maintain timelines
• Budget control: Monitor costs and expenses
• Quality assurance: Ensure deliverable standards
• Team management: Lead and develop team members

Mnemonic: “POLCR” - Planning, Organizing, Leading, Controlling, Risk management

Question 4(b) OR [4 marks]

#

Explain Risk Assessment in detail

Answer:

Risk Assessment: Process of evaluating identified risks to determine their probability and impact on project success.

Assessment Components:

Risk Assessment Matrix:

Assessment Techniques:

• Qualitative assessment: Descriptive scales (High/Medium/Low)
• Quantitative assessment: Numerical values and calculations
• Expert judgment: Experience-based evaluation
• Historical data: Past project analysis

Risk Categorization:

• High risk (7-9): Immediate attention required
• Medium risk (4-6): Monitor and plan mitigation
• Low risk (1-3): Accept or minimal mitigation

Mnemonic: “PIS” - Probability, Impact, Score

Question 4(c) OR [7 marks]

#

Prepare Sprint burn down chart for any system of your choice

Answer:

Sprint Burn Down Chart for E-commerce Mobile App (2-week Sprint):

Sprint Details:

Key Insights:

• Slope: Progress rate compared to ideal
• Flat areas: Blocked work or scope changes
• Below ideal: Ahead of schedule
• Above ideal: Behind schedule

Mnemonic: “DABC” - Days, Actual, Burn-down, Chart

Question 5(a) [3 marks]

#

List Code Review Techniques and explain anyone

Answer:

Code Review Techniques:

Code Inspection Explained:

Process:

1. Planning: Select code, assign roles
2. Overview: Author explains code structure
3. Preparation: Individual review of code
4. Inspection meeting: Group examines code
5. Rework: Fix identified defects
6. Follow-up: Verify corrections

Roles:

• Moderator: Leads the inspection process
• Author: Code developer, explains logic
• Reviewers: Find defects and issues
• Recorder: Documents findings

Benefits: High defect detection rate, knowledge sharing, improved code quality

Mnemonic: “CWIP” - Code Walkthrough, Inspection, Peer review

Question 5(b) [4 marks]

#

Prepare test cases for online shopping system

Answer:

Test Cases for Online Shopping System:

Detailed Test Case Example:

Test Case ID: TC003 Test Title: Add Product to Shopping Cart Pre-conditions: User is logged in, product is available Test Steps:

1. Navigate to product catalog
2. Select a product
3. Choose quantity
4. Click “Add to Cart” button

Expected Result: Product appears in cart with correct quantity and price Post-conditions: Cart count increases, total amount updates

Mnemonic: “RAULC” - Registration, Authentication, User cart, Login, Checkout

Question 5(c) [7 marks]

#

Define White box technique. List various white box technique. Explain any two

Answer:

White Box Testing Definition: Testing technique that examines internal code structure, logic paths, and implementation details.

White Box Techniques:

1. Statement Coverage: Ensures every executable statement in code is executed at least once.

Formula: (Executed statements / Total statements) × 100%

Example:

if (x > 0)        // Statement 1
    y = x + 1;    // Statement 2
else
    y = x - 1;    // Statement 3
z = y * 2;        // Statement 4

Test Cases: x = 5 (covers statements 1,2,4), x = -1 (covers statements 1,3,4) Coverage: 100% statement coverage achieved

2. Branch Coverage: Ensures every branch (true/false) of decision points is executed.

Example:

if (a > b && c > d)    // Two conditions
    result = 1;        // True branch
else
    result = 0;        // False branch

Test Cases:

• a=5, b=3, c=7, d=2 (true branch)
• a=1, b=3, c=7, d=2 (false branch)

Benefits: Higher defect detection than statement coverage

Mnemonic: “SBPCL” - Statement, Branch, Path, Condition, Loop

Question 5(a) OR [3 marks]

#

Explain software documentation

Answer:

Software Documentation: Written material that describes software system, its design, implementation, and usage.

Types of Documentation:

Internal Documentation:

• Comments: Explain code logic and purpose
• Code structure: Class and method descriptions
• Design rationale: Why specific approaches chosen

External Documentation:

• User manuals: Step-by-step usage instructions
• Installation guides: Setup procedures
• API documentation: Interface specifications

Benefits: Easier maintenance, knowledge transfer, reduced training time

Mnemonic: “IESU” - Internal, External, System, User documentation

Question 5(b) OR [4 marks]

#

Prepare at least 4 test cases for ATM System

Answer:

Test Cases for ATM System:

Detailed Test Case:

Test Case ID: TC003 Test Description: Withdraw cash with sufficient balance Pre-conditions: Valid ATM card, sufficient account balance Test Data: PIN=1234, Withdrawal amount=₹1000, Account balance=₹5000

Post-conditions: Account balance reduced by ₹1000, transaction recorded

Mnemonic: “VPCI” - Valid PIN, PIN error, Cash withdrawal, Insufficient funds

Question 5(c) OR [7 marks]

#

Enlist all black box testing methodologies. Explain why it is known as functional testing? Explain at least 2 methods with diagram

Answer:

Black Box Testing Methodologies:

Why called Functional Testing? Black box testing focuses on what the system does rather than how it works. It validates functional requirements by testing inputs and expected outputs without knowledge of internal code structure.

1. Equivalence Partitioning:

Example: Age validation for job application

• Valid partition: 18-65 years
• Invalid partitions: <0, 0-17, 66-120, >120
• Test cases: One from each partition (e.g., 25, -5, 10, 70, 130)

2. Boundary Value Analysis:

Example: Student score validation (0-100)

• Test values: -1, 0, 1, 50, 99, 100, 101
• Focus: Just inside and outside boundaries
• Rationale: Most errors occur at boundaries

Benefits:

• Independence: No programming knowledge required
• User perspective: Tests from user’s viewpoint
• Requirement validation: Verifies functional specifications

Mnemonic: “EBDSUE” - Equivalence, Boundary, Decision, State, Use case, Error guessing